descriptions; any use of SRTP needs to consider them.
The second constraint is that the ROC MUST be zero at the time that
each SSRC commences sending packets. Thus, there is no concept of a
"late joiner" in SRTP security descriptions, which are constrained to
be unicast and pairwise. The ROC and SEQ form a "packet index" in
the default SRTP transforms and the ROC is consistently set to zero
at session commencement, according to this document.
The third constraint is that the initial value of SEQ SHOULD be
chosen to be within the range of 0..2^15-1; this avoids an ambiguity
when packets are lost at the start of the session. If it is at the
start of a session, an SSRC source might randomly select a high
sequence-number value and put the receiver in an ambiguous situation:
if initial packets are lost in transit up to the point that the
sequence number wraps (i.e., exceeds 2^16-1), then the receiver might
not recognize that its ROC needs to be incremented. By restricting
the initial SEQ to the range of 0..2^15-1, SRTP packet-index
determination will find the correct ROC value, unless all the first
2^15 packets are lost (which seems, if not impossible, rather
unlikely). See Section 3.3.1 of the SRTP specification regarding
packet-index determination [RFC3711].
6.4.1. Late Binding of One or More SSRCs to a Crypto Context
The packet index, therefore, depends on the SSRC, the SEQ of an
incoming packet, and the ROC, which is an SRTP crypto context
variable. Thus, SRTP has a big security dependency on SSRC
uniqueness.
Given the above constraints, unicast SRTP crypto contexts can be
established without the need to negotiate SSRC values in the SRTP
security descriptions. Instead, an approach called "late binding" is
RECOMMENDED by this specification. When a packet arrives, the SSRC
that is contained in it can be bound to the crypto context at the
time of session commencement (i.e., SRTP packet arrival) rather than
at the time of session signaling (i.e., receipt of an SDP). With the
arrival of the packet containing the SSRC, all the data items needed
for the SRTP crypto context are held by the receiver. (Note that the
ROC value by definition is zero; if non-zero values were to be
supported, additional signaling would be required.) In other words,
the crypto context for a secure RTP session using late binding is
initially identified by the SDP as
<*, address, port>
where ’*’ is a wildcard SSRC, "address" is the local receive address
from the "c=" line, and "port" is the local receive port from the
"m=" line. When the first packet arrives with ssrcX in its SSRC
field, the crypto context
<ssrcX, address, port>
is instantiated subject to the following constraints:
* Media packets are authenticated: authentication MUST succeed;
otherwise, the crypto context is not instantiated.
* Media packets are not authenticated: crypto context is
automatically instantiated.
Note that use of late binding when there is no authentication of the
SRTP media packets is subject to numerous security attacks, and that
consequently it is NOT RECOMMENDED (of course, this can be said for
unauthenticated SRTP in general).
Note that use of late binding without authentication will result
in the creation of local state as a result of receiving a packet
from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore, is NOT
RECOMMENDED because it invites easy denial-of-service attack. In
contrast, late binding with authentication does not suffer from
this weakness.
6.4.2. Sharing Cryptographic Contexts among Sessions or SSRCs
With the constraints and procedures described above, it is not
necessary to explicitly signal the SSRC, ROC, and SEQ for a unicast
RTP session. So there are no a=crypto parameters for signaling SSRC,
ROC, or SEQ. Thus, multiple SSRCs from the same entity will share
a=crypto parameters when late binding is used. Multiple SSRCs from
the same entity arise due to either multiple sources (microphones,
cameras, etc.) or RTP payloads requiring SSRC multiplexing within
that same session. SDP also allows multiple RTP sessions to be
defined in the same media description ("m="); these RTP sessions will
also share the a=crypto parameters. An application that uses
a=crypto in this way serially shares a master key among RTP sessions
or SSRCs and MUST replace the master key when the aggregate number of
packets among all SSRCs approaches 2^31 packets. SSRCs that share a
master key MUST be unique from one another.
6.5. Removal of Crypto Contexts
The mechanism defined above addresses the issue of creating crypto
contexts. However, in practice, session participants may want to
remove crypto contexts prior to session termination. Since a crypto
context contains information that cannot automatically be recovered
(e.g., ROC), it is important that the sender and receiver agree on
when a crypto context can be removed, and perhaps more importantly
when it cannot.
Even when late binding is used for a unicast stream, the ROC is
lost and cannot be recovered automatically (unless it is zero)
once the crypto context is removed.
We resolve this problem as follows. When SRTP security descriptions
are being used, crypto-context removal MUST follow the same rules as
SSRC removal from the member table [RFC3550]; note that this can
happen as the result of an SRTCP BYE packet or a simple time-out due
to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals.
7. SRTP-Specific Use of the Crypto Attribute
Section 5 describes general use of the crypto attribute, and this
section completes it by describing SRTP-specific use.
7.1. Use with Offer/Answer
In this section, we describe how the SRTP security descriptions are
used with the offer/answer model to negotiate cryptographic
capabilities and communicate SRTP master keys. The rules defined
below complement the general offer/answer rules defined in Section
5.1, which MUST be followed, unless otherwise specified. Note that
the rules below define unicast operation only; support for multicast
and multipoint unicast streams is for further study.
7.1.1. Generating the Initial Offer - Unicast Streams
When the initial offer is generated, the offerer MUST follow the
steps in Section 5.1.1, as well as the following steps.
For each unicast media line (m=) using the secure RTP transport where
the offerer wants to specify cryptographic parameters, the offerer
MUST provide at least one valid SRTP security description ("a=crypto"
line), as defined in Section 6. If the media stream includes Forward
Error Correction with a different IP-address and/or port from that of
the media stream itself, an FEC_KEY parameter MUST be included, as
described in Section 6.3.5.
The inline parameter conveys the SRTP master key used by an endpoint
to encrypt the SRTP and SRTCP streams transmitted by that endpoint.
The same key is used by the recipient to decrypt those streams.
However, the receiver MUST NOT use that same key for the SRTP or
SRTCP packets that it sends to the session because the default SRTP
cipher and mode is insecure when the master key is reused across
distinct SRTP streams.
The offerer MAY include one or more other SRTP session parameters, as
defined in Section 6.3. Note, however, that if any SRTP session
parameters are included that are not known to the answerer, but that
are nonetheless mandatory (see Section 6.3.6), the negotiation will
fail if the answerer does not support them.
7.1.2. Generating the Initial Answer - Unicast Streams
When the initial answer is generated, the answerer MUST follow the
steps in Section 5.1.2, as well as the following steps.
For each unicast media line that uses the secure RTP transport and
contains one or more "a=crypto" lines in the offer, the answerer MUST
either accept one (and only one) of the crypto lines for that media
stream, or it MUST reject the media stream. Only "a=crypto" lines
that are considered valid SRTP security descriptions, as defined in
Section 6, can be accepted. Furthermore, all parameters (crypto-
suite, key parameter, and mandatory session parameters) MUST be
acceptable to the answerer in order for the offered media stream to
be accepted. Note that if the media stream includes Forward Error
Correction with a different IP-address and/or port from that of the
media stream itself, an FEC_KEY parameter MUST be included, as
described in Section 6.3.5.
When the answerer accepts an SRTP unicast media stream with a crypto
line, the answerer MUST include one or more master keys appropriate
for the selected crypto algorithm; the master key(s) included in the
answer MUST be different from those in the offer.
When the master key(s) are not shared between the offerer and
answerer, SSRC collisions between the offerer and answerer will
not lead to keystream reuse, and hence SSRC collisions do not
necessarily have to be prevented.
If Forward Error Correction to a separate IP-address and/or port is
included, the answer MUST include an FEC_KEY parameter, as described
in Section 6.3.5.
Declarative session parameters may be added to the answer as usual;
however, the answerer SHOULD NOT add any mandatory session parameter
(see Section 6.3.6) that might be unknown to the offerer.
If the answerer cannot find any valid crypto line that it supports,
or if its configured policy prohibits any cryptographic key parameter
(e.g., key length) or cryptographic session parameter (e.g., KDR,
FEC_ORDER), it MUST reject the media stream, unless it is able to
successfully negotiate use of SRTP by other means outside the scope
of this document (e.g., by use of MIKEY [mikey]).
7.1.3. Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in
Section 5.1.3, as well as the following steps for each SRTP media
stream it offered with one or more crypto lines in it.
If the media stream was accepted and it contains a crypto line, it
MUST be checked that the crypto line is valid according to the
constraints specified in Section 6 (including any FEC constraints).
If the offerer either does not support or is not willing to honor one
or more of the SRTP parameters in the answer, the offerer MUST
consider the crypto line invalid.
If the crypto line is not valid, or the offerer’s configured policy
prohibits any cryptographic key parameter (e.g., key length) or
cryptographic session parameter, the SRTP security negotiation MUST
be deemed to have failed.
7.1.4. Modifying the Session
When a media stream using the SRTP security descriptions has been
established and a new offer/answer exchange is performed, the offerer
and answerer MUST follow the steps in Section 5.1.4, as well as the
following steps.
When modifying the session, all negotiated aspects of the SRTP media
stream can be modified. For example, a new crypto suite can be used
or a new master key can be established. As described in RFC 3264,
when a new offer/answer exchange is made, there will be a window of
time where the offerer and the answerer must be prepared to receive
media according to both the old and new offer/answer exchange.
This requirement applies here as well; however, the following should
be noted:
* When authentication is not being used, it may not be possible for
either the offerer or answerer to determine if a given packet is
encrypted according to the old or new offer/answer exchange. RFC
3264 defines a couple of techniques to address this problem, e.g.,
changing the payload types used and/or the transport addresses.
Note, however, that a change in transport addresses may have an
impact on quality of service as well as on firewall and NAT
traversal. The SRTP security descriptions use the MKI to deal
with this (which adds a few bytes to each SRTP packet), as
described in Section 6.1. For further details on the MKI, please
refer to [RFC3711].
* If the answerer changes its master key, the offerer will not be
able to process packets secured via this master key until the
answer is received. This could be addressed by using a security
"precondition" [sprecon].
If the offerer includes an IP address and/or port that differs from
that used previously for a media stream (or FEC stream), the offerer
MUST include a new master key with the offer (and in so doing, it
will be creating a new crypto context where the ROC is set to zero).
Similarly, if the answerer includes an IP address and/or port that
differs from that used previously for a media stream (or FEC stream),
the answerer MUST include a new master key with the answer (and hence
create a new crypto context with the ROC set to zero). The reason
for this is that when the answerer receives an offer or the offerer
receives an answer with an updated IP address and/or port, it is not
possible to determine if the other side has access to the old crypto
context parameters (and in particular the ROC). For example, if one
side is a decomposed media gateway, or if a SIP back-to-back user
agent is involved, it is possible that the media endpoint changed and
no longer has access to the old crypto context. By always requiring
a new master key in this case, the answerer/offerer will know that
the ROC is zero for this offer/answer, and any key lifetime
constraints will trivially be satisfied too. Another consideration
here applies to media relays; if the relay changes the media endpoint
on one side transparently to the other side, the relay cannot operate
as a simple packet reflector but will have to actively engage in SRTP
packet processing and transformation (i.e., decryption and re-
encryption, etc.).
Finally, note that if the new offer is rejected, the old crypto
parameters remain in place.
7.1.5. Offer/Answer Example
In this example, the offerer supports two crypto suites (f8 and AES).
The a=crypto line is actually one long line, although it is shown as
two lines in this document due to page formatting. The f8 example
shows two inline parameters; as explained in Section 6.1, there may
be one or more key (i.e., inline) parameters in a crypto attribute.
In this way, multiple keys are offered to support key rotation using
a Master Key Identifier (MKI).
Offerer sends:
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP
Answerer replies:
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
In this case, the session would use the AES_CM_128_HMAC_SHA1_80
crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80
were selected by the answerer, there would be two inline keys
associated with the SRTP cryptographic context. One key has an MKI
value of 1 and the second has an MKI of 2.
7.2. SRTP-Specific Use Outside Offer/Answer
Use of SRTP security descriptions outside the offer/answer model is
not defined.
Use of SRTP security descriptions outside the offer/answer model
could have been defined for sendonly media streams; however, there
would not be a way to indicate the key to use for SRTCP by the
receiver of said media stream.
7.3. Support for SIP Forking
As mentioned earlier, the security descriptions defined here do not
support multicast media streams or multipoint unicast streams.
However, in the SIP protocol, it is possible to receive several
answers to a single offer due to the use of forking (see [SIP]).
Receiving multiple answers leads to a couple of problems for the SRTP
security descriptions:
* Different answerers may choose different ciphers, keys, etc.;
however, there is no way for the offerer to associate a particular
incoming media packet with a particular answer.
* Two or more answerers may pick the same SSRC, and hence the SSRC
collision problems mentioned earlier may arise.
As stated earlier, the above point-to-multipoint cases are outside
the scope of the SDP security descriptions. However, there are still
ways of supporting SIP forking, e.g., by changing the multipoint
scenario resulting from SIP forking into multiple two-party unicast
cases. This can be done as follows:
For each answer received beyond the initial answer, issue a new offer
to that particular answerer using a new receive transport address (IP
address and port); note that this requires support for the SIP UPDATE
method [RFC3311]. Also, to ensure that two media sessions are not
inadvertently established prior to the UPDATE being processed by one
of them, use security preconditions [sprecon].
Finally, note that all SIP User Agents that received the offer will
know the key(s) being proposed by the initial offer. If the offerer
wants to ensure security with respect to all other User Agents that
may have received the offer, a new offer/answer exchange with a new
key needs to be performed with the answerer as well. Note that the
offerer cannot determine whether a single or multiple SIP User Agents
received the offer, since intermediate forking proxies may only
forward a single answer to the offerer.
The above description is intended to suggest one possible way of
supporting SIP forking. There are many details missing and it should
not be considered a normative specification. Alternative approaches
may also be possible
7.4. SRTP-Specific Backwards Compatibility Considerations
It is possible that the answerer supports the SRTP transport and
accepts the offered media stream, but that it does not support the
crypto attribute defined here. The offerer can recognize this
situation by seeing an accepted SRTP media stream in the answer that
does not include a crypto line. In that case, the security
negotiation defined here MUST be deemed to have failed.
Also, if a media stream with a given SRTP transport (e.g.,
"RTP/SAVP") is sent to a device that does not support SRTP, that
media stream will be rejected.
7.5. Operation with KEYMGT= and k= lines
An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt].
Per SDP rules, the answerer will ignore attribute lines that it does
not understand. If the answerer supports both "a=crypto" and
"a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt",
but not both, as including both is undefined.
An offer MAY include both "a=crypto" and "k=" lines [RFC4566]. Per
SDP rules, the answerer will ignore attribute lines it does not
understand. If the answerer supports both "a=crypto" and "k=", the
answer MUST include either "a=crypto" or "k=" but not both, as
including both is undefined.
8. Security Considerations
Like all SDP messages, SDP messages containing security descriptions
are conveyed in an encapsulating application protocol (e.g., SIP,
MGCP). It is the responsibility of the encapsulating protocol to
ensure the protection of the SDP security descriptions. Therefore,
IT IS REQUIRED that the application invoke its own security
mechanisms (e.g., secure multiparts such as S/MIME [smime]) or,
alternatively, utilize a lower-layer security service (e.g., TLS or
IPsec). IT IS REQUIRED that this security service provide strong
message authentication and packet-payload encryption, as well as
effective replay protection.
"Replay protection" is needed against an attacker that has enough
access to the communications channel to intercept messages and to
deliver copies to the destination. A successful replay attack will
cause the recipient to perform duplicate processing on a message; the
attack is worse when the duped recipient sends a duplicate reply to
the initiator. Replay protections are not found in S/MIME or in the
other secure-multiparts standard, PGP/MIME. S/MIME and PGP/MIME,
therefore, need to be augmented with some replay-protection mechanism
that is appropriate to the encapsulating application protocol (e.g.,
SIP, MGCP). Three common ways to provide replay protection are to
place a sequence number in the message, to use a timestamp, or for
the receiver to keep a hash of the message to be compared with
incoming messages. There typically needs to be a replay "window" and
some policy for keeping state information from previous messages in a
"replay table" or list.
The discussion that follows uses "message authentication" and
"message confidentiality" in a manner consistent with SRTP [RFC3711].
"Message confidentiality" means that only the holder of the secret
decryption key can access the plain-text content of the message. The
decryption key is the same key as the encryption key, using SRTP
counter mode and f8 encryption transforms, which are vulnerable to
message tampering and need SRTP message authentication to detect such
tampering. "Message authentication" and "message integrity
validation" generally mean the same thing in IETF security standards:
an SRTP message is authenticated following a successful HMAC
integrity check [RFC3711], which proves that the message originated
from the holder of an SRTP master key and was not altered en route.
Such an "authentic" message, however, can be captured by an attacker
and "replayed" when the attacker re-inserts the packet into the
channel. A replayed packet can have a variety of bad effects on the
session, and SRTP uses the extended sequence number to detect
replayed SRTP packets [RFC3711].
The SRTP specification identifies which services and features are
default values that are normative-to-implement (such as
AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32).
8.1. Authentication of Packets
Security descriptions as defined herein signal security services for
RTP packets. RTP messages are vulnerable to a variety of attacks,
such as replay and forging. To limit these attacks, SRTP message
integrity mechanisms SHOULD be used (SRTP replay protection is always
enabled).
8.2. Keystream Reuse
SRTP security descriptions signal configuration parameters for SRTP
sessions. Misconfigured SRTP sessions are vulnerable to attacks on
their encryption services when running the crypto suites defined in
Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is
"misconfigured" when two or more media streams are encrypted using
the same keystream of AES blocks. When senders and receivers share
derived session keys, SRTP requires that the SSRCs of session
participants serve to make their corresponding keystreams unique,
which is violated in the case of SSRC collision: SRTP SSRC collision
drastically weakens SRTP or SRTCP payload encryption during the time
that identical keystreams are used [RFC3711]. An attacker, for
example, might collect SRTP and SRTCP messages and await a collision.
This attack on the AES-CM and AES-f8 encryption is avoided entirely
when each media stream has its own unique master key in both the send
and receive direction. This specification restricts use of SDP
security description to unicast point-to-point streams so that keys
are not shared between SRTP hosts, and the master keys used in the
send and receive direction for a given media stream are unique.
8.3. Signaling Authentication and Signaling Encryption
There is no reason to incur the complexity and computational expense
of SRTP, however, when its key establishment is exposed to
unauthorized parties. In most cases, the SRTP crypto attribute and