answer has been received.
5.1.3. Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, the offerer MUST verify that
one of the initially offered crypto suites and its accompanying tag
were accepted and echoed in the answer. Also, the answer MUST
include one or more keys, which will be used for media sent from the
answerer to the offerer.
If the offer contained any mandatory negotiated session parameters
(see Section 6.3.7), the offerer MUST verify that said parameters are
included in the answer and support them. If the answer contains any
mandatory declarative session parameters, the offerer MUST be able to
support those.
If any of the above fails, the negotiation MUST fail.
5.1.4. Modifying the Session
Once a media stream has been established, it MAY be modified at any
time, as described in RFC 3264, Section 8. Such a modification MAY
be triggered by the security service, e.g., in order to perform a
re-keying or change the crypto-suite. If media stream security using
the general security descriptions defined here is still desired, the
crypto attribute MUST be included in these new offer/answer
exchanges. The procedures are similar to those defined in Section
5.1.1, 5.1.2, and 5.1.3 of this document, subject to the
considerations provided in RFC 3264, Section 8.
5.2. Use Outside Offer/Answer
The crypto attribute can also be used outside the context of
offer/answer where there is no negotiation of the crypto suite,
cryptographic key, or session parameters. In this case, the sender
determines security parameters for the stream. Since there is no
negotiation mechanism, the sender MUST include exactly one crypto
attribute, and the receiver MUST either accept it or SHOULD NOT
receive the associated stream. The sender SHOULD select the security
description that it deems most secure for its purposes.
5.3. General Backwards Compatibility Considerations
In the offer/answer model, it is possible that the answerer supports
a given secure transport (e.g., "RTP/SAVP") and accepts the offered
media stream, but that the answerer does not support the crypto
attribute defined in this document and hence ignores it. The offerer
can recognize this situation by seeing an accepted media stream in
the answer that does not include a crypto line. In that case, the
security negotiation defined here MUST fail.
Similar issues exist when security descriptions are used outside the
offer/answer model. But the source of a non-negotiated security
description has no indication that the receiver has ignored the
crypto attribute.
6. SRTP Security Descriptions
In this section, we provide definitions for security descriptions for
SRTP media streams. In the next section, we define how to use SRTP
security descriptions with and without the offer/answer model.
SRTP security descriptions MUST only be used with the SRTP transport
(e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security
descriptions for the "RTP/SAVP" profile, defined in [RFC3711].
However, it is expected that other secure RTP profiles (e.g.,
"RTP/SAVPF") can use the same descriptions, which are in accordance
with the SRTP protocol specification [RFC3711].
There is no assurance that an endpoint is capable of configuring its
SRTP service with a particular crypto attribute parameter, but SRTP
guarantees minimal interoperability among SRTP endpoints through the
default SRTP parameters [RFC3711]. More capable SRTP endpoints
support a variety of parameter values beyond the SRTP defaults, and
these values can be configured by the SRTP security descriptions
defined here. An endpoint that does not support the crypto attribute
will ignore it according to the SDP. Such an endpoint will not
correctly process the particular media stream. By using the
Offer/Answer model, the offerer and answerer can negotiate the crypto
parameters to be used before commencement of the multimedia session
(see Section 7.1).
There are over twenty cryptographic parameters listed in the SRTP
specification. Many of these parameters have fixed values for
particular cryptographic transforms. At the time of session
establishment, however, there is usually no need to provide unique
settings for many of the SRTP parameters, such as salt length and
pseudo-random function (PRF). Thus, it is possible to simplify the
list of parameters by defining "cryptographic suites" that fix a set
of SRTP parameter values for the security session. This approach is
followed by the SRTP security descriptions, which uses the general
security description parameters as follows:
* crypto-suite: Identifies the encryption and authentication
transforms.
* key parameter: SRTP keying material and parameters
* session parameters: The following parameters are defined:
- KDR: The SRTP Key Derivation Rate is the rate at which a
pseudo-random function is applied to a master key.
- UNENCRYPTED_SRTP: SRTP messages are not encrypted.
- UNENCRYPTED_SRTCP: SRTCP messages are not encrypted.
- UNAUTHENTICATED_SRTP: SRTP messages are not authenticated.
- FEC_ORDER: Order of forward error correction (FEC)
relative to SRTP services.
- FEC_KEY: Master Key for FEC when the FEC stream is sent
to a separate address and/or port.
- WSH: Window Size Hint.
- Extensions: Extension parameters can be defined.
Please refer to the SRTP specification for a complete list of
parameters and their descriptions [Section 8.2, srtp]. Regarding the
UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security
descriptions MUST NOT use the SRTCP E-bit to override
UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP
messages (see Section 6.3.2). The key parameter, the crypto-suite,
and the session parameters shown above are described in detail in the
following subsections.
6.1. SRTP Key Parameter
SRTP security descriptions define the use of the "inline" key method
as described in the following. Use of any other keying method (e.g.,
URL) for SRTP security descriptions is for further study.
The "inline" type of key contains the keying material (master key and
salt) and all policy related to that master key, including how long
it can be used (lifetime) and whether it uses a master key identifier
(MKI) to associate an incoming SRTP packet with a particular master
key. Compliant implementations obey the policies associated with a
master key and MUST NOT accept incoming packets that violate the
policy (e.g., after the master key lifetime has expired).
The key parameter contains one or more cryptographic master keys,
each of which MUST be a unique cryptographically random [RFC1750]
value with respect to other master keys in the entire SDP message
(i.e., including master keys for other streams). Each key follows
the format (the formal definition is provided in Section 9.2):
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
key||salt concatenated master key and salt, base64 encoded
(see [RFC3548], Section 3)
lifetime master key lifetime (max number of SRTP or SRTCP
packets using this master key)
MKI:length MKI and length of the MKI field in SRTP packets
The following definition provides an example for
AES_CM_128_HMAC_SHA1_80:
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4
The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the
parameter is the cryptographic master key appended with the master
salt; the two are first concatenated and then base64 encoded. The
length of the concatenated key and salt is determined by the crypto-
suite for which the key applies. If the length (after being decoded
from base64) does not match that specified for the crypto-suite, the
crypto attribute in question MUST be considered invalid. Each master
key and salt MUST be a cryptographically random number and MUST be
unique to the entire SDP message. When base64 decoding the key and
salt, padding characters (i.e., one or two "=" at the end of the
base64-encoded data) are discarded (see [RFC3548] for details).
Base64 encoding assumes that the base64 encoding input is an integral
number of octets. If a given crypto-suite requires the use of a
concatenated key and salt with a length that is not an integral
number of octets, said crypto-suite MUST define a padding scheme that
results in the base64 input being an integral number of octets. For
example, if the length defined were 250 bits, then 6 padding bits
would be needed, which could be defined to be the last 6 bits in a
256 bit input.
The second field is the OPTIONAL lifetime of the master key as
measured in maximum number of SRTP or SRTCP packets using that master
key (i.e., the number of SRTP packets and the number of SRTCP packets
each have to be less than the lifetime). The lifetime value MAY be
written as a non-zero, positive decimal integer or as a power of 2
(see the grammar in Section 9.2 for details); leading zeroes MUST NOT
be used. The "lifetime" value MUST NOT exceed the maximum packet
lifetime for the crypto-suite. If the lifetime is too large or
otherwise invalid, then the entire crypto attribute MUST be
considered invalid. The default MAY be implicitly signaled by
omitting the lifetime (note that the lifetime field never includes a
colon, whereas the third field always does). This is convenient when
the SRTP cryptographic key lifetime is the default value. As a
shortcut to avoid long decimal values, the syntax of the lifetime
allows using the literal "2^", which indicates "two to the power of".
The example above shows a case where the lifetime is specified as
2^20. The following example, which is for the
AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime
field, which means that SRTP’s and SRTCP’s default values will be
used (see [RFC3711]):
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4
The example shows a 30-octet key and concatenated salt that is base64
encoded: The 30-octet key/salt concatenation is expanded to 40
characters (octets) by the three-in-four encoding of base64.
The third field, which is also OPTIONAL, is the Master Key Identifier
(MKI) and its byte length.
"MKI" is the master key identifier associated with the SRTP master
key. The MKI is here defined as a positive decimal integer that is
encoded as a big-endian integer in the actual SRTP packets; leading
zeroes MUST NOT be used in the integer representation. If the MKI is
given, then the length of the MKI MUST also be given and separated
from the MKI by a colon (":"). The MKI length is the size of the MKI
field in the SRTP packet, specified in bytes as a decimal integer;
leading zeroes MUST NOT be used. If the MKI length is not given or
its value exceeds 128 (bytes), then the entire crypto attribute MUST
be considered invalid. The substring "1:4" in the first example
assigns to the key a master key identifier of 1 that is 4 bytes long,
and the second example assigns a 4-byte master key identifier of 1066
to the key. One or more master keys with their associated MKI can be
initially defined, and then later updated, or deleted and new ones
defined.
SRTP offers a second feature for specifying the lifetime of a master
key in terms of two values, called "From" and "To," which are defined
on the SRTP sequence number space [RFC3711]. This SRTP Security
Descriptions specification, however, does not support the <"From",
"To"> feature since the lifetime of an AES master key is 2^48 SRTP
packets, which means that there is no cryptographic reason to replace
a master key for practical point-to-point applications. For this
reason, there is no need to support two means for signaling key
update. The MKI is chosen over <"From", "To"> by this specification
for the very few applications that need it since the MKI feature is
simpler (though the MKI adds additional bytes to each packet, whereas
<"From", "To"> does not).
As mentioned above, the key parameter can contain one or more master
keys. When the key parameter contains more than one master key, all
the master keys in that key parameter MUST include an MKI value.
When using the MKI, the MKI length MUST be the same for all keys in a
given crypto attribute.
6.2. Crypto-Suites
The SRTP crypto-suites define the encryption and authentication
transforms to be used for the SRTP media stream. The SRTP
specification has defined three crypto-suites, which are described
further in the following subsections in the context of the SRTP
security descriptions. The table below provides an overview of the
crypto-suites and their parameters:
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Master salt length | 112 bits | 112 bits | 112 bits |
| SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets |
| SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | AES F8 Mode |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| SRTP auth. tag | 80 bits | 32 bits | 80 bits |
| SRTCP auth. tag | 80 bits | 80 bits | 80 bits |
| SRTP auth. key len. | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key len.| 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+
6.2.1. AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher
and HMAC-SHA1 message authentication with an 80-bit authentication
tag. The master-key length is 128 bits and has a default lifetime of
a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes
first [Page 39, srtp].
SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, whichever
comes first. However, it is RECOMMENDED that automated key
management allow easy and efficient rekeying at intervals far
smaller than 2^31 packets given today’s media rates or even HDTV
media rates.
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and
SRTCP authentication key lengths are 160 bits (see Security
Considerations in Section 8). The master salt value is 112 bits in
length and the session salt value is 112 bits in length. The
pseudo-random function (PRF) is the default SRTP pseudo-random
function that uses AES Counter Mode with a 128-bit key length.
The length of the base64-decoded key and salt value for this crypto-
suite MUST be 30 characters (i.e., 240 bits); otherwise, the crypto
attribute is considered invalid.
6.2.2. AES_CM_128_HMAC_SHA1_32
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that
the authentication tag is 32 bits.
The length of the base64-decoded key and salt value for this crypto-
suite MUST be 30 octets i.e., 240 bits; otherwise, the crypto
attribute is considered invalid.
6.2.3. F8_128_HMAC_SHA1_80
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that
the cipher is F8 [RFC3711].
The length of the base64-decoded key and salt value for this crypto-
suite MUST be 30 octets, i.e., 240 bits; otherwise the crypto
attribute is considered invalid.
6.2.4. Adding New Crypto-Suite Definitions
If new transforms are added to SRTP, new definitions for those
transforms SHOULD be given for the SRTP security descriptions and
published in a Standards-Track RFC. Sections 6.2.1 through 6.2.3
illustrate how to define crypto-suite values for particular
cryptographic transforms. Any new crypto-suites MUST be registered
with IANA following the procedures in Section 10.
6.3. Session Parameters
SRTP security descriptions define a set of "session" parameters,
which OPTIONALLY may be used to override SRTP session defaults for
the SRTP and SRTCP streams. These parameters configure an RTP
session for SRTP services. The session parameters provide session-
specific information to establish the SRTP cryptographic context.
6.3.1. KDR=n
KDR specifies the Key Derivation Rate, as described in Section 4.3.1
of [RFC3711].
The value n MUST be a decimal integer in the set {1,2,...,24}, which
denotes a power of 2 from 2^1 to 2^24, inclusive; leading zeroes MUST
NOT be used. The SRTP key derivation rate controls how frequently a
new session key is derived from an SRTP master key(s) [RFC3711] given
in the declaration. When the key derivation rate is not specified
(i.e., the KDR parameter is omitted), a single initial key derivation
is performed [RFC3711].
In the offer/answer model, KDR is a declarative parameter.
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
SRTP and SRTCP packet payloads are encrypted by default. The
UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the
default behavior of the crypto-suites with which they are used:
* UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
encrypted.
* UNENCRYPTED_SRTP signals that the SRTP packet payloads are not
encrypted.
In the offer/answer model, these parameters are negotiated. If
UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit
MUST be clear (0) in all SRTCP messages. If the default is used, all
SRTCP messages are encrypted, and the E bit MUST be set (1) on all
SRTCP messages.
6.3.3. UNAUTHENTICATED_SRTP
SRTP and SRTCP packet payloads are authenticated by default. The
UNAUTHENTICATED_SRTP session parameter signals that SRTP messages are
not authenticated. Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED
(see Security Considerations).
The SRTP specification requires use of message authentication for
SRTCP, but not for SRTP [RFC3711].
In the offer/answer model, this parameter is negotiated.
6.3.4. FEC_ORDER=order
FEC_ORDER signals the use of forward error correction for the RTP
packets [RFC2733]. The forward error correction values for "order"
are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied
before SRTP processing by the sender of the SRTP media and after SRTP
processing by the receiver of the SRTP media; FEC_SRTP is the
default. SRTP_FEC is the reverse processing.
In the offer/answer model, FEC_ORDER is a declarative parameter.
6.3.5. FEC_KEY=key-params
FEC_KEY signals the use of separate master key(s) for a Forward Error
Correction (FEC) stream. The master key(s) are specified with the
exact same format as the SRTP Key Parameter defined in Section 6.1,
and the semantic rules are the same - in particular, the master
key(s) MUST be different from all other master key(s) in the SDP. An
FEC_KEY MUST be specified when the FEC stream is sent to a different
IP-address and/or port than the media stream to which it applies
(i.e., the "m=" line), e.g., as described in RFC 2733, Section 11.1.
When an FEC stream is sent to the same IP-address and port as the
media stream to which it applies, an FEC_KEY MUST NOT be specified.
If an FEC_KEY is specified in this latter case, the crypto attribute
in question MUST be considered invalid.
In the offer/answer model, FEC_KEY is a declarative parameter.
6.3.6. Window Size Hint (WSH)
SRTP defines the SRTP-WINDOW-SIZE [RFC3711, Section 3.3.2] parameter
to protect against replay attacks. The minimum value is 64
[RFC3711]; however, this value may be considered too low for some
applications (e.g., video).
The Window Size Hint (WSH) session parameter provides a hint for how
big this window should be to work satisfactorily (e.g., based on
sender knowledge of the number of packets per second). However,
there might be enough information given in SDP attributes like
"a=maxprate" [maxprate] and the bandwidth modifiers to allow a
receiver to derive the parameter satisfactorily. Consequently, this
value is only considered a hint to the receiver of the SDP that MAY
choose to ignore the value provided. The value is a decimal integer;
leading zeroes MUST NOT be used.
In the offer/answer model, WSH is a declarative parameter.
6.3.7. Defining New SRTP Session Parameters
New SRTP session parameters for the SRTP security descriptions can be
defined in a Standards-Track RFC and registered with IANA according
to the registration procedures defined in Section 10.
New SRTP session parameters are by default mandatory. A newly
defined SRTP session parameter that is prefixed with the dash
character ("-"), however, is considered optional and MAY be ignored.
If an SDP crypto attribute is received with an unknown session
parameter that is not prefixed with a "-" character, that crypto
attribute MUST be considered invalid.
6.4. SRTP Crypto Context Initialization
In addition to the various SRTP parameters defined above, there are
three pieces of information that are critical to the operation of the
default SRTP ciphers:
* SSRC: Synchronization source
* ROC: Roll-over counter for a given SSRC
* SEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints on
these values.
The first constraint is on the SSRC, which makes an SRTP keystream
unique from other participants. As explained in SRTP, the keystream
MUST NOT be reused on two or more different pieces of plaintext.
Keystream reuse makes the ciphertext vulnerable to cryptanalysis.
One vulnerability is that known-plaintext fields in one stream can
expose portions of the reused keystream, and this could further
expose more plaintext in other streams. Since all current SRTP
encryption transforms use keystreams, key sharing is a general
problem [RFC3711]. SRTP mitigates this problem by including the SSRC
of the sender in the keystream. But SRTP does not solve this problem
in its entirety because the Real-time Transport Protocol has SSRC
collisions, which although very rare [RFC3550] are quite possible.
During a collision, two or more SSRCs that share a master key will
have identical keystreams for overlapping portions of the RTP
sequence number space. SRTP Security Descriptions avoid keystream
reuse by making unique master keys REQUIRED for the sender and
receiver of the security description. Thus, the first constraint is
satisfied.
Also note that there is a second problem with SSRC collisions: the
SSRC is used to identify the crypto context and thereby the
cipher, key, ROC, etc. to process incoming packets. In case of
SSRC collisions, crypto context identification becomes ambiguous
and correct packet processing may not occur. Furthermore, if an
RTCP BYE packet is to be sent for a colliding SSRC, that packet
may also have to be secured. In a (unicast) point-to-multipoint
scenario, this can be problematic for the same reasons, i.e., it
is not known which of the possible crypto contexts to use. Note
that these problems are not unique to the SDP security