idnits 2.17.1 draft-ietf-mmusic-sdescriptions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 112: '...DP transport and SHOULD be specified i...' RFC 2119 keyword, line 157: '..."crypto" attribute MUST only appear at...' RFC 2119 keyword, line 184: '...key-param field MUST either contain a...' RFC 2119 keyword, line 185: '... or it MUST be a pointer to a uri wh...' RFC 2119 keyword, line 196: '...lue that follows MUST be a Uniform Res...' (91 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 390 has weird spacing: '..._length sal...' -- 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.) -- The document date (June 27, 2003) is 7602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 91, but not defined == Missing Reference: 'SRTP' is mentioned on line 527, but not defined == Missing Reference: 'RFC 3264' is mentioned on line 560, but not defined == Missing Reference: 'RFC2396' is mentioned on line 874, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) == Unused Reference: 'RFC1889' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'Bellovin' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1008, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDPnew' ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Flemming Andreasen 3 MMUSIC Working Group Mark Baugher 4 INTERNET-DRAFT Dan Wing 5 EXPIRES: December 2003 Cisco Systems 6 June 27, 2003 8 SDP Security Descriptions for Media Streams 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/lid-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document defines a Session Description Protocol (SDP) 35 cryptographic attribute for media streams. The attribute describes 36 a cryptographic key and other parameters, which serve to configure 37 security for a media stream. This document defines the Secure Real- 38 time Transport Protocol (SRTP) parameters for the attribute. The 39 SDP crypto attribute requires the services of a data security 40 protocol to secure the SDP message. 42 TABLE OF CONTENTS 44 1. Notational Conventions............................................2 45 2. Introduction......................................................3 46 3. SDP "Crypto" Attribute and Parameters.............................4 47 3.1 Crypto-suite....................................................4 48 3.2 Key Parameter...................................................4 49 3.4 Session Parameters..............................................5 50 3.5 Examples........................................................5 51 4. RTP/SAVP (SRTP) Security Descriptions.............................6 52 4.1 Crypto-suites...................................................7 53 4.1.1 AES_CM_128_HMAC_SHA1_80.....................................7 54 4.1.2 AES_CM_128_HMAC_SHA1_32.....................................7 55 4.1.3 F8_128_HMAC_SHA1_80.........................................7 56 4.1.4 Adding new CRYPTO-SUITE definitions.........................8 57 4.2 Key-param Parameter.............................................8 58 4.2.1 Key Usage...................................................8 59 4.2.2 INLINE Definition...........................................8 60 4.3 Session Parameters.............................................10 61 4.3.1 SRC=/SSRC/ROC/SEQ..........................................10 62 4.3.2 KEY_DERIVATION_RATE=n......................................11 63 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP.....................11 64 4.3.4 FEC_ORDER=order............................................11 65 4.3.5 UNAUTHENTICATED_SRTP.......................................12 66 5. Use with Offer/Answer............................................12 67 5.1 Generating the Offer...........................................12 68 5.2 Answerer Processing............................................12 69 5.4 Non-RTP/SAVP Answerers.........................................14 70 5.4 Offer/Answer Example: Receiver Supports SRTP...................14 71 5.7 Use of a=crypto With Active Media Streams......................15 72 5.8 Operation with KEYMGT and Key lines............................15 73 6. Security Considerations..........................................15 74 6.1 Authentication of packets......................................16 75 6.1 Key-stream Reuse...............................................16 76 6.2 Signaling Authentication and Signaling Encryption..............17 77 7. SRTP "Crypto" Attribute Grammar..................................18 78 8. Open Issues......................................................19 79 9. Acknowledgements.................................................19 80 10. Authors' Addresses..............................................19 81 11. Normative References............................................20 82 Intellectual Property Statement.....................................21 83 Acknowledgement.....................................................22 85 1. Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. The 90 terminology conforms to [RFC2828]. 92 2. Introduction 94 The Session Description Protocol (SDP) describes multimedia 95 sessions, which can be audio, video, whiteboard, fax, modem and 96 other media sessions. Security services such as data origin 97 authentication, integrity and confidentiality are often needed for 98 these media streams. The Secure Real-time Transport Protocol (SRTP) 99 can be used to provide such security services, and use of it can be 100 signaled by use of the "RTP/SAVP" transport in an SDP media (m=) 101 line. However, there are no means within SDP itself to configure 102 SRTP beyond using defaults values. This document specifies a new 103 SDP attribute called "crypto", which is used to signal and negotiate 104 cryptographic parameters for SRTP. 106 The crypto attribute might be extended to non-SRTP transports such 107 as whiteboard, modem, fax, and other transports that could use 108 various security protocols such as IPsec or TLS. These extensions, 109 however, are beyond the scope of this document. Each type of SDP 110 media stream needs its own definitions that assign values to its 111 crypto-attribute parameters. These definitions are unique to the 112 particular SDP transport and SHOULD be specified in an Internet RFC. 113 This document defines the parameter values for SRTP. 115 It would be self-defeating not to secure cryptographic keys and 116 other parameters at least as well as SRTP secures RTP packets or 117 IPsec secures IP packets. Data security protocols such as SRTP rely 118 upon a separate key management system to securely establish 119 encryption and/or authentication keys. Key management protocols 120 provide authenticated key establishment (AKE) procedures to 121 authenticate the identity of each endpoint and protect against man- 122 in-the-middle, reflection/replay, connection hijacking and some 123 denial of service attacks [skeme]. Along with the key, an AKE 124 protocol such as MIKEY, GDOI, KINK, IKE or TLS securely disseminates 125 information describing both the key and the data-security session 126 (for example, whether SRTCP payloads are encrypted or unencrypted in 127 an SRTP session). AKE is needed because it is pointless to provide 128 a key over a medium where an attacker can snoop the key, alter the 129 definition of the key to render it useless, or change the parameters 130 of the security session to gain unauthorized access to session- 131 related information. 133 SDP, however, was not designed to provide AKE services, and the 134 media security descriptions that follow do not add AKE services to 135 SDP. This specification is no replacement for a key management 136 protocol or for the conveyance of key management messages in SDP 137 [keymgt]. The SDP security descriptions are suitable for restricted 138 cases where IPsec, TLS, or some other encapsulating data-security 139 protocol (e.g. SIP secure multiparts) protects the SDP message. 140 This draft adds security descriptions to those encrypted and/or 141 authenticated SDP messages through the "crypto" attribute, which 142 provides the cryptographic parameters of a media stream. The " 143 crypto" attribute could be adapted to any media transport, but its 144 definition is unique to a particular transport. In Section 3, we 145 introduce the SDP crypto attribute, and in Section 4, we define the 146 crypto attribute details needed for SRTP. In Section 5, we specify 147 how to use the crypto attribute for SRTP streams with the 148 Offer/Answer model [RFC3264]. Section 6 recites security 149 considerations, and Section 7 gives an Augmented-BNF grammar for the 150 SRTP security descriptions provided for the crypto attribute. A 151 list of open issues is provided in Section 8. 153 3. SDP "Crypto" Attribute and Parameters 155 A new media-level SDP attribute called "crypto" describes the 156 cryptographic suite, key parameters, and session parameters for the 157 proceeding media line. The "crypto" attribute MUST only appear at 158 the SDP media level (not the session level). The "crypto" attribute 159 is defined by the following ABNF [RFC2234]: 161 "a=crypto:" crypto-suite SP key-param *(SP session-param) 163 where "SP" is the space character (see [RFC2234]); the fields 164 crypto-suite, key-param, and session-param are described in Section 165 3.1, 3.2, and 3.3. 167 The ordering of multiple "a=crypto" lines is significant: The most- 168 preferred crypto line is listed first; see section 5 for details. We 169 now describe the crypto fields in more detail. 171 3.1 Crypto-suite 173 The crypto-suite field describes all needed information about the 174 encryption and authentication algorithms for the RTP/SAVP transport. 175 The ABNF grammar for crypto-suite is: 177 crypto-suite = VCHAR 179 where VCHAR is defined in [RFC2234]. The possible values for the 180 crypto-suite parameter is unique to the transport. 182 3.2 Key Parameter 184 The key-param field MUST either contain an inline key descriptor, 185 or it MUST be a pointer to a uri which contains the actual key. The 186 ABNF grammar for key-param is: 188 key-param = inline-key / uri-key 189 inline-key = "inline:" key-descriptor 190 key-descriptor = VCHAR 191 uri-key = "uri:" absolute-uri 192 absolute-uri = VCHAR 193 where VCHAR is defined in [RFC2234]. 195 If the key parameter starts with the string "uri:", the URI method 196 is used and the value that follows MUST be a Uniform Resource 197 Identifier. The URI is a resource that SHOULD be queried to obtain 198 the cryptographic key for the session. The format or protocols used 199 for the uri are beyond the scope of this document, however it is 200 RECOMMENDED that such protocols provide both integrity and 201 confidentiality. 203 The INLINE method is invoked when the key parameter starts with the 204 string "inline:"; the cryptographic key is encoded according to a 205 transport-specific syntax subject to the general format provided 206 above. Thus, the URI method is transport generic and the INLINE 207 method is transport specific. Section 4 describes the INLINE key- 208 parameter syntax for RTP/SAVP (the SRTP media transport type). 210 3.4 Session Parameters 212 The session parameters are specific to the SDP media stream 213 transport and are OPTIONAL. The ABNF grammar for session-param is: 215 session-param = VCHAR 217 where VCHAR is defined in [RFC2234]. Section 4 describes the session 218 parameters for RTP/SAVP. 220 3.5 Example 222 The first example shows use of the crypto attribute for the RTP/SAVP 223 media transport type (as defined in Section 4). The a=crypto line 224 is actually one long line, although it is shown as two lines in this 225 document due to page formatting. 227 v=0 228 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 229 s=SDP Seminar 230 i=A Seminar on the session description protocol 231 u=http://www.example.com/seminars/sdp.pdf 232 e=j.doe@example.com (Jane Doe) 233 c=IN IP4 161.44.17.12/127 234 t=2873397496 2873404696 235 m=video 51372 RTP/SAVP 31 236 a=crypto:AES_CM_128_HMAC_SHA1_80 237 inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:32 238 m=audio 49170 RTP/SAVP 0 239 a=crypto:AES_CM_128_HMAC_SHA1_32 240 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1:32 241 m=application 32416 udp wb 242 a=orient:portrait 243 This SDP message describes three media streams, two of which use the 244 RTP/SAVP transport. Each has a crypto attribute for the RTP/SAVP 245 transport. These RTP/SAVP-specific descriptions are defined in the 246 next section. 248 4. RTP/SAVP (SRTP) Security Descriptions 250 SRTP security descriptions for a media stream MUST only be used for 251 media streams that use the RTP/SAVP transport in the media (m=) line 252 and SHALL apply to that media stream only. 254 There is no assurance that an endpoint is capable of configuring its 255 SRTP service with a particular crypto attribute parameter, but SRTP 256 guarantees minimal interoperability among SRTP endpoints through the 257 default SRTP parameters [srtp]. More capable SRTP endpoints support 258 a variety of parameter values beyond the SRTP defaults and these 259 values can be configured by the crypto attribute defined in this 260 document. An endpoint that does not support the crypto attribute 261 will ignore it (per [SDPnew]) and hence, if it supports SRTP, it 262 will simply assume use of default SRTP parameters. Such an endpoint 263 will not correctly process the particular media stream. By using 264 the Offer/Answer model, the offerer and answerer can negotiate the 265 crypto parameters to be used before commencement of the multimedia 266 session (see Section 5.0). 268 There are over twenty cryptographic parameters listed in the SRTP 269 specification. Many of these parameters have fixed values for 270 particular cryptographic transforms. At the time of session 271 establishment, however, there is usually no need to provide unique 272 settings for many of the SRTP parameters, such as salt length and 273 pseudo-random function (PRF). Thus, it is possible to simplify the 274 list of parameters by defining "cryptographic suites" that fix a set 275 of SRTP parameter values for the security session. 277 SRTP Crypto Parameter Description 278 --------------------- ----------- 279 CRYPTO-SUITE Encryption and authentication transforms 280 INLINE SRTP and associated parameters 281 SRC An triple 282 KEY_DERIVATION_RATE Rate that the pseudo-random function 283 is applied to a master key 284 UNENCRYPTED_SRTP SRTP messages are not encrypted 285 UNENCRYPTED_SRTCP SRTCP messages are not encrypted 286 UNAUTHENTICATED_SRTP SRTP messages are not authenticated 287 FEC_ORDER Order of forward error correction (FEC) 288 relative to SRTP services 290 Table 4-1: SRTP Crypto-suite, Key and Session Parameters 291 Please refer to the SRTP specification for a complete list of 292 parameters and their descriptions [Section 8.2, srtp]. The CRYPTO- 293 SUITE, the key parameter, and the session parameters shown in the 294 table above are described in the following sections. If a receiver 295 cannot recognize a parameter or value, then the receiver MUST NOT 296 participate in the media stream and SHOULD log an "invalid name" 297 condition unless the receiver is participating in an Offer/Answer 298 exchange (Section 5). 300 4.1 Crypto-suites 302 A crypto-suite value appears as the first parameter in a crypto 303 attribute. If a receiver does not support the particular crypto- 304 suite, then the receiver MUST NOT participate in the media stream 305 and SHOULD log an "unrecognized crypto-suite" condition unless the 306 receiver is participating in an Offer/Answer exchange (Section 5). 307 RTP/SAVP has three crypto-suites as described below. 309 4.1.1 AES_CM_128_HMAC_SHA1_80 311 This is the SRTP default AES Counter Mode cipher and HMAC-SHA1 312 message authentication having an 80-bit authentication tag. The 313 master-key length is 128 bits and has a lifetime of a maximum of 314 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first 315 [srtp]. The SRTP and SRTCP encryption key lengths are 128 bits. 316 The SRTP and SRTCP authentication key lengths are 160 bits (see 317 Security Considerations). The master salt value is 112 bits and the 318 session salt value is 112 bits. The PRF is the default SRTP pseudo- 319 random function that uses AES Counter Mode with a 128-bit key 320 length. 322 4.1.2 AES_CM_128_HMAC_SHA1_32 324 The SRTP AES Counter Mode cipher is used with HMAC-SHA1 message 325 authentication having a 32-bit authentication tag for SRTP packets; 326 SRTCP uses an 80-bit tag. The master-key length is 128 bits and has 327 a lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, 328 whichever comes first [srtp]. The SRTP and SRTCP encryption key 329 lengths are 128 bits. The SRTP and SRTCP authentication key lengths 330 are 160 bits (see Security Considerations). The master salt value 331 is 112 bits and the session salt value is 112 bits. The PRF is the 332 default SRTP pseudo-random function that uses AES Counter Mode with 333 a 128-bit key length. 335 4.1.3 F8_128_HMAC_SHA1_80 337 The SRTP f8 cipher is used with HMAC-SHA1 message authentication 338 having a 80-bit authentication tag. The master-key length is 128 339 bits and has a lifetime of a maximum of 2^48 SRTP packets or 2^31 340 SRTCP packets, whichever comes first [srtp]. The SRTP and SRTCP 341 encryption key lengths are 128 bits. The SRTP and SRTCP 342 authentication key lengths are 160 bits (see Security 343 Considerations). The master salt value is 112 bits and the session 344 salt value is 112 bits. The PRF is the default SRTP pseudo-random 345 function that uses AES Counter Mode with a 128-bit key length. 347 4.1.4 Adding new CRYPTO-SUITE definitions 349 If new transforms are added to SRTP, new definitions for those 350 transforms SHOULD be given for the SDP crypto attribute and 351 published in an Internet RFC. Sections 4.1.1 through 4.1.3 352 illustrate how to define CRYPTO-SUITE values for particular 353 cryptographic transforms. New definitions MAY be added to existing 354 transforms, moreover, to augment or modify definitions 4.1.1 through 355 4.1.3. For example, if AES_CM_128_HMAC_SHA1_80 were desired that 356 used a 160-bit master key, then a new crypto-suite MUST be defined 357 having a new name that is identical to AES_CM_128_HMAC_SHA1_80 but 358 with the size of the master key defined to be 160 bits instead of 359 128 bits. 361 4.2 Key-param Parameter 363 If the key-param parameter has a "uri:" descriptor, the value is a 364 Uniform Resource Identifier value as described in Section 3. When 365 the key-param parameter has an "inline:" descriptor, the value 366 contains a cryptographic master key that MUST be a unique 367 cryptographically random [RFC1750] value with respect to other 368 "inline:" values in the SDP message. 370 4.2.1 Key Usage 372 The "inline" type of key contains the keying material and all policy 373 relating to that key, including how it can be used (for encryption, 374 decryption, or both encryption and decryption), how long it can be 375 used (lifetime) and whether or not it uses a master key index 376 (master key index or MKI) to associate an incoming SRTP packet with 377 a master key. Compliant implementations obey the policies 378 associated with a master key, and MUST NOT accept incoming packets 379 that violate the policy (e.g. after the key lifetime has expired, 380 for example). 382 4.2.2 INLINE Definition 384 If the identifier is "inline", the key-param descriptor has the 385 format described in Section 7 (Grammar) and contains the following 386 fields: 388 use key use indicator 389 key_length key length 390 salt_length salt length 391 key||salt concatenated key and salt, BASE64-encoded 392 lifetime key lifetime (number of packets) 393 MKI:length MKI and length of the MKI field in SRTP packets. 395 The "use" indicator defines usage as one of three values which are 396 all provided from the perspective of the recipient of the SDP: "d" 397 means the key is used for decryption only, "e" means the key is used 398 for encryption only, and "b" means the key is used for both 399 encryption and decryption. If the crypto suite uses the same key 400 for both encryption and decryption, "b" MUST be specified. 402 The "key_length" is the integer length of the SRTP master key in 403 bytes, and "salt_length" is the integer length of the master salt in 404 bytes. Their sum MUST be exactly equal to the length of the 405 concatenated master key and salt provided in the fourth field. The 406 key_length and salt_length MUST appear in the "inline" encoding. For 407 example, 409 inline:d/16/14/d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj/2^20/1:4 411 is a decryption key with a key length of 16 and a salt length of 14. 413 The fourth part of the "inline" encoding is the cryptographic master 414 key appended with the master salt. Each master key and salt MUST be 415 a cryptographically random number and MUST be unique to the SDP 416 message. Both are concatenated and then base-64 encoded. If the 417 length of the concatenated key and salt (after being decoded from 418 base 64) does not equal the sum of the key_length and salt_length 419 indicated, the receiver MUST NOT use this crypto attribute line for 420 the media stream and SHOULD log a "inline encoding too short" 421 condition. For example, 423 inline:d/16/8/YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6//1066:4 425 describes a decryption key with a key_length of 16, a salt_length of 426 8, and a 32-character key and concatenated salt that is base-64 427 encoded: The 24-character key/salt concatenation is expanded to 32 428 characters by the three-in-four encoding of base 64. 430 The fifth part of the of the "inline" encoding is the OPTIONAL 431 lifetime of the master key as measured in number of packets using 432 that key. The lifetime value MAY be written as an non-zero, 433 positive integer or as a power of 2, see the ABNF in Section 7 for 434 details. The "lifetime" value MUST NOT exceed the maximum packet 435 lifetime for the crypto-suite. If lifetime is too large or 436 otherwise invalid, then the receiver MUST NOT use this crypto 437 attribute line for the media stream and SHOULD log an "invalid 438 lifetime" condition. The default MAY be implicitly signaled by 439 having no described value for lifetime (i.e. "//"). This is 440 convenient when the srtp crypto_key lifetime is allowed to default. 441 The first example, above, shows a case where the lifetime is 442 specified as 2^20 while the second example shows an empty lifetime, 443 which means the SRTP default value of 2^48 will be used with 444 UNENCRYPTED_SRTCP and 2^31 will be used otherwise. 446 The MKI and its byte length are OPTIONAL (see Section 7). "MKI" is 447 the master key index associated with the SRTP_master key. If the 448 MKI is given, then the length of the MKI MUST also be given and 449 separated from the MKI by a colon (":"). The MKI_length is the size 450 of the MKI field in the SRTP packet, specified in bytes. If the 451 MKI_length is not given or if the value exceeds 128, then the 452 receiver MUST NOT use this crypto attribute line for the media 453 stream and SHOULD log an "invalid MKI_length" condition. If the 454 value of the MKI is larger than allowed by MKI_length, then the 455 receiver MUST NOT use this crypto attribute line for the media 456 stream and SHOULD log an "invalid MKI" condition. The substring 457 "1:4" in the first example assigns to the key a master key index of 458 1 that is 4 bytes long, and the second example assigns a 4-byte key 459 index of 1066 to the key. 461 4.3 Session Parameters 463 The "session" parameters are OPTIONAL and serve to override SRTP 464 session defaults for the SRTP and SRTCP streams. These parameters 465 configure an RTP session for SRTP services. 467 4.3.1 SRC=SSRC/ROC/SEQ 469 The SRC session parameter provides information to establish the SRTP 470 cryptographic context. The ROC and sequence number are typically 471 only needed for sessions already in progress (as when rekeying or 472 when joining a multicast session). 474 Zero or more SRC parameters MAY appear in a crypto attribute. Each 475 SRC parameter defines a separate SRTP crypto context (see section 476 3.2 of [srtp]) that SHALL share the master key and salt defined by 477 an INLINE parameter. The total number of all packets that are 478 encrypted by keys derived from this master key MUST NOT exceed the 479 lifetime of the INLINE key. The SRTP crypto contexts so defined 480 SHALL also have a common definition for the crypto-suite and all 481 other crypto parameters. 483 SSRC is OPTIONAL provided that either a ROC or a SEQ appear in the 484 SRC parameter. SSRC is an integer in the range of 0..2^32-1 for the 485 RTP SSRC parameter, which is undefined by default. This is the RTP 486 SSRC that is associated with the inline key. If the SSRC value is 487 invalid, the receiver MUST NOT use this crypto attribute line for 488 the media stream but SHOULD log an "invalid SSRC" condition. If 489 SSRC is specified and an SRTP packet is received with a different 490 SSRC value, the receiver SHOULD discard the packet and log an error. 492 ROC is OPTIONAL provided that either an SSRC or a SEQ appear in the 493 SRC parameter. ROC is an integer in the range of 0..2^32-1 for the 494 SRTP rollover counter (ROC), which is zero by default. The ROC MAY 495 be set to a non-zero value for an ongoing RTP/SAVP stream in which 496 the SRTP ROC has cycled one or more times [srtp]. The receiver of 497 the SDP message SHOULD refresh the ROC value before joining an 498 ongoing session. Depending on the nature of the session control, 499 the late-joining receiver might need to refresh its ROC value 500 through a unicast exchange or through receipt of a multicast or 501 unicast SDP message containing a ROC SRTP description. If ROC is 502 greater than 2^32-1, then the receiver MUST NOT use this crypto 503 attribute line for the media stream but SHOULD log an "invalid ROC" 504 condition. 506 SEQ is OPTIONAL provided that either an SSRC or a ROC appear in the 507 SRC parameter. SEQ is an integer in the range of 0..2^16-1 for the 508 SRTP sequence number (SEQ). SRTP uses the RTP sequence number (and 509 the ROC) to compute the packet index [srtp]. At the start of a 510 session, an SSRC that randomly selects a high sequence-number value 511 can put the receiver in an ambiguous situation: If initial packets 512 are lost in transit up to the point that the sequence number wraps 513 (exceeds 2^16-1), then the receiver might not recognize that its ROC 514 needs to be incremented. See also section 3.3.1 of [srtp]. If SEQ 515 is greater than 2^16-1, then the receiver MUST NOT use this crypto 516 attribute line for the media stream but SHOULD log an "invalid SEQ" 517 condition. 519 4.3.2 KDR=n 521 KDR specifies the Key Derivation Rate, as described in section 4.3.1 522 of [srtp]. 524 The value n MUST be an integer in the set {0,1,2,...,24}, which 525 denotes a power of 2 from 2^0 to 2^24, inclusive. The SRTP key 526 derivation rate controls how frequently a new session key is derived 527 from an SRTP master key [SRTP]. The default value is 0, which 528 causes the key derivation function to be invoked exactly once (since 529 2^0 is 1). 531 4.3.3 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 533 UNENCRYPTED_SRTCP indicates that the SRTCP packet payloads are not 534 encrypted. UNENCRYPTED_SRTP indicates that the SRTP packet payloads 535 are not encrypted. SRTP and SRTCP packet payloads are encrypted by 536 default. 538 4.3.4 FEC_ORDER=order 540 The forward error correction values for "order" are FEC_SRTP, 541 SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC is applied 542 before SRTP processing on the sender and after SRTP processing on 543 the receiver; FEC_SRTP is the default. SRTP_FEC is the reverse 544 processing. SPLIT signals that SRTP encryption occurs on the 545 sender, followed by FEC processing, followed by SRTP authentication; 546 processing is reversed on the receiver. If the receiver cannot 547 recognize the order value, then the receiver MUST NOT use this 548 crypto attribute line for the media stream but SHOULD log an 549 "invalid FEC_ORDER" condition. 551 4.3.5 UNAUTHENTICATED_SRTP 553 This parameter signals that SRTP messages are not authenticated. 554 SRTP authenticates SRTP messages by default. Use of 555 UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security 556 Considerations). 558 5. Use with Offer/Answer 560 The Offer/Answer model [RFC 3264] enables parties that wish to 561 engage in a multimedia session to negotiate the media stream 562 parameters that will be used for the multimedia session. In this 563 section, we detail how the security descriptions defined for SRTP 564 are used with the offer/answer model to negotiate cryptographic 565 capabilities and communicate SRTP master keys. 567 5.1 Generating the Offer 569 For each SDP media line (m=) using the "RTP/SAVP" transport where 570 the offerer wants to specify cryptographic parameters, the offerer 571 MUST provide at least one "a=crypto" line. When multiple crypto 572 lines are provided, the a=crypto lines are specified in preference 573 order, with the most preferred listed first. The offerer determines 574 the crypto parameters based on its capabilities and its security 575 policies. 577 The offerer obtains keying material for "inline", or obtains the uri 578 pointing to a key server. The mechanism to generate or obtain a key 579 is outside the scope of this specification. 581 5.2 Answerer Processing 583 For each SDP media line using the "RTP/SAVP" transport that contains 584 an "a=crypto" line in the offer, the answerer MUST either accept 585 exactly one of the crypto lines for that media stream, or it MUST 586 reject the media stream as described in RFC 3264. Note that if 587 there are no "a=crypto" lines for the media stream in the offer, 588 then the answerer MUST skip the following steps and instead use the 589 default SRTP/SRTCP parameters for that media stream (note that the 590 endpoint will then need to somehow obtain the correct master key as 591 well). When the answerer accepts an "RTP/SAVP" media stream with a 592 crypto line, the answerer MUST include exactly one "a=crypto" line 593 in the answer. The answer crypto line MUST include at least the 594 selected crypto-suite and a key-param parameter. 596 To determine if the answerer can accept any of the provided 597 "a=crypto" lines, the answerer examines the crypto lines in order. 598 If an "a=crypto" line does not satisfy the constraints provided in 599 Section 4, that crypto line is deemed invalid and MUST be discarded. 600 The answerer selects the first valid crypto line that it supports, 601 considering the answerer's capabilities and security policies. If 602 the answerer cannot find any valid crypto line that it supports, or 603 its configured policy prohibits any cryptographic key parameter 604 (e.g. key length) or cryptographic session parameter (e.g. SSRC, 605 ROC, KDR, FEC_ORDER), it MUST reject the media stream, unless it is 606 able to successfully negotiate use of "RTP/SAVP" by other means 607 outside the scope of this document (e.g. by use of MIKEY [mikey]). 609 After selecting a single crypto line, the answerer generates a 610 master key appropriate for the selected crypto algorithm(s), unless 611 the offered master key was specified to apply to both encryption and 612 decryption, in which case the offered master key MUST be used 613 instead. If the offered master key was for decryption, then the 614 answerer MUST use it to decrypt any incoming packets; the key 615 provided in the answer MUST also be marked as being for decryption, 616 since the answerer will be using it when encrypting it's packets. 617 Similarly, if the offered key was for encryption, then the answerer 618 MUST use it to encrypt any packets it sends and the key it provides 619 in its answer MUST be used to decrypt any incoming packets. The 620 master key in the answer MUST have the same key length and salt 621 length as the offer. 623 To set up the bi-directional media with transport set to RTP/SAVP, 624 the answerer includes one "a=crypto" line after its media line with 625 transport set to RTP/SAVP. 627 5.3 Offerer Processing of the Answer 629 When the offerer receives the answer, it MUST perform the following 630 steps for each "RTP/SAVP" media stream it offerered with one or more 631 crypto lines in it. 633 If the media stream was accepted and it contains a crypto line, it 634 MUST be checked that the media line is valid according to the 635 constraints specified in Section 4. Furthermore, the offerer MUST 636 validate, that the crypto-suite selected was one of the offered 637 crypto-suites for the media stream. If any of these checks fails, 638 the security negotiation defined here MUST be deemed to have failed. 640 It is possible that the answerer supports the "RTP/SAVP" transport 641 and accepts the offered media stream, yet it does not support the 642 crypto attribute defined here. The offerer can recognize this 643 situation by seeing an accepted "RTP/SAVP" media stream in the 644 answer that does not include a crypto line. In that case, the 645 security negotiation defined here MUST be deemed to have failed. 647 5.4 Non-RTP/SAVP Answerers 649 If a media stream with transport set to "RTP/SAVP" is sent to a 650 device that doesn't support "RTP/SAVP", that media stream will be 651 rejected. 653 In some cases, it is desirable to send SRTP when possible, but allow 654 use of RTP if SRTP isn't supported by a remote device. However, it 655 is ambiguous to send an extra media line with transport set to 656 "RTP/AVP" and with the same port as the "RTP/SAVP" line. Thus, an 657 offerer MUST NOT specify multiple media lines with the same port. 659 Instead, such interoperability is obtained by first sending an offer 660 with transport set to "RTP/SAVP". If that media line is rejected by 661 the answerer, the offerer can, if its policy permits, send a new 662 offer with transport set to "RTP/AVP". Also, the SDP extensions 663 defined in RFC 3407 [RFC3407] can be used by both the offerer and 664 answerer to indicate capabilities above and beyond what is being 665 negotiated for the media stream. Another offer/answer exchange will 666 then be needed to negotiate use of any of these latent capabilities. 668 5.4 Offer/Answer Example: Receiver Supports SRTP 670 In this example, the Offerer supports two crypto suites (F8 and 671 AES). The a=crypto line is actually one long line, although it is 672 shown as two lines in this document due to page formatting. 674 Offerer sends: 675 v=0 676 o=sam 2890844526 2890842807 IN IP4 10.47.16.5 677 s=SRTP Discussion 678 i=A discussion of Secure RTP 679 u=http://www.example.com/seminars/srtp.pdf 680 e=marge@example.com (Marge Simpson) 681 c=IN IP4 168.2.17.12 682 t=2873397496 2873404696 683 m=audio 49170 RTP/SAVP 0 684 a=crypto:AES_CM_128_HMAC_SHA1_80 685 inline:d/16/14/WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz/2^20/1:32 686 FEC_ORDER=FEC_SRTP SRC=17174//49126 687 a=crypto:F8_128_HMAC_SHA1_80 688 inline:d/16/14/MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm/2^20/1:32 689 FEC_ORDER=FEC_SRTP SRC=17174//49126 691 Answerer replies: 692 v=0 693 o=jill 25690844 8070842634 IN IP4 10.47.16.5 694 s=SRTP Discussion 695 i=A discussion of Secure RTP 696 u=http://www.example.com/seminars/srtp.pdf 697 e=homer@example.com (Homer Simpson) 698 c=IN IP4 168.2.17.11 699 t=2873397526 2873405696 700 m=audio 32640 RTP/SAVP 0 701 a=crypto:AES_CM_128_HMAC_SHA1_80 702 inline:d/16/14/PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR/2^20/1:32 703 SRC=88131/721/13 705 In this case, the session would use the AES_CM_128_HMAC_SHA1_80 706 crypto suite for the RTP and RTCP traffic. The answerer is also 707 specifying both its initial SSRC (88131), rollover counter (721), 708 and rollover counter (13). 710 5.7 Use of a=crypto With Active Media Streams 712 When an active SRTP session is rekeyed, this is indicated by sending 713 a new SDP. Rekeying is done following the rules described for a 714 normal Offer/Answer exchange. The Answerer can take this 715 opportunity to rekey the traffic it is sending, if the Answerer 716 desires. During rekeying, the session parameters cannot be changed 717 and MUST NOT be specified in the Offer or the Answer. 719 When the Offerer needs to rekey, the offerer MUST send an "a=crypto" 720 line with same crypto-suite, key length, and salt length that was 721 previously accepted by the Answerer. 723 If the answerer selected "a=crypto" lines using the "inline" method, 724 the exact same "a=crypto" line(s) as agreed to in the answer MUST be 725 sent and a new new inline key MUST be sent. 727 If the answerer selected "a=crypto" lines using the "uri" method, 728 the sender MAY transmit the same uri, and the recipient MUST fetch 729 the new key using the uri. 731 5.8 Operation with KEYMGT and Key lines 733 An Offer MAY include both a=crypto and a=keymgt lines [keymgt]. Per 734 SDP rules, the Answerer will ignore attribute lines it doesn't 735 understand. If the Answerer supports both a=crypto and [keymgt], 736 the Answer MUST include either a=crypto or [keymgt], as including 737 both is undefined. 739 6. Security Considerations 741 Like all SDP messages, SDP messages containing security 742 descriptions, are conveyed in an encapsulating application protocol 743 (e.g. SIP, MGCP, RTSP, SAP, etc.). It is the responsibility of the 744 encapsulating protocol to ensure the protection of the SDP security 745 descriptions. Therefore, that protocol should either invoke its own 746 security mechanisms to do so, or alternatively utilize a lower-layer 747 security service (e.g. TLS, IPSEC) where that service is deemed 748 adequate for protecting the encapsulating protocol itself. Where 749 the encapsulating protocol is used in both a hop-by-hop and end-to- 750 end context (e.g. SIP), an end-to-end security service SHOULD be 751 provided by that protocol for all sensitive information including 752 SDP's security parameters. This service SHOULD provide strong 753 message authentication and packet-payload encryption as well as 754 effective replay protection. As an example, SIP with S/MIME bodies 755 satisfies these requirements. 757 6.1 Authentication of packets 759 RTP messages are vulnerable to a variety of attacks such as replay 760 and forging. To limit these attacks, SRTP message integrity 761 mechanisms SHOULD be used (SRTP replay protection is always 762 enabled). Source authentication of unicast SRTP messages SHOULD be 763 performed [srtp]. Note that SRTP source-message authentication does 764 not authenticate the IP-address of the SRTP source, but ensures that 765 the SRTP message that the SRTP receiver had received is exactly what 766 the SRTP sender had sent. Source authentication of multicast SRTP 767 messages is today non-standard and hence for further study. But 768 even in multicast sessions, SRTP packet authentication ensures that 769 the packet originated from a member of the secure group. Use of the 770 UNAUTHENTICATED_SRTP parameter, therefore, is NOT RECOMMENDED. 772 6.1 Key-stream Reuse 774 Misconfigured SRTP sessions, moreover, are vulnerable to attacks on 775 their encryption services when running the crypto suites defined in 776 Sections 4.1.1, 4.1.2 and 4.1.3. An SRTP encryption service is 777 "mis-configured" when two or more media streams are encrypted using 778 the same AES keystream. When senders and receivers share derived 779 session keys, SRTP requires that the SSRCs of session participants 780 make their corresponding keystreams unique, which is violated in the 781 case of SSRC collision: SRTP SSRC collision drastically weakens SRTP 782 or SRTCP payload encryption during the time that identical 783 keystreams were used [srtp]. An attacker, for example, might 784 collect SRTP and SRTCP messages and await a collision. This attack 785 on the AES-CM and AES-f8 encryption is avoided entirely when each 786 media stream has its own unique master key, as this document 787 RECOMMENDS (Section 4.2). 789 SRTP multicast operation requires that each host-sender have a 790 unique SRTP keystream. This can be accomplished by ensuring that 791 each sender be allocated a unique key or by ensuring that the SSRC 792 of each sender will not collide. Since SSRC collision might occur, 793 the latter condition is avoided when all SSRCs are assigned by a 794 central authority such as a 3rd-party key server [srtp]. This is 795 for further study. The RECOMMENDED approach of this document is to 796 allocate a different master key for each host-participant of an SRTP 797 session. 799 6.2 Signaling Authentication and Signaling Encryption 801 There is no reason to incur the complexity and computational expense 802 of SRTP, however, when its key establishment is exposed to 803 unauthorized parties. In most cases, the SRTP crypto attribute and 804 its parameters are vulnerable to denial of service attacks when they 805 are carried in an unauthenticated SDP message. In some cases, the 806 integrity or confidentiality of the RTP stream can be compromised. 807 For example, if an attacker sets UNENCRYPTED for the SRTP stream in 808 an offer, this could result in the answerer not decrypting the 809 encrypted SRTP messages. In the worst case, the answerer might 810 itself send unencrypted SRTP and leave its data exposed to snooping. 812 IPsec, TLS, encapsulating-protocol security or some other data 813 security service SHOULD be used to provide message authentication 814 for SDP messages that carry the SRTP attribute. Message encryption 815 SHOULD be used because a master key parameter appears in the 816 message. Failure to encrypt the SDP message containing an inline 817 SRTP master key renders the SRTP authentication or encryption 818 service useless in practically all circumstances. Failure to 819 authenticate an SDP message that carries SRTP parameters renders the 820 SRTP authentication or encryption service useless in most practical 821 applications. 823 When the SDP parameters cannot be carried in an encrypted and 824 authenticated SDP message, it is RECOMMENDED that a key management 825 protocol be used. The proposed SDP key-mgmt extension [keymgt] 826 allows authentication and encryption of the key management protocol 827 data independently of the SDP message that carries it. The security 828 of the SDP SRTP attribute, however, is as good as the data security 829 protocol that protects the SDP message. For example, if an IPsec 830 security association exists between the source endpoint, its 831 signaling controller, and the destination endpoints, then this 832 solution is more secure than use of the key-mgmt statement in an 833 unauthenticated SDP message, which is vulnerable to tampering. 835 There are practical cases, however, where SDP security is not end- 836 to-end: If there is a third-party provider between the sender and 837 receiver, then the data-security session might not be end-to-end. 838 That is, one possible configuration might have an IPsec or TLS 839 connection between the sender of the SDP message and the provider, 840 such as a VoIP service provider, with a second secure connection 841 between the provider and the receiver: 843 signaling controller---(network-b)---signaling controller 844 | | 845 (network a) (network c) 846 | | 847 sender----------------(SRTP bearer)--------------receiver 849 where all of link a, b, and c are encrypted with TLS or IPsec. 851 In this case, the third-party provider gets the contents of the SRTP 852 descriptions in the SDP message. SDP key-mgmt statement, however, 853 allows true end-to-end security that is independent of the service 854 provider, who often needs access to some parts of the SDP message to 855 render its services. The SRTP attribute SHOULD NOT be used when 856 end-to-end authentication or confidentiality is needed but the SDP 857 message is not secured end to end (such as the above example where a 858 third-party provider maintains the security associations with the 859 endpoints for the SDP message). 861 7. SRTP "Crypto" Attribute Grammar 863 This section provides an Augmented BNF grammar for the SRTP profile 864 of the SDP crypto attribute. ABNF is defined in [RFC2234]. 866 key-param = method-inline / method-uri 868 crypto-suite = "AES_CM_128_HMAC_SHA1_32" / 869 "F8_128_HMAC_SHA1_32" / 870 "AES_CM_128_HMAC_SHA1_80" 872 method-inline = "inline:" key-info *(SP session-param) 873 method-uri = "uri:<" absoluteURI ">" ; absoluteURI defined in 874 ; [RFC2396] 876 key-info = key-use "/" key-length "/" salt-length "/" key-salt 877 "/" [lifetime] "/" [mki] 879 key-use = "d" / "e" / "b" ; decrypt, encrypt, or both 880 key-length = 1*DIGIT 881 salt-length = 1*DIGIT 883 key-salt = 1*(base64) ; binary key and salt values 884 ; concatenated together, and then 885 ; base64 encoded [section 6.8 of 886 ; RFC2046] 888 lifetime = ["2^"] 1*(DIGIT) 889 mki = mki-length ":" mki-value 890 mki-length = 1*DIGIT ; real value is 2^mki-length, max 128 891 mki-value = 1*DIGIT 893 session-param = src / 894 kdr / 895 "UNENCRYPTED_SRTP" / 896 "UNENCRYPTED_SRTCP" / 897 "UNAUTHENTICATED_SRTP" / 898 fec-order 899 src = "SRC=" [ssrc] "/" [roc] "/" [seq] 901 ssrc = 1*DIGIT ; range 0...2^32-1 902 roc = 1*DIGIT ; range 0...2^32-1 903 seq = 1*DIGIT ; range 0...2^16-1 905 kdr = "KDR=" 1*(DIGIT) 907 fec-order = "FEC_ORDER=" fec-type 908 fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT" 910 base64 = ALPHA / DIGIT / "+" / "/" / "=" 912 8. Open Issues 914 The following is a list of open issues in this document: 916 * The crypto attribute can be used with or without offer/answer, 917 however, details on usage outside of offer/answer are missing. 919 * The offer/answer procedures need to be expanded to better describe 920 unidirectional and inactive streams, unicast versus multicast, as 921 well as additional detail for some of the session parameters. 923 9. Acknowledgements 925 This document benefited from discussions with David McGrew, Mats 926 Naslund, Mike Thomas, Elisabetta Cararra, Brian Weis, Dave Oran, 927 Bill Foster, Earl Carter, Matt Hammer and Dave Singer. These people 928 shared observations, identified errors and made suggestions for 929 improving the specification. Mats made several valuable suggestions 930 on parameters and syntax that are in the current draft. Dave Oran 931 and Mike Thomas encouraged us to bring this work to the IETF for 932 standardization. David McGrew suggested the conservative approach 933 of using unique master keys for each SDP media stream as followed in 934 this document. Jonathan Rosenberg suggested reducing the complexity 935 by specifying only one security parameter for each media stream. 937 10. Authors' Addresses 939 Flemming Andreasen 940 Cisco Systems, Inc. 941 499 Thornall Street, 8th Floor 942 Edison, New Jersey 08837 USA 943 fandreas@cisco.com 945 Mark Baugher 946 5510 SW Orchid Street 947 Portland, Oregon 97219 USA 948 mbaugher@cisco.com 949 +1-408-853-4418 950 Dan Wing 951 Cisco Systems, Inc. 952 170 West Tasman Drive 953 San Jose, CA 95134 USA 954 dwing@cisco.com 955 +1-408-902-3348 957 11. Normative References 959 [RFC1889] H. Schulzrinne, S. Casner, R. Fredrick, V. Jacobson, "RTP: 960 A Transport Protocol for Real-Time Applications", January 1996, 961 http://www.ietf.org/rfc/rfc1889.txt. 963 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 964 Specifications: ABNF," November 1997, 965 http://www.ietf.org/rfc/rfc2234.txt. 967 [SDPnew] M. Handley, V. Jacobson, C. Perkins, "SDP: Session 968 Description Protocol,", Work in Progress. 970 [RFC2828] R. Shirey, "Internet Security Glossary", May 2000, 971 http://www.ietf.org/rfc/rfc2828.txt 973 [RFC3264] "J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with 974 the Session Description Protocol (SDP)", June 2202, 975 http://www.ietf.org/rfc/rfc3264.txt 977 [srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. 978 Norrman, D. Oran, "The Secure Real-time Transport Protocol", May 979 2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- 980 08.txt, Work in Progress 982 [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness 983 Recommendations for Security", RFC 1750, December 1994. 985 12. Informative References 987 [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 988 Capability Declaration", RFC 3407, October 2002. 990 [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security 991 Protocols," in Proceedings of the Sixth Usenix Unix Security 992 Symposium, pp. 1-16, San Jose, CA, July 1996. 994 [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 995 "Key Management Extensions for SDP and RTSP", February 2003, 996 http://search.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext- 997 07.txt, Work in Progress. 999 [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1000 "MIKEY: Multimedia Internet KEYing", July 2002, 1001 http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt, 1002 Work in Progress. 1004 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1005 Extensions (MIME) Part One: Format of Internet Message Bodies", 1006 November 1996, http://www.ietf.org/rfc/rfc2045.txt. 1008 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1009 for Message Authentication", November 1997, 1010 http://www.ietf.org/rfc/rfc2104.txt. 1012 [skeme] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 1013 Mechanism for the Internet", ISOC Secure Networks and Distributed 1014 Systems Symposium, San Diego, 1996. 1016 Intellectual Property Statement 1018 The IETF takes no position regarding the validity or scope of any 1019 intellectual property or other rights that might be claimed to 1020 pertain to the implementation or use of the technology described in 1021 this document or the extent to which any license under such rights 1022 might or might not be available; neither does it represent that it 1023 has made any effort to identify any such rights. Information on the 1024 IETF's procedures with respect to rights in standards-track and 1025 standards-related documentation can be found in BCP-11. Copies of 1026 claims of rights made available for publication and any assurances 1027 of licenses to be made available, or the result of an attempt made 1028 to obtain a general license or permission for the use of such 1029 proprietary rights by implementors or users of this specification 1030 can be obtained from the IETF Secretariat. 1032 The IETF invites any interested party to bring to its attention any 1033 copyrights, patents or patent applications, or other proprietary 1034 rights which may cover technology that may be required to practice 1035 this standard. Please address the information to the IETF Executive 1036 Director. 1038 Full Copyright Statement 1040 Copyright(C) The Internet Society 2003. All Rights Reserved. 1042 This document and translations of it may be copied and furnished to 1043 others, and derivative works that comment on or otherwise explain it 1044 or assist in its implementation may be prepared, copied, published 1045 and distributed, in whole or in part, without restriction of any 1046 kind, provided that the above copyright notice and this paragraph 1047 are included on all such copies and derivative works. However, this 1048 document itself may not be modified in any way, such as by removing 1049 the copyright notice or references to the Internet Society or other 1050 Internet organizations, except as needed for the purpose of 1051 developing Internet standards in which case the procedures for 1052 copyrights defined in the Internet Standards process must be 1053 followed, or as required to translate it into languages other than 1054 English. 1056 The limited permissions granted above are perpetual and will not be 1057 revoked by the Internet Society or its successors or assigns. 1059 This document and the information contained herein is provided on an 1060 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1061 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1062 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1063 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1064 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1066 Acknowledgement 1068 Funding for the RFC Editor function is currently provided by the 1069 Internet Society.