idnits 2.17.1 draft-ietf-mmusic-sdescriptions-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 214: '...ine. The "crypto" attribute MUST only...' RFC 2119 keyword, line 236: '...ion 8.1 for details). The tag MUST be...' RFC 2119 keyword, line 278: '... New key methods MUST be registered wi...' RFC 2119 keyword, line 283: '... semantics MUST be provided in a Sta...' RFC 2119 keyword, line 290: '...uded in the key parameters, it MUST be...' (122 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 548 has weird spacing: '...applied to a ...' == Line 1296 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: 'RFC2119' is mentioned on line 124, but not defined == Missing Reference: 'TLS' is mentioned on line 177, but not defined == Missing Reference: 'RFC 3550' is mentioned on line 996, but not defined == Missing Reference: 'SIP' is mentioned on line 1215, but not defined == Missing Reference: 'RFC 3313' is mentioned on line 1235, but not defined == Unused Reference: 'RFC3550' is defined on line 1620, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1631, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1652, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 1661, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1698, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 1706, but no explicit reference was found in the text == Unused Reference: 'RFC2974' is defined on line 1710, 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 2733 (Obsoleted by RFC 5109) ** 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) Summary: 11 errors (**), 0 flaws (~~), 19 warnings (==), 3 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: November 2004 Cisco Systems 6 May, 2004 8 Session Description Protocol Security Descriptions 9 for Media Streams 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines a Session Description Protocol (SDP) 40 cryptographic attribute for unicast media streams. The attribute 41 describes a cryptographic key and other parameters, which serve to 42 configure security for a unicast media stream in either a single 43 message or a roundtrip exchange. The attribute can be used with a 44 variety of SDP media transports and this document defines how to use 45 it for the Secure Real-time Transport Protocol (SRTP) unicast media 46 streams. The SDP crypto attribute requires the services of a data 47 security protocol to secure the SDP message. 49 Table of Contents 51 1. Notational Conventions............................................3 52 2. Introduction......................................................3 53 3. SDP "Crypto" Attribute and Parameters.............................5 54 3.1 Tag.............................................................5 55 3.2 Crypto-suite....................................................5 56 3.3 Key Parameters..................................................6 57 3.4 Session Parameters..............................................7 58 3.5 Example.........................................................7 59 4. General Use of the crypto Attribute...............................8 60 4.1 Use With Offer/Answer...........................................8 61 4.1.1 Generating the Initial Offer - Unicast Streams............8 62 4.1.2 Generating the Initial Answer - Unicast Streams...........9 63 4.1.3 Offerer Processing of the Initial Answer - Unicast Streams10 64 4.1.4 Modifying the Session....................................10 65 4.2 Use Outside Offer/Answer.......................................10 66 4.3 General Backwards Compatibility Considerations.................10 67 5. SRTP Security Descriptions.......................................11 68 5.1 SRTP Key Parameter.............................................12 69 5.2 Crypto-suites..................................................14 70 5.2.1 AES_CM_128_HMAC_SHA1_80..................................15 71 5.2.2 AES_CM_128_HMAC_SHA1_32..................................15 72 5.2.3 F8_128_HMAC_SHA1_80......................................16 73 5.2.4 Adding new Crypto-suite Definitions......................16 74 5.3 Session Parameters.............................................16 75 5.3.1 KDR=n....................................................16 76 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16 77 5.3.3 UNAUTHENTICATED_SRTP.....................................17 78 5.3.4 FEC_ORDER=order..........................................17 79 5.3.5 FEC_KEY=key-params.......................................17 80 5.3.6 Window Size Hint (WSH)...................................18 81 5.3.7 Defining New SRTP Session Parameters.....................18 82 5.4 SRTP Crypto Context Initialization.............................18 83 5.5 Removal of Crypto Contexts.....................................20 84 6. SRTP-Specific Use of the crypto Attribute........................21 85 6.1 Use with Offer/Answer..........................................21 86 6.1.1 Generating the Initial Offer - Unicast Streams...........21 87 6.1.2 Generating the Initial Answer - Unicast Streams..........22 88 6.1.3 Offerer Processing of the Initial Answer - Unicast Streams22 89 6.1.4 Modifying the Session....................................23 90 6.1.5 Offer/Answer Example.....................................24 91 6.2 SRTP-Specific Use Outside Offer/Answer.........................25 92 6.3 Support for SIP Forking........................................25 93 6.4 SRTP-Specific Backwards Compatibility Considerations...........26 94 6.5 Operation with KEYMGT= and k= lines............................26 95 7. Security Considerations..........................................26 96 7.1 Authentication of packets......................................26 97 7.2 Keystream Reuse................................................27 98 7.3 Signaling Authentication and Signaling Encryption..............27 99 8. Grammar..........................................................28 100 8.1 Generic "Crypto" Attribute Grammar.............................28 101 8.2 SRTP "Crypto" Attribute Grammar................................29 102 9. IANA Considerations..............................................30 103 9.1 Registration of the "crypto" attribute.........................30 104 9.2 New IANA Registries and Registration Procedures................30 105 9.2.1 Security Descriptions Key Method Registry and Registration31 106 9.2.2 Security Description Media Stream Transport Registry and 107 Registration.....................................................31 108 9.3 Initial Registrations..........................................31 109 9.3.1 Key Method...............................................31 110 9.3.2 SRTP Media Stream Transport..............................31 111 10. Acknowledgements................................................32 112 11. Authors' Addresses..............................................33 113 12. Normative References............................................33 114 13. Informative References..........................................34 115 Intellectual Property Statement.....................................35 116 Acknowledgement.....................................................36 118 1. Notational Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 121 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 122 be interpreted as described in [RFC2119]. The terminology in this 123 document conforms to [RFC2828], "Internet Security Glossary". 125 n^r is exponentiation where n is multiplied by itself r times; n and 126 r are integers. 0..k is an integer range of all integers from 0 127 through k inclusive. 129 The terms 'transport' and 'media transport' are used to mean 130 'transport protocol' as defined in RFC2327, page 20. 132 Explanatory notes are provided in several places throughout the 133 document; these notes are indented two spaces from the surrounding 134 text. 136 2. Introduction 138 The Session Description Protocol (SDP) [SDP] describes multimedia 139 sessions, which can be audio, video, whiteboard, fax, modem, and 140 other media streams. Security services such as data origin 141 authentication, integrity and confidentiality are often needed for 142 those streams. The Secure Real-time Transport Protocol (SRTP) 143 [srtp] provides security services for RTP media and is signaled by 144 use of secure RTP transport (e.g., "RTP/SAVP" or "RTP/SAVPF") in an 145 SDP media (m=) line. However, there are no means within SDP itself 146 to configure SRTP beyond using default values. This document 147 specifies a new SDP attribute called "crypto", which is used to 148 signal and negotiate cryptographic parameters for media streams in 149 general, and SRTP in particular. The definition of the crypto 150 attribute in this document is limited to two-party unicast media 151 streams where each source has a unique cryptographic key; support 152 for multicast media streams or multipoint unicast streams is for 153 further study. 155 The crypto attribute is defined in a generic way to enable its use 156 with SRTP and any other secure transports that can establish 157 cryptographic parameters with only a single message or in a single 158 round-trip exchange using the offer/answer model [RFC3264]. 159 Extension to transports other than SRTP, however, is beyond the 160 scope of this document. Each type of secure media transport needs 161 its own specification for the crypto-attribute parameter. These 162 definitions are frequently unique to the particular type of 163 transport and must be specified in a Standards Track RFC and 164 registered with IANA according to the procedures defined in Section 165 9. This document defines the security parameters and keying 166 material for SRTP only. 168 It would be self-defeating not to secure cryptographic keys and 169 other parameters at least as well as the data is secured. Data 170 security protocols such as SRTP rely upon a separate key management 171 system to securely establish encryption and/or authentication keys. 172 Key management protocols provide authenticated key establishment 173 (AKE) procedures to authenticate the identity of each endpoint and 174 protect against man-in-the-middle, reflection/replay, connection 175 hijacking and some denial of service attacks [skeme]. Along with 176 the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK 177 [kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS] 178 securely disseminates information describing both the key and the 179 data-security session. AKE is needed because it is pointless to 180 provide a key over a medium where an attacker can snoop the key, 181 alter the definition of the key to render it useless, or change the 182 parameters of the security session to gain unauthorized access to 183 session-related information. 185 SDP, however, was not designed to provide AKE services, and the 186 media security descriptions defined in this document do not add AKE 187 services to SDP. This specification is no replacement for a key 188 management protocol or for the conveyance of key management messages 189 in SDP [keymgt]. The SDP security descriptions defined here are 190 suitable for restricted cases only where IPsec, TLS, or some other 191 encapsulating data-security protocol (e.g., SIP secure multiparts) 192 protects the SDP message. This document adds security descriptions 193 to those encrypted and/or authenticated SDP messages through the new 194 SDP "crypto" attribute, which provides the cryptographic parameters 195 of a media stream. 197 The "crypto" attribute can be adapted to any media transport, but 198 its precise definition is unique to a particular transport. 200 In Section 3, we introduce the general SDP crypto attribute, and in 201 Section 4 we define how it is used with and without the offer/answer 202 model. In Section 5, we define the crypto attribute details needed 203 for SRTP, and in Section 6 we define SRTP-specific use of the 204 attribute with and without the offer/answer model. Section 7 205 recites security considerations, and Section 8 gives an Augmented- 206 BNF grammar for the general crypto attribute as well as the SRTP- 207 specific use of the crypto attribute. IANA considerations are 208 provided in Section 9. 210 3. SDP "Crypto" Attribute and Parameters 212 A new media-level SDP attribute called "crypto" describes the 213 cryptographic suite, key parameters, and session parameters for the 214 preceding unicast media line. The "crypto" attribute MUST only 215 appear at the SDP media level (not at the session level). The 216 "crypto" attribute follows the format (see Section 8.1 for the 217 formal ABNF grammar): 219 a=crypto: [] 221 The fields tag, crypto-suite, key-params, and session-params are 222 described in the following sub-sections. Below we show an example 223 of the crypto attribute for the "RTP/SAVP" transport, i.e., the 224 secure RTP extension to the Audio/Video Profile [srtp]. In the 225 following, newlines are included for formatting reasons only: 227 a=crypto:1 AES_CM_128_HMAC_SHA1_80 228 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 230 The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined 231 by the text starting with "inline:", and session-params is omitted. 233 3.1 Tag 235 The tag is a decimal number used as an identifier for a particular 236 crypto attribute (see Section 8.1 for details). The tag MUST be 237 unique among all crypto attributes for a given media line. It is 238 used with the offer/answer model to determine which of several 239 offered crypto attributes were chosen by the answerer (see Section 240 4.1). 242 In the offer/answer model, the tag is a negotiated parameter. 244 3.2 Crypto-suite 246 The crypto-suite field is an identifier that describes the 247 encryption and authentication algorithms (e.g., 248 AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section 249 8.1 for details). The possible values for the crypto-suite 250 parameter are defined within the context of the transport, i.e., 251 each transport defines a separate namespace for the set of crypto- 252 suites. For example, the crypto-suite "AES_CM_128_HMAC_SHA1_80" 253 defined within the context "RTP/SAVP" transport applies to Secure 254 RTP only; the string may be reused for another transport (e.g., 255 "RTP/SAVPF" [srtpf]), but a separate definition would be needed. 257 In the offer/answer model, the crypto-suite is a negotiated 258 parameter. 260 3.3 Key Parameters 262 The key-params field provides one or more sets of keying material 263 for the crypto-suite in question. The field consists of a method 264 indicator followed by a colon, and the actual keying information as 265 shown below (the formal grammar is provided in Section 8.1): 267 key-params = ":" 269 Keying material might be provided by different means than key- 270 params, however this is out of scope. Only one method is defined in 271 this document, namely "inline", which indicates that the actual 272 keying material is provided in the key-info field itself. There is 273 a single name space for the key-method, i.e., the key-method is 274 transport independent. New key-methods (e.g., use of a URL) may be 275 defined in a Standards Track RFC in the future. Although the key- 276 method itself may be generic, the accompanying key-info definition 277 is specific not only to the key-method, but also to the transport in 278 question. New key methods MUST be registered with the IANA 279 according to the procedures defined in Section 9.2.1. 281 Key-info is defined as a general character string (see Section 8.1 282 for details); further transport and key-method specific syntax and 283 semantics MUST be provided in a Standards Track RFC for each 284 combination of transport and key-method that use it; definitions for 285 SRTP are provided in Section 5. Note that such definitions are 286 provided within the context of both a particular transport (e.g., 287 "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will 288 register the list of supported key methods for each transport. 290 When multiple keys are included in the key parameters, it MUST be 291 possible to determine which of the keys is being used in a given 292 media packet by a simple inspection of the media packet received; a 293 trial-and-error approach between the possible keys MUST NOT be 294 performed. 296 For SRTP, this could be achieved by use of Master Key Identifiers 297 (MKI), or <"From", "To"> values [srtp]. 299 In the offer/answer model, the key parameter is a declarative 300 parameter. 302 3.4 Session Parameters 304 Session parameters are specific to a given transport and use of them 305 is OPTIONAL in the security descriptions framework, where they are 306 just defined as general character strings. If session parameters 307 are to be used for a given transport, then transport-specific syntax 308 and semantics MUST be provided in a Standards Track RFC; definitions 309 for SRTP are provided in Section 5. 311 In the offer/answer model, session parameters may be either 312 negotiated or declarative; the definition of specific session 313 parameters MUST indicate whether they are negotiated or declarative. 314 Negotiated parameters apply to data sent in both directions, whereas 315 declarative parameters apply only to media sent by the entity that 316 generated the SDP. Thus, a declarative parameter in an offer 317 applies to media sent by the offerer, whereas a declarative 318 parameter in an answer applies to media sent by the answerer. 320 3.5 Example 322 This example shows use of the crypto attribute for the "RTP/SAVP" 323 media transport type (as defined in Section 4). The "a=crypto" line 324 is actually one long line; it is shown as two lines due to page 325 formatting: 327 v=0 328 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 329 s=SDP Seminar 330 i=A Seminar on the session description protocol 331 u=http://www.example.com/seminars/sdp.pdf 332 e=j.doe@example.com (Jane Doe) 333 c=IN IP4 161.44.17.12/127 334 t=2873397496 2873404696 335 m=video 51372 RTP/SAVP 31 336 a=crypto:1 AES_CM_128_HMAC_SHA1_80 337 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 338 m=audio 49170 RTP/SAVP 0 339 a=crypto:1 AES_CM_128_HMAC_SHA1_32 340 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 341 m=application 32416 udp wb 342 a=orient:portrait 344 This SDP message describes three media streams, two of which use the 345 "RTP/SAVP" transport. Each has a crypto attribute for the 346 "RTP/SAVP" transport. These secure-RTP specific descriptions are 347 defined in Section 5. 349 4. General Use of the crypto Attribute 351 In this section, we describe the general use of the crypto attribute 352 outside of any transport or key-method specific rules. 354 4.1 Use With Offer/Answer 356 The general offer/answer rules for the crypto attribute are in 357 addition to the rules specified in RFC 3264, which MUST be followed, 358 unless otherwise noted. RFC 3264 defines operation for both unicast 359 and multicast streams; the sections below describe operation for 360 two-party unicast streams only, since support for multicast streams 361 (and multipoint unicast streams) is for further study. 363 4.1.1 Generating the Initial Offer - Unicast Streams 365 When generating an initial offer for a unicast stream, there MUST be 366 one or more crypto attributes present for each media stream for 367 which security is desired. Each crypto attribute for a given media 368 stream MUST contain a unique tag. 370 The ordering of multiple "a=crypto" lines is significant: The most 371 preferred crypto line is listed first. Each crypto attribute 372 describes the crypto-suite, key(s) and possibly session parameters 373 offered for the media stream. In general, a "more preferred" 374 crypto-suite SHOULD be cryptographically stronger than a "less 375 preferred" crypto-suite. 377 The crypto-suite always applies to media in the directions supported 378 by the media stream (e.g., send and receive). The key(s), however, 379 apply to media in the direction from the offerer to the answerer; if 380 the media stream is marked as "recvonly", a key MUST still be 381 provided. 383 This is done for consistency. Also, in the case of SRTP, for 384 example, secure RTCP will still be flowing in both the send and 385 receive direction for a unidirectional stream. 387 The offer may include session parameters. There are no general 388 offer rules for the session parameters; instead, specific rules may 389 be provided as part of the transport-specific definitions of any 390 session parameters. 392 When issuing an offer, the offerer MUST be prepared to support media 393 security in accordance with any of the crypto attributes included in 394 the offer. There are however two problems associated with this. 395 First of all, the offerer does not know which key the answerer will 396 be using for media sent to the offerer. Second, the offerer may not 397 be able to deduce which of the offered crypto attributes were 398 accepted. Since media may arrive prior to the answer, delay or 399 clipping can occur. If this is unacceptable to the offerer, the 400 offerer SHOULD use a mechanism outside the scope of this document to 401 prevent the above problem. 403 For example, in SIP [RFC3261], a "security" precondition as 404 defined in [sprecon] could solve the above problem. 406 4.1.2 Generating the Initial Answer - Unicast Streams 408 When the answerer receives the initial offer with one or more crypto 409 attributes for a given unicast media stream, the answerer MUST 410 either accept exactly one of the offered crypto attributes, or the 411 offered stream MUST be rejected. 413 If the answerer wishes to indicate support for other crypto 414 attributes, those can be listed by use of the SDP Simple 415 Capability Declaration [RFC3407] extensions. 417 Only crypto attributes that are valid can be accepted; valid 418 attributes do not violate any of the general rules defined for 419 security descriptions as well as any specific rules defined for the 420 transport and key-method in question. When selecting one of the 421 valid crypto attributes, the answerer SHOULD select the most 422 preferred crypto attribute it can support, i.e., the first valid 423 supported crypto attribute in the list, considering the answerer's 424 capabilities and security policies. 426 If there are one or more crypto attributes in the offer, but none of 427 them are valid, or none of the valid ones are supported, the offered 428 media stream MUST be rejected. 430 When an offered crypto attribute is accepted, the crypto attribute 431 in the answer MUST contain the following: 433 * The tag and crypto-suite from the accepted crypto attribute in the 434 offer (the same crypto-suite MUST be used in the send and receive 435 direction). 436 * The key(s) the answerer will be using for media sent to the 437 offerer. Note that a key MUST be provided, irrespective of any 438 direction attributes in the offer or answer. 440 Furthermore, any session parameters that are negotiated MUST be 441 included in the answer. Declarative session parameters provided by 442 the offerer are not included in the answer, however the answerer may 443 provide its own set of declarative session parameters. 445 Once the answerer has accepted one of the offered crypto attributes, 446 the answerer MAY begin sending media to the offerer in accordance 447 with the selected crypto attribute. Note however, that the offerer 448 may not be able to process such media packets correctly until the 449 answer has been received. 451 4.1.3 Offerer Processing of the Initial Answer - Unicast Streams 453 When the offerer receives the answer, the offerer MUST verify, that 454 one of the initially offered crypto suites and its accompanying tag 455 was accepted and echoed in the answer. Also, the answer MUST 456 include one or more keys, which will be used for media sent from the 457 answerer to the offerer. 459 If the offer contained any mandatory negotiated session parameters 460 (see section 5.3.7), the offerer MUST verify that said parameters 461 are included in the answer and support them. If the answer contains 462 any mandatory declarative session parameters, the offerer MUST be 463 able to support those. 465 If any of the above fails, the negotiation MUST fail. 467 4.1.4 Modifying the Session 469 Once a media stream has been established, it MAY be modified at any 470 time, as described in RFC 3264, Section 8. Such a modification MAY 471 be triggered by the security service, e.g., in order to perform a 472 re-keying or change the crypto-suite. If media stream security 473 using the general security descriptions defined here is still 474 desired, the crypto attribute MUST be included in these new 475 offer/answer exchanges. The procedures are similar to those defined 476 in Section 4.1.1, 4.1.2, 4.1.3 of this document, subject to the 477 considerations provided in RFC 3264 Section 8. 479 4.2 Use Outside Offer/Answer 481 The crypto attribute can also be used outside the context of 482 offer/answer where there is no negotiation of the crypto suite, 483 cryptographic key or session parameters. In this case, the sender 484 determines security parameters for the stream. Since there is no 485 negotiation mechanisms, the sender MUST include exactly one crypto 486 attribute and the receiver MUST either accept it or else SHOULD NOT 487 receive the associated stream. The sender SHOULD select the 488 security description that it deems most secure for its purposes. 490 4.3 General Backwards Compatibility Considerations 492 In the offer/answer model, it is possible that the answerer supports 493 a given secure transport (e.g., "RTP/SAVP") and accepts the offered 494 media stream, yet the answerer does not support the crypto attribute 495 defined in this document and hence ignores it. The offerer can 496 recognize this situation by seeing an accepted media stream in the 497 answer that does not include a crypto line. In that case, the 498 security negotiation defined here MUST fail. 500 Similar issues exist when security descriptions are used outside of 501 the offer/answer model. But the source of a non-negotiated security 502 description has no indication that the receiver has ignored the 503 crypto attribute. 505 5. SRTP Security Descriptions 507 In this section, we provide definitions for security descriptions 508 for SRTP media streams. In the next section, we define how to use 509 SRTP security descriptions with and without the offer/answer model. 511 SRTP security descriptions MUST only be used with the SRTP transport 512 (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security 513 descriptions for the "RTP/SAVP" profile defined in [srtp], however 514 it is expected that other secure RTP profiles (e.g., "RTP/SAVPF") 515 can use the same descriptions, which are in accordance with the SRTP 516 protocol specification [srtp]. 518 There is no assurance that an endpoint is capable of configuring its 519 SRTP service with a particular crypto attribute parameter, but SRTP 520 guarantees minimal interoperability among SRTP endpoints through the 521 default SRTP parameters [srtp]. More capable SRTP endpoints support 522 a variety of parameter values beyond the SRTP defaults and these 523 values can be configured by the SRTP security descriptions defined 524 here. An endpoint that does not support the crypto attribute will 525 ignore it according to the SDP. Hence the endpoint will simply 526 assume use of default SRTP parameters, if it supports SRTP but not 527 the crypto attribute. Such an endpoint will not correctly process 528 the particular media stream. By using the Offer/Answer model, the 529 offerer and answerer can negotiate the crypto parameters to be used 530 before commencement of the multimedia session (see Section 6.1). 532 There are over twenty cryptographic parameters listed in the SRTP 533 specification. Many of these parameters have fixed values for 534 particular cryptographic transforms. At the time of session 535 establishment, however, there is usually no need to provide unique 536 settings for many of the SRTP parameters, such as salt length and 537 pseudo-random function (PRF). Thus, it is possible to simplify the 538 list of parameters by defining "cryptographic suites" that fix a set 539 of SRTP parameter values for the security session. This approach is 540 followed by the SRTP security descriptions, which uses the general 541 security description parameters as follows: 543 * crypto-suite: Identifies the encryption and authentication 544 transforms 545 * key parameter: SRTP keying material and parameters 546 * session parameters: The following parameters are defined: 547 - KDR: The SRTP Key Derivation Rate is the rate that a 548 pseudo-random function is applied to a master key 549 - UNENCRYPTED_SRTP: SRTP messages are not encrypted 550 - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted 551 - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated 552 - FEC_ORDER: Order of forward error correction (FEC) 553 relative to SRTP services 554 - FEC_KEY: Master Key for FEC when the FEC stream is sent 555 to a separate address and/or port. 556 - WSH: Window Size Hint 557 - Extensions: Extension parameters can be defined 559 Please refer to the SRTP specification for a complete list of 560 parameters and their descriptions [Section 8.2, srtp]. The key 561 parameter, the crypto-suite, and the session parameters shown above 562 are described in detail in the following subsections. 564 5.1 SRTP Key Parameter 566 SRTP security descriptions define use of the "inline" key method as 567 described in the following. Use of any other keying method, e.g., 568 URL, for SRTP security descriptions is for further study. 570 The "inline" type of key contains the keying material (master key 571 and salt) and all policy related to that master key, including how 572 long it can be used (lifetime) and whether or not it uses a master 573 key identifier (MKI) to associate an incoming SRTP packet with a 574 particular master key. Compliant implementations obey the policies 575 associated with a master key, and MUST NOT accept incoming packets 576 that violate the policy (e.g., after the master key lifetime has 577 expired). 579 The key parameter contains one or more cryptographic master keys, 580 each of which MUST be a unique cryptographically random [RFC1750] 581 value with respect to other master keys in the entire SDP message 582 (i.e., including master keys for other streams). Each key follows 583 the format (the formal definition is provided in Section 8.2): 585 "inline:" "|" [lifetime] "|" [MKI ":" length / FromTo] 587 key||salt concatenated master key and salt, base64 encoded 588 (see [RFC3548], Section 3) 589 lifetime master key lifetime (max number of SRTP or SRTCP 590 packets using this master key) 591 MKI:length MKI and length of the MKI field in SRTP packets 592 FromTo <"From", "To"> values, specifying the lifetime for 593 a master key 595 The following definition provides an example for 596 AES_CM_128_HMAC_SHA1_80: 598 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 600 The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the 601 parameter is the cryptographic master key appended with the master 602 salt; the two are first concatenated and then base64 encoded. The 603 length of the concatenated key and salt is determined by the crypto- 604 suite for which the key applies. If the length (after being decoded 605 from base64) does not match that specified for the crypto-suite, the 606 crypto attribute in question MUST be considered invalid. Each 607 master key and salt MUST be a cryptographically random number and 608 MUST be unique to the entire SDP message. When base64 decoding the 609 key and salt, padding characters (i.e., one or two "=" at the end of 610 the base64 encoded data) are discarded (see [RFC3548] for details). 611 Base64 encoding assumes that the base64 encoding input is an 612 integral number of octets. If a given crypto-suite requires the use 613 of a concatenated key and salt with a length that is not an integral 614 number of octets, said crypto-suite MUST define a padding scheme 615 that results in the base64 input being an integral number of octets. 616 For example, if the length defined was 250 bits, then 6 padding bits 617 would be needed, which could be defined to be the last 6 bits in a 618 256 bit input. 620 The second field, is the OPTIONAL lifetime of the master key as 621 measured in maximum number of SRTP or SRTCP packets using that 622 master key (i.e., the number of SRTP packets and the number of SRTCP 623 packets each have to be less than the lifetime). The lifetime value 624 MAY be written as a non-zero, positive integer or as a power of 2 625 (see the grammar in Section 8.2 for details). The "lifetime" value 626 MUST NOT exceed the maximum packet lifetime for the crypto-suite. 627 If the lifetime is too large or otherwise invalid then the entire 628 crypto attribute MUST be considered invalid. The default MAY be 629 implicitly signaled by omitting the lifetime value (i.e., "||"). 630 This is convenient when the SRTP cryptographic key lifetime is the 631 default value. As a shortcut to avoid long decimal values, the 632 syntax of the lifetime allows using the literal "2^", which 633 indicates "two to the power of". The example above, shows a case 634 where the lifetime is specified as 2^20. The following example, 635 which is for the AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default 636 for the lifetime field, which means that SRTP's and SRTCP's default 637 values will be used (see [srtp]): 639 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2||1066:4 641 The example shows a 30-character key and concatenated salt that is 642 base64 encoded: The 30-character key/salt concatenation is expanded 643 to 40 characters by the three-in-four encoding of base64. 645 The third field, which is also OPTIONAL, is either the Master Key 646 Identifier (MKI) and its byte length, or a <"From", "To"> value. 648 "MKI" is the master key identifier associated with the SRTP master 649 key. If the MKI is given, then the length of the MKI MUST also be 650 given and separated from the MKI by a colon (":"). The MKI length 651 is the size of the MKI field in the SRTP packet, specified in bytes. 652 If the MKI length is not given or its value exceeds 128 (bytes), 653 then the entire crypto attribute MUST be considered invalid. The 654 substring "1:4" in the first example assigns to the key a master key 655 identifier of 1 that is 4 bytes long, and the second example assigns 656 a 4-byte master key identifier of 1066 to the key. 658 <"From", "To"> specifies the lifetime for a master key, expressed in 659 terms of the ROC and SEQ values inside whose range (including the 660 range ends) the master key is valid. <"From", "To"> is an 661 alternative to the MKI and assumes that a master key is in one-to- 662 one correspondence with the SRTP session key on which the <"From", 663 "To"> range is defined (see [srtp, Section 8.1.1] for details). The 664 following example illustrates the use of the <"From", "To"> 665 parameter: 667 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|FT=0:0,1:0 669 As mentioned above, the key parameter can contain one or more master 670 keys. When the key parameter contains more than one master key, all 671 of the master keys in that key parameter MUST either include an MKI 672 or a <"From", "To"> value. Note that it is not permissible to mix 673 the two within a single key parameter (i.e., one crypto attribute); 674 all master keys in a given key parameter must use one or the other 675 (or neither). Furthermore, when using the MKI, the MKI length MUST 676 be the same for all keys in a given crypto attribute. 678 5.2 Crypto-suites 680 The SRTP crypto-suites define the encryption and authentication 681 transforms to be used for the SRTP media stream. The SRTP 682 specification has defined three crypto-suites, which are described 683 further in the following subsections in the context of the SRTP 684 security descriptions. The table below provides an overview of the 685 crypto-suites and their parameters: 687 +---------------------+-------------+--------------+---------------+ 688 | |AES_CM_128_ | AES_CM_128_ | F8_128_ | 689 | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | 690 +---------------------+-------------+--------------+---------------+ 691 | Master key length | 128 bits | 128 bits | 128 bits | 692 | Salt value | 112 bits | 112 bits | 112 bits | 693 | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | 694 | Cipher | AES Counter | AES Counter | F8 | 695 | | Mode | Mode | | 696 | Encryption key | 128 bits | 128 bits | 128 bits | 697 | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | 698 | Authentication tag | 80 bits | 32 bits | 80 bits | 699 | SRTP auth. key | 160 bits | 160 bits | 160 bits | 700 | SRTCP auth. key | 160 bits | 160 bits | 160 bits | 701 +---------------------+-------------+--------------+---------------+ 703 5.2.1 AES_CM_128_HMAC_SHA1_80 705 AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher 706 and HMAC-SHA1 message authentication having an 80-bit authentication 707 tag. The master-key length is 128 bits and has a default lifetime 708 of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes 709 first [Page 39, srtp]. 711 Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, 712 whichever comes first. SRTP security descriptions, however, 713 simplify the parameters to share a single upper bound of 2^31 714 packets. It is RECOMMENDED that automated key management allow 715 easy and efficient rekeying at intervals far smaller than 2^31 716 packets given today's media rates or even HDTV media rates. 718 The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP 719 and SRTCP authentication key lengths are 160 bits (see Security 720 Considerations in Section 7). The master salt value is 112 bits in 721 length and the session salt value is 112 bits in length. The 722 pseudo-random function (PRF) is the default SRTP pseudo-random 723 function that uses AES Counter Mode with a 128-bit key length. 725 The length of the base64 decoded key and salt value for this crypto- 726 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 727 attribute is considered invalid. 729 5.2.2 AES_CM_128_HMAC_SHA1_32 731 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except 732 that the authentication tag is 32 bits. 734 The length of the base64-decoded key and salt value for this crypto- 735 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 736 attribute is considered invalid. 738 5.2.3 F8_128_HMAC_SHA1_80 740 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the 741 cipher is F8 [srtp]. 743 The length of the base64 decoded key and salt value for this crypto- 744 suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto 745 attribute is considered invalid. 747 5.2.4 Adding new Crypto-suite Definitions 749 If new transforms are added to SRTP, new definitions for those 750 transforms SHOULD be given for the SRTP security descriptions and 751 published in a Standards Track RFC. Sections 5.2.1 through 5.2.3 752 illustrate how to define crypto-suite values for particular 753 cryptographic transforms. Any new crypto-suites MUST be registered 754 with IANA following the procedures in section 9. 756 5.3 Session Parameters 758 SRTP security descriptions define a set of "session" parameters, 759 which OPTIONALLY may be used to override SRTP session defaults for 760 the SRTP and SRTCP streams. These parameters configure an RTP 761 session for SRTP services. The session parameters provide session- 762 specific information to establish the SRTP cryptographic context. 764 5.3.1 KDR=n 766 KDR specifies the Key Derivation Rate, as described in section 4.3.1 767 of [srtp]. 769 The value n MUST be an integer in the set {1,2,...,24}, which 770 denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key 771 derivation rate controls how frequently a new session key is derived 772 from an SRTP master key [srtp]. When the key derivation rate is not 773 specified (i.e., the KDR parameter is omitted), a single initial key 774 derivation is performed [srtp]. 776 In the offer/answer model, KDR is a declarative parameter. 778 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 780 SRTP and SRTCP packet payloads are encrypted by default. The 781 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the 782 default behavior of the crypto-suites with which they are used: 784 * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not 785 encrypted. 787 * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not 788 encrypted. 790 In the offer/answer model, these parameters are negotiated. 792 5.3.3 UNAUTHENTICATED_SRTP 794 SRTP and SRTCP packet payloads are authenticated by default. The 795 UNAUTHENTICATED_SRTP session parameter signals that SRTP messages 796 are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT 797 RECOMMENDED (see Security Considerations). 799 The SRTP specification requires use of message authentication for 800 SRTCP, but not for SRTP [srtp]. 802 In the offer/answer model, this parameter is negotiated. 804 5.3.4 FEC_ORDER=order 806 FEC_ORDER signals the use of forward error correction for the RTP 807 packets [rfc2733]. The forward error correction values for "order" 808 are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied 809 before SRTP processing by the sender of the SRTP media and after 810 SRTP processing by the receiver of the SRTP media; FEC_SRTP is the 811 default. SRTP_FEC is the reverse processing. 813 In the offer/answer model, FEC_ORDER is a declarative parameter. 815 5.3.5 FEC_KEY=key-params 817 FEC_KEY signals the use of separate master key(s) for a Forward 818 Error Correction (FEC) stream. The master key(s) are specified with 819 the exact same format as the SRTP Key Parameter defined in Section 820 5.1, and the semantic rules are the same - in particular, the master 821 key(s) MUST be different from all other master key(s) in the SDP. A 822 FEC_KEY MUST be specified when the FEC stream is sent to a different 823 IP-address and/or port than the media stream to which it applies 824 (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. 825 When a FEC stream is sent to the same IP-address and port as the 826 media stream to which it applies, a FEC_KEY MUST NOT be specified. 827 If a FEC_KEY is specified in this latter case, the crypto attribute 828 in question MUST be considered invalid. 830 In the offer/answer model, FEC_KEY is a declarative parameter. 832 5.3.6 Window Size Hint (WSH) 834 SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to 835 protect against replay attacks. The minimum value is 64 [srtp], 836 however this value may be considered too low for some applications 837 (e.g., video). 839 The Window Size Hint (WSH) session parameter provides a hint for how 840 big this window should be to work satisfactorily (e.g., based on 841 sender knowledge of number of packets per second). However, there 842 might be enough information given in SDP attributes like 843 "a=maxprate" and the bandwidth modifiers to allow a receiver to 844 derive the parameter satisfactorily. Consequently, this value is 845 only considered a hint to the receiver of the SDP which MAY choose 846 to ignore the value provided. 848 In the offer/answer model, WSH is a declarative parameter. 850 5.3.7 Defining New SRTP Session Parameters 852 New SRTP session parameters for the SRTP security descriptions can 853 be defined in a Standards Track RFC and registered with IANA 854 according to the registration procedures defined in Section 9. 856 New SRTP session parameters are by default mandatory. A newly- 857 defined SRTP session parameter that is prefixed with the dash 858 character ("-") however is considered optional and MAY be ignored. 859 If an SDP crypto attribute is received with an unknown session 860 parameter that is not prefixed with a "-" character, that crypto 861 attribute MUST be considered invalid. 863 5.4 SRTP Crypto Context Initialization 865 In addition to the various SRTP parameters defined above, there are 866 three pieces of information that are critical to the operation of 867 the default SRTP ciphers: 869 * SSRC: Synchronization source 870 * ROC: Roll-over counter for a given SSRC 871 * SEQ: Sequence number for a given SSRC 873 In a unicast session, as defined here, there are three constraints 874 on these values. 876 The first constraint is on the SSRC, which makes an SRTP keystream 877 be unique from other participants. As explained in SRTP, the 878 keystream MUST NOT be reused on two or more different pieces of 879 plaintext. Keystream reuse makes the ciphertext vulnerable to 880 cryptanalysis. One vulnerability is that known-plaintext fields in 881 one stream can expose portions of the reused keystream and this 882 could further expose more plaintext in other streams. Since all 883 current SRTP encryption transforms use keystreams, key sharing is a 884 general problem [srtp]. SRTP mitigates this problem by including 885 the SSRC of the sender in the keystream. But SRTP does not solve 886 this problem in its entirety because Real-time Transport Protocol 887 has SSRC collisions, which are very rare [rtp] but quite possible. 888 During a collision, two or more SSRCs that share a master key will 889 have identical keystreams for overlapping portions of the RTP 890 sequence-number space. SRTP Security Descriptions avoids keystream 891 reuse by making unique master keys REQUIRED for the sender and 892 receiver of the security description. Thus, the first constraint is 893 satisfied. 895 Also note, that there is a second problem with SSRC collisions: 896 The SSRC is used to identify the crypto context and thereby the 897 cipher, key, ROC, etc. to process incoming packets. In case of 898 SSRC collisions, crypto context identification becomes ambiguous 899 and correct packet processing may not occur. Furthermore, if an 900 RTCP BYE packet is to be sent for a colliding SSRC, that packet 901 may also have to be secured. In a (unicast) point-to-multipoint 902 scenario, this can be problematic for the same reasons, i.e., it 903 is not known which of the possible crypto contexts to use. Note 904 that these problems are not unique to the SDP security 905 descriptions; any use of SRTP needs to consider them. 907 The second constraint is that the ROC MUST be zero at the time that 908 each SSRC commences sending packets. Thus, there is no concept of a 909 "late joiner" in SRTP security descriptions, which are constrained 910 to be unicast and pairwise. The ROC and SEQ form a "packet index" 911 in the default SRTP transforms and the ROC is consistently set to 912 zero at session commencement, according to this document. 914 The third constraint is that the initial value of SEQ SHOULD be 915 chosen to be within the range of 0..2^15-1; this avoids an ambiguity 916 when packets are lost at the start of the session. If at the start 917 of a session, an SSRC source might randomly select a high sequence- 918 number value and put the receiver in an ambiguous situation: If 919 initial packets are lost in transit up to the point that the 920 sequence number wraps (i.e., exceeds 2^16-1), then the receiver 921 might not recognize that its ROC needs to be incremented. By 922 restricting the initial SEQ to the range of 0..2^15-1, SRTP packet- 923 index determination will find the correct ROC value, unless all of 924 the first 2^15 packets are lost (which seems, if not impossible, 925 then rather unlikely). See Section 3.3.1 of the SRTP specification 926 regarding packet-index determination [srtp]. 928 The packet index, therefore, depends on the SSRC, the SEQ of an 929 incoming packet and the ROC, which is an SRTP crypto context 930 variable. Thus, SRTP has a big security dependency on SSRC 931 uniqueness. 933 Given the above constraints, unicast SRTP crypto contexts can be 934 established without the need to negotiate SSRC values in the SRTP 935 security descriptions. Instead, an approach called "late binding" 936 is RECOMMENDED by this specification. When a packet arrives, the 937 SSRC that is contained in it can be bound to the crypto context at 938 the time of session commencement (i.e., SRTP packet arrival) rather 939 than at the time of session signaling (i.e., receipt of an SDP). 940 With the arrival of the packet containing the SSRC, all the data 941 items needed for the SRTP crypto context are held by the receiver 942 (note that the ROC value by definition is zero; if non-zero values 943 were to be supported, additional signaling would be required). In 944 other words, the crypto context for a secure RTP session using late 945 binding is initially identified by the SDP as: 947 <*, address, port> 949 where '*' is a wildcard SSRC, "address" is the local receive address 950 from the "c=" line, and "port" is the local receive port from the 951 "m=" line. When the first packet arrives with ssrcX in its SSRC 952 field, the crypto context 954 956 is instantiated subject to the following constraints: 958 * Media packets are authenticated: Authentication MUST succeed; 959 otherwise, the crypto context is not instantiated. 961 * Media packets are not authenticated: Crypto context is 962 automatically instantiated. 964 It should be noted, that use of late binding when there is no 965 authentication of the SRTP media packets is subject to numerous 966 security attacks and consequently it is NOT RECOMMENDED (of course, 967 this can be said for unauthenticated SRTP in general). 969 Note that use of late binding without authentication will result 970 in local state being created as a result of receiving a packet 971 from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 972 RECOMMENDED because it invites easy denial-of-service attack. In 973 contrast, late binding with authentication does not suffer from 974 this weakness. 976 With the constraints and procedures described above, it is not 977 necessary to explicitly signal the SSRC, ROC and SEQ for a unicast 978 SRTP session. 980 5.5 Removal of Crypto Contexts 982 The mechanism defined above addresses the issue of creating crypto 983 contexts, however in practice, session participants may want to 984 remove crypto contexts prior to session termination. Since a crypto 985 context contains information that can not automatically be recovered 986 (e.g., ROC), it is important that the sender and receiver agree on 987 when a crypto context can be removed, and perhaps more importantly 988 when it cannot. 990 Even when late binding is used for a unicast stream, the ROC is 991 lost and cannot be recovered automatically (unless it is zero) 992 once the crypto context is removed. 994 We resolve this problem as follows. When SRTP security descriptions 995 are being used, crypto-context removal MUST follow the same rules as 996 SSRC removal from the member table [RFC 3550]; note that this can 997 happen as the result of an SRTCP BYE packet or a simple time-out due 998 to inactivity. Inactive session participants that wish to ensure 999 their crypto contexts are not timed out MUST thus send SRTCP packets 1000 at regular intervals. 1002 6. SRTP-Specific Use of the crypto Attribute 1004 Section 4 describes general use of the crypto attribute, and this 1005 section completes it by describing SRTP-specific use. 1007 6.1 Use with Offer/Answer 1009 In this section, we describe how the SRTP security descriptions are 1010 used with the offer/answer model to negotiate cryptographic 1011 capabilities and communicate SRTP master keys. The rules defined 1012 below complement the general offer/answer rules defined in Section 1013 4.1, which MUST be followed, unless otherwise specified. Note that 1014 the rules below define unicast operation only; support for multicast 1015 and multipoint unicast streams is for further study. 1017 6.1.1 Generating the Initial Offer - Unicast Streams 1019 When the initial offer is generated, the offerer MUST follow the 1020 steps in Section 4.1.1 as well as the following steps. 1022 For each unicast media line (m=) using the secure RTP transport 1023 where the offerer wants to specify cryptographic parameters, the 1024 offerer MUST provide at least one valid SRTP security description 1025 ("a=crypto" line), as defined in Section 5. If the media stream 1026 includes Forward Error Correction with a different IP-address and/or 1027 port than the media stream itself, a FEC_KEY parameter MUST be 1028 included, as described in Section 5.3.5. 1030 The offerer MAY include one or more other SRTP session parameters as 1031 defined in Section 5.3. Note however, that if any SRTP session 1032 parameters are included that are not known to the answerer, but are 1033 nonetheless mandatory (see Section 5.3.6), the negotiation will fail 1034 if the answerer does not support them. 1036 6.1.2 Generating the Initial Answer - Unicast Streams 1038 When the initial answer is generated, the answerer MUST follow the 1039 steps in Section 4.1.2 as well as the following steps. 1041 For each unicast media line which uses the secure RTP transport and 1042 contains one or more "a=crypto" lines in the offer, the answerer 1043 MUST either accept one (and only one) of the crypto lines for that 1044 media stream, or it MUST reject the media stream. Only "a=crypto" 1045 lines that are considered valid SRTP security descriptions as 1046 defined in Section 5 can be accepted. Furthermore, all parameters 1047 (crypto-suite, key parameter, and mandatory session parameters) MUST 1048 be acceptable to the answerer in order for the offered media stream 1049 to be accepted. Note that if the media stream includes Forward 1050 Error Correction with a different IP-address and/or port than the 1051 media stream itself, a FEC_KEY parameter MUST be included, as 1052 described in Section 5.3.5. 1054 When the answerer accepts an SRTP unicast media stream with a crypto 1055 line, the answerer MUST include one or more master keys appropriate 1056 for the selected crypto algorithm; the master key(s) included in the 1057 answer MUST be different from those in the offer. 1059 When the master key(s) are not shared between the offerer and 1060 answerer, SSRC collisions between the offerer and answerer will 1061 not lead to keystream reuse, and hence SSRC collisions do not 1062 necessarily have to be prevented. 1064 If Forward Error Correction to a separate IP-address and/or port is 1065 included, the answer MUST include a FEC_KEY parameter, as described 1066 in Section 5.3.5. 1068 Declarative session parameters may be added to the answer as usual, 1069 however the answerer SHOULD NOT add any mandatory session parameter 1070 (see Section 5.3.6) that might be unknown to the offerer. 1072 If the answerer cannot find any valid crypto line that it supports, 1073 or if its configured policy prohibits any cryptographic key 1074 parameter (e.g., key length) or cryptographic session parameter 1075 (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it 1076 is able to successfully negotiate use of SRTP by other means outside 1077 the scope of this document (e.g., by use of MIKEY [mikey]). 1079 6.1.3 Offerer Processing of the Initial Answer - Unicast Streams 1081 When the offerer receives the answer, it MUST perform the steps in 1082 Section 4.1.3 as well as the following steps for each SRTP media 1083 stream it offered with one or more crypto lines in it. 1085 If the media stream was accepted and it contains a crypto line, it 1086 MUST be checked that the crypto line is valid according to the 1087 constraints specified in Section 5 (including any FEC constraints). 1089 If the offerer either does not support or is not willing to honor 1090 one or more of the SRTP parameters in the answer, the offerer MUST 1091 consider the crypto line invalid. 1093 If the crypto line is not valid, or the offerer's configured policy 1094 prohibits any cryptographic key parameter (e.g. key length) or 1095 cryptographic session parameter, the SRTP security negotiation MUST 1096 be deemed to have failed. 1098 6.1.4 Modifying the Session 1100 When a media stream using the SRTP security descriptions has been 1101 established, and a new offer/answer exchange is performed, the 1102 offerer and answerer MUST follow the steps in Section 4.1.4 as well 1103 as the following steps. 1105 When modifying the session, all negotiated aspects of the SRTP media 1106 stream can be modified. For example, a new crypto suite can be used 1107 or a new master key can be established. As described in RFC 3264, 1108 when doing a new offer/answer exchange there will be a window of 1109 time, where the offerer and the answerer must be prepared to receive 1110 media according to both the old and the new offer/answer exchange. 1111 This requirement applies here as well, however the following should 1112 be noted: 1114 * When authentication is not being used, it may not be possible for 1115 either the offerer or the answerer to determine if a given packet 1116 is encrypted according to the old or new offer/answer exchange. 1117 RFC 3264 defines a couple of techniques to address this problem, 1118 e.g., changing the payload types used and/or the transport 1119 addresses. Note however that a change in transport addresses may 1120 have an impact on Quality of Service as well as firewall and NAT 1121 traversal. The SRTP security descriptions offers two other ways 1122 of dealing with this; use the MKI (which adds a few bytes to each 1123 SRTP packet) or the <"From","To"> mechanism (which doesn't add 1124 bytes to each SRTP packet) as described in Section 5.1. For 1125 further details on MKI and "<"From","To">, please refer to [srtp]. 1127 * If the answerer changes its master key, the offerer will not 1128 be able to process packets secured via this master key until the 1129 answer is received. This could be addressed by using a security 1130 "precondition" [sprecon]. 1132 If the offerer includes an IP address and/or port that differs from 1133 that used previously for a media stream (or FEC stream), the offerer 1134 MUST include a new master key with the offer (and in so doing, it 1135 will be creating a new crypto context with the ROC set to zero). 1137 Similarly, if the answerer includes an IP address and/or port that 1138 differs from that used previously for a media stream (or FEC 1139 stream), the answerer MUST include a new master key with the offer 1140 (and hence create a new crypto context with the ROC set to zero). 1141 The reason for this is, that when the answerer receives an offer, or 1142 the offerer receives an answer, with an updated IP address and/or 1143 port, it is not possible to determine if the other side has access 1144 to the old crypto context parameters (and in particular the ROC) or 1145 not. For example, if one side is a decomposed gateway, or a back- 1146 to-back user agent is involved, it is possible that the media 1147 endpoint changed and no longer has access to the old crypto context. 1148 By always requiring a new master key in this case, the 1149 answerer/offerer will know that the ROC is zero for this 1150 offer/answer, and any key lifetime constraints will trivially be 1151 satisfied too. Another consideration here applies to media relays; 1152 if the relay changes the media endpoint on one side transparently to 1153 the other side, the relay cannot operate as a simple packet 1154 reflector but will have to actively engage in SRTP packet processing 1155 and transformation (i.e., decryption and re-encryption, etc.). 1157 Finally note, that if the new offer is rejected, the old crypto 1158 parameters remain in place. 1160 6.1.5 Offer/Answer Example 1162 In this example, the offerer supports two crypto suites (F8 and 1163 AES). The a=crypto line is actually one long line, although it is 1164 shown as two lines in this document due to page formatting. 1166 Offerer sends: 1167 v=0 1168 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 1169 s=SRTP Discussion 1170 i=A discussion of Secure RTP 1171 u=http://www.example.com/seminars/srtp.pdf 1172 e=marge@example.com (Marge Simpson) 1173 c=IN IP4 168.2.17.12 1174 t=2873397496 2873404696 1175 m=audio 49170 RTP/SAVP 0 1176 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1177 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1178 FEC_ORDER=FEC_SRTP 1179 a=crypto:2 F8_128_HMAC_SHA1_80 1180 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1181 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1182 FEC_ORDER=FEC_SRTP 1184 Answerer replies: 1185 v=0 1186 o=jill 25690844 8070842634 IN IP4 10.47.16.5 1187 s=SRTP Discussion 1188 i=A discussion of Secure RTP 1189 u=http://www.example.com/seminars/srtp.pdf 1190 e=homer@example.com (Homer Simpson) 1191 c=IN IP4 168.2.17.11 1192 t=2873397526 2873405696 1193 m=audio 32640 RTP/SAVP 0 1194 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1195 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1197 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 1198 crypto suite for the RTP and RTCP traffic. 1200 6.2 SRTP-Specific Use Outside Offer/Answer 1202 Use of SRTP security descriptions outside the offer/answer model is 1203 not defined. 1205 Use of SRTP security descriptions outside offer/answer could have 1206 been defined for sendonly media streams, however, there would not 1207 be a way to indicate the key to use for SRTCP by the receiver of 1208 said media stream. 1210 6.3 Support for SIP Forking 1212 As mentioned earlier, the security descriptions defined here do not 1213 support multicast media streams or multipoint unicast streams. 1214 However, in the SIP protocol, it is possible to receive several 1215 answers to a single offer due to the use of forking (see [SIP]). 1216 Receiving multiple answers leads to a couple of problems for the 1217 SRTP security descriptions: 1219 * Different answerers may choose different ciphers, keys, etc., 1220 however there is no way for the offerer to associate a particular 1221 incoming media packet with a particular answer. 1223 * Two or more answerers may pick the same SSRC and hence the SSRC 1224 collision problems mentioned earlier may arise. 1226 As stated earlier, the above point-to-multipoint cases are outside 1227 the scope of the SDP security descriptions. However, there is a way 1228 of supporting SIP forking: Change the multipoint scenario resulting 1229 from SIP forking into multiple two-party unicast cases. This is 1230 done as follows: 1232 For each answer received beyond the initial answer, issue a new 1233 offer to that particular answerer using a new receive transport 1234 address (IP address and port); note that this requires support for 1235 the SIP UPDATE method [RFC 3313]. Also, to ensure that two media 1236 sessions are not inadvertently established prior to the UPDATE being 1237 processed by one of them, use security preconditions [sprecon]. 1239 Finally, note that all the answerers will know the key(s) being 1240 proposed by the initial offer. If the offerer wants to ensure 1241 security with respect to other answerers, a new offer/answer 1242 exchange with a new key needs to be performed with the first 1243 answerer as well. 1245 6.4 SRTP-Specific Backwards Compatibility Considerations 1247 It is possible that the answerer supports the SRTP transport and 1248 accepts the offered media stream, yet it does not support the crypto 1249 attribute defined here. The offerer can recognize this situation by 1250 seeing an accepted SRTP media stream in the answer that does not 1251 include a crypto line. In that case, the security negotiation 1252 defined here MUST be deemed to have failed. 1254 Also, if a media stream with a given SRTP transport (e.g., 1255 "RTP/SAVP") is sent to a device that does not support SRTP, that 1256 media stream will be rejected. 1258 6.5 Operation with KEYMGT= and k= lines 1260 An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. 1261 Per SDP rules, the answerer will ignore attribute lines that it does 1262 not understand. If the answerer supports both "a=crypto" and 1263 "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" 1264 but not both, as including both is undefined. 1266 An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP 1267 rules, the answerer will ignore attribute lines it does not 1268 understand. If the answerer supports both "a=crypto" and "k=", the 1269 answer MUST include either "a=crypto" or "k=" but not both, as 1270 including both is undefined. 1272 7. Security Considerations 1274 Like all SDP messages, SDP messages containing security 1275 descriptions, are conveyed in an encapsulating application protocol 1276 (e.g., SIP, MGCP, etc.). It is the responsibility of the 1277 encapsulating protocol to ensure the protection of the SDP security 1278 descriptions. Therefore, the application protocol SHOULD either 1279 invoke its own security mechanisms (e.g., secure multiparts) or 1280 alternatively utilize a lower-layer security service (e.g., TLS, or 1281 IPSec). This security service SHOULD provide strong message 1282 authentication and packet-payload encryption as well as effective 1283 replay protection. 1285 7.1 Authentication of packets 1287 Security descriptions as defined herein signal security services for 1288 RTP packets. RTP messages are vulnerable to a variety of attacks 1289 such as replay and forging. To limit these attacks, SRTP message 1290 integrity mechanisms SHOULD be used (SRTP replay protection is 1291 always enabled). 1293 7.2 Keystream Reuse 1295 SRTP security descriptions signal configuration parameters for SRTP 1296 sessions. Misconfigured SRTP sessions are vulnerable to attacks on 1297 their encryption services when running the crypto suites defined in 1298 Sections 5.2.1, 5.2.2, and 5.2.3. An SRTP encryption service is 1299 "misconfigured" when two or more media streams are encrypted using 1300 the same AES keystream. When senders and receivers share derived 1301 session keys, SRTP requires that the SSRCs of session participants 1302 serve to make their corresponding keystreams unique, which is 1303 violated in the case of SSRC collision: SRTP SSRC collision 1304 drastically weakens SRTP or SRTCP payload encryption during the time 1305 that identical keystreams were used [srtp]. An attacker, for 1306 example, might collect SRTP and SRTCP messages and await a 1307 collision. This attack on the AES-CM and AES-f8 encryption is 1308 avoided entirely when each media stream has its own unique master 1309 key in both the send and receive direction. This specification 1310 restricts use of SDP security description to unicast point-to-point 1311 streams so that keys are not shared between SRTP hosts, and the 1312 master keys used in the send and receive direction for a given media 1313 stream are unique. 1315 7.3 Signaling Authentication and Signaling Encryption 1317 There is no reason to incur the complexity and computational expense 1318 of SRTP, however, when its key establishment is exposed to 1319 unauthorized parties. In most cases, the SRTP crypto attribute and 1320 its parameters are vulnerable to denial of service attacks when they 1321 are carried in an unauthenticated SDP message. In some cases, the 1322 integrity or confidentiality of the RTP stream can be compromised. 1323 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 1324 an offer, this could result in the answerer not decrypting the 1325 encrypted SRTP messages. In the worst case, the answerer might 1326 itself send unencrypted SRTP and leave its data exposed to snooping. 1328 Thus, MIME secure multiparts, IPsec, TLS, or some other data 1329 security service SHOULD be used to provide message authentication 1330 for the encapsulating protocol that carries the SDP messages having 1331 a crypto attribute (a=crypto). Furthermore, encryption of the 1332 encapsulating payload SHOULD be used because a master key parameter 1333 (inline) appears in the message. Failure to encrypt the SDP message 1334 containing an inline SRTP master key renders the SRTP authentication 1335 or encryption service useless in practically all circumstances. 1336 Failure to authenticate an SDP message that carries SRTP parameters 1337 renders the SRTP authentication or encryption service useless in 1338 most practical applications. 1340 When the communication path of the SDP message is routed through 1341 intermediate systems that inspect parts of the SDP message, security 1342 protocols such as IPsec or TLS SHOULD NOT be used for encrypting 1343 and/or authenticating the security description. In the case of 1344 intermediate-system processing of a message containing SDP security 1345 descriptions, the "a=crypto" attributes SHOULD be protected end-to- 1346 end so that the intermediate system can neither modify the security 1347 description nor access the keying material. Network or transport 1348 security protocols that terminate at each intermediate system, 1349 therefore, SHOULD NOT be used for protecting SDP security 1350 descriptions. A security protocol SHOULD allow the security 1351 descriptions to be encrypted and authenticated end-to-end 1352 independently of the portions of the SDP message that any 1353 intermediate system modifies or inspects: MIME secure multiparts 1354 are RECOMMENDED for the protection of SDP messages that are 1355 processed by intermediate systems. 1357 When the SDP parameters cannot be carried in an encrypted and 1358 authenticated SDP message, it is RECOMMENDED that a key management 1359 protocol be used instead of the security descriptions defined here 1360 (a=crypto). The proposed SDP key-mgmt extension [keymgt] allows 1361 authentication and encryption of the key management protocol data 1362 independently of the SDP message that carries it. The security of 1363 the SDP SRTP attribute, however, is as good as the data security 1364 protocol that protects the SDP message. For example, if an IPSec 1365 security association exists between the SDP source and destination 1366 endpoints, then this solution is more secure than use of the key- 1367 mgmt statement in an unauthenticated SDP message, which is 1368 vulnerable to tampering. 1370 8. Grammar 1372 In this section we first provide the ABNF grammar for the generic 1373 crypto attribute, and then we provide the ABNF grammar for the SRTP 1374 specific use of the crypto attribute. 1376 8.1 Generic "Crypto" Attribute Grammar 1378 The ABNF grammar for the crypto attribute is defined below: 1380 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params 1381 *(1*WSP session-param) 1383 tag = 1*ALPHANUM 1384 crypto-suite = 1*(ALPHA / DIGIT / "_") 1386 key-params = key-param *(";" key-param) 1387 key-param = key-method ":" key-info 1388 key-method = "inline" / key-method-ext 1389 key-method-ext = 1*(ALPHA / DIGIT / "_") 1390 key-info = %x21-3A / %x3C-7E ; visible (printing) characters 1391 ; except semi-colon 1392 session-param = 1*(VCHAR) ; visible (printing) characters 1394 where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. 1396 8.2 SRTP "Crypto" Attribute Grammar 1398 This section provides an Augmented BNF [RFC2234] grammar for the 1399 SRTP-specific use of the SDP crypto attribute: 1401 crypto-suite = srtp-crypto-suite 1402 key-method = srtp-key-method 1403 key-info = srtp-key-info 1404 session-param = srtp-session-param 1406 srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 1407 "F8_128_HMAC_SHA1_32" / 1408 "AES_CM_128_HMAC_SHA1_80" / 1409 srtp-crypto-suite-ext 1411 srtp-key-method = "inline" 1412 srtp-key-info = key-salt "|" [lifetime] "|" [mki / FromTo] 1414 key-salt = 1*(base64) ; binary key and salt values 1415 ; concatenated together, and then 1416 ; base64 encoded [section 6.8 of 1417 ; RFC2046] 1419 lifetime = ["2^"] 1*(DIGIT) ; see section 5.1 for "2^" 1420 mki = mki-value ":" mki-length 1421 mki-value = 1*DIGIT 1422 mki-length = 1*3DIGIT ; range 1..128. 1423 FromTo = "FT=" ftval "," ftval 1424 ftval = roc ":" seq ; packet index expressed in terms 1425 ; of ROC and SEQ. 1426 roc = 1*DIGIT ; range 0..2^32-1 1427 seq = 1*DIGIT ; range 0..2^16-1 1429 srtp-session-param = kdr / 1430 "UNENCRYPTED_SRTP" / 1431 "UNENCRYPTED_SRTCP" / 1432 "UNAUTHENTICATED_SRTP" / 1433 fec-order / 1434 fec-key / 1435 wsh / 1436 srtp-session-extension 1438 kdr = "KDR=" 1*2(DIGIT) ; range 0..24, power of two 1440 fec-order = "FEC_ORDER=" fec-type 1441 fec-type = "FEC_SRTP" / "SRTP_FEC" 1442 fec-key = "FEC_KEY=" key-params 1444 wsh = "WSH=" 2*DIGIT ; minimum value is 64 1445 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1447 srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") 1448 srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] 1449 ; first character must not be dash ("-") 1451 9. IANA Considerations 1453 9.1 Registration of the "crypto" attribute 1455 The IANA is hereby requested to register a new SDP attribute as 1456 follows: 1458 Attribute name: crypto 1459 Long form name: Security description cryptographic attribute 1460 for media streams 1461 Type of attribute: Media-level 1462 Subject to charset: No 1463 Purpose: Security descriptions 1464 Appropriate values: See Section 3 1466 9.2 New IANA Registries and Registration Procedures 1468 The following sub-sections define a new IANA registry with 1469 associated sub-registries to be used for the SDP security 1470 descriptions. The IANA is hereby requested to create an SDP 1471 Security Description registry as shown below and further described 1472 in the following sections: 1474 SDP Security Descriptions 1475 | 1476 +- Key Methods (described in 9.2.1) 1477 | 1478 +- Media Stream Transports (described in 9.2.2) 1479 | 1480 +- Transport1 (e.g. SRTP) 1481 | | 1482 | +- Supported Key Methods (e.g. inline) 1483 | | 1484 | +- crypto suites 1485 | | 1486 | +- session parameters 1487 | 1488 +- Transport2 1489 : : 1491 9.2.1 Security Descriptions Key Method Registry and Registration 1493 The IANA is hereby requested to create a new subregistry for SDP 1494 security description key methods. An IANA key method registration 1495 MUST be documented in an RFC in accordance with the RFC 2434 1496 Standards Action and it MUST provide the name of the key method in 1497 accordance with the grammar for key-method-ext defined in Section 1498 8.1. 1500 9.2.2 Security Description Media Stream Transport Registry and 1501 Registration 1503 The IANA is hereby requested to create a new subregistry for SDP 1504 security description Media Stream Transports. An IANA media stream 1505 transport registration MUST be documented in an RFC in accordance 1506 with the RFC 2434 Standards Action and the procedures defined in 1507 Section 3 and 4 of this document. The registration MUST provide the 1508 name of the transport and a list of supported key methods. 1510 In addition, each new media stream transport registry must contain a 1511 crypto-suite registry and a session parameter registry as well as 1512 IANA instructions for how to populate these registries. 1514 9.3 Initial Registrations 1516 9.3.1 Key Method 1518 The following security descriptions key methods are hereby 1519 registered: 1521 inline 1523 9.3.2 SRTP Media Stream Transport 1525 The IANA is hereby requested to create an SDP Security Description 1526 Media Stream Transport subregistry for "SRTP". The key methods 1527 supported is "inline". The reference for the SDP security 1528 description for SRTP is this document. 1530 9.3.2.1 SRTP Crypto Suite Registry and Registration 1532 The IANA is hereby requested to create a new subregistry for SRTP 1533 crypto suites under the SRTP transport of the SDP Security 1534 Descriptions. An IANA SRTP crypto suite registration MUST indicate 1535 the crypto suite name in accordance with the grammar for srtp- 1536 crypto-suite-ext defined in Section 8.2. 1538 The semantics of the SRTP crypto suite MUST be described in an RFC 1539 in accordance with the RFC 2434 Standards Action, including the 1540 semantics of the "inline" key-method and any special semantics of 1541 parameters. 1543 The following SRTP crypto suites are hereby registered: 1545 AES_CM_128_HMAC_SHA1_80 1546 AES_CM_128_HMAC_SHA1_32 1547 F8_128_HMAC_SHA1_80 1549 The reference for these crypto-suites is provided in this document. 1551 9.3.2.2 SRTP Session Parameter Registration 1553 The IANA is hereby requested to create a new subregistry for SRTP 1554 session parameters under the SRTP transport of the SDP Security 1555 Descriptions. An IANA SRTP session parameter registration MUST 1556 indicate the session parameter name (srtp-session-extension as 1557 defined in Section 8.2); the name MUST NOT begin with the dash 1558 character ("-"). 1560 The semantics of the parameter MUST be described in an RFC in 1561 accordance with the RFC 2434 Standards Action. If values can be 1562 assigned to the parameter, then the format and possible values that 1563 can be assigned MUST be described in the RFC in accordance with the 1564 RFC 2434 Standards Action as well. Also, it MUST be specified 1565 whether the parameter is declarative or negotiated in the 1566 offer/answer model. 1568 The following SRTP session parameters are hereby registered: 1570 KDR 1571 UNENCRYPTED_SRTP 1572 UNENCRYPTED_SRTCP 1573 UNAUTHENTICATED_SRTP 1574 FEC_ORDER 1575 FEC_KEY 1576 WSH 1578 The reference for these parameters is this document. 1580 10. Acknowledgements 1582 This document is a product of the IETF MMUSIC working group and has 1583 benefited from comments from its participants. This document also 1584 benefited from discussions with Elisabetta Cararra, Earl Carter, 1585 Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David 1586 McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, 1587 Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared 1588 observations, identified errors and made suggestions for improving 1589 the specification. Magnus provided many useful comments and Mats 1590 made several valuable suggestions on parameters and syntax that are 1591 in the current draft. Dave Oran and Mike Thomas encouraged us to 1592 bring this work to the IETF for standardization. David McGrew 1593 suggested the conservative approach of requiring unique master keys 1594 for each unicast SDP media stream as followed in this document. 1595 Paul Kyzivat suggested how to handle SIP forking. Jonathan 1596 Rosenberg suggested reducing the complexity by specifying only one 1597 security parameter for each media stream. 1599 11. Authors' Addresses 1601 Flemming Andreasen 1602 Cisco Systems, Inc. 1603 499 Thornall Street, 8th Floor 1604 Edison, New Jersey 08837 USA 1605 fandreas@cisco.com 1607 Mark Baugher 1608 5510 SW Orchid Street 1609 Portland, Oregon 97219 USA 1610 mbaugher@cisco.com 1612 Dan Wing 1613 Cisco Systems, Inc. 1614 170 West Tasman Drive 1615 San Jose, CA 95134 USA 1616 dwing@cisco.com 1618 12. Normative References 1620 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1621 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 1622 July 2003, http://www.ietf.org/rfc/rfc3550.txt. 1624 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1625 Specifications: ABNF," RFC 2234, November 1997, 1626 http://www.ietf.org/rfc/rfc2234.txt. 1628 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1629 RFC 2327, April 1998. 1631 [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for 1632 Generic Forward Error Correction", RFC 2733, December 1999, 1633 http://www.ietf.org/rfc/rfc2733.txt. 1635 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 1636 2000, http://www.ietf.org/rfc/rfc2828.txt. 1638 [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1639 the Session Description Protocol (SDP)", RFC 3264, June 2202, 1640 http://www.ietf.org/rfc/rfc3264.txt. 1642 [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 1643 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 1645 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 1646 Recommendations for Security", RFC 1750, December 1994, 1647 http://www.ietf.org/rfc/rfc1750.txt. 1649 [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data 1650 Encodings", RFC 3548, July 2003. 1652 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1653 Considerations Section in RFCs", RFC 2434, October 1998. 1655 13. Informative References 1657 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1658 Capability Declaration", RFC 3407, October 2002, 1659 http://www.ietf.org/rfc/rfc3407.txt. 1661 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 1662 Protocols," in Proceedings of the Sixth Usenix Unix Security 1663 Symposium, pp. 1-16, San Jose, CA, July 1996. 1665 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1666 Domain of Interpretation", RFC 3547, July 2003, 1667 http://www.ietf.org/rfc/rfc3547.txt. 1669 [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of 1670 Keys (KINK)", Work in Progress. 1672 [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 1673 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 1675 [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the 1676 Internet Protocol", RFC 2401, November 1998, 1677 http://www.ietf.org/rfc/rfc2401.txt. 1679 [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 1680 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 1682 [pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy 1683 (PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. 1685 [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1686 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 1688 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1689 "Key Management Extensions for SDP and RTSP", Work in Progress. 1691 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1692 "MIKEY: Multimedia Internet KEYing", Work in Progress. 1694 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1695 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1696 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1698 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1699 for Message Authentication", RFC 2014, November 1997, 1700 http://www.ietf.org/rfc/rfc2104.txt. 1702 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1703 Mechanism for the Internet", ISOC Secure Networks and Distributed 1704 Systems Symposium, San Diego, 1996. 1706 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 1707 Resource Management and Session Initiation Protocol (SIP)", RFC 1708 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 1710 [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement 1711 Protocol", RFC 2974, October 2000, 1712 http://www.ietf.org/rfc/rfc2974.txt. 1714 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1715 RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. 1717 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1718 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1719 Session Initiation Protocol", RFC 3261, June 2002. 1721 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security 1722 Preconditions for Session Description Protocol Media Streams", work 1723 in progress, February 2004. 1725 Intellectual Property Statement 1727 The IETF takes no position regarding the validity or scope of any 1728 intellectual property or other rights that might be claimed to 1729 pertain to the implementation or use of the technology described in 1730 this document or the extent to which any license under such rights 1731 might or might not be available; neither does it represent that it 1732 has made any effort to identify any such rights. Information on the 1733 IETF's procedures with respect to rights in standards-track and 1734 standards-related documentation can be found in BCP-11. Copies of 1735 claims of rights made available for publication and any assurances 1736 of licenses to be made available, or the result of an attempt made 1737 to obtain a general license or permission for the use of such 1738 proprietary rights by implementors or users of this specification 1739 can be obtained from the IETF Secretariat. 1741 The IETF invites any interested party to bring to its attention any 1742 copyrights, patents or patent applications, or other proprietary 1743 rights which may cover technology that may be required to practice 1744 this standard. Please address the information to the IETF Executive 1745 Director. 1747 Full Copyright Statement 1749 Copyright(C) The Internet Society 2004. All Rights Reserved. 1751 This document and translations of it may be copied and furnished to 1752 others, and derivative works that comment on or otherwise explain it 1753 or assist in its implementation may be prepared, copied, published 1754 and distributed, in whole or in part, without restriction of any 1755 kind, provided that the above copyright notice and this paragraph 1756 are included on all such copies and derivative works. However, this 1757 document itself may not be modified in any way, such as by removing 1758 the copyright notice or references to the Internet Society or other 1759 Internet organizations, except as needed for the purpose of 1760 developing Internet standards in which case the procedures for 1761 copyrights defined in the Internet Standards process must be 1762 followed, or as required to translate it into languages other than 1763 English. 1765 The limited permissions granted above are perpetual and will not be 1766 revoked by the Internet Society or its successors or assigns. 1768 This document and the information contained herein is provided on an 1769 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1770 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1771 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1772 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1773 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1775 Acknowledgement 1777 Funding for the RFC Editor function is currently provided by the 1778 Internet Society.