idnits 2.17.1 draft-ietf-mmusic-sdescriptions-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1835. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1803), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 223: '...ignaling. Implementations MUST employ...' RFC 2119 keyword, line 226: '... of SIP [RFC3261], the application SHOULD employ either the SIPS URI...' RFC 2119 keyword, line 230: '... RECOMMENDED since the protection of...' RFC 2119 keyword, line 238: '...ine. The "crypto" attribute MUST only...' RFC 2119 keyword, line 260: '...ion 9.1 for details). The tag MUST be...' (128 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 221 has weird spacing: '...aterial withi...' == Line 574 has weird spacing: '...applied to a ...' == Line 1393 has weird spacing: '...essions are v...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TLS' is mentioned on line 160, but not defined == Missing Reference: 'RFC2119' is mentioned on line 201, but not defined == Missing Reference: 'RFC 3550' is mentioned on line 1046, but not defined == Missing Reference: 'SIP' is mentioned on line 1271, but not defined == Missing Reference: 'RFC 3313' is mentioned on line 1291, but not defined == Missing Reference: 'RFC3711' is mentioned on line 1376, but not defined == Unused Reference: 'RFC3550' is defined on line 1689, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 1730, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1753, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1772, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1776, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 1784, but no explicit reference was found in the text == Unused Reference: 'RFC2974' is defined on line 1788, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. 'GDOI') (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) Summary: 13 errors (**), 0 flaws (~~), 21 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Flemming Andreasen 3 MMUSIC Working Group Mark Baugher 4 INTERNET-DRAFT Dan Wing 5 EXPIRES: March 2006 Cisco Systems 6 September, 2005 8 Session Description Protocol Security Descriptions 9 for Media Streams 10 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document defines a Session Description Protocol (SDP) 41 cryptographic attribute for unicast media streams. The attribute 42 describes a cryptographic key and other parameters, which serve to 43 configure security for a unicast media stream in either a single 44 message or a roundtrip exchange. The attribute can be used with a 45 variety of SDP media transports and this document defines how to use 46 it for the Secure Real-time Transport Protocol (SRTP) unicast media 47 streams. The SDP crypto attribute requires the services of a data 48 security protocol to secure the SDP message. 50 Table of Contents 52 1 Introduction......................................................3 53 2 Notational Conventions............................................4 54 3 Applicability.....................................................5 55 4 SDP "Crypto" Attribute and Parameters.............................5 56 4.1 Tag............................................................6 57 4.2 Crypto-suite...................................................6 58 4.3 Key Parameters.................................................6 59 4.4 Session Parameters.............................................7 60 4.5 Example........................................................7 61 5 General Use of the crypto Attribute...............................8 62 5.1 Use With Offer/Answer..........................................8 63 5.1.1 Generating the Initial Offer - Unicast Streams............8 64 5.1.2 Generating the Initial Answer - Unicast Streams...........9 65 5.1.3 Processing of the Initial Answer - Unicast Streams.......10 66 5.1.4 Modifying the Session....................................10 67 5.2 Use Outside Offer/Answer......................................11 68 5.3 General Backwards Compatibility Considerations................11 69 6 SRTP Security Descriptions.......................................11 70 6.1 SRTP Key Parameter............................................12 71 6.2 Crypto-suites.................................................15 72 6.2.1 AES_CM_128_HMAC_SHA1_80..................................15 73 6.2.2 AES_CM_128_HMAC_SHA1_32..................................16 74 6.2.3 F8_128_HMAC_SHA1_80......................................16 75 6.2.4 Adding new Crypto-suite Definitions......................16 76 6.3 Session Parameters............................................16 77 6.3.1 KDR=n....................................................16 78 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................17 79 6.3.3 UNAUTHENTICATED_SRTP.....................................17 80 6.3.4 FEC_ORDER=order..........................................17 81 6.3.5 FEC_KEY=key-params.......................................17 82 6.3.6 Window Size Hint (WSH)...................................18 83 6.3.7 Defining New SRTP Session Parameters.....................18 84 6.4 SRTP Crypto Context Initialization............................18 85 6.4.1 Late Binding of one or more SSRCs to a crypto context....20 86 6.4.2 Sharing cryptographic contexts among Sessions or SSRCs...21 87 6.5 Removal of Crypto Contexts....................................21 88 7 SRTP-Specific Use of the crypto Attribute........................21 89 7.1 Use with Offer/Answer.........................................21 90 7.1.1 Generating the Initial Offer - Unicast Streams...........22 91 7.1.2 Generating the Initial Answer - Unicast Streams..........22 92 7.1.3 Processing of the Initial Answer - Unicast Streams.......23 93 7.1.4 Modifying the Session....................................23 94 7.1.5 Offer/Answer Example.....................................24 95 7.2 SRTP-Specific Use Outside Offer/Answer........................25 96 7.3 Support for SIP Forking.......................................26 97 7.4 SRTP-Specific Backwards Compatibility Considerations..........26 98 7.5 Operation with KEYMGT= and k= lines...........................27 99 8 Security Considerations..........................................27 100 8.1 Authentication of packets.....................................28 101 8.2 Keystream Reuse...............................................28 102 8.3 Signaling Authentication and Signaling Encryption.............29 103 9 Grammar..........................................................29 104 9.1 Generic "Crypto" Attribute Grammar............................29 105 9.2 SRTP "Crypto" Attribute Grammar...............................30 107 10 IANA Considerations.............................................31 108 10.1 Registration of the "crypto" attribute......................31 109 10.2 New IANA Registries and Registration Procedures.............31 110 10.2.1 Key Method Registry and Registration.....................32 111 10.2.2 Media Stream Transport Registry and Registration.........32 112 10.3 Initial Registrations.......................................32 113 10.3.1 Key Method...............................................32 114 10.3.2 SRTP Media Stream Transport..............................32 115 11 Acknowledgements................................................33 116 12 Authors' Addresses..............................................34 117 13 Normative References............................................34 118 14 Informative References..........................................35 119 15 Full Copyright Statement........................................36 121 1 Introduction 123 The Session Description Protocol (SDP) [SDP] describes multimedia 124 sessions, which can be audio, video, whiteboard, fax, modem, and 125 other media streams. Security services such as data origin 126 authentication, integrity and confidentiality are often needed for 127 those streams. The Secure Real-time Transport Protocol (SRTP) [srtp] 128 provides security services for RTP media and is signaled by use of 129 secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an SDP 130 media (m=) line. However, there are no means within SDP itself to 131 configure SRTP beyond using default values. This document specifies 132 a new SDP attribute called "crypto", which is used to signal and 133 negotiate cryptographic parameters for media streams in general, and 134 SRTP in particular. The definition of the crypto attribute in this 135 document is limited to two-party unicast media streams where each 136 source has a unique cryptographic key; support for multicast media 137 streams or multipoint unicast streams is for further study. 139 The crypto attribute is defined in a generic way to enable its use 140 with SRTP and any other secure transports that can establish 141 cryptographic parameters with only a single message or in a single 142 round-trip exchange using the offer/answer model [RFC3264]. 143 Extension to transports other than SRTP, however, is beyond the scope 144 of this document. Each type of secure media transport needs its own 145 specification for the crypto-attribute parameter. These definitions 146 are frequently unique to the particular type of transport and must be 147 specified in a Standards Track RFC and registered with IANA according 148 to the procedures defined in Section 10. This document defines the 149 security parameters and keying material for SRTP only. 151 It would be self-defeating not to secure cryptographic keys and other 152 parameters at least as well as the data is secured. Data security 153 protocols such as SRTP rely upon a separate key management system to 154 securely establish encryption and/or authentication keys. Key 155 management protocols provide authenticated key establishment (AKE) 156 procedures to authenticate the identity of each endpoint and protect 157 against man-in-the-middle, reflection/replay, connection hijacking 158 and some denial of service attacks [skeme]. Along with the key, an 159 AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE 160 [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] securely 161 disseminates information describing both the key and the data- 162 security session. AKE is needed because it is pointless to provide a 163 key over a medium where an attacker can snoop the key, alter the 164 definition of the key to render it useless, or change the parameters 165 of the security session to gain unauthorized access to session- 166 related information. 168 SDP, however, was not designed to provide AKE services, and the media 169 security descriptions defined in this document do not add AKE 170 services to SDP. This specification is no replacement for a key 171 management protocol or for the conveyance of key management messages 172 in SDP [keymgt]. The SDP security descriptions defined here are 173 suitable for restricted cases only where IPsec, TLS, or some other 174 encapsulating data-security protocol (e.g., SIP S/MIME) protects the 175 SDP message. This document adds security descriptions to those 176 encrypted and/or authenticated SDP messages through the new SDP 177 "crypto" attribute, which provides the cryptographic parameters of a 178 media stream. 180 The "crypto" attribute can be adapted to any media transport, but its 181 precise definition is unique to a particular transport. 183 Below, we first provide notational conventions in Section 2 followed 184 by an applicability statement for the crypto attribute in Section 3. 185 In Section 4, we introduce the general SDP crypto attribute, and in 186 Section 5 we define how it is used with and without the offer/answer 187 model. In Section 6, we define the crypto attribute details needed 188 for SRTP, and in Section 7 we define SRTP-specific use of the 189 attribute with and without the offer/answer model. Section 8 recites 190 security considerations, and Section 9 gives an Augmented-BNF grammar 191 for the general crypto attribute as well as the SRTP-specific use of 192 the crypto attribute. IANA considerations are provided in Section 193 10. 195 2 Notational Conventions 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 198 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 199 be interpreted as described in [RFC2119]. The terminology in this 200 document conforms to [RFC2828], "Internet Security Glossary". 202 n^r is exponentiation where n is multiplied by itself r times; n and 203 r are integers. 0..k is an integer range of all integers from 0 204 through k inclusive. 206 The terms 'transport' and 'media transport' are used to mean 207 'transport protocol' as defined in RFC2327, page 20. 209 Explanatory notes are provided in several places throughout the 210 document; these notes are indented two spaces from the surrounding 211 text. 213 3 Applicability 215 RFC YYYY {Note to RFC Editor: replace "YYYY" with RFC number for 216 [keymgt]} provides similar cryptographic key distribution 217 capabilities, and is intended for use when the signaling is to be 218 confidential and/or integrity-protected separately from the keying 219 material. 221 In contrast, this specification carries the keying material within 222 the SDP message, and it is intended for use when the keying material 223 is protected along with the signaling. Implementations MUST employ 224 security mechanisms that provide confidentiality and integrity for 225 the keying material. When this specification is used in the context 226 of SIP [RFC3261], the application SHOULD employ either the SIPS URI 227 or S/MIME to provide protection for the SDP message and the keying 228 material that it contains. The use of transport layer or IP layer 229 security in lieu of the SIPS URI or S/MIME protection is NOT 230 RECOMMENDED since the protection of the SDP message and the keying 231 material that it contains cannot be ensured through all intermediate 232 entities such as SIP proxies. 234 4 SDP "Crypto" Attribute and Parameters 236 A new media-level SDP attribute called "crypto" describes the 237 cryptographic suite, key parameters, and session parameters for the 238 preceding unicast media line. The "crypto" attribute MUST only 239 appear at the SDP media level (not at the session level). The 240 "crypto" attribute follows the format (see Section 9.1 for the formal 241 ABNF grammar): 243 a=crypto: [] 245 The fields tag, crypto-suite, key-params, and session-params are 246 described in the following sub-sections. Below we show an example of 247 the crypto attribute for the "RTP/SAVP" transport, i.e., the secure 248 RTP extension to the Audio/Video Profile [srtp]. In the following, 249 newlines are included for formatting reasons only: 251 a=crypto:1 AES_CM_128_HMAC_SHA1_80 252 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 254 The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined 255 by the text starting with "inline:", and session-params is omitted. 257 4.1 Tag 259 The tag is a decimal number used as an identifier for a particular 260 crypto attribute (see Section 9.1 for details). The tag MUST be 261 unique among all crypto attributes for a given media line. It is 262 used with the offer/answer model to determine which of several 263 offered crypto attributes were chosen by the answerer (see Section 264 5.1). 266 In the offer/answer model, the tag is a negotiated parameter. 268 4.2 Crypto-suite 270 The crypto-suite field is an identifier that describes the encryption 271 and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for 272 the transport in question (see Section 9.1 for details). The 273 possible values for the crypto-suite parameter are defined within the 274 context of the transport, i.e., each transport defines a separate 275 namespace for the set of crypto-suites. For example, the crypto- 276 suite "AES_CM_128_HMAC_SHA1_80" defined within the context 277 "RTP/SAVP" transport applies to Secure RTP only; the string may be 278 reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a 279 separate definition would be needed. 281 In the offer/answer model, the crypto-suite is a negotiated 282 parameter. 284 4.3 Key Parameters 286 The key-params field provides one or more sets of keying material for 287 the crypto-suite in question. The field consists of a method 288 indicator followed by a colon, and the actual keying information as 289 shown below (the formal grammar is provided in Section 9.1): 291 key-params = ":" 293 Keying material might be provided by different means than key-params, 294 however this is out of scope. Only one method is defined in this 295 document, namely "inline", which indicates that the actual keying 296 material is provided in the key-info field itself. There is a single 297 name space for the key-method, i.e., the key-method is transport 298 independent. New key-methods (e.g., use of a URL) may be defined in 299 a Standards Track RFC in the future. Although the key-method itself 300 may be generic, the accompanying key-info definition is specific not 301 only to the key-method, but also to the transport in question. Key- 302 info encodes keying material for a crypto suite, which defines that 303 keying material. New key methods MUST be registered with the IANA 304 according to the procedures defined in Section 10.2.1. 306 Key-info is defined as a general character string (see Section 9.1 307 for details); further transport and key-method specific syntax and 308 semantics MUST be provided in a Standards Track RFC for each 309 combination of transport and key-method that use it; definitions for 310 SRTP are provided in Section 6. Note that such definitions are 311 provided within the context of both a particular transport (e.g., 312 "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will 313 register the list of supported key methods for each transport. 315 When multiple keys are included in the key parameters, it MUST be 316 possible to determine which of the keys is being used in a given 317 media packet by a simple inspection of the media packet received; a 318 trial-and-error approach between the possible keys MUST NOT be 319 performed. 321 For SRTP, this could be achieved by use of Master Key Identifiers 322 (MKI) [srtp]. Use of <"From, "To"> values are not supported in 323 SRTP security descriptions for reasons explained in Section 6.1, 324 below. 326 In the offer/answer model, the key parameter is a declarative 327 parameter. 329 4.4 Session Parameters 331 Session parameters are specific to a given transport and use of them 332 is OPTIONAL in the security descriptions framework, where they are 333 just defined as general character strings. If session parameters are 334 to be used for a given transport, then transport-specific syntax and 335 semantics MUST be provided in a Standards Track RFC; definitions for 336 SRTP are provided in Section 6. 338 In the offer/answer model, session parameters may be either 339 negotiated or declarative; the definition of specific session 340 parameters MUST indicate whether they are negotiated or declarative. 341 Negotiated parameters apply to data sent in both directions, whereas 342 declarative parameters apply only to media sent by the entity that 343 generated the SDP. Thus, a declarative parameter in an offer applies 344 to media sent by the offerer, whereas a declarative parameter in an 345 answer applies to media sent by the answerer. 347 4.5 Example 349 This example shows use of the crypto attribute for the "RTP/SAVP" 350 media transport type (as defined in Section 5). The "a=crypto" line 351 is actually one long line; it is shown as two lines due to page 352 formatting: 354 v=0 355 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 356 s=SDP Seminar 357 i=A Seminar on the session description protocol 358 u=http://www.example.com/seminars/sdp.pdf 359 e=j.doe@example.com (Jane Doe) 360 c=IN IP4 161.44.17.12/127 361 t=2873397496 2873404696 362 m=video 51372 RTP/SAVP 31 363 a=crypto:1 AES_CM_128_HMAC_SHA1_80 364 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 365 m=audio 49170 RTP/SAVP 0 366 a=crypto:1 AES_CM_128_HMAC_SHA1_32 367 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 368 m=application 32416 udp wb 369 a=orient:portrait 371 This SDP message describes three media streams, two of which use the 372 "RTP/SAVP" transport. Each has a crypto attribute for the 373 "RTP/SAVP" transport. These secure-RTP specific descriptions are 374 defined in Section 6. 376 5 General Use of the crypto Attribute 378 In this section, we describe the general use of the crypto attribute 379 outside of any transport or key-method specific rules. 381 5.1 Use With Offer/Answer 383 The general offer/answer rules for the crypto attribute are in 384 addition to the rules specified in RFC 3264, which MUST be followed, 385 unless otherwise noted. RFC 3264 defines operation for both unicast 386 and multicast streams; the sections below describe operation for two- 387 party unicast streams only, since support for multicast streams (and 388 multipoint unicast streams) is for further study. 390 5.1.1 Generating the Initial Offer - Unicast Streams 392 When generating an initial offer for a unicast stream, there MUST be 393 one or more crypto attributes present for each media stream for which 394 security is desired. Each crypto attribute for a given media stream 395 MUST contain a unique tag. 397 The ordering of multiple "a=crypto" lines is significant: The most 398 preferred crypto line is listed first. Each crypto attribute 399 describes the crypto-suite, key(s) and possibly session parameters 400 offered for the media stream. In general, a "more preferred" crypto- 401 suite SHOULD be cryptographically stronger than a "less preferred" 402 crypto-suite. 404 The crypto-suite always applies to media in the directions supported 405 by the media stream (e.g., send and receive). The key(s), however, 406 apply to media in the direction from the offerer to the answerer; if 407 the media stream is marked as "recvonly", a key MUST still be 408 provided. 410 This is done for consistency. Also, in the case of SRTP, for 411 example, secure RTCP will still be flowing in both the send and 412 receive direction for a unidirectional stream. 414 The offer may include session parameters. There are no general offer 415 rules for the session parameters; instead, specific rules may be 416 provided as part of the transport-specific definitions of any session 417 parameters. 419 When issuing an offer, the offerer MUST be prepared to support media 420 security in accordance with any of the crypto attributes included in 421 the offer. There are however two problems associated with this. 422 First of all, the offerer does not know which key the answerer will 423 be using for media sent to the offerer. Second, the offerer may not 424 be able to deduce which of the offered crypto attributes were 425 accepted. Since media may arrive prior to the answer, delay or 426 clipping can occur. If this is unacceptable to the offerer, the 427 offerer SHOULD use a mechanism outside the scope of this document to 428 prevent the above problem. 430 For example, in SIP [RFC3261], a "security" precondition as defined 431 in [sprecon] could solve the above problem. 433 5.1.2 Generating the Initial Answer - Unicast Streams 435 When the answerer receives the initial offer with one or more crypto 436 attributes for a given unicast media stream, the answerer MUST either 437 accept exactly one of the offered crypto attributes, or the offered 438 stream MUST be rejected. 440 If the answerer wishes to indicate support for other crypto 441 attributes, those can be listed by use of the SDP Simple Capability 442 Declaration [RFC3407] extensions. 444 Only crypto attributes that are valid can be accepted; valid 445 attributes do not violate any of the general rules defined for 446 security descriptions as well as any specific rules defined for the 447 transport and key-method in question. When selecting one of the 448 valid crypto attributes, the answerer SHOULD select the most 449 preferred crypto attribute it can support, i.e., the first valid 450 supported crypto attribute in the list, considering the answerer's 451 capabilities and security policies. 453 If there are one or more crypto attributes in the offer, but none of 454 them are valid, or none of the valid ones are supported, the offered 455 media stream MUST be rejected. 457 When an offered crypto attribute is accepted, the crypto attribute in 458 the answer MUST contain the following: 460 * The tag and crypto-suite from the accepted crypto attribute in the 461 offer (the same crypto-suite MUST be used in the send and receive 462 direction). 463 * The key(s) the answerer will be using for media sent to the 464 offerer. Note that a key MUST be provided, irrespective of any 465 direction attributes in the offer or answer. 467 Furthermore, any session parameters that are negotiated MUST be 468 included in the answer. Declarative session parameters provided by 469 the offerer are not included in the answer, however the answerer may 470 provide its own set of declarative session parameters. 472 Once the answerer has accepted one of the offered crypto attributes, 473 the answerer MAY begin sending media to the offerer in accordance 474 with the selected crypto attribute. Note however, that the offerer 475 may not be able to process such media packets correctly until the 476 answer has been received. 478 5.1.3 Processing of the Initial Answer - Unicast Streams 480 When the offerer receives the answer, the offerer MUST verify, that 481 one of the initially offered crypto suites and its accompanying tag 482 was accepted and echoed in the answer. Also, the answer MUST include 483 one or more keys, which will be used for media sent from the answerer 484 to the offerer. 486 If the offer contained any mandatory negotiated session parameters 487 (see section 6.3.7), the offerer MUST verify that said parameters are 488 included in the answer and support them. If the answer contains any 489 mandatory declarative session parameters, the offerer MUST be able to 490 support those. 492 If any of the above fails, the negotiation MUST fail. 494 5.1.4 Modifying the Session 496 Once a media stream has been established, it MAY be modified at any 497 time, as described in RFC 3264, Section 8. Such a modification MAY 498 be triggered by the security service, e.g., in order to perform a re- 499 keying or change the crypto-suite. If media stream security using 500 the general security descriptions defined here is still desired, the 501 crypto attribute MUST be included in these new offer/answer 502 exchanges. The procedures are similar to those defined in Section 503 5.1.1, 5.1.2, 5.1.3 of this document, subject to the considerations 504 provided in RFC 3264 Section 8. 506 5.2 Use Outside Offer/Answer 508 The crypto attribute can also be used outside the context of 509 offer/answer where there is no negotiation of the crypto suite, 510 cryptographic key or session parameters. In this case, the sender 511 determines security parameters for the stream. Since there is no 512 negotiation mechanisms, the sender MUST include exactly one crypto 513 attribute and the receiver MUST either accept it or else SHOULD NOT 514 receive the associated stream. The sender SHOULD select the security 515 description that it deems most secure for its purposes. 517 5.3 General Backwards Compatibility Considerations 519 In the offer/answer model, it is possible that the answerer supports 520 a given secure transport (e.g., "RTP/SAVP") and accepts the offered 521 media stream, yet the answerer does not support the crypto attribute 522 defined in this document and hence ignores it. The offerer can 523 recognize this situation by seeing an accepted media stream in the 524 answer that does not include a crypto line. In that case, the 525 security negotiation defined here MUST fail. 527 Similar issues exist when security descriptions are used outside of 528 the offer/answer model. But the source of a non-negotiated security 529 description has no indication that the receiver has ignored the 530 crypto attribute. 532 6 SRTP Security Descriptions 534 In this section, we provide definitions for security descriptions for 535 SRTP media streams. In the next section, we define how to use SRTP 536 security descriptions with and without the offer/answer model. 538 SRTP security descriptions MUST only be used with the SRTP transport 539 (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security 540 descriptions for the "RTP/SAVP" profile defined in [srtp], however it 541 is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can 542 use the same descriptions, which are in accordance with the SRTP 543 protocol specification [srtp]. 545 There is no assurance that an endpoint is capable of configuring its 546 SRTP service with a particular crypto attribute parameter, but SRTP 547 guarantees minimal interoperability among SRTP endpoints through the 548 default SRTP parameters [srtp]. More capable SRTP endpoints support 549 a variety of parameter values beyond the SRTP defaults and these 550 values can be configured by the SRTP security descriptions defined 551 here. An endpoint that does not support the crypto attribute will 552 ignore it according to the SDP. Such an endpoint will not correctly 553 process the particular media stream. By using the Offer/Answer 554 model, the offerer and answerer can negotiate the crypto parameters 555 to be used before commencement of the multimedia session (see Section 556 7.1). 558 There are over twenty cryptographic parameters listed in the SRTP 559 specification. Many of these parameters have fixed values for 560 particular cryptographic transforms. At the time of session 561 establishment, however, there is usually no need to provide unique 562 settings for many of the SRTP parameters, such as salt length and 563 pseudo-random function (PRF). Thus, it is possible to simplify the 564 list of parameters by defining "cryptographic suites" that fix a set 565 of SRTP parameter values for the security session. This approach is 566 followed by the SRTP security descriptions, which uses the general 567 security description parameters as follows: 569 * crypto-suite: Identifies the encryption and authentication 570 transforms 571 * key parameter: SRTP keying material and parameters 572 * session parameters: The following parameters are defined: 573 - KDR: The SRTP Key Derivation Rate is the rate that a 574 pseudo-random function is applied to a master key 575 - UNENCRYPTED_SRTP: SRTP messages are not encrypted 576 - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted 577 - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated 578 - FEC_ORDER: Order of forward error correction (FEC) 579 relative to SRTP services 580 - FEC_KEY: Master Key for FEC when the FEC stream is sent 581 to a separate address and/or port. 582 - WSH: Window Size Hint 583 - Extensions: Extension parameters can be defined 585 Please refer to the SRTP specification for a complete list of 586 parameters and their descriptions [Section 8.2, srtp]. Regarding the 587 UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security 588 descriptions MUST NOT use the SRTCP E-bit to override 589 UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP 590 messages (see Section 6.3.2). The key parameter, the crypto-suite, 591 and the session parameters shown above are described in detail in the 592 following subsections. 594 6.1 SRTP Key Parameter 596 SRTP security descriptions define use of the "inline" key method as 597 described in the following. Use of any other keying method, e.g., 598 URL, for SRTP security descriptions is for further study. 600 The "inline" type of key contains the keying material (master key 601 and salt) and all policy related to that master key, including how 602 long it can be used (lifetime) and whether or not it uses a master 603 key identifier (MKI) to associate an incoming SRTP packet with a 604 particular master key. Compliant implementations obey the policies 605 associated with a master key, and MUST NOT accept incoming packets 606 that violate the policy (e.g., after the master key lifetime has 607 expired). 609 The key parameter contains one or more cryptographic master keys, 610 each of which MUST be a unique cryptographically random [RFC1750] 611 value with respect to other master keys in the entire SDP message 612 (i.e., including master keys for other streams). Each key follows 613 the format (the formal definition is provided in Section 9.2): 615 "inline:" ["|" lifetime] ["|" MKI ":" length] 617 key||salt concatenated master key and salt, base64 encoded 618 (see [RFC3548], Section 3) 619 lifetime master key lifetime (max number of SRTP or SRTCP 620 packets using this master key) 621 MKI:length MKI and length of the MKI field in SRTP packets 623 The following definition provides an example for 624 AES_CM_128_HMAC_SHA1_80: 626 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 628 The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the 629 parameter is the cryptographic master key appended with the master 630 salt; the two are first concatenated and then base64 encoded. The 631 length of the concatenated key and salt is determined by the crypto- 632 suite for which the key applies. If the length (after being decoded 633 from base64) does not match that specified for the crypto-suite, the 634 crypto attribute in question MUST be considered invalid. Each master 635 key and salt MUST be a cryptographically random number and MUST be 636 unique to the entire SDP message. When base64 decoding the key and 637 salt, padding characters (i.e., one or two "=" at the end of the 638 base64 encoded data) are discarded (see [RFC3548] for details). 639 Base64 encoding assumes that the base64 encoding input is an integral 640 number of octets. If a given crypto-suite requires the use of a 641 concatenated key and salt with a length that is not an integral 642 number of octets, said crypto-suite MUST define a padding scheme that 643 results in the base64 input being an integral number of octets. For 644 example, if the length defined was 250 bits, then 6 padding bits 645 would be needed, which could be defined to be the last 6 bits in a 646 256 bit input. 648 The second field, is the OPTIONAL lifetime of the master key as 649 measured in maximum number of SRTP or SRTCP packets using that master 650 key (i.e., the number of SRTP packets and the number of SRTCP packets 651 each have to be less than the lifetime). The lifetime value MAY be 652 written as a non-zero, positive integer or as a power of 2 (see the 653 grammar in Section 9.2 for details). The "lifetime" value MUST NOT 654 exceed the maximum packet lifetime for the crypto-suite. If the 655 lifetime is too large or otherwise invalid then the entire crypto 656 attribute MUST be considered invalid. The default MAY be implicitly 657 signaled by omitting the lifetime (note that the lifetime field never 658 includes a colon, whereas the third field always does). This is 659 convenient when the SRTP cryptographic key lifetime is the default 660 value. As a shortcut to avoid long decimal values, the syntax of the 661 lifetime allows using the literal "2^", which indicates "two to the 662 power of". The example above, shows a case where the lifetime is 663 specified as 2^20. The following example, which is for the 664 AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime 665 field, which means that SRTP's and SRTCP's default values will be 666 used (see [srtp]): 668 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4 670 The example shows a 30-character key and concatenated salt that is 671 base64 encoded: The 30-character key/salt concatenation is expanded 672 to 40 characters by the three-in-four encoding of base64. 674 The third field, which is also OPTIONAL, is the Master Key Identifier 675 (MKI) and its byte length. 677 "MKI" is the master key identifier associated with the SRTP master 678 key. The MKI is here defined as a positive integer which is encoded 679 as a big-endian integer in the actual SRTP packets. If the MKI is 680 given, then the length of the MKI MUST also be given and separated 681 from the MKI by a colon (":"). The MKI length is the size of the MKI 682 field in the SRTP packet, specified in bytes. If the MKI length is 683 not given or its value exceeds 128 (bytes), then the entire crypto 684 attribute MUST be considered invalid. The substring "1:4" in the 685 first example assigns to the key a master key identifier of 1 that is 686 4 bytes long, and the second example assigns a 4-byte master key 687 identifier of 1066 to the key. One or more master keys with their 688 associated MKI can be initially defined, and then later updated, or 689 deleted and new ones defined. 691 SRTP offers a second feature for specifying the lifetime of a master 692 key in terms of two values, called "From" and "To," which are defined 693 on the SRTP sequence number space [srtp]. This SRTP Security 694 Descriptions specification, however, does not support the 695 <"From","To"> feature since the lifetime of an AES master key is 2^48 696 SRTP packets, which means that there is no cryptographic reason to 697 replace a master key for practical point-to-point applications. For 698 this reason, there is no need to support two means for signaling key 699 update. The MKI is chosen over <"From","To"> by this specification 700 for the very few applications that need it since the MKI feature is 701 simpler (though the MKI adds additional bytes to each packet whereas 702 <"From", "To"> does not). 704 As mentioned above, the key parameter can contain one or more master 705 keys. When the key parameter contains more than one master key, all 706 of the master keys in that key parameter MUST include an MKI value. 708 When using the MKI, the MKI length MUST be the same for all keys in a 709 given crypto attribute. 711 6.2 Crypto-suites 713 The SRTP crypto-suites define the encryption and authentication 714 transforms to be used for the SRTP media stream. The SRTP 715 specification has defined three crypto-suites, which are described 716 further in the following subsections in the context of the SRTP 717 security descriptions. The table below provides an overview of the 718 crypto-suites and their parameters: 720 +---------------------+-------------+--------------+---------------+ 721 | |AES_CM_128_ | AES_CM_128_ | F8_128_ | 722 | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | 723 +---------------------+-------------+--------------+---------------+ 724 | Master key length | 128 bits | 128 bits | 128 bits | 725 | Salt value | 112 bits | 112 bits | 112 bits | 726 | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | 727 | Cipher | AES Counter | AES Counter | F8 | 728 | | Mode | Mode | | 729 | Encryption key | 128 bits | 128 bits | 128 bits | 730 | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | 731 | Authentication tag | 80 bits | 32 bits | 80 bits | 732 | SRTP auth. key | 160 bits | 160 bits | 160 bits | 733 | SRTCP auth. key | 160 bits | 160 bits | 160 bits | 734 +---------------------+-------------+--------------+---------------+ 736 6.2.1 AES_CM_128_HMAC_SHA1_80 738 AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher 739 and HMAC-SHA1 message authentication having an 80-bit authentication 740 tag. The master-key length is 128 bits and has a default lifetime 741 of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes 742 first [Page 39, srtp]. 744 Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, 745 whichever comes first. SRTP security descriptions, however, 746 simplify the parameters to share a single upper bound of 2^31 747 packets. It is RECOMMENDED that automated key management allow 748 easy and efficient rekeying at intervals far smaller than 2^31 749 packets given today's media rates or even HDTV media rates. 751 The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP 752 and SRTCP authentication key lengths are 160 bits (see Security 753 Considerations in Section 8). The master salt value is 112 bits in 754 length and the session salt value is 112 bits in length. The 755 pseudo-random function (PRF) is the default SRTP pseudo-random 756 function that uses AES Counter Mode with a 128-bit key length. 758 The length of the base64 decoded key and salt value for this crypto- 759 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 760 attribute is considered invalid. 762 6.2.2 AES_CM_128_HMAC_SHA1_32 764 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except 765 that the authentication tag is 32 bits. 767 The length of the base64-decoded key and salt value for this crypto- 768 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 769 attribute is considered invalid. 771 6.2.3 F8_128_HMAC_SHA1_80 773 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the 774 cipher is F8 [srtp]. 776 The length of the base64 decoded key and salt value for this crypto- 777 suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto 778 attribute is considered invalid. 780 6.2.4 Adding new Crypto-suite Definitions 782 If new transforms are added to SRTP, new definitions for those 783 transforms SHOULD be given for the SRTP security descriptions and 784 published in a Standards Track RFC. Sections 6.2.1 through 6.2.3 785 illustrate how to define crypto-suite values for particular 786 cryptographic transforms. Any new crypto-suites MUST be registered 787 with IANA following the procedures in section 10. 789 6.3 Session Parameters 791 SRTP security descriptions define a set of "session" parameters, 792 which OPTIONALLY may be used to override SRTP session defaults for 793 the SRTP and SRTCP streams. These parameters configure an RTP 794 session for SRTP services. The session parameters provide session- 795 specific information to establish the SRTP cryptographic context. 797 6.3.1 KDR=n 799 KDR specifies the Key Derivation Rate, as described in section 4.3.1 800 of [srtp]. 802 The value n MUST be an integer in the set {1,2,...,24}, which 803 denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key 804 derivation rate controls how frequently a new session key is derived 805 from an SRTP master key(s) [srtp] given in the declaration. When 806 the key derivation rate is not specified (i.e., the KDR parameter is 807 omitted), a single initial key derivation is performed [srtp]. 809 In the offer/answer model, KDR is a declarative parameter. 811 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 813 SRTP and SRTCP packet payloads are encrypted by default. The 814 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the 815 default behavior of the crypto-suites with which they are used: 817 * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not 818 encrypted. 820 * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not 821 encrypted. 823 In the offer/answer model, these parameters are negotiated. If 824 UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit 825 MUST be clear (0) in all SRTCP messages. If the default is used, 826 all SRTCP messages are encrypted and the E bit MUST be set (1) on 827 all SRTCP messages. 829 6.3.3 UNAUTHENTICATED_SRTP 831 SRTP and SRTCP packet payloads are authenticated by default. The 832 UNAUTHENTICATED_SRTP session parameter signals that SRTP messages 833 are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT 834 RECOMMENDED (see Security Considerations). 836 The SRTP specification requires use of message authentication for 837 SRTCP, but not for SRTP [srtp]. 839 In the offer/answer model, this parameter is negotiated. 841 6.3.4 FEC_ORDER=order 843 FEC_ORDER signals the use of forward error correction for the RTP 844 packets [rfc2733]. The forward error correction values for "order" 845 are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied 846 before SRTP processing by the sender of the SRTP media and after SRTP 847 processing by the receiver of the SRTP media; FEC_SRTP is the 848 default. SRTP_FEC is the reverse processing. 850 In the offer/answer model, FEC_ORDER is a declarative parameter. 852 6.3.5 FEC_KEY=key-params 854 FEC_KEY signals the use of separate master key(s) for a Forward 855 Error Correction (FEC) stream. The master key(s) are specified with 856 the exact same format as the SRTP Key Parameter defined in Section 857 6.1, and the semantic rules are the same - in particular, the master 858 key(s) MUST be different from all other master key(s) in the SDP. A 859 FEC_KEY MUST be specified when the FEC stream is sent to a different 860 IP-address and/or port than the media stream to which it applies 861 (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. 862 When a FEC stream is sent to the same IP-address and port as the 863 media stream to which it applies, a FEC_KEY MUST NOT be specified. 864 If a FEC_KEY is specified in this latter case, the crypto attribute 865 in question MUST be considered invalid. 867 In the offer/answer model, FEC_KEY is a declarative parameter. 869 6.3.6 Window Size Hint (WSH) 871 SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to 872 protect against replay attacks. The minimum value is 64 [srtp], 873 however this value may be considered too low for some applications 874 (e.g., video). 876 The Window Size Hint (WSH) session parameter provides a hint for how 877 big this window should be to work satisfactorily (e.g., based on 878 sender knowledge of number of packets per second). However, there 879 might be enough information given in SDP attributes like 880 "a=maxprate" [maxprate] and the bandwidth modifiers to allow a 881 receiver to derive the parameter satisfactorily. Consequently, this 882 value is only considered a hint to the receiver of the SDP which MAY 883 choose to ignore the value provided. 885 In the offer/answer model, WSH is a declarative parameter. 887 6.3.7 Defining New SRTP Session Parameters 889 New SRTP session parameters for the SRTP security descriptions can 890 be defined in a Standards Track RFC and registered with IANA 891 according to the registration procedures defined in Section 10. 893 New SRTP session parameters are by default mandatory. A newly- 894 defined SRTP session parameter that is prefixed with the dash 895 character ("-") however is considered optional and MAY be ignored. 896 If an SDP crypto attribute is received with an unknown session 897 parameter that is not prefixed with a "-" character, that crypto 898 attribute MUST be considered invalid. 900 6.4 SRTP Crypto Context Initialization 902 In addition to the various SRTP parameters defined above, there are 903 three pieces of information that are critical to the operation of the 904 default SRTP ciphers: 906 * SSRC: Synchronization source 907 * ROC: Roll-over counter for a given SSRC 908 * SEQ: Sequence number for a given SSRC 909 In a unicast session, as defined here, there are three constraints on 910 these values. 912 The first constraint is on the SSRC, which makes an SRTP keystream be 913 unique from other participants. As explained in SRTP, the keystream 914 MUST NOT be reused on two or more different pieces of plaintext. 915 Keystream reuse makes the ciphertext vulnerable to cryptanalysis. 916 One vulnerability is that known-plaintext fields in one stream can 917 expose portions of the reused keystream and this could further expose 918 more plaintext in other streams. Since all current SRTP encryption 919 transforms use keystreams, key sharing is a general problem [srtp]. 920 SRTP mitigates this problem by including the SSRC of the sender in 921 the keystream. But SRTP does not solve this problem in its entirety 922 because Real-time Transport Protocol has SSRC collisions, which are 923 very rare [rtp] but quite possible. During a collision, two or more 924 SSRCs that share a master key will have identical keystreams for 925 overlapping portions of the RTP sequence-number space. SRTP Security 926 Descriptions avoids keystream reuse by making unique master keys 927 REQUIRED for the sender and receiver of the security description. 928 Thus, the first constraint is satisfied. 930 Also note, that there is a second problem with SSRC collisions: The 931 SSRC is used to identify the crypto context and thereby the cipher, 932 key, ROC, etc. to process incoming packets. In case of SSRC 933 collisions, crypto context identification becomes ambiguous and 934 correct packet processing may not occur. Furthermore, if an RTCP 935 BYE packet is to be sent for a colliding SSRC, that packet may also 936 have to be secured. In a (unicast) point-to-multipoint scenario, 937 this can be problematic for the same reasons, i.e., it is not known 938 which of the possible crypto contexts to use. Note that these 939 problems are not unique to the SDP security descriptions; any use 940 of SRTP needs to consider them. 942 The second constraint is that the ROC MUST be zero at the time that 943 each SSRC commences sending packets. Thus, there is no concept of a 944 "late joiner" in SRTP security descriptions, which are constrained to 945 be unicast and pairwise. The ROC and SEQ form a "packet index" in 946 the default SRTP transforms and the ROC is consistently set to zero 947 at session commencement, according to this document. 949 The third constraint is that the initial value of SEQ SHOULD be 950 chosen to be within the range of 0..2^15-1; this avoids an ambiguity 951 when packets are lost at the start of the session. If at the start 952 of a session, an SSRC source might randomly select a high sequence- 953 number value and put the receiver in an ambiguous situation: If 954 initial packets are lost in transit up to the point that the sequence 955 number wraps (i.e., exceeds 2^16-1), then the receiver might not 956 recognize that its ROC needs to be incremented. By restricting the 957 initial SEQ to the range of 0..2^15-1, SRTP packet-index 958 determination will find the correct ROC value, unless all of the 959 first 2^15 packets are lost (which seems, if not impossible, then 960 rather unlikely). See Section 3.3.1 of the SRTP specification 961 regarding packet-index determination [srtp]. 963 6.4.1 Late Binding of one or more SSRCs to a crypto context 965 The packet index, therefore, depends on the SSRC, the SEQ of an 966 incoming packet and the ROC, which is an SRTP crypto context 967 variable. Thus, SRTP has a big security dependency on SSRC 968 uniqueness. 970 Given the above constraints, unicast SRTP crypto contexts can be 971 established without the need to negotiate SSRC values in the SRTP 972 security descriptions. Instead, an approach called "late binding" is 973 RECOMMENDED by this specification. When a packet arrives, the SSRC 974 that is contained in it can be bound to the crypto context at the 975 time of session commencement (i.e., SRTP packet arrival) rather than 976 at the time of session signaling (i.e., receipt of an SDP). With the 977 arrival of the packet containing the SSRC, all the data items needed 978 for the SRTP crypto context are held by the receiver (note that the 979 ROC value by definition is zero; if non-zero values were to be 980 supported, additional signaling would be required). In other words, 981 the crypto context for a secure RTP session using late binding is 982 initially identified by the SDP as: 984 <*, address, port> 986 where '*' is a wildcard SSRC, "address" is the local receive address 987 from the "c=" line, and "port" is the local receive port from the 988 "m=" line. When the first packet arrives with ssrcX in its SSRC 989 field, the crypto context 991 993 is instantiated subject to the following constraints: 995 * Media packets are authenticated: Authentication MUST succeed; 996 otherwise, the crypto context is not instantiated. 998 * Media packets are not authenticated: Crypto context is 999 automatically instantiated. 1001 It should be noted, that use of late binding when there is no 1002 authentication of the SRTP media packets is subject to numerous 1003 security attacks and consequently it is NOT RECOMMENDED (of course, 1004 this can be said for unauthenticated SRTP in general). 1006 Note that use of late binding without authentication will result in 1007 local state being created as a result of receiving a packet from 1008 any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 1009 RECOMMENDED because it invites easy denial-of-service attack. In 1010 contrast, late binding with authentication does not suffer from 1011 this weakness. 1013 6.4.2 Sharing cryptographic contexts among Sessions or SSRCs 1015 With the constraints and procedures described above, it is not 1016 necessary to explicitly signal the SSRC, ROC and SEQ for a unicast 1017 RTP session. So there are no a=crypto parameters for signaling SSRC, 1018 ROC or SEQ. Thus, multiple SSRCs from the same entity will share 1019 a=crypto parameters when late binding is used. Multiple SSRCs from 1020 the same entity arises due to either multiple sources (microphones, 1021 cameras, etc.), or RTP payloads requiring SSRC multiplexing within 1022 that same session. SDP also allows multiple RTP sessions to be 1023 defined in the same media description ("m="), these RTP sessions will 1024 also share the a=crypto parameters. An application that uses 1025 a=crypto in this way serially shares a master key among RTP sessions 1026 or SSRCs and MUST replace the master key when the aggregate number of 1027 packets among all SSRCs approaches 2^31 packets. SSRCs that share a 1028 master key MUST be unique from one another. 1030 6.5 Removal of Crypto Contexts 1032 The mechanism defined above addresses the issue of creating crypto 1033 contexts, however in practice, session participants may want to 1034 remove crypto contexts prior to session termination. Since a crypto 1035 context contains information that can not automatically be recovered 1036 (e.g., ROC), it is important that the sender and receiver agree on 1037 when a crypto context can be removed, and perhaps more importantly 1038 when it cannot. 1040 Even when late binding is used for a unicast stream, the ROC is 1041 lost and cannot be recovered automatically (unless it is zero) once 1042 the crypto context is removed. 1044 We resolve this problem as follows. When SRTP security descriptions 1045 are being used, crypto-context removal MUST follow the same rules as 1046 SSRC removal from the member table [RFC 3550]; note that this can 1047 happen as the result of an SRTCP BYE packet or a simple time-out due 1048 to inactivity. Inactive session participants that wish to ensure 1049 their crypto contexts are not timed out MUST thus send SRTCP packets 1050 at regular intervals. 1052 7 SRTP-Specific Use of the crypto Attribute 1054 Section 5 describes general use of the crypto attribute, and this 1055 section completes it by describing SRTP-specific use. 1057 7.1 Use with Offer/Answer 1059 In this section, we describe how the SRTP security descriptions are 1060 used with the offer/answer model to negotiate cryptographic 1061 capabilities and communicate SRTP master keys. The rules defined 1062 below complement the general offer/answer rules defined in Section 1063 5.1, which MUST be followed, unless otherwise specified. Note that 1064 the rules below define unicast operation only; support for multicast 1065 and multipoint unicast streams is for further study. 1067 7.1.1 Generating the Initial Offer - Unicast Streams 1069 When the initial offer is generated, the offerer MUST follow the 1070 steps in Section 5.1.1 as well as the following steps. 1072 For each unicast media line (m=) using the secure RTP transport 1073 where the offerer wants to specify cryptographic parameters, the 1074 offerer MUST provide at least one valid SRTP security description 1075 ("a=crypto" line), as defined in Section 6. If the media stream 1076 includes Forward Error Correction with a different IP-address and/or 1077 port than the media stream itself, a FEC_KEY parameter MUST be 1078 included, as described in Section 6.3.5. 1080 The offerer MAY include one or more other SRTP session parameters as 1081 defined in Section 6.3. Note however, that if any SRTP session 1082 parameters are included that are not known to the answerer, but are 1083 nonetheless mandatory (see Section 6.3.6), the negotiation will fail 1084 if the answerer does not support them. 1086 7.1.2 Generating the Initial Answer - Unicast Streams 1088 When the initial answer is generated, the answerer MUST follow the 1089 steps in Section 5.1.2 as well as the following steps. 1091 For each unicast media line which uses the secure RTP transport and 1092 contains one or more "a=crypto" lines in the offer, the answerer 1093 MUST either accept one (and only one) of the crypto lines for that 1094 media stream, or it MUST reject the media stream. Only "a=crypto" 1095 lines that are considered valid SRTP security descriptions as 1096 defined in Section 6 can be accepted. Furthermore, all parameters 1097 (crypto-suite, key parameter, and mandatory session parameters) MUST 1098 be acceptable to the answerer in order for the offered media stream 1099 to be accepted. Note that if the media stream includes Forward 1100 Error Correction with a different IP-address and/or port than the 1101 media stream itself, a FEC_KEY parameter MUST be included, as 1102 described in Section 6.3.5. 1104 When the answerer accepts an SRTP unicast media stream with a crypto 1105 line, the answerer MUST include one or more master keys appropriate 1106 for the selected crypto algorithm; the master key(s) included in the 1107 answer MUST be different from those in the offer. 1109 When the master key(s) are not shared between the offerer and 1110 answerer, SSRC collisions between the offerer and answerer will not 1111 lead to keystream reuse, and hence SSRC collisions do not 1112 necessarily have to be prevented. 1114 If Forward Error Correction to a separate IP-address and/or port is 1115 included, the answer MUST include a FEC_KEY parameter, as described 1116 in Section 6.3.5. 1118 Declarative session parameters may be added to the answer as usual, 1119 however the answerer SHOULD NOT add any mandatory session parameter 1120 (see Section 6.3.6) that might be unknown to the offerer. 1122 If the answerer cannot find any valid crypto line that it supports, 1123 or if its configured policy prohibits any cryptographic key 1124 parameter (e.g., key length) or cryptographic session parameter 1125 (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it 1126 is able to successfully negotiate use of SRTP by other means outside 1127 the scope of this document (e.g., by use of MIKEY [mikey]). 1129 7.1.3 Processing of the Initial Answer - Unicast Streams 1131 When the offerer receives the answer, it MUST perform the steps in 1132 Section 5.1.3 as well as the following steps for each SRTP media 1133 stream it offered with one or more crypto lines in it. 1135 If the media stream was accepted and it contains a crypto line, it 1136 MUST be checked that the crypto line is valid according to the 1137 constraints specified in Section 6 (including any FEC constraints). 1139 If the offerer either does not support or is not willing to honor 1140 one or more of the SRTP parameters in the answer, the offerer MUST 1141 consider the crypto line invalid. 1143 If the crypto line is not valid, or the offerer's configured policy 1144 prohibits any cryptographic key parameter (e.g. key length) or 1145 cryptographic session parameter, the SRTP security negotiation MUST 1146 be deemed to have failed. 1148 7.1.4 Modifying the Session 1150 When a media stream using the SRTP security descriptions has been 1151 established, and a new offer/answer exchange is performed, the 1152 offerer and answerer MUST follow the steps in Section 5.1.4 as well 1153 as the following steps. 1155 When modifying the session, all negotiated aspects of the SRTP media 1156 stream can be modified. For example, a new crypto suite can be used 1157 or a new master key can be established. As described in RFC 3264, 1158 when doing a new offer/answer exchange there will be a window of 1159 time, where the offerer and the answerer must be prepared to receive 1160 media according to both the old and the new offer/answer exchange. 1162 This requirement applies here as well, however the following should 1163 be noted: 1165 * When authentication is not being used, it may not be possible for 1166 either the offerer or the answerer to determine if a given packet 1167 is encrypted according to the old or new offer/answer exchange. 1168 RFC 3264 defines a couple of techniques to address this problem, 1169 e.g., changing the payload types used and/or the transport 1170 addresses. Note however that a change in transport addresses may 1171 have an impact on Quality of Service as well as firewall and NAT 1172 traversal. The SRTP security descriptions use the MKI to deal with 1173 this (which adds a few bytes to each SRTP packet) as described in 1174 Section 6.1. For further details on the MKI, please refer to 1175 [srtp]. 1177 * If the answerer changes its master key, the offerer will not 1178 be able to process packets secured via this master key until the 1179 answer is received. This could be addressed by using a security 1180 "precondition" [sprecon]. 1182 If the offerer includes an IP address and/or port that differs from 1183 that used previously for a media stream (or FEC stream), the offerer 1184 MUST include a new master key with the offer (and in so doing, it 1185 will be creating a new crypto context with the ROC set to zero). 1186 Similarly, if the answerer includes an IP address and/or port that 1187 differs from that used previously for a media stream (or FEC 1188 stream), the answerer MUST include a new master key with the offer 1189 (and hence create a new crypto context with the ROC set to zero). 1190 The reason for this is, that when the answerer receives an offer, or 1191 the offerer receives an answer, with an updated IP address and/or 1192 port, it is not possible to determine if the other side has access 1193 to the old crypto context parameters (and in particular the ROC) or 1194 not. For example, if one side is a decomposed gateway, or a back- 1195 to-back user agent is involved, it is possible that the media 1196 endpoint changed and no longer has access to the old crypto context. 1197 By always requiring a new master key in this case, the 1198 answerer/offerer will know that the ROC is zero for this 1199 offer/answer, and any key lifetime constraints will trivially be 1200 satisfied too. Another consideration here applies to media relays; 1201 if the relay changes the media endpoint on one side transparently to 1202 the other side, the relay cannot operate as a simple packet 1203 reflector but will have to actively engage in SRTP packet processing 1204 and transformation (i.e., decryption and re-encryption, etc.). 1206 Finally note, that if the new offer is rejected, the old crypto 1207 parameters remain in place. 1209 7.1.5 Offer/Answer Example 1211 In this example, the offerer supports two crypto suites (f8 and AES). 1212 The a=crypto line is actually one long line, although it is shown as 1213 two lines in this document due to page formatting. The f8 example 1214 shows two inline parameters; as explained in Section 6.1, there may 1215 be one or more key (i.e. inline) parameters in a crypto attribute. 1216 In this way, multiple keys are offered to support key rotation using 1217 a master key index (MKI). 1219 Offerer sends: 1220 v=0 1221 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 1222 s=SRTP Discussion 1223 i=A discussion of Secure RTP 1224 u=http://www.example.com/seminars/srtp.pdf 1225 e=marge@example.com (Marge Simpson) 1226 c=IN IP4 168.2.17.12 1227 t=2873397496 2873404696 1228 m=audio 49170 RTP/SAVP 0 1229 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1230 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1231 FEC_ORDER=FEC_SRTP 1232 a=crypto:2 F8_128_HMAC_SHA1_80 1233 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1234 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1235 FEC_ORDER=FEC_SRTP 1237 Answerer replies: 1238 v=0 1239 o=jill 25690844 8070842634 IN IP4 10.47.16.5 1240 s=SRTP Discussion 1241 i=A discussion of Secure RTP 1242 u=http://www.example.com/seminars/srtp.pdf 1243 e=homer@example.com (Homer Simpson) 1244 c=IN IP4 168.2.17.11 1245 t=2873397526 2873405696 1246 m=audio 32640 RTP/SAVP 0 1247 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1248 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1250 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 1251 crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80 1252 were selected by the answerer, there would be two inline keys 1253 associated with the SRTP cryptographic context. One key has an MKI 1254 value of 1 and the second has an MKI of 2. 1256 7.2 SRTP-Specific Use Outside Offer/Answer 1258 Use of SRTP security descriptions outside the offer/answer model is 1259 not defined. 1261 Use of SRTP security descriptions outside offer/answer could have 1262 been defined for sendonly media streams, however, there would not 1263 be a way to indicate the key to use for SRTCP by the receiver of 1264 said media stream. 1266 7.3 Support for SIP Forking 1268 As mentioned earlier, the security descriptions defined here do not 1269 support multicast media streams or multipoint unicast streams. 1270 However, in the SIP protocol, it is possible to receive several 1271 answers to a single offer due to the use of forking (see [SIP]). 1272 Receiving multiple answers leads to a couple of problems for the 1273 SRTP security descriptions: 1275 * Different answerers may choose different ciphers, keys, etc., 1276 however there is no way for the offerer to associate a particular 1277 incoming media packet with a particular answer. 1279 * Two or more answerers may pick the same SSRC and hence the SSRC 1280 collision problems mentioned earlier may arise. 1282 As stated earlier, the above point-to-multipoint cases are outside 1283 the scope of the SDP security descriptions. However, there is a way 1284 of supporting SIP forking: Change the multipoint scenario resulting 1285 from SIP forking into multiple two-party unicast cases. This is 1286 done as follows: 1288 For each answer received beyond the initial answer, issue a new 1289 offer to that particular answerer using a new receive transport 1290 address (IP address and port); note that this requires support for 1291 the SIP UPDATE method [RFC 3313]. Also, to ensure that two media 1292 sessions are not inadvertently established prior to the UPDATE being 1293 processed by one of them, use security preconditions [sprecon]. 1295 Finally, note that all SIP User Agents that received the offer will 1296 know the key(s) being proposed by the initial offer. If the offerer 1297 wants to ensure security with respect to all other User Agents that 1298 may have received the offer, a new offer/answer exchange with a new 1299 key needs to be performed with the answerer as well. It should be 1300 noted, that the offerer cannot determine whether a single or 1301 multiple SIP User Agents received the offer, since intermediate 1302 forking proxies may only forward a single answer to the offerer. 1304 7.4 SRTP-Specific Backwards Compatibility Considerations 1306 It is possible that the answerer supports the SRTP transport and 1307 accepts the offered media stream, yet it does not support the crypto 1308 attribute defined here. The offerer can recognize this situation by 1309 seeing an accepted SRTP media stream in the answer that does not 1310 include a crypto line. In that case, the security negotiation 1311 defined here MUST be deemed to have failed. 1313 Also, if a media stream with a given SRTP transport (e.g., 1314 "RTP/SAVP") is sent to a device that does not support SRTP, that 1315 media stream will be rejected. 1317 7.5 Operation with KEYMGT= and k= lines 1319 An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. 1320 Per SDP rules, the answerer will ignore attribute lines that it does 1321 not understand. If the answerer supports both "a=crypto" and 1322 "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" 1323 but not both, as including both is undefined. 1325 An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP 1326 rules, the answerer will ignore attribute lines it does not 1327 understand. If the answerer supports both "a=crypto" and "k=", the 1328 answer MUST include either "a=crypto" or "k=" but not both, as 1329 including both is undefined. 1331 8 Security Considerations 1333 Like all SDP messages, SDP messages containing security 1334 descriptions, are conveyed in an encapsulating application protocol 1335 (e.g., SIP, MGCP, etc.). It is the responsibility of the 1336 encapsulating protocol to ensure the protection of the SDP security 1337 descriptions. Therefore, IT IS REQUIRED that the application invoke 1338 its own security mechanisms (e.g., secure multiparts such as S/MIME 1339 [smime]) or alternatively utilize a lower-layer security service 1340 (e.g., TLS, or IPsec). IT IS REQUIRED that this security service 1341 provide strong message authentication and packet-payload encryption 1342 as well as effective replay protection. 1344 "Replay protection" is needed against an attacker that has enough 1345 access to the communications channel to intercept messages and 1346 deliver copies to the destination. A successful replay attack will 1347 cause the recipient to perform duplicate processing on a message; 1348 the attack is worse when the duped recipient sends a duplicate reply 1349 to the initiator. Replay protections are not found in S/MIME or in 1350 the other secure-multiparts standard, PGP/MIME. S/MIME and 1351 PGP/MIME, therefore need to be augmented with some replay-protection 1352 mechanism that is appropriate to the encapsulating application 1353 protocol (e.g. SIP, MGCP, etc.). Three common ways to provide 1354 replay protection are to place a sequence number in the message, use 1355 a timestamp, or for the receiver to keep a hash of the message to 1356 compare with incoming messages. There typically needs to be a 1357 replay "window" and some policy for keeping state information from 1358 previous messages in a "replay table" or list. 1360 The discussion which follows uses "message authentication" and 1361 "message confidentiality" in a consistent manner with SRTP 1362 [RFC3711]. "Message confidentiality" means that only the holder of 1363 the secret decryption key can access the plain-text content of the 1364 message. The decryption key is the same key as the encryption key 1365 using SRTP counter mode and f8 encryption transforms, which are 1366 vulnerable to message tampering and need SRTP message authentication 1367 to detect such tampering. "Message authentication" and "message 1368 integrity validation" generally mean the same thing in IETF security 1369 standards: An SRTP message is authenticated following a successful 1370 HMAC integrity check [RFC3711], which proves that the message 1371 originated from the holder of an SRTP master key and was not altered 1372 en route. Such an "authentic" message, however, can be captured by 1373 an attacker and "replayed" when the attacker re-inserts the packet 1374 into the channel. A replayed packet can have a variety of bad 1375 effects on the session, and SRTP uses the extended sequence number 1376 to detect replayed SRTP packets [RFC3711]. 1378 The SRTP specification identifies which services and features are 1379 default values that are normative-to-implement (such as 1380 AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32). 1382 8.1 Authentication of packets 1384 Security descriptions as defined herein signal security services for 1385 RTP packets. RTP messages are vulnerable to a variety of attacks 1386 such as replay and forging. To limit these attacks, SRTP message 1387 integrity mechanisms SHOULD be used (SRTP replay protection is 1388 always enabled). 1390 8.2 Keystream Reuse 1392 SRTP security descriptions signal configuration parameters for SRTP 1393 sessions. Misconfigured SRTP sessions are vulnerable to attacks on 1394 their encryption services when running the crypto suites defined in 1395 Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is 1396 "misconfigured" when two or more media streams are encrypted using 1397 the same keystream of AES blocks. When senders and receivers share 1398 derived session keys, SRTP requires that the SSRCs of session 1399 participants serve to make their corresponding keystreams unique, 1400 which is violated in the case of SSRC collision: SRTP SSRC collision 1401 drastically weakens SRTP or SRTCP payload encryption during the time 1402 that identical keystreams were used [srtp]. An attacker, for 1403 example, might collect SRTP and SRTCP messages and await a 1404 collision. This attack on the AES-CM and AES-f8 encryption is 1405 avoided entirely when each media stream has its own unique master 1406 key in both the send and receive direction. This specification 1407 restricts use of SDP security description to unicast point-to-point 1408 streams so that keys are not shared between SRTP hosts, and the 1409 master keys used in the send and receive direction for a given media 1410 stream are unique. 1412 8.3 Signaling Authentication and Signaling Encryption 1414 There is no reason to incur the complexity and computational expense 1415 of SRTP, however, when its key establishment is exposed to 1416 unauthorized parties. In most cases, the SRTP crypto attribute and 1417 its parameters are vulnerable to denial of service attacks when they 1418 are carried in an unauthenticated SDP message. In some cases, the 1419 integrity or confidentiality of the RTP stream can be compromised. 1420 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 1421 an offer, this could result in the answerer not decrypting the 1422 encrypted SRTP messages. In the worst case, the answerer might 1423 itself send unencrypted SRTP and leave its data exposed to snooping. 1425 Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or 1426 some other data security service be used to provide message 1427 authentication for the encapsulating protocol that carries the SDP 1428 messages having a crypto attribute (a=crypto). Furthermore, IT IS 1429 REQUIRED that encryption of the encapsulating payload be used 1430 whenever a master key parameter (inline) appears in the message. 1431 Failure to encrypt the SDP message containing an inline SRTP master 1432 key renders the SRTP authentication or encryption service useless in 1433 practically all circumstances. Failure to authenticate an SDP 1434 message that carries SRTP parameters renders the SRTP authentication 1435 or encryption service useless in most practical applications. 1437 When the communication path of the SDP message is routed through 1438 intermediate systems that inspect parts of the SDP message, security 1439 protocols such as IPsec or TLS SHOULD NOT be used for encrypting 1440 and/or authenticating the security description. In the case of 1441 intermediate-system processing of a message containing SDP security 1442 descriptions, the "a=crypto" attributes SHOULD be protected end-to- 1443 end so that the intermediate system can neither modify the security 1444 description nor access the keying material. Network or transport 1445 security protocols that terminate at each intermediate system, 1446 therefore, SHOULD NOT be used for protecting SDP security 1447 descriptions. A security protocol SHOULD allow the security 1448 descriptions to be encrypted and authenticated end-to-end 1449 independently of the portions of the SDP message that any 1450 intermediate system modifies or inspects: MIME secure multiparts 1451 are RECOMMENDED for the protection of SDP messages that are 1452 processed by intermediate systems. 1454 9 Grammar 1456 In this section we first provide the ABNF grammar for the generic 1457 crypto attribute, and then we provide the ABNF grammar for the SRTP 1458 specific use of the crypto attribute. 1460 9.1 Generic "Crypto" Attribute Grammar 1462 The ABNF grammar for the crypto attribute is defined below: 1464 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params 1465 *(1*WSP session-param) 1467 tag = 1*9DIGIT 1468 crypto-suite = 1*(ALPHA / DIGIT / "_") 1470 key-params = key-param *(";" key-param) 1471 key-param = key-method ":" key-info 1472 key-method = "inline" / key-method-ext 1473 key-method-ext = 1*(ALPHA / DIGIT / "_") 1474 key-info = %x21-3A / %x3C-7E ; visible (printing) characters 1475 ; except semi-colon 1476 session-param = 1*(VCHAR) ; visible (printing) characters 1478 where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. 1480 9.2 SRTP "Crypto" Attribute Grammar 1482 This section provides an Augmented BNF [RFC2234] grammar for the 1483 SRTP-specific use of the SDP crypto attribute: 1485 crypto-suite = srtp-crypto-suite 1486 key-method = srtp-key-method 1487 key-info = srtp-key-info 1488 session-param = srtp-session-param 1490 srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 1491 "F8_128_HMAC_SHA1_32" / 1492 "AES_CM_128_HMAC_SHA1_80" / 1493 srtp-crypto-suite-ext 1495 srtp-key-method = "inline" 1496 srtp-key-info = key-salt ["|" lifetime] ["|" mki] 1498 key-salt = 1*(base64) ; binary key and salt values 1499 ; concatenated together, and then 1500 ; base64 encoded [section 6.8 of 1501 ; RFC2046] 1503 lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^" 1504 mki = mki-value ":" mki-length 1505 mki-value = 1*DIGIT 1506 mki-length = 1*3DIGIT ; range 1..128. 1508 srtp-session-param = kdr / 1509 "UNENCRYPTED_SRTP" / 1510 "UNENCRYPTED_SRTCP" / 1511 "UNAUTHENTICATED_SRTP" / 1512 fec-order / 1513 fec-key / 1514 wsh / 1515 srtp-session-extension 1517 kdr = "KDR=" 1*2(DIGIT) ; range 0..24, 1518 ; power of two 1520 fec-order = "FEC_ORDER=" fec-type 1521 fec-type = "FEC_SRTP" / "SRTP_FEC" 1522 fec-key = "FEC_KEY=" key-params 1524 wsh = "WSH=" 2*DIGIT ; minimum value is 64 1525 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1527 srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") 1528 srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] 1529 ; first character must not be dash ("-") 1531 10 IANA Considerations 1533 10.1 Registration of the "crypto" attribute 1535 The IANA is hereby requested to register a new SDP attribute as 1536 follows: 1538 Attribute name: crypto 1539 Long form name: Security description cryptographic attribute 1540 for media streams 1541 Type of attribute: Media-level 1542 Subject to charset: No 1543 Purpose: Security descriptions 1544 Appropriate values: See Section 4 1546 10.2 New IANA Registries and Registration Procedures 1548 The following sub-sections define a new IANA registry with associated 1549 sub-registries to be used for the SDP security descriptions. The 1550 IANA is hereby requested to create an SDP Security Description 1551 registry as shown below and further described in the following 1552 sections: 1554 SDP Security Descriptions 1555 | 1556 +- Key Methods (described in 10.2.1) 1557 | 1558 +- Media Stream Transports (described in 10.2.2) 1559 | 1560 +- Transport1 (e.g. SRTP) 1561 | | 1562 | +- Supported Key Methods (e.g. inline) 1563 | | 1564 | +- crypto suites 1565 | | 1566 | +- session parameters 1567 | 1568 +- Transport2 1569 : : 1571 10.2.1 Key Method Registry and Registration 1573 The IANA is hereby requested to create a new subregistry for SDP 1574 security description key methods. An IANA key method registration 1575 MUST be documented in an RFC in accordance with the RFC 2434 1576 Standards Action and it MUST provide the name of the key method in 1577 accordance with the grammar for key-method-ext defined in Section 1578 9.1. 1580 10.2.2 Media Stream Transport Registry and Registration 1582 The IANA is hereby requested to create a new subregistry for SDP 1583 security description Media Stream Transports. An IANA media stream 1584 transport registration MUST be documented in an RFC in accordance 1585 with the RFC 2434 Standards Action and the procedures defined in 1586 Section 4 and 5 of this document. The registration MUST provide the 1587 name of the transport and a list of supported key methods. 1589 In addition, each new media stream transport registry must contain a 1590 crypto-suite registry and a session parameter registry as well as 1591 IANA instructions for how to populate these registries. 1593 10.3 Initial Registrations 1595 10.3.1 Key Method 1597 The following security descriptions key methods are hereby 1598 registered: 1600 inline 1602 10.3.2 SRTP Media Stream Transport 1604 The IANA is hereby requested to create an SDP Security Description 1605 Media Stream Transport subregistry for "SRTP". The key methods 1606 supported is "inline". The reference for the SDP security 1607 description for SRTP is this document. 1609 10.3.2.1 SRTP Crypto Suite Registry and Registration 1611 The IANA is hereby requested to create a new subregistry for SRTP 1612 crypto suites under the SRTP transport of the SDP Security 1613 Descriptions. An IANA SRTP crypto suite registration MUST indicate 1614 the crypto suite name in accordance with the grammar for srtp- 1615 crypto-suite-ext defined in Section 9.2. 1617 The semantics of the SRTP crypto suite MUST be described in an RFC 1618 in accordance with the RFC 2434 Standards Action, including the 1619 semantics of the "inline" key-method and any special semantics of 1620 parameters. 1622 The following SRTP crypto suites are hereby registered: 1624 AES_CM_128_HMAC_SHA1_80 1625 AES_CM_128_HMAC_SHA1_32 1626 F8_128_HMAC_SHA1_80 1628 The reference for these crypto-suites is provided in this document. 1630 10.3.2.2 SRTP Session Parameter Registration 1632 The IANA is hereby requested to create a new subregistry for SRTP 1633 session parameters under the SRTP transport of the SDP Security 1634 Descriptions. An IANA SRTP session parameter registration MUST 1635 indicate the session parameter name (srtp-session-extension as 1636 defined in Section 9.2); the name MUST NOT begin with the dash 1637 character ("-"). 1639 The semantics of the parameter MUST be described in an RFC in 1640 accordance with the RFC 2434 Standards Action. If values can be 1641 assigned to the parameter, then the format and possible values that 1642 can be assigned MUST be described in the RFC in accordance with the 1643 RFC 2434 Standards Action as well. Also, it MUST be specified 1644 whether the parameter is declarative or negotiated in the 1645 offer/answer model. 1647 The following SRTP session parameters are hereby registered: 1649 KDR 1650 UNENCRYPTED_SRTP 1651 UNENCRYPTED_SRTCP 1652 UNAUTHENTICATED_SRTP 1653 FEC_ORDER 1654 FEC_KEY 1655 WSH 1657 The reference for these parameters is this document. 1659 11 Acknowledgements 1661 This document is a product of the IETF MMUSIC working group and has 1662 benefited from comments from its participants. This document also 1663 benefited from discussions with Elisabetta Cararra, Earl Carter, 1664 Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David 1665 McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, 1666 Mike Thomas, Brian Weis, and Magnus Westerlund. 1668 12 Authors' Addresses 1670 Flemming Andreasen 1671 Cisco Systems, Inc. 1672 499 Thornall Street, 8th Floor 1673 Edison, New Jersey 08837 USA 1674 fandreas@cisco.com 1676 Mark Baugher 1677 5510 SW Orchid Street 1678 Portland, Oregon 97219 USA 1679 mbaugher@cisco.com 1681 Dan Wing 1682 Cisco Systems, Inc. 1683 170 West Tasman Drive 1684 San Jose, CA 95134 USA 1685 dwing@cisco.com 1687 13 Normative References 1689 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1690 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 1691 STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt. 1693 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1694 Specifications: ABNF," RFC 2234, November 1997, 1695 http://www.ietf.org/rfc/rfc2234.txt. 1697 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1698 RFC 2327, April 1998. 1700 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 1701 2000, http://www.ietf.org/rfc/rfc2828.txt. 1703 [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1704 the Session Description Protocol (SDP)", RFC 3264, June 2202, 1705 http://www.ietf.org/rfc/rfc3264.txt. 1707 [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 1708 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 1710 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 1711 Recommendations for Security", RFC 1750, December 1994, 1712 http://www.ietf.org/rfc/rfc1750.txt. 1714 [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data 1715 Encodings", RFC 3548, July 2003. 1717 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1718 Considerations Section in RFCs", RFC 2434, October 1998. 1720 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security 1721 Preconditions for Session Description Protocol Media Streams", work 1722 in progress, February 2004. 1724 14 Informative References 1726 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1727 Capability Declaration", RFC 3407, October 2002, 1728 http://www.ietf.org/rfc/rfc3407.txt. 1730 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 1731 Protocols," in Proceedings of the Sixth Usenix Unix Security 1732 Symposium, pp. 1-16, San Jose, CA, July 1996. 1734 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1735 Domain of Interpretation", RFC 3547, July 2003, 1736 http://www.ietf.org/rfc/rfc3547.txt. 1738 [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of 1739 Keys (KINK)", Work in Progress. 1741 [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 1742 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 1744 [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the 1745 Internet Protocol", RFC 2401, November 1998, 1746 http://www.ietf.org/rfc/rfc2401.txt. 1748 [maxprate] Westerlund, M., "A Transport-independent Bandwidth 1749 Modifier for the Session Description Protocol (SDP)," April 2004, 1750 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam- 1751 06.txt 1753 [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for 1754 Generic Forward Error Correction", RFC 2733, December 1999, 1755 http://www.ietf.org/rfc/rfc2733.txt. 1757 [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 1758 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 1760 [pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy 1761 (PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. 1763 [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1764 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 1766 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1767 "Key Management Extensions for SDP and RTSP", Work in Progress. 1769 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1770 "MIKEY: Multimedia Internet KEYing", Work in Progress. 1772 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1773 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1774 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1776 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1777 for Message Authentication", RFC 2014, November 1997, 1778 http://www.ietf.org/rfc/rfc2104.txt. 1780 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1781 Mechanism for the Internet", ISOC Secure Networks and Distributed 1782 Systems Symposium, San Diego, 1996. 1784 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 1785 Resource Management and Session Initiation Protocol (SIP)", RFC 1786 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 1788 [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement 1789 Protocol", RFC 2974, October 2000, 1790 http://www.ietf.org/rfc/rfc2974.txt. 1792 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1793 RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. 1795 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1796 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1797 Session Initiation Protocol", RFC 3261, June 2002. 1799 15 Full Copyright Statement 1801 Copyright (C) The Internet Society (2005). This document is subject 1802 to the rights, licenses and restrictions contained in BCP 78, and 1803 except as set forth therein, the authors retain all their rights. 1805 This document and the information contained herein are provided on 1806 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1807 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1808 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1809 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1810 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1811 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1813 Intellectual Property 1815 The IETF takes no position regarding the validity or scope of any 1816 Intellectual Property Rights or other rights that might be claimed 1817 to pertain to the implementation or use of the technology 1818 described in this document or the extent to which any license 1819 under such rights might or might not be available; nor does it 1820 represent that it has made any independent effort to identify any 1821 such rights. Information on the procedures with respect to 1822 rights in RFC documents can be found in BCP 78 and BCP 79. 1824 Copies of IPR disclosures made to the IETF Secretariat and any 1825 assurances of licenses to be made available, or the result of an 1826 attempt made to obtain a general license or permission for the use 1827 of such proprietary rights by implementers or users of this 1828 specification can be obtained from the IETF on-line IPR repository 1829 at http://www.ietf.org/ipr. 1831 The IETF invites any interested party to bring to its attention 1832 any copyrights, patents or patent applications, or other 1833 proprietary rights that may cover technology that may be required 1834 to implement this standard. Please address the information to the 1835 IETF at ietf-ipr@ietf.org. 1837 Acknowledgement 1839 Funding for the RFC Editor function is currently provided by the 1840 Internet Society.