idnits 2.17.1 draft-ietf-mmusic-sdescriptions-11.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 1793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1817. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1785), 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 229: '... security is NOT RECOMMENDED since the...' RFC 2119 keyword, line 237: '...ine. The "crypto" attribute MUST only...' RFC 2119 keyword, line 259: '...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 573 has weird spacing: '...applied to a ...' == Line 1376 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 1045, but not defined == Missing Reference: 'SIP' is mentioned on line 1270, but not defined == Missing Reference: 'RFC 3313' is mentioned on line 1290, but not defined == Missing Reference: 'RFC3711' is mentioned on line 1359, but not defined == Unused Reference: 'RFC3550' is defined on line 1671, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1699, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 1712, but no explicit reference was found in the text == Unused Reference: 'RFC2733' is defined on line 1735, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1758, but no explicit reference was found in the text == Unused Reference: 'RFC3312' is defined on line 1766, but no explicit reference was found in the text == Unused Reference: 'RFC2974' is defined on line 1770, 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: December 2005 Cisco Systems 6 June, 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.............28 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.....................31 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..............................................33 117 13 Normative References............................................34 118 14 Informative References..........................................34 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 is NOT RECOMMENDED since the protection of the SDP message 230 and the keying material that it contains cannot be ensured through 231 all intermediate entities such as SIP proxies. 233 4 SDP "Crypto" Attribute and Parameters 235 A new media-level SDP attribute called "crypto" describes the 236 cryptographic suite, key parameters, and session parameters for the 237 preceding unicast media line. The "crypto" attribute MUST only 238 appear at the SDP media level (not at the session level). The 239 "crypto" attribute follows the format (see Section 9.1 for the formal 240 ABNF grammar): 242 a=crypto: [] 244 The fields tag, crypto-suite, key-params, and session-params are 245 described in the following sub-sections. Below we show an example of 246 the crypto attribute for the "RTP/SAVP" transport, i.e., the secure 247 RTP extension to the Audio/Video Profile [srtp]. In the following, 248 newlines are included for formatting reasons only: 250 a=crypto:1 AES_CM_128_HMAC_SHA1_80 251 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 253 The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined 254 by the text starting with "inline:", and session-params is omitted. 256 4.1 Tag 258 The tag is a decimal number used as an identifier for a particular 259 crypto attribute (see Section 9.1 for details). The tag MUST be 260 unique among all crypto attributes for a given media line. It is 261 used with the offer/answer model to determine which of several 262 offered crypto attributes were chosen by the answerer (see Section 263 5.1). 265 In the offer/answer model, the tag is a negotiated parameter. 267 4.2 Crypto-suite 269 The crypto-suite field is an identifier that describes the encryption 270 and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for 271 the transport in question (see Section 9.1 for details). The 272 possible values for the crypto-suite parameter are defined within the 273 context of the transport, i.e., each transport defines a separate 274 namespace for the set of crypto-suites. For example, the crypto- 275 suite "AES_CM_128_HMAC_SHA1_80" defined within the context 276 "RTP/SAVP" transport applies to Secure RTP only; the string may be 277 reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a 278 separate definition would be needed. 280 In the offer/answer model, the crypto-suite is a negotiated 281 parameter. 283 4.3 Key Parameters 285 The key-params field provides one or more sets of keying material for 286 the crypto-suite in question. The field consists of a method 287 indicator followed by a colon, and the actual keying information as 288 shown below (the formal grammar is provided in Section 9.1): 290 key-params = ":" 292 Keying material might be provided by different means than key-params, 293 however this is out of scope. Only one method is defined in this 294 document, namely "inline", which indicates that the actual keying 295 material is provided in the key-info field itself. There is a single 296 name space for the key-method, i.e., the key-method is transport 297 independent. New key-methods (e.g., use of a URL) may be defined in 298 a Standards Track RFC in the future. Although the key-method itself 299 may be generic, the accompanying key-info definition is specific not 300 only to the key-method, but also to the transport in question. Key- 301 info encodes keying material for a crypto suite, which defines that 302 keying material. New key methods MUST be registered with the IANA 303 according to the procedures defined in Section 10.2.1. 305 Key-info is defined as a general character string (see Section 9.1 306 for details); further transport and key-method specific syntax and 307 semantics MUST be provided in a Standards Track RFC for each 308 combination of transport and key-method that use it; definitions for 309 SRTP are provided in Section 6. Note that such definitions are 310 provided within the context of both a particular transport (e.g., 311 "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will 312 register the list of supported key methods for each transport. 314 When multiple keys are included in the key parameters, it MUST be 315 possible to determine which of the keys is being used in a given 316 media packet by a simple inspection of the media packet received; a 317 trial-and-error approach between the possible keys MUST NOT be 318 performed. 320 For SRTP, this could be achieved by use of Master Key Identifiers 321 (MKI) [srtp]. Use of <"From, "To"> values are not supported in 322 SRTP security descriptions for reasons explained in Section 6.1, 323 below. 325 In the offer/answer model, the key parameter is a declarative 326 parameter. 328 4.4 Session Parameters 330 Session parameters are specific to a given transport and use of them 331 is OPTIONAL in the security descriptions framework, where they are 332 just defined as general character strings. If session parameters are 333 to be used for a given transport, then transport-specific syntax and 334 semantics MUST be provided in a Standards Track RFC; definitions for 335 SRTP are provided in Section 6. 337 In the offer/answer model, session parameters may be either 338 negotiated or declarative; the definition of specific session 339 parameters MUST indicate whether they are negotiated or declarative. 340 Negotiated parameters apply to data sent in both directions, whereas 341 declarative parameters apply only to media sent by the entity that 342 generated the SDP. Thus, a declarative parameter in an offer applies 343 to media sent by the offerer, whereas a declarative parameter in an 344 answer applies to media sent by the answerer. 346 4.5 Example 348 This example shows use of the crypto attribute for the "RTP/SAVP" 349 media transport type (as defined in Section 5). The "a=crypto" line 350 is actually one long line; it is shown as two lines due to page 351 formatting: 353 v=0 354 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 355 s=SDP Seminar 356 i=A Seminar on the session description protocol 357 u=http://www.example.com/seminars/sdp.pdf 358 e=j.doe@example.com (Jane Doe) 359 c=IN IP4 161.44.17.12/127 360 t=2873397496 2873404696 361 m=video 51372 RTP/SAVP 31 362 a=crypto:1 AES_CM_128_HMAC_SHA1_80 363 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 364 m=audio 49170 RTP/SAVP 0 365 a=crypto:1 AES_CM_128_HMAC_SHA1_32 366 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 367 m=application 32416 udp wb 368 a=orient:portrait 370 This SDP message describes three media streams, two of which use the 371 "RTP/SAVP" transport. Each has a crypto attribute for the 372 "RTP/SAVP" transport. These secure-RTP specific descriptions are 373 defined in Section 6. 375 5 General Use of the crypto Attribute 377 In this section, we describe the general use of the crypto attribute 378 outside of any transport or key-method specific rules. 380 5.1 Use With Offer/Answer 382 The general offer/answer rules for the crypto attribute are in 383 addition to the rules specified in RFC 3264, which MUST be followed, 384 unless otherwise noted. RFC 3264 defines operation for both unicast 385 and multicast streams; the sections below describe operation for two- 386 party unicast streams only, since support for multicast streams (and 387 multipoint unicast streams) is for further study. 389 5.1.1 Generating the Initial Offer - Unicast Streams 391 When generating an initial offer for a unicast stream, there MUST be 392 one or more crypto attributes present for each media stream for which 393 security is desired. Each crypto attribute for a given media stream 394 MUST contain a unique tag. 396 The ordering of multiple "a=crypto" lines is significant: The most 397 preferred crypto line is listed first. Each crypto attribute 398 describes the crypto-suite, key(s) and possibly session parameters 399 offered for the media stream. In general, a "more preferred" crypto- 400 suite SHOULD be cryptographically stronger than a "less preferred" 401 crypto-suite. 403 The crypto-suite always applies to media in the directions supported 404 by the media stream (e.g., send and receive). The key(s), however, 405 apply to media in the direction from the offerer to the answerer; if 406 the media stream is marked as "recvonly", a key MUST still be 407 provided. 409 This is done for consistency. Also, in the case of SRTP, for 410 example, secure RTCP will still be flowing in both the send and 411 receive direction for a unidirectional stream. 413 The offer may include session parameters. There are no general offer 414 rules for the session parameters; instead, specific rules may be 415 provided as part of the transport-specific definitions of any session 416 parameters. 418 When issuing an offer, the offerer MUST be prepared to support media 419 security in accordance with any of the crypto attributes included in 420 the offer. There are however two problems associated with this. 421 First of all, the offerer does not know which key the answerer will 422 be using for media sent to the offerer. Second, the offerer may not 423 be able to deduce which of the offered crypto attributes were 424 accepted. Since media may arrive prior to the answer, delay or 425 clipping can occur. If this is unacceptable to the offerer, the 426 offerer SHOULD use a mechanism outside the scope of this document to 427 prevent the above problem. 429 For example, in SIP [RFC3261], a "security" precondition as defined 430 in [sprecon] could solve the above problem. 432 5.1.2 Generating the Initial Answer - Unicast Streams 434 When the answerer receives the initial offer with one or more crypto 435 attributes for a given unicast media stream, the answerer MUST either 436 accept exactly one of the offered crypto attributes, or the offered 437 stream MUST be rejected. 439 If the answerer wishes to indicate support for other crypto 440 attributes, those can be listed by use of the SDP Simple Capability 441 Declaration [RFC3407] extensions. 443 Only crypto attributes that are valid can be accepted; valid 444 attributes do not violate any of the general rules defined for 445 security descriptions as well as any specific rules defined for the 446 transport and key-method in question. When selecting one of the 447 valid crypto attributes, the answerer SHOULD select the most 448 preferred crypto attribute it can support, i.e., the first valid 449 supported crypto attribute in the list, considering the answerer's 450 capabilities and security policies. 452 If there are one or more crypto attributes in the offer, but none of 453 them are valid, or none of the valid ones are supported, the offered 454 media stream MUST be rejected. 456 When an offered crypto attribute is accepted, the crypto attribute in 457 the answer MUST contain the following: 459 * The tag and crypto-suite from the accepted crypto attribute in the 460 offer (the same crypto-suite MUST be used in the send and receive 461 direction). 462 * The key(s) the answerer will be using for media sent to the 463 offerer. Note that a key MUST be provided, irrespective of any 464 direction attributes in the offer or answer. 466 Furthermore, any session parameters that are negotiated MUST be 467 included in the answer. Declarative session parameters provided by 468 the offerer are not included in the answer, however the answerer may 469 provide its own set of declarative session parameters. 471 Once the answerer has accepted one of the offered crypto attributes, 472 the answerer MAY begin sending media to the offerer in accordance 473 with the selected crypto attribute. Note however, that the offerer 474 may not be able to process such media packets correctly until the 475 answer has been received. 477 5.1.3 Processing of the Initial Answer - Unicast Streams 479 When the offerer receives the answer, the offerer MUST verify, that 480 one of the initially offered crypto suites and its accompanying tag 481 was accepted and echoed in the answer. Also, the answer MUST include 482 one or more keys, which will be used for media sent from the answerer 483 to the offerer. 485 If the offer contained any mandatory negotiated session parameters 486 (see section 6.3.7), the offerer MUST verify that said parameters are 487 included in the answer and support them. If the answer contains any 488 mandatory declarative session parameters, the offerer MUST be able to 489 support those. 491 If any of the above fails, the negotiation MUST fail. 493 5.1.4 Modifying the Session 495 Once a media stream has been established, it MAY be modified at any 496 time, as described in RFC 3264, Section 8. Such a modification MAY 497 be triggered by the security service, e.g., in order to perform a re- 498 keying or change the crypto-suite. If media stream security using 499 the general security descriptions defined here is still desired, the 500 crypto attribute MUST be included in these new offer/answer 501 exchanges. The procedures are similar to those defined in Section 502 5.1.1, 5.1.2, 5.1.3 of this document, subject to the considerations 503 provided in RFC 3264 Section 8. 505 5.2 Use Outside Offer/Answer 507 The crypto attribute can also be used outside the context of 508 offer/answer where there is no negotiation of the crypto suite, 509 cryptographic key or session parameters. In this case, the sender 510 determines security parameters for the stream. Since there is no 511 negotiation mechanisms, the sender MUST include exactly one crypto 512 attribute and the receiver MUST either accept it or else SHOULD NOT 513 receive the associated stream. The sender SHOULD select the security 514 description that it deems most secure for its purposes. 516 5.3 General Backwards Compatibility Considerations 518 In the offer/answer model, it is possible that the answerer supports 519 a given secure transport (e.g., "RTP/SAVP") and accepts the offered 520 media stream, yet the answerer does not support the crypto attribute 521 defined in this document and hence ignores it. The offerer can 522 recognize this situation by seeing an accepted media stream in the 523 answer that does not include a crypto line. In that case, the 524 security negotiation defined here MUST fail. 526 Similar issues exist when security descriptions are used outside of 527 the offer/answer model. But the source of a non-negotiated security 528 description has no indication that the receiver has ignored the 529 crypto attribute. 531 6 SRTP Security Descriptions 533 In this section, we provide definitions for security descriptions for 534 SRTP media streams. In the next section, we define how to use SRTP 535 security descriptions with and without the offer/answer model. 537 SRTP security descriptions MUST only be used with the SRTP transport 538 (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security 539 descriptions for the "RTP/SAVP" profile defined in [srtp], however it 540 is expected that other secure RTP profiles (e.g., "RTP/SAVPF") can 541 use the same descriptions, which are in accordance with the SRTP 542 protocol specification [srtp]. 544 There is no assurance that an endpoint is capable of configuring its 545 SRTP service with a particular crypto attribute parameter, but SRTP 546 guarantees minimal interoperability among SRTP endpoints through the 547 default SRTP parameters [srtp]. More capable SRTP endpoints support 548 a variety of parameter values beyond the SRTP defaults and these 549 values can be configured by the SRTP security descriptions defined 550 here. An endpoint that does not support the crypto attribute will 551 ignore it according to the SDP. Such an endpoint will not correctly 552 process the particular media stream. By using the Offer/Answer 553 model, the offerer and answerer can negotiate the crypto parameters 554 to be used before commencement of the multimedia session (see Section 555 7.1). 557 There are over twenty cryptographic parameters listed in the SRTP 558 specification. Many of these parameters have fixed values for 559 particular cryptographic transforms. At the time of session 560 establishment, however, there is usually no need to provide unique 561 settings for many of the SRTP parameters, such as salt length and 562 pseudo-random function (PRF). Thus, it is possible to simplify the 563 list of parameters by defining "cryptographic suites" that fix a set 564 of SRTP parameter values for the security session. This approach is 565 followed by the SRTP security descriptions, which uses the general 566 security description parameters as follows: 568 * crypto-suite: Identifies the encryption and authentication 569 transforms 570 * key parameter: SRTP keying material and parameters 571 * session parameters: The following parameters are defined: 572 - KDR: The SRTP Key Derivation Rate is the rate that a 573 pseudo-random function is applied to a master key 574 - UNENCRYPTED_SRTP: SRTP messages are not encrypted 575 - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted 576 - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated 577 - FEC_ORDER: Order of forward error correction (FEC) 578 relative to SRTP services 579 - FEC_KEY: Master Key for FEC when the FEC stream is sent 580 to a separate address and/or port. 581 - WSH: Window Size Hint 582 - Extensions: Extension parameters can be defined 584 Please refer to the SRTP specification for a complete list of 585 parameters and their descriptions [Section 8.2, srtp]. Regarding the 586 UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security 587 descriptions MUST NOT use the SRTCP E-bit to override 588 UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP 589 messages (see Section 6.3.2). The key parameter, the crypto-suite, 590 and the session parameters shown above are described in detail in the 591 following subsections. 593 6.1 SRTP Key Parameter 595 SRTP security descriptions define use of the "inline" key method as 596 described in the following. Use of any other keying method, e.g., 597 URL, for SRTP security descriptions is for further study. 599 The "inline" type of key contains the keying material (master key 600 and salt) and all policy related to that master key, including how 601 long it can be used (lifetime) and whether or not it uses a master 602 key identifier (MKI) to associate an incoming SRTP packet with a 603 particular master key. Compliant implementations obey the policies 604 associated with a master key, and MUST NOT accept incoming packets 605 that violate the policy (e.g., after the master key lifetime has 606 expired). 608 The key parameter contains one or more cryptographic master keys, 609 each of which MUST be a unique cryptographically random [RFC1750] 610 value with respect to other master keys in the entire SDP message 611 (i.e., including master keys for other streams). Each key follows 612 the format (the formal definition is provided in Section 9.2): 614 "inline:" ["|" lifetime] ["|" MKI ":" length] 616 key||salt concatenated master key and salt, base64 encoded 617 (see [RFC3548], Section 3) 618 lifetime master key lifetime (max number of SRTP or SRTCP 619 packets using this master key) 620 MKI:length MKI and length of the MKI field in SRTP packets 622 The following definition provides an example for 623 AES_CM_128_HMAC_SHA1_80: 625 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4 627 The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") of the 628 parameter is the cryptographic master key appended with the master 629 salt; the two are first concatenated and then base64 encoded. The 630 length of the concatenated key and salt is determined by the crypto- 631 suite for which the key applies. If the length (after being decoded 632 from base64) does not match that specified for the crypto-suite, the 633 crypto attribute in question MUST be considered invalid. Each master 634 key and salt MUST be a cryptographically random number and MUST be 635 unique to the entire SDP message. When base64 decoding the key and 636 salt, padding characters (i.e., one or two "=" at the end of the 637 base64 encoded data) are discarded (see [RFC3548] for details). 638 Base64 encoding assumes that the base64 encoding input is an integral 639 number of octets. If a given crypto-suite requires the use of a 640 concatenated key and salt with a length that is not an integral 641 number of octets, said crypto-suite MUST define a padding scheme that 642 results in the base64 input being an integral number of octets. For 643 example, if the length defined was 250 bits, then 6 padding bits 644 would be needed, which could be defined to be the last 6 bits in a 645 256 bit input. 647 The second field, is the OPTIONAL lifetime of the master key as 648 measured in maximum number of SRTP or SRTCP packets using that master 649 key (i.e., the number of SRTP packets and the number of SRTCP packets 650 each have to be less than the lifetime). The lifetime value MAY be 651 written as a non-zero, positive integer or as a power of 2 (see the 652 grammar in Section 9.2 for details). The "lifetime" value MUST NOT 653 exceed the maximum packet lifetime for the crypto-suite. If the 654 lifetime is too large or otherwise invalid then the entire crypto 655 attribute MUST be considered invalid. The default MAY be implicitly 656 signaled by omitting the lifetime (note that the lifetime field never 657 includes a colon, whereas the third field always does). This is 658 convenient when the SRTP cryptographic key lifetime is the default 659 value. As a shortcut to avoid long decimal values, the syntax of the 660 lifetime allows using the literal "2^", which indicates "two to the 661 power of". The example above, shows a case where the lifetime is 662 specified as 2^20. The following example, which is for the 663 AES_CM_128_HMAC_SHA1_80 crypto-suite, has a default for the lifetime 664 field, which means that SRTP's and SRTCP's default values will be 665 used (see [srtp]): 667 inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4 669 The example shows a 30-character key and concatenated salt that is 670 base64 encoded: The 30-character key/salt concatenation is expanded 671 to 40 characters by the three-in-four encoding of base64. 673 The third field, which is also OPTIONAL, is the Master Key Identifier 674 (MKI) and its byte length. 676 "MKI" is the master key identifier associated with the SRTP master 677 key. The MKI is here defined as a positive integer which is encoded 678 as a big-endian integer in the actual SRTP packets. If the MKI is 679 given, then the length of the MKI MUST also be given and separated 680 from the MKI by a colon (":"). The MKI length is the size of the MKI 681 field in the SRTP packet, specified in bytes. If the MKI length is 682 not given or its value exceeds 128 (bytes), then the entire crypto 683 attribute MUST be considered invalid. The substring "1:4" in the 684 first example assigns to the key a master key identifier of 1 that is 685 4 bytes long, and the second example assigns a 4-byte master key 686 identifier of 1066 to the key. One or more master keys with their 687 associated MKI can be initially defined, and then later updated, or 688 deleted and new ones defined. 690 SRTP offers a second feature for specifying the lifetime of a master 691 key in terms of two values, called "From" and "To," which are defined 692 on the SRTP sequence number space [srtp]. This SRTP Security 693 Descriptions specification, however, does not support the 694 <"From","To"> feature since the lifetime of an AES master key is 2^48 695 SRTP packets, which means that there is no cryptographic reason to 696 replace a master key for practical point-to-point applications. For 697 this reason, there is no need to support two means for signaling key 698 update. The MKI is chosen over <"From","To"> by this specification 699 for the very few applications that need it since the MKI feature is 700 simpler (though the MKI adds additional bytes to each packet whereas 701 <"From", "To"> does not). 703 As mentioned above, the key parameter can contain one or more master 704 keys. When the key parameter contains more than one master key, all 705 of the master keys in that key parameter MUST include an MKI value. 707 When using the MKI, the MKI length MUST be the same for all keys in a 708 given crypto attribute. 710 6.2 Crypto-suites 712 The SRTP crypto-suites define the encryption and authentication 713 transforms to be used for the SRTP media stream. The SRTP 714 specification has defined three crypto-suites, which are described 715 further in the following subsections in the context of the SRTP 716 security descriptions. The table below provides an overview of the 717 crypto-suites and their parameters: 719 +---------------------+-------------+--------------+---------------+ 720 | |AES_CM_128_ | AES_CM_128_ | F8_128_ | 721 | |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 | 722 +---------------------+-------------+--------------+---------------+ 723 | Master key length | 128 bits | 128 bits | 128 bits | 724 | Salt value | 112 bits | 112 bits | 112 bits | 725 | Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets | 726 | Cipher | AES Counter | AES Counter | F8 | 727 | | Mode | Mode | | 728 | Encryption key | 128 bits | 128 bits | 128 bits | 729 | MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 | 730 | Authentication tag | 80 bits | 32 bits | 80 bits | 731 | SRTP auth. key | 160 bits | 160 bits | 160 bits | 732 | SRTCP auth. key | 160 bits | 160 bits | 160 bits | 733 +---------------------+-------------+--------------+---------------+ 735 6.2.1 AES_CM_128_HMAC_SHA1_80 737 AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher 738 and HMAC-SHA1 message authentication having an 80-bit authentication 739 tag. The master-key length is 128 bits and has a default lifetime 740 of a maximum of 2^31 SRTP packets or SRTCP packets, whichever comes 741 first [Page 39, srtp]. 743 Technically, SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, 744 whichever comes first. SRTP security descriptions, however, 745 simplify the parameters to share a single upper bound of 2^31 746 packets. It is RECOMMENDED that automated key management allow 747 easy and efficient rekeying at intervals far smaller than 2^31 748 packets given today's media rates or even HDTV media rates. 750 The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP 751 and SRTCP authentication key lengths are 160 bits (see Security 752 Considerations in Section 8). The master salt value is 112 bits in 753 length and the session salt value is 112 bits in length. The 754 pseudo-random function (PRF) is the default SRTP pseudo-random 755 function that uses AES Counter Mode with a 128-bit key length. 757 The length of the base64 decoded key and salt value for this crypto- 758 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 759 attribute is considered invalid. 761 6.2.2 AES_CM_128_HMAC_SHA1_32 763 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except 764 that the authentication tag is 32 bits. 766 The length of the base64-decoded key and salt value for this crypto- 767 suite MUST be 30 characters, i.e., 240 bits; otherwise the crypto 768 attribute is considered invalid. 770 6.2.3 F8_128_HMAC_SHA1_80 772 This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except the 773 cipher is F8 [srtp]. 775 The length of the base64 decoded key and salt value for this crypto- 776 suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto 777 attribute is considered invalid. 779 6.2.4 Adding new Crypto-suite Definitions 781 If new transforms are added to SRTP, new definitions for those 782 transforms SHOULD be given for the SRTP security descriptions and 783 published in a Standards Track RFC. Sections 6.2.1 through 6.2.3 784 illustrate how to define crypto-suite values for particular 785 cryptographic transforms. Any new crypto-suites MUST be registered 786 with IANA following the procedures in section 10. 788 6.3 Session Parameters 790 SRTP security descriptions define a set of "session" parameters, 791 which OPTIONALLY may be used to override SRTP session defaults for 792 the SRTP and SRTCP streams. These parameters configure an RTP 793 session for SRTP services. The session parameters provide session- 794 specific information to establish the SRTP cryptographic context. 796 6.3.1 KDR=n 798 KDR specifies the Key Derivation Rate, as described in section 4.3.1 799 of [srtp]. 801 The value n MUST be an integer in the set {1,2,...,24}, which 802 denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key 803 derivation rate controls how frequently a new session key is derived 804 from an SRTP master key(s) [srtp] given in the declaration. When 805 the key derivation rate is not specified (i.e., the KDR parameter is 806 omitted), a single initial key derivation is performed [srtp]. 808 In the offer/answer model, KDR is a declarative parameter. 810 6.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 812 SRTP and SRTCP packet payloads are encrypted by default. The 813 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the 814 default behavior of the crypto-suites with which they are used: 816 * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not 817 encrypted. 819 * UNENCRYPTED_SRTP signals that the SRTP packet payloads are not 820 encrypted. 822 In the offer/answer model, these parameters are negotiated. If 823 UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit 824 MUST be clear (0) in all SRTCP messages. If the default is used, 825 all SRTCP messages are encrypted and the E bit MUST be set (1) on 826 all SRTCP messages. 828 6.3.3 UNAUTHENTICATED_SRTP 830 SRTP and SRTCP packet payloads are authenticated by default. The 831 UNAUTHENTICATED_SRTP session parameter signals that SRTP messages 832 are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT 833 RECOMMENDED (see Security Considerations). 835 The SRTP specification requires use of message authentication for 836 SRTCP, but not for SRTP [srtp]. 838 In the offer/answer model, this parameter is negotiated. 840 6.3.4 FEC_ORDER=order 842 FEC_ORDER signals the use of forward error correction for the RTP 843 packets [rfc2733]. The forward error correction values for "order" 844 are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied 845 before SRTP processing by the sender of the SRTP media and after SRTP 846 processing by the receiver of the SRTP media; FEC_SRTP is the 847 default. SRTP_FEC is the reverse processing. 849 In the offer/answer model, FEC_ORDER is a declarative parameter. 851 6.3.5 FEC_KEY=key-params 853 FEC_KEY signals the use of separate master key(s) for a Forward 854 Error Correction (FEC) stream. The master key(s) are specified with 855 the exact same format as the SRTP Key Parameter defined in Section 856 6.1, and the semantic rules are the same - in particular, the master 857 key(s) MUST be different from all other master key(s) in the SDP. A 858 FEC_KEY MUST be specified when the FEC stream is sent to a different 859 IP-address and/or port than the media stream to which it applies 860 (i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1. 861 When a FEC stream is sent to the same IP-address and port as the 862 media stream to which it applies, a FEC_KEY MUST NOT be specified. 863 If a FEC_KEY is specified in this latter case, the crypto attribute 864 in question MUST be considered invalid. 866 In the offer/answer model, FEC_KEY is a declarative parameter. 868 6.3.6 Window Size Hint (WSH) 870 SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to 871 protect against replay attacks. The minimum value is 64 [srtp], 872 however this value may be considered too low for some applications 873 (e.g., video). 875 The Window Size Hint (WSH) session parameter provides a hint for how 876 big this window should be to work satisfactorily (e.g., based on 877 sender knowledge of number of packets per second). However, there 878 might be enough information given in SDP attributes like 879 "a=maxprate" [maxprate] and the bandwidth modifiers to allow a 880 receiver to derive the parameter satisfactorily. Consequently, this 881 value is only considered a hint to the receiver of the SDP which MAY 882 choose to ignore the value provided. 884 In the offer/answer model, WSH is a declarative parameter. 886 6.3.7 Defining New SRTP Session Parameters 888 New SRTP session parameters for the SRTP security descriptions can 889 be defined in a Standards Track RFC and registered with IANA 890 according to the registration procedures defined in Section 10. 892 New SRTP session parameters are by default mandatory. A newly- 893 defined SRTP session parameter that is prefixed with the dash 894 character ("-") however is considered optional and MAY be ignored. 895 If an SDP crypto attribute is received with an unknown session 896 parameter that is not prefixed with a "-" character, that crypto 897 attribute MUST be considered invalid. 899 6.4 SRTP Crypto Context Initialization 901 In addition to the various SRTP parameters defined above, there are 902 three pieces of information that are critical to the operation of the 903 default SRTP ciphers: 905 * SSRC: Synchronization source 906 * ROC: Roll-over counter for a given SSRC 907 * SEQ: Sequence number for a given SSRC 908 In a unicast session, as defined here, there are three constraints on 909 these values. 911 The first constraint is on the SSRC, which makes an SRTP keystream be 912 unique from other participants. As explained in SRTP, the keystream 913 MUST NOT be reused on two or more different pieces of plaintext. 914 Keystream reuse makes the ciphertext vulnerable to cryptanalysis. 915 One vulnerability is that known-plaintext fields in one stream can 916 expose portions of the reused keystream and this could further expose 917 more plaintext in other streams. Since all current SRTP encryption 918 transforms use keystreams, key sharing is a general problem [srtp]. 919 SRTP mitigates this problem by including the SSRC of the sender in 920 the keystream. But SRTP does not solve this problem in its entirety 921 because Real-time Transport Protocol has SSRC collisions, which are 922 very rare [rtp] but quite possible. During a collision, two or more 923 SSRCs that share a master key will have identical keystreams for 924 overlapping portions of the RTP sequence-number space. SRTP Security 925 Descriptions avoids keystream reuse by making unique master keys 926 REQUIRED for the sender and receiver of the security description. 927 Thus, the first constraint is satisfied. 929 Also note, that there is a second problem with SSRC collisions: The 930 SSRC is used to identify the crypto context and thereby the cipher, 931 key, ROC, etc. to process incoming packets. In case of SSRC 932 collisions, crypto context identification becomes ambiguous and 933 correct packet processing may not occur. Furthermore, if an RTCP 934 BYE packet is to be sent for a colliding SSRC, that packet may also 935 have to be secured. In a (unicast) point-to-multipoint scenario, 936 this can be problematic for the same reasons, i.e., it is not known 937 which of the possible crypto contexts to use. Note that these 938 problems are not unique to the SDP security descriptions; any use 939 of SRTP needs to consider them. 941 The second constraint is that the ROC MUST be zero at the time that 942 each SSRC commences sending packets. Thus, there is no concept of a 943 "late joiner" in SRTP security descriptions, which are constrained to 944 be unicast and pairwise. The ROC and SEQ form a "packet index" in 945 the default SRTP transforms and the ROC is consistently set to zero 946 at session commencement, according to this document. 948 The third constraint is that the initial value of SEQ SHOULD be 949 chosen to be within the range of 0..2^15-1; this avoids an ambiguity 950 when packets are lost at the start of the session. If at the start 951 of a session, an SSRC source might randomly select a high sequence- 952 number value and put the receiver in an ambiguous situation: If 953 initial packets are lost in transit up to the point that the sequence 954 number wraps (i.e., exceeds 2^16-1), then the receiver might not 955 recognize that its ROC needs to be incremented. By restricting the 956 initial SEQ to the range of 0..2^15-1, SRTP packet-index 957 determination will find the correct ROC value, unless all of the 958 first 2^15 packets are lost (which seems, if not impossible, then 959 rather unlikely). See Section 3.3.1 of the SRTP specification 960 regarding packet-index determination [srtp]. 962 6.4.1 Late Binding of one or more SSRCs to a crypto context 964 The packet index, therefore, depends on the SSRC, the SEQ of an 965 incoming packet and the ROC, which is an SRTP crypto context 966 variable. Thus, SRTP has a big security dependency on SSRC 967 uniqueness. 969 Given the above constraints, unicast SRTP crypto contexts can be 970 established without the need to negotiate SSRC values in the SRTP 971 security descriptions. Instead, an approach called "late binding" is 972 RECOMMENDED by this specification. When a packet arrives, the SSRC 973 that is contained in it can be bound to the crypto context at the 974 time of session commencement (i.e., SRTP packet arrival) rather than 975 at the time of session signaling (i.e., receipt of an SDP). With the 976 arrival of the packet containing the SSRC, all the data items needed 977 for the SRTP crypto context are held by the receiver (note that the 978 ROC value by definition is zero; if non-zero values were to be 979 supported, additional signaling would be required). In other words, 980 the crypto context for a secure RTP session using late binding is 981 initially identified by the SDP as: 983 <*, address, port> 985 where '*' is a wildcard SSRC, "address" is the local receive address 986 from the "c=" line, and "port" is the local receive port from the 987 "m=" line. When the first packet arrives with ssrcX in its SSRC 988 field, the crypto context 990 992 is instantiated subject to the following constraints: 994 * Media packets are authenticated: Authentication MUST succeed; 995 otherwise, the crypto context is not instantiated. 997 * Media packets are not authenticated: Crypto context is 998 automatically instantiated. 1000 It should be noted, that use of late binding when there is no 1001 authentication of the SRTP media packets is subject to numerous 1002 security attacks and consequently it is NOT RECOMMENDED (of course, 1003 this can be said for unauthenticated SRTP in general). 1005 Note that use of late binding without authentication will result in 1006 local state being created as a result of receiving a packet from 1007 any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 1008 RECOMMENDED because it invites easy denial-of-service attack. In 1009 contrast, late binding with authentication does not suffer from 1010 this weakness. 1012 6.4.2 Sharing cryptographic contexts among Sessions or SSRCs 1014 With the constraints and procedures described above, it is not 1015 necessary to explicitly signal the SSRC, ROC and SEQ for a unicast 1016 RTP session. So there are no a=crypto parameters for signaling SSRC, 1017 ROC or SEQ. Thus, multiple SSRCs from the same entity will share 1018 a=crypto parameters when late binding is used. Multiple SSRCs from 1019 the same entity arises due to either multiple sources (microphones, 1020 cameras, etc.), or RTP payloads requiring SSRC multiplexing within 1021 that same session. SDP also allows multiple RTP sessions to be 1022 defined in the same media description ("m="), these RTP sessions will 1023 also share the a=crypto parameters. An application that uses 1024 a=crypto in this way serially shares a master key among RTP sessions 1025 or SSRCs and MUST replace the master key when the aggregate number of 1026 packets among all SSRCs approaches 2^31 packets. SSRCs that share a 1027 master key MUST be unique from one another. 1029 6.5 Removal of Crypto Contexts 1031 The mechanism defined above addresses the issue of creating crypto 1032 contexts, however in practice, session participants may want to 1033 remove crypto contexts prior to session termination. Since a crypto 1034 context contains information that can not automatically be recovered 1035 (e.g., ROC), it is important that the sender and receiver agree on 1036 when a crypto context can be removed, and perhaps more importantly 1037 when it cannot. 1039 Even when late binding is used for a unicast stream, the ROC is 1040 lost and cannot be recovered automatically (unless it is zero) once 1041 the crypto context is removed. 1043 We resolve this problem as follows. When SRTP security descriptions 1044 are being used, crypto-context removal MUST follow the same rules as 1045 SSRC removal from the member table [RFC 3550]; note that this can 1046 happen as the result of an SRTCP BYE packet or a simple time-out due 1047 to inactivity. Inactive session participants that wish to ensure 1048 their crypto contexts are not timed out MUST thus send SRTCP packets 1049 at regular intervals. 1051 7 SRTP-Specific Use of the crypto Attribute 1053 Section 5 describes general use of the crypto attribute, and this 1054 section completes it by describing SRTP-specific use. 1056 7.1 Use with Offer/Answer 1058 In this section, we describe how the SRTP security descriptions are 1059 used with the offer/answer model to negotiate cryptographic 1060 capabilities and communicate SRTP master keys. The rules defined 1061 below complement the general offer/answer rules defined in Section 1062 5.1, which MUST be followed, unless otherwise specified. Note that 1063 the rules below define unicast operation only; support for multicast 1064 and multipoint unicast streams is for further study. 1066 7.1.1 Generating the Initial Offer - Unicast Streams 1068 When the initial offer is generated, the offerer MUST follow the 1069 steps in Section 5.1.1 as well as the following steps. 1071 For each unicast media line (m=) using the secure RTP transport 1072 where the offerer wants to specify cryptographic parameters, the 1073 offerer MUST provide at least one valid SRTP security description 1074 ("a=crypto" line), as defined in Section 6. If the media stream 1075 includes Forward Error Correction with a different IP-address and/or 1076 port than the media stream itself, a FEC_KEY parameter MUST be 1077 included, as described in Section 6.3.5. 1079 The offerer MAY include one or more other SRTP session parameters as 1080 defined in Section 6.3. Note however, that if any SRTP session 1081 parameters are included that are not known to the answerer, but are 1082 nonetheless mandatory (see Section 6.3.6), the negotiation will fail 1083 if the answerer does not support them. 1085 7.1.2 Generating the Initial Answer - Unicast Streams 1087 When the initial answer is generated, the answerer MUST follow the 1088 steps in Section 5.1.2 as well as the following steps. 1090 For each unicast media line which uses the secure RTP transport and 1091 contains one or more "a=crypto" lines in the offer, the answerer 1092 MUST either accept one (and only one) of the crypto lines for that 1093 media stream, or it MUST reject the media stream. Only "a=crypto" 1094 lines that are considered valid SRTP security descriptions as 1095 defined in Section 6 can be accepted. Furthermore, all parameters 1096 (crypto-suite, key parameter, and mandatory session parameters) MUST 1097 be acceptable to the answerer in order for the offered media stream 1098 to be accepted. Note that if the media stream includes Forward 1099 Error Correction with a different IP-address and/or port than the 1100 media stream itself, a FEC_KEY parameter MUST be included, as 1101 described in Section 6.3.5. 1103 When the answerer accepts an SRTP unicast media stream with a crypto 1104 line, the answerer MUST include one or more master keys appropriate 1105 for the selected crypto algorithm; the master key(s) included in the 1106 answer MUST be different from those in the offer. 1108 When the master key(s) are not shared between the offerer and 1109 answerer, SSRC collisions between the offerer and answerer will not 1110 lead to keystream reuse, and hence SSRC collisions do not 1111 necessarily have to be prevented. 1113 If Forward Error Correction to a separate IP-address and/or port is 1114 included, the answer MUST include a FEC_KEY parameter, as described 1115 in Section 6.3.5. 1117 Declarative session parameters may be added to the answer as usual, 1118 however the answerer SHOULD NOT add any mandatory session parameter 1119 (see Section 6.3.6) that might be unknown to the offerer. 1121 If the answerer cannot find any valid crypto line that it supports, 1122 or if its configured policy prohibits any cryptographic key 1123 parameter (e.g., key length) or cryptographic session parameter 1124 (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it 1125 is able to successfully negotiate use of SRTP by other means outside 1126 the scope of this document (e.g., by use of MIKEY [mikey]). 1128 7.1.3 Processing of the Initial Answer - Unicast Streams 1130 When the offerer receives the answer, it MUST perform the steps in 1131 Section 5.1.3 as well as the following steps for each SRTP media 1132 stream it offered with one or more crypto lines in it. 1134 If the media stream was accepted and it contains a crypto line, it 1135 MUST be checked that the crypto line is valid according to the 1136 constraints specified in Section 6 (including any FEC constraints). 1138 If the offerer either does not support or is not willing to honor 1139 one or more of the SRTP parameters in the answer, the offerer MUST 1140 consider the crypto line invalid. 1142 If the crypto line is not valid, or the offerer's configured policy 1143 prohibits any cryptographic key parameter (e.g. key length) or 1144 cryptographic session parameter, the SRTP security negotiation MUST 1145 be deemed to have failed. 1147 7.1.4 Modifying the Session 1149 When a media stream using the SRTP security descriptions has been 1150 established, and a new offer/answer exchange is performed, the 1151 offerer and answerer MUST follow the steps in Section 5.1.4 as well 1152 as the following steps. 1154 When modifying the session, all negotiated aspects of the SRTP media 1155 stream can be modified. For example, a new crypto suite can be used 1156 or a new master key can be established. As described in RFC 3264, 1157 when doing a new offer/answer exchange there will be a window of 1158 time, where the offerer and the answerer must be prepared to receive 1159 media according to both the old and the new offer/answer exchange. 1161 This requirement applies here as well, however the following should 1162 be noted: 1164 * When authentication is not being used, it may not be possible for 1165 either the offerer or the answerer to determine if a given packet 1166 is encrypted according to the old or new offer/answer exchange. 1167 RFC 3264 defines a couple of techniques to address this problem, 1168 e.g., changing the payload types used and/or the transport 1169 addresses. Note however that a change in transport addresses may 1170 have an impact on Quality of Service as well as firewall and NAT 1171 traversal. The SRTP security descriptions use the MKI to deal with 1172 this (which adds a few bytes to each SRTP packet) as described in 1173 Section 6.1. For further details on the MKI, please refer to 1174 [srtp]. 1176 * If the answerer changes its master key, the offerer will not 1177 be able to process packets secured via this master key until the 1178 answer is received. This could be addressed by using a security 1179 "precondition" [sprecon]. 1181 If the offerer includes an IP address and/or port that differs from 1182 that used previously for a media stream (or FEC stream), the offerer 1183 MUST include a new master key with the offer (and in so doing, it 1184 will be creating a new crypto context with the ROC set to zero). 1185 Similarly, if the answerer includes an IP address and/or port that 1186 differs from that used previously for a media stream (or FEC 1187 stream), the answerer MUST include a new master key with the offer 1188 (and hence create a new crypto context with the ROC set to zero). 1189 The reason for this is, that when the answerer receives an offer, or 1190 the offerer receives an answer, with an updated IP address and/or 1191 port, it is not possible to determine if the other side has access 1192 to the old crypto context parameters (and in particular the ROC) or 1193 not. For example, if one side is a decomposed gateway, or a back- 1194 to-back user agent is involved, it is possible that the media 1195 endpoint changed and no longer has access to the old crypto context. 1196 By always requiring a new master key in this case, the 1197 answerer/offerer will know that the ROC is zero for this 1198 offer/answer, and any key lifetime constraints will trivially be 1199 satisfied too. Another consideration here applies to media relays; 1200 if the relay changes the media endpoint on one side transparently to 1201 the other side, the relay cannot operate as a simple packet 1202 reflector but will have to actively engage in SRTP packet processing 1203 and transformation (i.e., decryption and re-encryption, etc.). 1205 Finally note, that if the new offer is rejected, the old crypto 1206 parameters remain in place. 1208 7.1.5 Offer/Answer Example 1210 In this example, the offerer supports two crypto suites (f8 and AES). 1211 The a=crypto line is actually one long line, although it is shown as 1212 two lines in this document due to page formatting. The f8 example 1213 shows two inline parameters; as explained in Section 6.1, there may 1214 be one or more key (i.e. inline) parameters in a crypto attribute. 1215 In this way, multiple keys are offered to support key rotation using 1216 a master key index (MKI). 1218 Offerer sends: 1219 v=0 1220 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 1221 s=SRTP Discussion 1222 i=A discussion of Secure RTP 1223 u=http://www.example.com/seminars/srtp.pdf 1224 e=marge@example.com (Marge Simpson) 1225 c=IN IP4 168.2.17.12 1226 t=2873397496 2873404696 1227 m=audio 49170 RTP/SAVP 0 1228 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1229 inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4 1230 FEC_ORDER=FEC_SRTP 1231 a=crypto:2 F8_128_HMAC_SHA1_80 1232 inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4; 1233 inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 1234 FEC_ORDER=FEC_SRTP 1236 Answerer replies: 1237 v=0 1238 o=jill 25690844 8070842634 IN IP4 10.47.16.5 1239 s=SRTP Discussion 1240 i=A discussion of Secure RTP 1241 u=http://www.example.com/seminars/srtp.pdf 1242 e=homer@example.com (Homer Simpson) 1243 c=IN IP4 168.2.17.11 1244 t=2873397526 2873405696 1245 m=audio 32640 RTP/SAVP 0 1246 a=crypto:1 AES_CM_128_HMAC_SHA1_80 1247 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 1249 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 1250 crypto suite for the RTP and RTCP traffic. If F8_128_HMAC_SHA1_80 1251 were selected by the answerer, there would be two inline keys 1252 associated with the SRTP cryptographic context. One key has an MKI 1253 value of 1 and the second has an MKI of 2. 1255 7.2 SRTP-Specific Use Outside Offer/Answer 1257 Use of SRTP security descriptions outside the offer/answer model is 1258 not defined. 1260 Use of SRTP security descriptions outside offer/answer could have 1261 been defined for sendonly media streams, however, there would not 1262 be a way to indicate the key to use for SRTCP by the receiver of 1263 said media stream. 1265 7.3 Support for SIP Forking 1267 As mentioned earlier, the security descriptions defined here do not 1268 support multicast media streams or multipoint unicast streams. 1269 However, in the SIP protocol, it is possible to receive several 1270 answers to a single offer due to the use of forking (see [SIP]). 1271 Receiving multiple answers leads to a couple of problems for the 1272 SRTP security descriptions: 1274 * Different answerers may choose different ciphers, keys, etc., 1275 however there is no way for the offerer to associate a particular 1276 incoming media packet with a particular answer. 1278 * Two or more answerers may pick the same SSRC and hence the SSRC 1279 collision problems mentioned earlier may arise. 1281 As stated earlier, the above point-to-multipoint cases are outside 1282 the scope of the SDP security descriptions. However, there is a way 1283 of supporting SIP forking: Change the multipoint scenario resulting 1284 from SIP forking into multiple two-party unicast cases. This is 1285 done as follows: 1287 For each answer received beyond the initial answer, issue a new 1288 offer to that particular answerer using a new receive transport 1289 address (IP address and port); note that this requires support for 1290 the SIP UPDATE method [RFC 3313]. Also, to ensure that two media 1291 sessions are not inadvertently established prior to the UPDATE being 1292 processed by one of them, use security preconditions [sprecon]. 1294 Finally, note that all SIP User Agents that received the offer will 1295 know the key(s) being proposed by the initial offer. If the offerer 1296 wants to ensure security with respect to all other User Agents that 1297 may have received the offer, a new offer/answer exchange with a new 1298 key needs to be performed with the answerer as well. It should be 1299 noted, that the offerer cannot determine whether a single or 1300 multiple SIP User Agents received the offer, since intermediate 1301 forking proxies may only forward a single answer to the offerer. 1303 7.4 SRTP-Specific Backwards Compatibility Considerations 1305 It is possible that the answerer supports the SRTP transport and 1306 accepts the offered media stream, yet it does not support the crypto 1307 attribute defined here. The offerer can recognize this situation by 1308 seeing an accepted SRTP media stream in the answer that does not 1309 include a crypto line. In that case, the security negotiation 1310 defined here MUST be deemed to have failed. 1312 Also, if a media stream with a given SRTP transport (e.g., 1313 "RTP/SAVP") is sent to a device that does not support SRTP, that 1314 media stream will be rejected. 1316 7.5 Operation with KEYMGT= and k= lines 1318 An offer MAY include both "a=crypto" and "a=keymgt" lines [keymgt]. 1319 Per SDP rules, the answerer will ignore attribute lines that it does 1320 not understand. If the answerer supports both "a=crypto" and 1321 "a=keymgt", the answer MUST include either "a=crypto" or "a=keymgt" 1322 but not both, as including both is undefined. 1324 An offer MAY include both "a=crypto" and "k=" lines [SDP]. Per SDP 1325 rules, the answerer will ignore attribute lines it does not 1326 understand. If the answerer supports both "a=crypto" and "k=", the 1327 answer MUST include either "a=crypto" or "k=" but not both, as 1328 including both is undefined. 1330 8 Security Considerations 1332 Like all SDP messages, SDP messages containing security 1333 descriptions, are conveyed in an encapsulating application protocol 1334 (e.g., SIP, MGCP, etc.). It is the responsibility of the 1335 encapsulating protocol to ensure the protection of the SDP security 1336 descriptions. Therefore, IT IS REQUIRED that the application invoke 1337 its own security mechanisms (e.g., secure multiparts such as S/MIME 1338 [smime]) or alternatively utilize a lower-layer security service 1339 (e.g., TLS, or IPsec). IT IS REQUIRED that this security service 1340 provide strong message authentication and packet-payload encryption 1341 as well as effective replay protection. 1343 The discussion which follows uses "message authentication" and 1344 "message confidentiality" in a consistent manner with SRTP 1345 [RFC3711]. "Message confidentiality" means that only the holder of 1346 the secret decryption key can access the plain-text content of the 1347 message. The decryption key is the same key as the encryption key 1348 using SRTP counter mode and f8 encryption transforms, which are 1349 vulnerable to message tampering and need SRTP message authentication 1350 to detect such tampering. "Message authentication" and "message 1351 integrity validation" generally mean the same thing in IETF security 1352 standards: An SRTP message is authenticated following a successful 1353 HMAC integrity check [RFC3711], which proves that the message 1354 originated from the holder of an SRTP master key and was not altered 1355 en route. Such an "authentic" message, however, can be captured by 1356 an attacker and "replayed" when the attacker re-inserts the packet 1357 into the channel. A replayed packet can have a variety of bad 1358 effects on the session, and SRTP uses the extended sequence number 1359 to detect replayed SRTP packets [RFC3711]. 1361 The SRTP specification identifies which services and features are 1362 default values that are normative-to-implement (such as 1363 AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32). 1365 8.1 Authentication of packets 1367 Security descriptions as defined herein signal security services for 1368 RTP packets. RTP messages are vulnerable to a variety of attacks 1369 such as replay and forging. To limit these attacks, SRTP message 1370 integrity mechanisms SHOULD be used (SRTP replay protection is 1371 always enabled). 1373 8.2 Keystream Reuse 1375 SRTP security descriptions signal configuration parameters for SRTP 1376 sessions. Misconfigured SRTP sessions are vulnerable to attacks on 1377 their encryption services when running the crypto suites defined in 1378 Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is 1379 "misconfigured" when two or more media streams are encrypted using 1380 the same keystream of AES blocks. When senders and receivers share 1381 derived session keys, SRTP requires that the SSRCs of session 1382 participants serve to make their corresponding keystreams unique, 1383 which is violated in the case of SSRC collision: SRTP SSRC collision 1384 drastically weakens SRTP or SRTCP payload encryption during the time 1385 that identical keystreams were used [srtp]. An attacker, for 1386 example, might collect SRTP and SRTCP messages and await a 1387 collision. This attack on the AES-CM and AES-f8 encryption is 1388 avoided entirely when each media stream has its own unique master 1389 key in both the send and receive direction. This specification 1390 restricts use of SDP security description to unicast point-to-point 1391 streams so that keys are not shared between SRTP hosts, and the 1392 master keys used in the send and receive direction for a given media 1393 stream are unique. 1395 8.3 Signaling Authentication and Signaling Encryption 1397 There is no reason to incur the complexity and computational expense 1398 of SRTP, however, when its key establishment is exposed to 1399 unauthorized parties. In most cases, the SRTP crypto attribute and 1400 its parameters are vulnerable to denial of service attacks when they 1401 are carried in an unauthenticated SDP message. In some cases, the 1402 integrity or confidentiality of the RTP stream can be compromised. 1403 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 1404 an offer, this could result in the answerer not decrypting the 1405 encrypted SRTP messages. In the worst case, the answerer might 1406 itself send unencrypted SRTP and leave its data exposed to snooping. 1408 Thus, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or 1409 some other data security service be used to provide message 1410 authentication for the encapsulating protocol that carries the SDP 1411 messages having a crypto attribute (a=crypto). Furthermore, IT IS 1412 REQUIRED that encryption of the encapsulating payload be used 1413 whenever a master key parameter (inline) appears in the message. 1414 Failure to encrypt the SDP message containing an inline SRTP master 1415 key renders the SRTP authentication or encryption service useless in 1416 practically all circumstances. Failure to authenticate an SDP 1417 message that carries SRTP parameters renders the SRTP authentication 1418 or encryption service useless in most practical applications. 1420 When the communication path of the SDP message is routed through 1421 intermediate systems that inspect parts of the SDP message, security 1422 protocols such as IPsec or TLS SHOULD NOT be used for encrypting 1423 and/or authenticating the security description. In the case of 1424 intermediate-system processing of a message containing SDP security 1425 descriptions, the "a=crypto" attributes SHOULD be protected end-to- 1426 end so that the intermediate system can neither modify the security 1427 description nor access the keying material. Network or transport 1428 security protocols that terminate at each intermediate system, 1429 therefore, SHOULD NOT be used for protecting SDP security 1430 descriptions. A security protocol SHOULD allow the security 1431 descriptions to be encrypted and authenticated end-to-end 1432 independently of the portions of the SDP message that any 1433 intermediate system modifies or inspects: MIME secure multiparts 1434 are RECOMMENDED for the protection of SDP messages that are 1435 processed by intermediate systems. 1437 9 Grammar 1439 In this section we first provide the ABNF grammar for the generic 1440 crypto attribute, and then we provide the ABNF grammar for the SRTP 1441 specific use of the crypto attribute. 1443 9.1 Generic "Crypto" Attribute Grammar 1445 The ABNF grammar for the crypto attribute is defined below: 1447 "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params 1448 *(1*WSP session-param) 1450 tag = 1*9DIGIT 1451 crypto-suite = 1*(ALPHA / DIGIT / "_") 1453 key-params = key-param *(";" key-param) 1454 key-param = key-method ":" key-info 1455 key-method = "inline" / key-method-ext 1456 key-method-ext = 1*(ALPHA / DIGIT / "_") 1457 key-info = %x21-3A / %x3C-7E ; visible (printing) characters 1458 ; except semi-colon 1459 session-param = 1*(VCHAR) ; visible (printing) characters 1461 where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC2234]. 1463 9.2 SRTP "Crypto" Attribute Grammar 1465 This section provides an Augmented BNF [RFC2234] grammar for the 1466 SRTP-specific use of the SDP crypto attribute: 1468 crypto-suite = srtp-crypto-suite 1469 key-method = srtp-key-method 1470 key-info = srtp-key-info 1471 session-param = srtp-session-param 1473 srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 1474 "F8_128_HMAC_SHA1_32" / 1475 "AES_CM_128_HMAC_SHA1_80" / 1476 srtp-crypto-suite-ext 1478 srtp-key-method = "inline" 1479 srtp-key-info = key-salt ["|" lifetime] ["|" mki] 1481 key-salt = 1*(base64) ; binary key and salt values 1482 ; concatenated together, and then 1483 ; base64 encoded [section 6.8 of 1484 ; RFC2046] 1486 lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^" 1487 mki = mki-value ":" mki-length 1488 mki-value = 1*DIGIT 1489 mki-length = 1*3DIGIT ; range 1..128. 1491 srtp-session-param = kdr / 1492 "UNENCRYPTED_SRTP" / 1493 "UNENCRYPTED_SRTCP" / 1494 "UNAUTHENTICATED_SRTP" / 1495 fec-order / 1496 fec-key / 1497 wsh / 1498 srtp-session-extension 1500 kdr = "KDR=" 1*2(DIGIT) ; range 0..24, 1501 ; power of two 1503 fec-order = "FEC_ORDER=" fec-type 1504 fec-type = "FEC_SRTP" / "SRTP_FEC" 1505 fec-key = "FEC_KEY=" key-params 1507 wsh = "WSH=" 2*DIGIT ; minimum value is 64 1508 base64 = ALPHA / DIGIT / "+" / "/" / "=" 1510 srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") 1511 srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] 1512 ; first character must not be dash ("-") 1514 10 IANA Considerations 1516 10.1 Registration of the "crypto" attribute 1518 The IANA is hereby requested to register a new SDP attribute as 1519 follows: 1521 Attribute name: crypto 1522 Long form name: Security description cryptographic attribute 1523 for media streams 1524 Type of attribute: Media-level 1525 Subject to charset: No 1526 Purpose: Security descriptions 1527 Appropriate values: See Section 4 1529 10.2 New IANA Registries and Registration Procedures 1531 The following sub-sections define a new IANA registry with associated 1532 sub-registries to be used for the SDP security descriptions. The 1533 IANA is hereby requested to create an SDP Security Description 1534 registry as shown below and further described in the following 1535 sections: 1537 SDP Security Descriptions 1538 | 1539 +- Key Methods (described in 10.2.1) 1540 | 1541 +- Media Stream Transports (described in 10.2.2) 1542 | 1543 +- Transport1 (e.g. SRTP) 1544 | | 1545 | +- Supported Key Methods (e.g. inline) 1546 | | 1547 | +- crypto suites 1548 | | 1549 | +- session parameters 1550 | 1551 +- Transport2 1552 : : 1554 10.2.1 Key Method Registry and Registration 1556 The IANA is hereby requested to create a new subregistry for SDP 1557 security description key methods. An IANA key method registration 1558 MUST be documented in an RFC in accordance with the RFC 2434 1559 Standards Action and it MUST provide the name of the key method in 1560 accordance with the grammar for key-method-ext defined in Section 1561 9.1. 1563 10.2.2 Media Stream Transport Registry and Registration 1565 The IANA is hereby requested to create a new subregistry for SDP 1566 security description Media Stream Transports. An IANA media stream 1567 transport registration MUST be documented in an RFC in accordance 1568 with the RFC 2434 Standards Action and the procedures defined in 1569 Section 4 and 5 of this document. The registration MUST provide the 1570 name of the transport and a list of supported key methods. 1572 In addition, each new media stream transport registry must contain a 1573 crypto-suite registry and a session parameter registry as well as 1574 IANA instructions for how to populate these registries. 1576 10.3 Initial Registrations 1578 10.3.1 Key Method 1580 The following security descriptions key methods are hereby 1581 registered: 1583 inline 1585 10.3.2 SRTP Media Stream Transport 1587 The IANA is hereby requested to create an SDP Security Description 1588 Media Stream Transport subregistry for "SRTP". The key methods 1589 supported is "inline". The reference for the SDP security 1590 description for SRTP is this document. 1592 10.3.2.1 SRTP Crypto Suite Registry and Registration 1594 The IANA is hereby requested to create a new subregistry for SRTP 1595 crypto suites under the SRTP transport of the SDP Security 1596 Descriptions. An IANA SRTP crypto suite registration MUST indicate 1597 the crypto suite name in accordance with the grammar for srtp- 1598 crypto-suite-ext defined in Section 9.2. 1600 The semantics of the SRTP crypto suite MUST be described in an RFC 1601 in accordance with the RFC 2434 Standards Action, including the 1602 semantics of the "inline" key-method and any special semantics of 1603 parameters. 1605 The following SRTP crypto suites are hereby registered: 1607 AES_CM_128_HMAC_SHA1_80 1608 AES_CM_128_HMAC_SHA1_32 1609 F8_128_HMAC_SHA1_80 1611 The reference for these crypto-suites is provided in this document. 1613 10.3.2.2 SRTP Session Parameter Registration 1615 The IANA is hereby requested to create a new subregistry for SRTP 1616 session parameters under the SRTP transport of the SDP Security 1617 Descriptions. An IANA SRTP session parameter registration MUST 1618 indicate the session parameter name (srtp-session-extension as 1619 defined in Section 9.2); the name MUST NOT begin with the dash 1620 character ("-"). 1622 The semantics of the parameter MUST be described in an RFC in 1623 accordance with the RFC 2434 Standards Action. If values can be 1624 assigned to the parameter, then the format and possible values that 1625 can be assigned MUST be described in the RFC in accordance with the 1626 RFC 2434 Standards Action as well. Also, it MUST be specified 1627 whether the parameter is declarative or negotiated in the 1628 offer/answer model. 1630 The following SRTP session parameters are hereby registered: 1632 KDR 1633 UNENCRYPTED_SRTP 1634 UNENCRYPTED_SRTCP 1635 UNAUTHENTICATED_SRTP 1636 FEC_ORDER 1637 FEC_KEY 1638 WSH 1640 The reference for these parameters is this document. 1642 11 Acknowledgements 1644 This document is a product of the IETF MMUSIC working group and has 1645 benefited from comments from its participants. This document also 1646 benefited from discussions with Elisabetta Cararra, Earl Carter, 1647 Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David 1648 McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, 1649 Mike Thomas, Brian Weis, and Magnus Westerlund. 1651 12 Authors' Addresses 1653 Flemming Andreasen 1654 Cisco Systems, Inc. 1655 499 Thornall Street, 8th Floor 1656 Edison, New Jersey 08837 USA 1657 fandreas@cisco.com 1659 Mark Baugher 1660 5510 SW Orchid Street 1661 Portland, Oregon 97219 USA 1662 mbaugher@cisco.com 1663 Dan Wing 1664 Cisco Systems, Inc. 1665 170 West Tasman Drive 1666 San Jose, CA 95134 USA 1667 dwing@cisco.com 1669 13 Normative References 1671 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1672 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 1673 STD 64, July 2003, http://www.ietf.org/rfc/rfc3550.txt. 1675 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 1676 Specifications: ABNF," RFC 2234, November 1997, 1677 http://www.ietf.org/rfc/rfc2234.txt. 1679 [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1680 RFC 2327, April 1998. 1682 [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May 1683 2000, http://www.ietf.org/rfc/rfc2828.txt. 1685 [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 1686 the Session Description Protocol (SDP)", RFC 3264, June 2202, 1687 http://www.ietf.org/rfc/rfc3264.txt. 1689 [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 1690 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 1692 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 1693 Recommendations for Security", RFC 1750, December 1994, 1694 http://www.ietf.org/rfc/rfc1750.txt. 1696 [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data 1697 Encodings", RFC 3548, July 2003. 1699 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1700 Considerations Section in RFCs", RFC 2434, October 1998. 1702 [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security 1703 Preconditions for Session Description Protocol Media Streams", work 1704 in progress, February 2004. 1706 14 Informative References 1708 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 1709 Capability Declaration", RFC 3407, October 2002, 1710 http://www.ietf.org/rfc/rfc3407.txt. 1712 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 1713 Protocols," in Proceedings of the Sixth Usenix Unix Security 1714 Symposium, pp. 1-16, San Jose, CA, July 1996. 1716 [GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1717 Domain of Interpretation", RFC 3547, July 2003, 1718 http://www.ietf.org/rfc/rfc3547.txt. 1720 [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of 1721 Keys (KINK)", Work in Progress. 1723 [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 1724 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 1726 [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the 1727 Internet Protocol", RFC 2401, November 1998, 1728 http://www.ietf.org/rfc/rfc2401.txt. 1730 [maxprate] Westerlund, M., "A Transport-independent Bandwidth 1731 Modifier for the Session Description Protocol (SDP)," April 2004, 1732 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam- 1733 06.txt 1735 [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for 1736 Generic Forward Error Correction", RFC 2733, December 1999, 1737 http://www.ietf.org/rfc/rfc2733.txt. 1739 [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 1740 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 1742 [pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy 1743 (PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. 1745 [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1746 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 1748 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1749 "Key Management Extensions for SDP and RTSP", Work in Progress. 1751 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1752 "MIKEY: Multimedia Internet KEYing", Work in Progress. 1754 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1755 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1756 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1758 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1759 for Message Authentication", RFC 2014, November 1997, 1760 http://www.ietf.org/rfc/rfc2104.txt. 1762 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1763 Mechanism for the Internet", ISOC Secure Networks and Distributed 1764 Systems Symposium, San Diego, 1996. 1766 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 1767 Resource Management and Session Initiation Protocol (SIP)", RFC 1768 3312, October 2002, http://www.ietf.org/rfc/rfc3312.txt. 1770 [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session Announcement 1771 Protocol", RFC 2974, October 2000, 1772 http://www.ietf.org/rfc/rfc2974.txt. 1774 [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1775 RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. 1777 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1778 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1779 Session Initiation Protocol", RFC 3261, June 2002. 1781 15 Full Copyright Statement 1783 Copyright (C) The Internet Society (2005). This document is subject 1784 to the rights, licenses and restrictions contained in BCP 78, and 1785 except as set forth therein, the authors retain all their rights. 1787 This document and the information contained herein are provided on 1788 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1789 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1790 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1791 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1792 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1793 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1795 Intellectual Property 1797 The IETF takes no position regarding the validity or scope of any 1798 Intellectual Property Rights or other rights that might be claimed 1799 to pertain to the implementation or use of the technology 1800 described in this document or the extent to which any license 1801 under such rights might or might not be available; nor does it 1802 represent that it has made any independent effort to identify any 1803 such rights. Information on the procedures with respect to 1804 rights in RFC documents can be found in BCP 78 and BCP 79. 1806 Copies of IPR disclosures made to the IETF Secretariat and any 1807 assurances of licenses to be made available, or the result of an 1808 attempt made to obtain a general license or permission for the use 1809 of such proprietary rights by implementers or users of this 1810 specification can be obtained from the IETF on-line IPR repository 1811 at http://www.ietf.org/ipr. 1813 The IETF invites any interested party to bring to its attention 1814 any copyrights, patents or patent applications, or other 1815 proprietary rights that may cover technology that may be required 1816 to implement this standard. Please address the information to the 1817 IETF at ietf-ipr@ietf.org. 1819 Acknowledgement 1821 Funding for the RFC Editor function is currently provided by the 1822 Internet Society.