1 - 2 - 3 - 8 - A - B - C - D - E - F - G - H - I - J - K - L - M - N - O - P - R - S - T - U - V - W - X
RTP
Click on the red underlined text to get to the source
... SRTP), a profile of the Real-time Transport Protocol (RTP), which
can provide confidentiality, message authentication ...
... confidentiality, message authentication, and replay
protection to the RTP traffic and to the control traffic for RTP ...
... RTP traffic and to the control traffic for RTP,
RTCP (the Real-time Transport Control Protocol ...
... encryption and message authentication
of RTP and RTCP streams (Section 3). SRTP defines a set of default
...
... and an "implicit" index for sequencing/synchronization based on the
RTP sequence number for SRTP and an index number for Secure RTCP ...
... erroneous alteration of RTCP messages could otherwise disrupt the
processing of the RTP stream).
Other, functional, goals for the protocol are:
...
... network, and physical
layers used by RTP, in particular high tolerance to packet loss
and re-ordering.
...
... These properties ensure that SRTP is a suitable protection scheme for
RTP/RTCP in both wired and wireless scenarios.
...
... profile of RTP. This profile is an extension to the RTP
Audio/Video Profile [RFC3551]. Except where explicitly noted, all
...
... security
features. Conceptually, we consider SRTP to be a "bump in the stack"
implementation which resides between the RTP application and the
transport layer. SRTP ...
... transport layer. SRTP intercepts RTP packets and then forwards an
equivalent SRTP packet on the sending side, and intercepts SRTP
packets ...
... equivalent SRTP packet on the sending side, and intercepts SRTP
packets and passes an equivalent RTP packet up the stack on the
receiving side.
...
... thereby protects the RTCP fields to keep track of membership, provide
feedback to RTP senders, or maintain packet sequence counters. SRTCP ...
... Secure RTP ...
... | .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ...
... payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
...
... | | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP ...
... SRTP packet consists of the encryption
of the RTP payload (including RTP padding when present) of the
equivalent RTP packet ...
... encryption
of the RTP payload (including RTP padding when present) of the
equivalent RTP packet. The Encrypted ...
... RTP payload (including RTP padding when present) of the
equivalent RTP packet. The Encrypted Portion MAY be the exact size
of the plaintext ...
... Encrypted Portion MAY be the exact size
of the plaintext or MAY be larger. Figure 1 shows the RTP payload
including any possible padding for RTP [RFC3550 ...
... plaintext or MAY be larger. Figure 1 shows the RTP payload
including any possible padding for RTP [RFC3550].
...
... None of the pre-defined encryption transforms uses any padding; for
these, the RTP and SRTP payload sizes match exactly. New transforms
...
... SRTP (following Section 6) may require padding, and may
hence produce larger payloads. RTP provides its own padding format
(as seen in Fig. 1), which due to the padding indicator in the RTP
header has merits in terms of compactness relative to paddings using
...
... payloads. RTP provides its own padding format
(as seen in Fig. 1), which due to the padding indicator in the RTP
header has merits in terms of compactness relative to paddings using
prefix-free codes. This RTP ...
... RTP
header has merits in terms of compactness relative to paddings using
prefix-free codes. This RTP padding SHALL be the default method for
transforms requiring padding. Transforms MAY specify other padding
...
... authentication tag are the only
fields defined by SRTP that are not in RTP. Only 8-bit alignment is
assumed.
...
... Authenticated Portion of an SRTP packet
consists of the RTP header followed by the Encrypted
Portion of the SRTP packet ...
... authentication tag provides
authentication of the RTP header and payload, and it
indirectly provides replay protection ...
... ROC), which records how many
times the 16-bit RTP sequence number has been reset to zero after
passing through 65,535. Unlike the sequence number ...
... bit sequence number s_l, which can be
thought of as the highest received RTP sequence number (see
Section 3.3.1 for its handling), which SHOULD be authenticated ...
... In addition, there can be cases (see Sections 8 and 9.1) where
several SRTP streams within a given RTP session, identified by their
synchronization source (SSRCs ...
... synchronization source (SSRCs, which is part of the RTP header),
share most of the crypto context parameters (including possibly
...
...
Recall that an RTP session for each participant is defined [RFC3550]
by a pair of destination transport ...
... RTCP), and that a multimedia session is
defined as a collection of RTP sessions. For example, a particular
multimedia session could include an audio ...
... multimedia session could include an audio RTP session, a video RTP
session, and a text RTP session.
...
... multimedia session could include an audio RTP session, a video RTP
session, and a text RTP session.
...
... port may not be
directly deducible from the RTP port only. Alternatively, the key
management may choose to provide separate SRTP- and SRTCP ...
... distinct transforms, if so desired. Similar considerations arise
when multiple SRTP streams, forming part of one single RTP session,
share keys and other parameters.
...
... cryptographic context, and the
sequence number in the RTP packet, as described in Section 3.3.1.
3. Determine the master key and master salt. This is done using the
...
...
5. Encrypt the RTP payload to produce the Encrypted Portion of the
packet (see Section 4.1, for the defined ciphers). This step uses
...
...
Receiver-side implementations use the RTP sequence number to
determine the correct index of a packet, which is the location of the
...
... counter requires its handling and use to
be well defined. In particular, out-of-order RTP packets with
sequence numbers close to 2^16 or zero must be properly handled.
...
... need to be 2^15 packets out of sequence before synchronization is
lost. Such drastic loss or reorder is likely to disrupt the RTP
application itself.
...
... to be lost, e.g., when the initial sequence number (randomly chosen
by RTP) is not known in advance (not sent in the key management
protocol) but may be near to wrap modulo 2^16.
...
...
A more elaborate and more robust scheme than the one given above is
the handling of RTP's own "rollover counter", see Appendix A.1 of
[RFC3550 ...
... integrity protection
is present. It is RECOMMENDED to use replay protection, both for RTP
and RTCP, as integrity protection ...
...
Secure RTCP follows the definition of Secure RTP. SRTCP adds three
mandatory new fields (the SRTCP ...
... Message authentication for RTCP is REQUIRED, as it is the control
protocol (e.g., it has a BYE packet) for RTP.
Precautions must be taken so that the packet expansion ...
... keystream segment encrypts a single RTP packet. The process of
encrypting a packet consists of generating the keystream segment ...
... keystream segment onto the payload of the RTP packet to produce the
Encrypted Portion of the SRTP packet ...
... +---------------------------------+ v
| Payload of RTP Packet |->(*)
+---------------------------------+ |
|
...
... keystream generators are defined. The NULL cipher is also defined,
to be used when encryption of RTP is not required.
The SRTP ...
... SSRC allows the use of the same key to protect
distinct SRTP streams within the same RTP session, see the security
caveats in Section 9.1.
...
... bits of keystream
needed to encrypt the largest possible RTP packet (except for IPv6
"jumbograms ...
... "jumbograms" [RFC2675], which are not likely to be used for RTP-based
multimedia traffic). This restriction on the maximum bit ...
... IV
are distinct for any particular key. The failure to ensure this
uniqueness could be catastrophic for Secure RTP. This is in contrast
to the situation for RTP itself, which may be able to tolerate such
...
... uniqueness could be catastrophic for Secure RTP. This is in contrast
to the situation for RTP itself, which may be able to tolerate such
failures. It is RECOMMENDED that, if a dedicated security module is
...
... failures. It is RECOMMENDED that, if a dedicated security module is
present, the RTP sequence numbers and SSRC either be generated or
...
... AES as a block cipher to be used in what we shall call "f8-mode of
operation" RTP encryption. The AES f8-mode SHALL use the same
...
... AES-f8 to be used
when a master key is shared between multiple streams within the same
RTP session, see Section 9.1.
...
...
The NULL cipher is used when no confidentiality for RTP/RTCP is
requested. The keystream can be thought of as "000..0", i.e., the
...
... DOA) for multicast and group RTP sessions is a hard problem that
needs a solution; while some promising proposals are being
investigated [PCST1 ...
...
The presence of mixers and translators does not allow data origin
authentication in case the RTP payload and/or the RTP header are
manipulated. Note that these types of middle entities also disrupt
...
... The presence of mixers and translators does not allow data origin
authentication in case the RTP payload and/or the RTP header are
manipulated. Note that these types of middle entities also disrupt
end-to-end ...
... confidentiality (as the IV formation depends e.g., on the
RTP header preservation). A certain trust model may choose to trust
...
... RFC3095]. A typical voice application produces 20 byte
samples, and the RTP, UDP and IP headers need to be jointly
...
... SRTP implementation SHOULD be
given the SSRC and MAY be given the initial RTP sequence number for
the RTP stream ...
... key management (thus, key management has a
dependency on RTP operational parameters). Sending the RTP sequence
number in the key management ...
... key management has a
dependency on RTP operational parameters). Sending the RTP sequence
number in the key management may be useful e.g., when the initial
sequence number ...
... same master key between SRTP/SRTCP streams belonging to the same RTP
session.
First, sharing between SRTP ...
...
First, sharing between SRTP streams belonging to the same RTP session
is secure if the design of the synchronization mechanism, i.e., the
...
... IV, avoids keystream re-use (the two-time pad, Section 9.1). This is
taken care of by the fact that RTP provides for unique SSRCs for
streams belonging to the same RTP session ...
... RTP provides for unique SSRCs for
streams belonging to the same RTP session. See Section 9.1 for
further discussion.
...
... SRTP and SRTCP corresponding to
one RTP session MAY share master keys (as they do by default).
Note that message authentication ...
... bits. However, its use
SHOULD be limited to specific, very simple scenarios. We recommend
to limit its use when the RTP session is a simple unidirectional or
bi-directional ...
... stream. This is because in case of multiple streams,
it is difficult to trigger the re-key based on the <From, To> of a
single RTP stream. For example, if several streams share a master
key, there is no simple one-to-one ...
... requiring the key, or some other parameter of cryptographic
significance, to be unique per RTP/RTCP stream and packet. The pre-
...
... CM and AES-f8) allow master keys to
be shared across streams belonging to the same RTP session by the
inclusion of the SSRC in the IV ...
... SSRC in the IV. A master key MUST NOT be shared
among different RTP sessions.
Thus, the SSRC ...
...
Thus, the SSRC MUST be unique between all the RTP streams within the
same RTP session that share the same master key. RTP ...
... SSRC MUST be unique between all the RTP streams within the
same RTP session that share the same master key. RTP itself provides
an algorithm ...
... RTP streams within the
same RTP session that share the same master key. RTP itself provides
an algorithm for detecting SSRC ...
... an algorithm for detecting SSRC collisions within the same RTP
session. Thus, temporary collisions could lead to temporary two-time
pad, in the unfortunate event that SSRCs collide at a point in time
...
... start to transmit simultaneously, before SSRC collision are detected
at the RTP level.
Note also that even with distinct SSRCs ...
...
As described, master keys MAY be shared between streams belonging to
the same RTP session, but it is RECOMMENDED that each SSRC have its
own master key. When master keys are shared among SSRC ...
... Note: in most typical applications (assuming at least one RTCP packet
for every 128,000 RTP packets), it will be the SRTCP index that first
reaches the upper limit, although the time until this occurs is very
...
... Note that if the master key is to be shared between SRTP streams
within the same RTP session (Section 9.1), although the above bounds
are on a per stream (i.e., per SSRC ...
... Confidentiality of the RTP Payload ...
... information deducible from this) will leak, but nothing else.
As some RTP packet could contain highly predictable data, e.g., SID,
it is important to use a cipher designed to resist known plaintext ...
... Confidentiality of the RTP Header ...
...
In SRTP, RTP headers are sent in the clear to allow for header
compression. This means that data such as payload type,
...
... identifier, and timestamp are available to an
eavesdropper. Moreover, since RTP allows for future extensions of
headers, we cannot foresee what kind of possibly sensitive
...
... bit key,
or a message authentication code with equivalent strength. Secure
RTP SHOULD NOT be used without message authentication, except under
the circumstances described in this section. It is important to note
...
...
Weak authentication is acceptable when the RTP application is such
that the effect of a small fraction of successful forgeries is
...
... negligible. If the application is stateless, then the effect of a
single forged RTP packet is limited to the decoding of that
particular packet. Under this condition, the size of the
authentication tag ...
... authentication tag MUST ensure that only a negligible fraction of the
packets passed to the RTP application by the SRTP receiver can be
...
... forgeries. This fraction is negligible when an adversary, if given
control of the forged packets, is not able to make a significant
impact on the output of the RTP application (see the example of
Section 7.5).
...
... ciphertext so that it decrypts to an
intelligible value. One important case is when it is difficult for
an adversary to acquire the RTP plaintext data, since for many
codecs ...
...
Weak or null authentication MUST NOT be used when the RTP application
makes data forwarding or access control ...
... makes data forwarding or access control decisions based on the RTP
data. In such a case, an attacker may be able to subvert
...
... denial of service attack, though in the
absence of message authentication, the RTP application will have
inputs that are bit-wise correlated with the true value. Some
...
... tunnel mode
(respectively, transport mode). When Secure RTP is used without
message authentication ...
... attack [V02] shows that this is indeed the case for
the standard RTP padding as discussed in reference to Figure 1, when
used together with CBC mode. Later transform additions to SRTP ...
... IV formation of the f8-mode gives implicit authentication (IHA)
of the RTP header, even when message authentication is not used.
When IHA is used, an attacker ...
... message authentication is not used.
When IHA is used, an attacker that modifies the value of the RTP
header will cause the decryption process at the receiver to produce
...
...
Consider one bi-directional RTP stream, as one RTP session. It is
possible for the two parties to share the same master key in the two
...
... Consider one bi-directional RTP stream, as one RTP session. It is
possible for the two parties to share the same master key in the two
directions according to the principles of Section 9.1. The first
...
... The same considerations can be extended to the unicast scenario with
multiple RTP sessions, where each session would have a distinct
master key.
...
... setups with the distribution of master keys among the receivers.
Given a single RTP session, one possibility is that the receivers
share the same master key as per Section 9.1 to secure all their
...
... SRTP/SRTCP stream (within the same RTP
session) that share the master key, the upper limit of 2^48 SRTP
packets / 2^31 SRTCP packets means that, before one of the streams
...
... removed during a multicast RTP session), or for pure cryptographic
reasons (e.g., the key is at the end of its lifetime ...
...
- If multiple SRTP streams in the same RTP session share the same
master key, also moderate rate re-keying MAY have the same
...
... Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC 3550std64 ...
... Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551std65, July 2003. ...
... RObust Header Compression: Framework and Four Profiles: RTP, UDP, ESP, and uncompressed (ROHC ...
... ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC 3242prop(-> 4362prop), April 2002. ...
... header : 806e5cba50681de55c621599
RTP packet payload : 70736575646f72616e646f6d6e657373
20697320746865206e65787420626573
...