Internet Engineering Task Force Flemming Andreasen MMUSIC Working Group Mark Baugher INTERNET-DRAFT Dan Wing EXPIRES: December 2003 Cisco Systems June 27, 2003 SDP Security Descriptions for Media Streams Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. INTERNET-DRAFT SDP Security Descriptions June 20, 2003 TABLE OF CONTENTS 1. Notational Conventions............................................2 2. Introduction......................................................3 3. SDP "Crypto" Attribute and Parameters.............................4 3.1 Crypto-suite....................................................4 3.2 Key Parameter...................................................4 3.4 Session Parameters..............................................5 3.5 Examples........................................................5 4. RTP/SAVP (SRTP) Security Descriptions.............................6 4.1 Crypto-suites...................................................7 4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7 4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7 4.1.3 F8_128_HMAC_SHA1_80.........................................7 4.1.4 Adding new CRYPTO-SUITE definitions.........................8 4.2 Key-param Parameter.............................................8 4.2.1 Key Usage...................................................8 4.2.2 INLINE Definition...........................................8 4.3 Session Parameters.............................................10 4.3.1 SRC=/SSRC/ROC/SEQ..........................................10 4.3.2 KEY_DERIVATION_RATE=n......................................11 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11 4.3.4 FEC_ORDER=order............................................11 4.3.5 UNAUTHENTICATED_SRTP.......................................12 5. Use with Offer/Answer............................................12 5.1 Generating the Offer...........................................12 5.2 Answerer Processing............................................12 5.4 Non-RTP/SAVP Answerers.........................................14 5.4 Offer/Answer Example: Receiver Supports SRTP...................14 5.7 Use of a=crypto With Active Media Streams......................15 5.8 Operation with KEYMGT and Key lines............................15 6. Security Considerations..........................................15 6.1 Authentication of packets......................................16 6.1 Key-stream Reuse...............................................16 6.2 Signaling Authentication and Signaling Encryption..............17 7. SRTP "Crypto" Attribute Grammar..................................18 8. Open Issues......................................................19 9. Acknowledgements.................................................19 10. Authors' Addresses..............................................19 11. Normative References............................................20 Intellectual Property Statement.....................................21 Acknowledgement.....................................................22 1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology conforms to [RFC2828]. Andreasen, Baugher & Wing [Page 2] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 2. Introduction The Session Description Protocol (SDP) describes multimedia sessions, which can be audio, video, whiteboard, fax, modem and other media sessions. Security services such as data origin authentication, integrity and confidentiality are often needed for these media streams. The Secure Real-time Transport Protocol (SRTP) can be used to provide such security services, and use of it can be signaled by use of the "RTP/SAVP" transport in an SDP media (m=) line. However, there are no means within SDP itself to configure SRTP beyond using defaults values. This document specifies a new SDP attribute called "crypto", which is used to signal and negotiate cryptographic parameters for SRTP. The crypto attribute might be extended to non-SRTP transports such as whiteboard, modem, fax, and other transports that could use various security protocols such as IPsec or TLS. These extensions, however, are beyond the scope of this document. Each type of SDP media stream needs its own definitions that assign values to its crypto-attribute parameters. These definitions are unique to the particular SDP transport and SHOULD be specified in an Internet RFC. This document defines the parameter values for SRTP. It would be self-defeating not to secure cryptographic keys and other parameters at least as well as SRTP secures RTP packets or IPsec secures IP packets. Data security protocols such as SRTP rely upon a separate key management system to securely establish encryption and/or authentication keys. Key management protocols provide authenticated key establishment (AKE) procedures to authenticate the identity of each endpoint and protect against man- in-the-middle, reflection/replay, connection hijacking and some denial of service attacks [skeme]. Along with the key, an AKE protocol such as MIKEY, GDOI, KINK, IKE or TLS securely disseminates information describing both the key and the data-security session (for example, whether SRTCP payloads are encrypted or unencrypted in an SRTP session). AKE is needed because it is pointless to provide a key over a medium where an attacker can snoop the key, alter the definition of the key to render it useless, or change the parameters of the security session to gain unauthorized access to session- related information. SDP, however, was not designed to provide AKE services, and the media security descriptions that follow do not add AKE services to SDP. This specification is no replacement for a key management protocol or for the conveyance of key management messages in SDP [keymgt]. The SDP security descriptions are suitable for restricted cases where IPsec, TLS, or some other encapsulating data-security protocol (e.g. SIP secure multiparts) protects the SDP message. This draft adds security descriptions to those encrypted and/or authenticated SDP messages through the "crypto" attribute, which Andreasen, Baugher & Wing [Page 3] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 provides the cryptographic parameters of a media stream. The " crypto" attribute could be adapted to any media transport, but its definition is unique to a particular transport. In Section 3, we introduce the SDP crypto attribute, and in Section 4, we define the crypto attribute details needed for SRTP. In Section 5, we specify how to use the crypto attribute for SRTP streams with the Offer/Answer model [RFC3264]. Section 6 recites security considerations, and Section 7 gives an Augmented-BNF grammar for the SRTP security descriptions provided for the crypto attribute. A list of open issues is provided in Section 8. 3. SDP "Crypto" Attribute and Parameters A new media-level SDP attribute called "crypto" describes the cryptographic suite, key parameters, and session parameters for the proceeding media line. The "crypto" attribute MUST only appear at the SDP media level (not the session level). The "crypto" attribute is defined by the following ABNF [RFC2234]: "a=crypto:" crypto-suite SP key-param *(SP session-param) where "SP" is the space character (see [RFC2234]); the fields crypto-suite, key-param, and session-param are described in Section 3.1, 3.2, and 3.3. The ordering of multiple "a=crypto" lines is significant: The most- preferred crypto line is listed first; see section 5 for details. We now describe the crypto fields in more detail. 3.1 Crypto-suite The crypto-suite field describes all needed information about the encryption and authentication algorithms for the RTP/SAVP transport. The ABNF grammar for crypto-suite is: crypto-suite = VCHAR where VCHAR is defined in [RFC2234]. The possible values for the crypto-suite parameter is unique to the transport. 3.2 Key Parameter The key-param field MUST either contain an inline key descriptor, or it MUST be a pointer to a uri which contains the actual key. The ABNF grammar for key-param is: key-param = inline-key / uri-key inline-key = "inline:" key-descriptor key-descriptor = VCHAR uri-key = "uri:" absolute-uri absolute-uri = VCHAR Andreasen, Baugher & Wing [Page 4] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 where VCHAR is defined in [RFC2234]. If the key parameter starts with the string "uri:", the URI method is used and the value that follows MUST be a Uniform Resource Identifier. The URI is a resource that SHOULD be queried to obtain the cryptographic key for the session. The format or protocols used for the uri are beyond the scope of this document, however it is RECOMMENDED that such protocols provide both integrity and confidentiality. The INLINE method is invoked when the key parameter starts with the string "inline:"; the cryptographic key is encoded according to a transport-specific syntax subject to the general format provided above. Thus, the URI method is transport generic and the INLINE method is transport specific. Section 4 describes the INLINE key- parameter syntax for RTP/SAVP (the SRTP media transport type). 3.4 Session Parameters The session parameters are specific to the SDP media stream transport and are OPTIONAL. The ABNF grammar for session-param is: session-param = VCHAR where VCHAR is defined in [RFC2234]. Section 4 describes the session parameters for RTP/SAVP. 3.5 Example The first example shows use of the crypto attribute for the RTP/SAVP media transport type (as defined in Section 4). The a=crypto line is actually one long line, although it is shown as two lines in this document due to page formatting. v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 161.44.17.12/127 t=2873397496 2873404696 m=video 51372 RTP/SAVP 31 a=crypto:AES_CM_128_HMAC_SHA1_80 inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 m=audio 49170 RTP/SAVP 0 a=crypto:AES_CM_128_HMAC_SHA1_32 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32 m=application 32416 udp wb a=orient:portrait Andreasen, Baugher & Wing [Page 5] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 This SDP message describes three media streams, two of which use the RTP/SAVP transport. Each has a crypto attribute for the RTP/SAVP transport. These RTP/SAVP-specific descriptions are defined in the next section. 4. RTP/SAVP (SRTP) Security Descriptions SRTP security descriptions for a media stream MUST only be used for media streams that use the RTP/SAVP transport in the media (m=) line and SHALL apply to that media stream only. 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 [srtp]. More capable SRTP endpoints support a variety of parameter values beyond the SRTP defaults and these values can be configured by the crypto attribute defined in this document. An endpoint that does not support the crypto attribute will ignore it (per [SDPnew]) and hence, if it supports SRTP, it will simply assume use of default SRTP parameters. 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 5.0). 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. SRTP Crypto Parameter Description --------------------- ----------- CRYPTO-SUITE Encryption and authentication transforms INLINE SRTP and associated parameters SRC An triple KEY_DERIVATION_RATE Rate that the 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 Table 4-1: SRTP Crypto-suite, Key and Session Parameters Andreasen, Baugher & Wing [Page 6] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 Please refer to the SRTP specification for a complete list of parameters and their descriptions [Section 8.2, srtp]. The CRYPTO- SUITE, the key parameter, and the session parameters shown in the table above are described in the following sections. If a receiver cannot recognize a parameter or value, then the receiver MUST NOT participate in the media stream and SHOULD log an "invalid name" condition unless the receiver is participating in an Offer/Answer exchange (Section 5). 4.1 Crypto-suites A crypto-suite value appears as the first parameter in a crypto attribute. If a receiver does not support the particular crypto- suite, then the receiver MUST NOT participate in the media stream and SHOULD log an "unrecognized crypto-suite" condition unless the receiver is participating in an Offer/Answer exchange (Section 5). RTP/SAVP has three crypto-suites as described below. 4.1.1 AES_CM_128_HMAC_SHA1_80 This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 message authentication having an 80-bit authentication tag. The master-key length is 128 bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP authentication key lengths are 160 bits (see Security Considerations). The master salt value is 112 bits and the session salt value is 112 bits. The PRF is the default SRTP pseudo- random function that uses AES Counter Mode with a 128-bit key length. 4.1.2 AES_CM_128_HMAC_SHA1_32 The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message authentication having a 32-bit authentication tag for SRTP packets; SRTCP uses an 80-bit tag. The master-key length is 128 bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP authentication key lengths are 160 bits (see Security Considerations). The master salt value is 112 bits and the session salt value is 112 bits. The PRF is the default SRTP pseudo-random function that uses AES Counter Mode with a 128-bit key length. 4.1.3 F8_128_HMAC_SHA1_80 The SRTP f8 cipher is used with HMAC-SHA1 message authentication having a 80-bit authentication tag. The master-key length is 128 bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP Andreasen, Baugher & Wing [Page 7] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 authentication key lengths are 160 bits (see Security Considerations). The master salt value is 112 bits and the session salt value is 112 bits. The PRF is the default SRTP pseudo-random function that uses AES Counter Mode with a 128-bit key length. 4.1.4 Adding new CRYPTO-SUITE definitions If new transforms are added to SRTP, new definitions for those transforms SHOULD be given for the SDP crypto attribute and published in an Internet RFC. Sections 4.1.1 through 4.1.3 illustrate how to define CRYPTO-SUITE values for particular cryptographic transforms. New definitions MAY be added to existing transforms, moreover, to augment or modify definitions 4.1.1 through 4.1.3. For example, if AES_CM_128_HMAC_SHA1_80 were desired that used a 160-bit master key, then a new crypto-suite MUST be defined having a new name that is identical to AES_CM_128_HMAC_SHA1_80 but with the size of the master key defined to be 160 bits instead of 128 bits. 4.2 Key-param Parameter If the key-param parameter has a "uri:" descriptor, the value is a Uniform Resource Identifier value as described in Section 3. When the key-param parameter has an "inline:" descriptor, the value contains a cryptographic master key that MUST be a unique cryptographically random [RFC1750] value with respect to other "inline:" values in the SDP message. 4.2.1 Key Usage The "inline" type of key contains the keying material and all policy relating to that key, including how it can be used (for encryption, decryption, or both encryption and decryption), how long it can be used (lifetime) and whether or not it uses a master key index (master key index or MKI) to associate an incoming SRTP packet with a 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 key lifetime has expired, for example). 4.2.2 INLINE Definition If the identifier is "inline", the key-param descriptor has the format described in Section 7 (Grammar) and contains the following fields: use key use indicator key_length key length salt_length salt length key||salt concatenated key and salt, BASE64-encoded lifetime key lifetime (number of packets) Andreasen, Baugher & Wing [Page 8] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 MKI:length MKI and length of the MKI field in SRTP packets. The "use" indicator defines usage as one of three values which are all provided from the perspective of the recipient of the SDP: "d" means the key is used for decryption only, "e" means the key is used for encryption only, and "b" means the key is used for both encryption and decryption. If the crypto suite uses the same key for both encryption and decryption, "b" MUST be specified. The "key_length" is the integer length of the SRTP master key in bytes, and "salt_length" is the integer length of the master salt in bytes. Their sum MUST be exactly equal to the length of the concatenated master key and salt provided in the fourth field. The key_length and salt_length MUST appear in the "inline" encoding. For example, inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:4 is a decryption key with a key length of 16 and a salt length of 14. The fourth part of the "inline" encoding is the cryptographic master key appended with the master salt. Each master key and salt MUST be a cryptographically random number and MUST be unique to the SDP message. Both are concatenated and then base-64 encoded. If the length of the concatenated key and salt (after being decoded from base 64) does not equal the sum of the key_length and salt_length indicated, the receiver MUST NOT use this crypto attribute line for the media stream and SHOULD log a "inline encoding too short" condition. For example, inline:d/16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:4 describes a decryption key with a key_length of 16, a salt_length of 8, and a 32-character key and concatenated salt that is base-64 encoded: The 24-character key/salt concatenation is expanded to 32 characters by the three-in-four encoding of base 64. The fifth part of the of the "inline" encoding is the OPTIONAL lifetime of the master key as measured in number of packets using that key. The lifetime value MAY be written as an non-zero, positive integer or as a power of 2, see the ABNF in Section 7 for details. The "lifetime" value MUST NOT exceed the maximum packet lifetime for the crypto-suite. If lifetime is too large or otherwise invalid, then the receiver MUST NOT use this crypto attribute line for the media stream and SHOULD log an "invalid lifetime" condition. The default MAY be implicitly signaled by having no described value for lifetime (i.e. "//"). This is convenient when the srtp crypto_key lifetime is allowed to default. The first example, above, shows a case where the lifetime is specified as 2^20 while the second example shows an empty lifetime, Andreasen, Baugher & Wing [Page 9] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 which means the SRTP default value of 2^48 will be used with UNENCRYPTED_SRTCP and 2^31 will be used otherwise. The MKI and its byte length are OPTIONAL (see Section 7). "MKI" is the master key index associated with the SRTP_master key. 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. If the MKI_length is not given or if the value exceeds 128, then the receiver MUST NOT use this crypto attribute line for the media stream and SHOULD log an "invalid MKI_length" condition. If the value of the MKI is larger than allowed by MKI_length, then the receiver MUST NOT use this crypto attribute line for the media stream and SHOULD log an "invalid MKI" condition. The substring "1:4" in the first example assigns to the key a master key index of 1 that is 4 bytes long, and the second example assigns a 4-byte key index of 1066 to the key. 4.3 Session Parameters The "session" parameters are OPTIONAL and serve to override SRTP session defaults for the SRTP and SRTCP streams. These parameters configure an RTP session for SRTP services. 4.3.1 SRC=SSRC/ROC/SEQ The SRC session parameter provides information to establish the SRTP cryptographic context. The ROC and sequence number are typically only needed for sessions already in progress (as when rekeying or when joining a multicast session). Zero or more SRC parameters MAY appear in a crypto attribute. Each SRC parameter defines a separate SRTP crypto context (see section 3.2 of [srtp]) that SHALL share the master key and salt defined by an INLINE parameter. The total number of all packets that are encrypted by keys derived from this master key MUST NOT exceed the lifetime of the INLINE key. The SRTP crypto contexts so defined SHALL also have a common definition for the crypto-suite and all other crypto parameters. SSRC is OPTIONAL provided that either a ROC or a SEQ appear in the SRC parameter. SSRC is an integer in the range of 0..2^32-1 for the RTP SSRC parameter, which is undefined by default. This is the RTP SSRC that is associated with the inline key. If the SSRC value is invalid, the receiver MUST NOT use this crypto attribute line for the media stream but SHOULD log an "invalid SSRC" condition. If SSRC is specified and an SRTP packet is received with a different SSRC value, the receiver SHOULD discard the packet and log an error. ROC is OPTIONAL provided that either an SSRC or a SEQ appear in the SRC parameter. ROC is an integer in the range of 0..2^32-1 for the Andreasen, Baugher & Wing [Page 10] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 SRTP rollover counter (ROC), which is zero by default. The ROC MAY be set to a non-zero value for an ongoing RTP/SAVP stream in which the SRTP ROC has cycled one or more times [srtp]. The receiver of the SDP message SHOULD refresh the ROC value before joining an ongoing session. Depending on the nature of the session control, the late-joining receiver might need to refresh its ROC value through a unicast exchange or through receipt of a multicast or unicast SDP message containing a ROC SRTP description. If ROC is greater than 2^32-1, then the receiver MUST NOT use this crypto attribute line for the media stream but SHOULD log an "invalid ROC" condition. SEQ is OPTIONAL provided that either an SSRC or a ROC appear in the SRC parameter. SEQ is an integer in the range of 0..2^16-1 for the SRTP sequence number (SEQ). SRTP uses the RTP sequence number (and the ROC) to compute the packet index [srtp]. At the start of a session, an SSRC that randomly selects a high sequence-number value can put the receiver in an ambiguous situation: If initial packets are lost in transit up to the point that the sequence number wraps (exceeds 2^16-1), then the receiver might not recognize that its ROC needs to be incremented. See also section 3.3.1 of [srtp]. If SEQ is greater than 2^16-1, then the receiver MUST NOT use this crypto attribute line for the media stream but SHOULD log an "invalid SEQ" condition. 4.3.2 KDR=n KDR specifies the Key Derivation Rate, as described in section 4.3.1 of [srtp]. The value n MUST be an integer in the set {0,1,2,...,24}, which denotes a power of 2 from 2^0 to 2^24, inclusive. The SRTP key derivation rate controls how frequently a new session key is derived from an SRTP master key [SRTP]. The default value is 0, which causes the key derivation function to be invoked exactly once (since 2^0 is 1). 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP UNENCRYPTED_SRTCP indicates that the SRTCP packet payloads are not encrypted. UNENCRYPTED_SRTP indicates that the SRTP packet payloads are not encrypted. SRTP and SRTCP packet payloads are encrypted by default. 4.3.4 FEC_ORDER=order The forward error correction values for "order" are FEC_SRTP, SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied before SRTP processing on the sender and after SRTP processing on the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse processing. SPLIT signals that SRTP encryption occurs on the Andreasen, Baugher & Wing [Page 11] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 sender, followed by FEC processing, followed by SRTP authentication; processing is reversed on the receiver. If the receiver cannot recognize the order value, then the receiver MUST NOT use this crypto attribute line for the media stream but SHOULD log an "invalid FEC_ORDER" condition. 4.3.5 UNAUTHENTICATED_SRTP This parameter signals that SRTP messages are not authenticated. SRTP authenticates SRTP messages by default. Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security Considerations). 5. Use with Offer/Answer The Offer/Answer model [RFC 3264] enables parties that wish to engage in a multimedia session to negotiate the media stream parameters that will be used for the multimedia session. In this section, we detail how the security descriptions defined for SRTP are used with the offer/answer model to negotiate cryptographic capabilities and communicate SRTP master keys. 5.1 Generating the Offer For each SDP media line (m=) using the "RTP/SAVP" transport where the offerer wants to specify cryptographic parameters, the offerer MUST provide at least one "a=crypto" line. When multiple crypto lines are provided, the a=crypto lines are specified in preference order, with the most preferred listed first. The offerer determines the crypto parameters based on its capabilities and its security policies. The offerer obtains keying material for "inline", or obtains the uri pointing to a key server. The mechanism to generate or obtain a key is outside the scope of this specification. 5.2 Answerer Processing For each SDP media line using the "RTP/SAVP" transport that contains an "a=crypto" line in the offer, the answerer MUST either accept exactly one of the crypto lines for that media stream, or it MUST reject the media stream as described in RFC 3264. Note that if there are no "a=crypto" lines for the media stream in the offer, then the answerer MUST skip the following steps and instead use the default SRTP/SRTCP parameters for that media stream (note that the endpoint will then need to somehow obtain the correct master key as well). When the answerer accepts an "RTP/SAVP" media stream with a crypto line, the answerer MUST include exactly one "a=crypto" line in the answer. The answer crypto line MUST include at least the selected crypto-suite and a key-param parameter. Andreasen, Baugher & Wing [Page 12] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 To determine if the answerer can accept any of the provided "a=crypto" lines, the answerer examines the crypto lines in order. If an "a=crypto" line does not satisfy the constraints provided in Section 4, that crypto line is deemed invalid and MUST be discarded. The answerer selects the first valid crypto line that it supports, considering the answerer's capabilities and security policies. If the answerer cannot find any valid crypto line that it supports, or its configured policy prohibits any cryptographic key parameter (e.g. key length) or cryptographic session parameter (e.g. SSRC, ROC, KDR, FEC_ORDER), it MUST reject the media stream, unless it is able to successfully negotiate use of "RTP/SAVP" by other means outside the scope of this document (e.g. by use of MIKEY [mikey]). After selecting a single crypto line, the answerer generates a master key appropriate for the selected crypto algorithm(s), unless the offered master key was specified to apply to both encryption and decryption, in which case the offered master key MUST be used instead. If the offered master key was for decryption, then the answerer MUST use it to decrypt any incoming packets; the key provided in the answer MUST also be marked as being for decryption, since the answerer will be using it when encrypting it's packets. Similarly, if the offered key was for encryption, then the answerer MUST use it to encrypt any packets it sends and the key it provides in its answer MUST be used to decrypt any incoming packets. The master key in the answer MUST have the same key length and salt length as the offer. To set up the bi-directional media with transport set to RTP/SAVP, the answerer includes one "a=crypto" line after its media line with transport set to RTP/SAVP. 5.3 Offerer Processing of the Answer When the offerer receives the answer, it MUST perform the following steps for each "RTP/SAVP" media stream it offerered 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 media line is valid according to the constraints specified in Section 4. Furthermore, the offerer MUST validate, that the crypto-suite selected was one of the offered crypto-suites for the media stream. If any of these checks fails, the security negotiation defined here MUST be deemed to have failed. It is possible that the answerer supports the "RTP/SAVP" transport and accepts the offered media stream, yet it does not support the crypto attribute defined here. The offerer can recognize this situation by seeing an accepted "RTP/SAVP" 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. Andreasen, Baugher & Wing [Page 13] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 5.4 Non-RTP/SAVP Answerers If a media stream with transport set to "RTP/SAVP" is sent to a device that doesn't support "RTP/SAVP", that media stream will be rejected. In some cases, it is desirable to send SRTP when possible, but allow use of RTP if SRTP isn't supported by a remote device. However, it is ambiguous to send an extra media line with transport set to "RTP/AVP" and with the same port as the "RTP/SAVP" line. Thus, an offerer MUST NOT specify multiple media lines with the same port. Instead, such interoperability is obtained by first sending an offer with transport set to "RTP/SAVP". If that media line is rejected by the answerer, the offerer can, if its policy permits, send a new offer with transport set to "RTP/AVP". Also, the SDP extensions defined in RFC 3407 [RFC3407] can be used by both the offerer and answerer to indicate capabilities above and beyond what is being negotiated for the media stream. Another offer/answer exchange will then be needed to negotiate use of any of these latent capabilities. 5.4 Offer/Answer Example: Receiver Supports SRTP 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. 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:AES_CM_128_HMAC_SHA1_80 inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32 FEC_ORDER=FEC_SRTP SRC=17174//49126 a=crypto:F8_128_HMAC_SHA1_80 inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32 FEC_ORDER=FEC_SRTP SRC=17174//49126 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) Andreasen, Baugher & Wing [Page 14] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 c=IN IP4 168.2.17.11 t=2873397526 2873405696 m=audio 32640 RTP/SAVP 0 a=crypto:AES_CM_128_HMAC_SHA1_80 inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32 SRC=88131/721/13 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 crypto suite for the RTP and RTCP traffic. The answerer is also specifying both its initial SSRC (88131), rollover counter (721), and rollover counter (13). 5.7 Use of a=crypto With Active Media Streams When an active SRTP session is rekeyed, this is indicated by sending a new SDP. Rekeying is done following the rules described for a normal Offer/Answer exchange. The Answerer can take this opportunity to rekey the traffic it is sending, if the Answerer desires. During rekeying, the session parameters cannot be changed and MUST NOT be specified in the Offer or the Answer. When the Offerer needs to rekey, the offerer MUST send an "a=crypto" line with same crypto-suite, key length, and salt length that was previously accepted by the Answerer. If the answerer selected "a=crypto" lines using the "inline" method, the exact same "a=crypto" line(s) as agreed to in the answer MUST be sent and a new new inline key MUST be sent. If the answerer selected "a=crypto" lines using the "uri" method, the sender MAY transmit the same uri, and the recipient MUST fetch the new key using the uri. 5.8 Operation with KEYMGT and Key lines An Offer MAY include both a=crypto and a=keymgt lines [keymgt]. Per SDP rules, the Answerer will ignore attribute lines it doesn't understand. If the Answerer supports both a=crypto and [keymgt], the Answer MUST include either a=crypto or [keymgt], as including both is undefined. 6. Security Considerations Like all SDP messages, SDP messages containing security descriptions, are conveyed in an encapsulating application protocol (e.g. SIP, MGCP, RTSP, SAP, etc.). It is the responsibility of the encapsulating protocol to ensure the protection of the SDP security descriptions. Therefore, that protocol should either invoke its own security mechanisms to do so, or alternatively utilize a lower-layer security service (e.g. TLS, IPSEC) where that service is deemed adequate for protecting the encapsulating protocol itself. Where Andreasen, Baugher & Wing [Page 15] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 the encapsulating protocol is used in both a hop-by-hop and end-to- end context (e.g. SIP), an end-to-end security service SHOULD be provided by that protocol for all sensitive information including SDP's security parameters. This service SHOULD provide strong message authentication and packet-payload encryption as well as effective replay protection. As an example, SIP with S/MIME bodies satisfies these requirements. 6.1 Authentication of 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). Source authentication of unicast SRTP messages SHOULD be performed [srtp]. Note that SRTP source-message authentication does not authenticate the IP-address of the SRTP source, but ensures that the SRTP message that the SRTP receiver had received is exactly what the SRTP sender had sent. Source authentication of multicast SRTP messages is today non-standard and hence for further study. But even in multicast sessions, SRTP packet authentication ensures that the packet originated from a member of the secure group. Use of the UNAUTHENTICATED_SRTP parameter, therefore, is NOT RECOMMENDED. 6.1 Key-stream Reuse Misconfigured SRTP sessions, moreover, are vulnerable to attacks on their encryption services when running the crypto suites defined in Sections 4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is "mis-configured" when two or more media streams are encrypted using the same AES keystream. When senders and receivers share derived session keys, SRTP requires that the SSRCs of session participants 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 were used [srtp]. 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, as this document RECOMMENDS (Section 4.2). SRTP multicast operation requires that each host-sender have a unique SRTP keystream. This can be accomplished by ensuring that each sender be allocated a unique key or by ensuring that the SSRC of each sender will not collide. Since SSRC collision might occur, the latter condition is avoided when all SSRCs are assigned by a central authority such as a 3rd-party key server [srtp]. This is for further study. The RECOMMENDED approach of this document is to allocate a different master key for each host-participant of an SRTP session. Andreasen, Baugher & Wing [Page 16] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 6.2 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 its parameters are vulnerable to denial of service attacks when they are carried in an unauthenticated SDP message. In some cases, the integrity or confidentiality of the RTP stream can be compromised. For example, if an attacker sets UNENCRYPTED for the SRTP stream in an offer, this could result in the answerer not decrypting the encrypted SRTP messages. In the worst case, the answerer might itself send unencrypted SRTP and leave its data exposed to snooping. IPsec, TLS, encapsulating-protocol security or some other data security service SHOULD be used to provide message authentication for SDP messages that carry the SRTP attribute. Message encryption SHOULD be used because a master key parameter appears in the message. Failure to encrypt the SDP message containing an inline SRTP master key renders the SRTP authentication or encryption service useless in practically all circumstances. Failure to authenticate an SDP message that carries SRTP parameters renders the SRTP authentication or encryption service useless in most practical applications. When the SDP parameters cannot be carried in an encrypted and authenticated SDP message, it is RECOMMENDED that a key management protocol be used. The proposed SDP key-mgmt extension [keymgt] allows authentication and encryption of the key management protocol data independently of the SDP message that carries it. The security of the SDP SRTP attribute, however, is as good as the data security protocol that protects the SDP message. For example, if an IPsec security association exists between the source endpoint, its signaling controller, and the destination endpoints, then this solution is more secure than use of the key-mgmt statement in an unauthenticated SDP message, which is vulnerable to tampering. There are practical cases, however, where SDP security is not end- to-end: If there is a third-party provider between the sender and receiver, then the data-security session might not be end-to-end. That is, one possible configuration might have an IPsec or TLS connection between the sender of the SDP message and the provider, such as a VoIP service provider, with a second secure connection between the provider and the receiver: signaling controller---(network-b)---signaling controller | | (network a) (network c) | | sender----------------(SRTP bearer)--------------receiver where all of link a, b, and c are encrypted with TLS or IPsec. Andreasen, Baugher & Wing [Page 17] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 In this case, the third-party provider gets the contents of the SRTP descriptions in the SDP message. SDP key-mgmt statement, however, allows true end-to-end security that is independent of the service provider, who often needs access to some parts of the SDP message to render its services. The SRTP attribute SHOULD NOT be used when end-to-end authentication or confidentiality is needed but the SDP message is not secured end to end (such as the above example where a third-party provider maintains the security associations with the endpoints for the SDP message). 7. SRTP "Crypto" Attribute Grammar This section provides an Augmented BNF grammar for the SRTP profile of the SDP crypto attribute. ABNF is defined in [RFC2234]. key-param = method-inline / method-uri crypto-suite = "AES_CM_128_HMAC_SHA1_32" / "F8_128_HMAC_SHA1_32" / "AES_CM_128_HMAC_SHA1_80" method-inline = "inline:" key-info *(SP session-param) method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in ; [RFC2396] key-info = key-use "/" key-length "/" salt-length "/" key-salt "/" [lifetime] "/" [mki] key-use = "d" / "e" / "b" ; decrypt, encrypt, or both key-length = 1*DIGIT salt-length = 1*DIGIT key-salt = 1*(base64) ; binary key and salt values ; concatenated together, and then ; base64 encoded [section 6.8 of ; RFC2046] lifetime = ["2^"] 1*(DIGIT) mki = mki-length ":" mki-value mki-length = 1*DIGIT ; real value is 2^mki-length, max 128 mki-value = 1*DIGIT session-param = src / kdr / "UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTCP" / "UNAUTHENTICATED_SRTP" / fec-order Andreasen, Baugher & Wing [Page 18] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 src = "SRC=" [ssrc] "/" [roc] "/" [seq] ssrc = 1*DIGIT ; range 0...2^32-1 roc = 1*DIGIT ; range 0...2^32-1 seq = 1*DIGIT ; range 0...2^16-1 kdr = "KDR=" 1*(DIGIT) fec-order = "FEC_ORDER=" fec-type fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT" base64 = ALPHA / DIGIT / "+" / "/" / "=" 8. Open Issues The following is a list of open issues in this document: * The crypto attribute can be used with or without offer/answer, however, details on usage outside of offer/answer are missing. * The offer/answer procedures need to be expanded to better describe unidirectional and inactive streams, unicast versus multicast, as well as additional detail for some of the session parameters. 9. Acknowledgements This document benefited from discussions with David McGrew, Mats Naslund, Mike Thomas, Elisabetta Cararra, Brian Weis, Dave Oran, Bill Foster, Earl Carter, Matt Hammer and Dave Singer. These people shared observations, identified errors and made suggestions for improving the specification. Mats made several valuable suggestions on parameters and syntax that are in the current draft. Dave Oran and Mike Thomas encouraged us to bring this work to the IETF for standardization. David McGrew suggested the conservative approach of using unique master keys for each SDP media stream as followed in this document. Jonathan Rosenberg suggested reducing the complexity by specifying only one security parameter for each media stream. 10. Authors' Addresses Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, New Jersey 08837 USA fandreas@cisco.com Mark Baugher 5510 SW Orchid Street Portland, Oregon 97219 USA mbaugher@cisco.com +1-408-853-4418 Andreasen, Baugher & Wing [Page 19] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA dwing@cisco.com +1-408-902-3348 11. Normative References [RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", January 1996, http://www.ietf.org/rfc/rfc1889.txt. [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF," November 1997, http://www.ietf.org/rfc/rfc2234.txt. [SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol,", Work in Progress. [RFC2828] R. Shirey, "Internet Security Glossary", May 2000, http://www.ietf.org/rfc/rfc2828.txt [RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", June 2202, http://www.ietf.org/rfc/rfc3264.txt [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The Secure Real-time Transport Protocol", May 2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- 08.txt, Work in Progress [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. 12. Informative References [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002. [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996. [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "Key Management Extensions for SDP and RTSP", February 2003, http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext- 07.txt, Work in Progress. Andreasen, Baugher & Wing [Page 20] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "MIKEY: Multimedia Internet KEYing", July 2002, http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt, Work in Progress. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996, http://www.ietf.org/rfc/rfc2045.txt. [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", November 1997, http://www.ietf.org/rfc/rfc2104.txt. [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for the Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright(C) The Internet Society 2003. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing Andreasen, Baugher & Wing [Page 21] INTERNET-DRAFT SDP Security Descriptions June 20, 2003 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Andreasen, Baugher & Wing [Page 22]