idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 231 has weird spacing: '...rotocol data ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In general, any key management protocol using SDP as a mean of transport, MUST not require a great number of exchange messages. It is RECOMMENDED that the key management protocol does not use more than one roundtrip. This is to create as small (if any) impact as possible on the underlying transporting mechanism (e.g., SIP and RTSP). -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIKEY' ** Obsolete normative reference: RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRTP' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 MMUSIC Working Group E. Carrara 4 INTERNET-DRAFT F. Lindholm 5 Expires: May 2002 M. Naslund 6 K. Norrman 7 Ericsson 8 November, 2001 10 Key Management Extensions for SDP and RTSP 11 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 Work for securing real-time applications have started. It has also 36 brought toward the need for a key management infrastructure to 37 support the security protocol. 39 This document defines extensions for SDP and RTSP to carry the 40 security information needed by a key management protocol, in order to 41 secure the media stream itself. 43 TABLE OF CONTENTS 45 1. Introduction..................................................2 46 1.1. Notational Conventions......................................3 47 2. SDP Attribute Fields for Key Management.......................3 48 2.1. SDP Grammar.................................................4 49 2.2. SDP in SIP and RTSP.........................................5 50 3. RTSP Header and Grammar.......................................5 51 4. Security Considerations.......................................6 52 5. IANA Considerations...........................................6 53 6. Conclusions...................................................7 54 7. Acknowledgments...............................................7 55 8. Author's Addresses............................................7 56 9. References....................................................7 58 1. Introduction 60 There has recently been work to define a security framework for the 61 protection of real-time applications running over RTP, [SRTP]. 62 However, a security protocol needs a key management infrastructure to 63 exchange keys and security parameters, managing and refreshing keys, 64 etc. 66 The Session Description Protocol [SDP] is used to convey 67 advertisements of conference sessions and communicate the relevant 68 conference setup information to prospective participants. SDP is 69 intended to use different transport protocols as appropriate, e.g. 70 the Session Initiation Protocol [SIP] and the Real-Time Streaming 71 Protocol [RTSP]. 73 An efficient way of performing key management is to integrate it into 74 SDP. This approach may reduce the number of roundtrips compared to a 75 standalone key management scheme (and in some cases it could also 76 reduce the total bandwidth consumption). However, to make it possible 77 to integrate the key management protocol (e.g. [MIKEY]) into SDP, a 78 set of attributes in SDP is needed. Such a set of attributes is 79 defined in this document to support integrated media stream key 80 management. 82 Currently in SDP, one field exists to transport keys, i.e. the "key=" 83 field. However, this is not enough for a key management protocol. 84 There MUST exist the possibility to include not only the key, but 85 also the key encrypted, encryption parameters, security protocol 86 parameters, and at the same time have it all authenticated. This can 87 not be done with the "key=" field as specified today. 89 In RTSP, the SDP description is mainly used in the response to the 90 DESCRIBE method. This makes it hard to send key management messages 91 back from the client to the server. Therefore, this draft also 92 defines an RTSP header that may be used to carry additional key 93 management messages. 95 1.1. Notational Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in RFC-2119. 101 2. SDP Attributes for Key Management 103 This subsection describes common attributes that are to be included 104 in the SDP description when an integrated key management protocol is 105 used. All attribute values MUST follow the general SDP guidelines. 107 The attributes are designed to give a minimal impact on SDP, i.e. 108 only a minimal set of "knowledge" MUST be built into an existing SDP 109 stack in order to support the key management. 111 Three SDP attributes are defined. 113 To be able to detect the key management protocol applied, this MUST 114 be signaled by: 116 a=keymgmt-prot: 118 The key management protocol data MUST be provided in the following 119 field: 121 a=keymgmt-data: 123 Note that the data MUST be encoded in a way so that it complies with 124 the normal SDP rules. 126 In case the key management mechanism does not provide authentication 127 of the key management part, additional authentication data MAY be 128 provided in the "keymgmt-auth" field. 130 a=keymgmt-auth: 132 The key management attributes may be defined both at the session 133 level (i.e. before the media descriptor lines) and at the media level 134 of the SDP description. If the key management attributes are defined 135 at media level, it will only apply to that specific media. If the key 136 management attributes are defined at both session and media level, 137 the media level definition overrides the session level definition for 138 that specific media. 140 Example 1 (session level) 142 a=keymgmt-prot:MIKEY 143 a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 144 m=audio 49000 RTP/SAVP 98 145 a=rtpmap:98 AMR/8000 146 m=video 2232 RTP/SAVP 31 148 In this example, MIKEY is negotiating the crypto suite for both 149 streams at session level. It is recommended to use this approach if 150 possible to save both bandwidth and computational resources. 152 Example 2 (media level) 154 m=audio 49000 RTP/SAVP 98 155 a=keymgmt-prot:MIKEY 156 a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 157 a=rtpmap:98 AMR/8000 158 m=video 2232 RTP/AVP 31 160 Note that the video part in this example is not protected by any 161 security protocol. 163 2.1. SDP Grammar 165 This section provides an Augmented Backus-Naur Form (ABNF) grammar 166 (as used in [SDP]) for the key management extensions to SDP. 168 Note that the new definitions are compliant with the definition of an 169 attribute field, i.e. 171 attribute = (att-field ":" att-value) | att-field 173 Three new attributes are defined, keymgmt-prtcl, keymgmt-data, and 174 key-extra-auth. 176 keymgmt-prtcl = "keymgmt-prot:" prtcl-name 178 prtcl-name = 1*(alpha-numeric|SAFE) 179 ; e.g. "MIKEY" 181 keymgmt-data = "keymgmt-data:" byte-string 183 key-extra-auth = "keymgmt-auth:" byte-string 185 byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) 186 ;any byte except NUL, CR or LF 188 alpha-numeric = ALPHA | DIGIT 190 DIGIT = "0" | POS-DIGIT 192 POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" 194 ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| 195 "l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"| 196 "w"|"x"|"y"|"z"|"A"|"B"|"C"|"D"|"E"|"F"|"G"| 197 "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"| 198 "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" 200 SAFE = "\$" | "-" | "_" | "." | "+" 202 2.2. SDP in SIP and RTSP 204 Both SIP and RTSP provide means to transport SDP descriptions. This 205 section gives a recommendation of how/when to include key management 206 initiated SDP descriptions in SIP and RTSP. 208 For SIP, the recommendation is to use the Invite message (and the 209 following response) to transport the SDP description with the key 210 management parameters. 212 For RTSP, the recommendation is to let the server include a SDP 213 description with the key management parameters in the response to a 214 DESCRIBE message. A problem with RTSP is that no SDP description can 215 be assumed to be sent back to the server. Therefore, other means to 216 send key management messages between client and server is needed. 217 This may be solved by using the new RTSP header defined in Section 3. 219 In general, any key management protocol using SDP as a mean of 220 transport, MUST not require a great number of exchange messages. It 221 is RECOMMENDED that the key management protocol does not use more 222 than one roundtrip. This is to create as small (if any) impact as 223 possible on the underlying transporting mechanism (e.g., SIP and 224 RTSP). 226 3. RTSP Header and Grammar 228 To support the three different parameters described in Section 2, a 229 new RTSP header is defined. 231 KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data [auth] 233 stream-url = "url" "=" url ";" 235 protocol = "Prot" "=" prtcl-name 236 data = ";" "Data" "=" string 238 auth = ";" "Auth" "=" string 240 string = 1*(alpha-numeric|SAFE|"=") 242 alpha-numeric, SAFE and prtcl-name are as defined in Section 2.1. The 243 url indicates the stream URL for which the parameters correspond to. 244 It is recommended that the string is a base64 encoded value. 246 The new key management header should be possible to use in both 247 request and response messages of the following methods: 248 * ANNOUNCE 249 * SETUP 250 * PLAY 251 * RECORD 252 * SET_PARAMETER 253 * GET_PARAMETER 254 * OPTIONS 256 When a key management protocol is enabled in the RTSP implementation, 257 it MUST for each message to be sent (that may contain the KeyMgmt 258 header), check with the key management protocol if any parameters(s) 259 should be include in the header (i.e. the Data or Auth parameter). 260 For each message received (that contains the KeyMgmt header), the key 261 management parameters (Data and Auth) are passed to the key 262 management protocol for processing. 264 4. Security Considerations 266 The nature of this document is to allow SDP and RTSP support for 267 security of the media sessions. It is therefore not the intention of 268 this document to describe possible security solution nor define 269 possible security problems. The defined SDP and RTSP extensions are 270 not believed to introduce any new security risks to SDP and RTSP. 272 Note that the purpose of the key management fields is to secure the 273 media streams themselves. Provided that the key management schemes 274 are secure, the SDP payloads can be passed along unprotected, and the 275 media streams will still be secure even if some attackers gained 276 knowledge of the SDP contents. There may, however, be other reasons 277 to protect the SDP payloads such as preventing attackers from gaining 278 any information regarding the session or the used equipment. 280 5. IANA Considerations 282 Three new attributes fields for SDP (see Section 2) and one new RTSP 283 header are registered (see Section 3). 285 6. Conclusions 287 A security solution for real-time applications needs a key management 288 infrastructure. Integrating the key management scheme with the 289 session establishment protocol could be done efficiently in most of 290 the scenarios. This document defines extensions to SDP and RTSP so 291 that it will be possible to integrate a key management protocol (e.g. 292 MIKEY) into protocol such as SIP and RTSP. 294 7. Acknowledgments 296 Thanks to: Joerg Ott, Colin Perkins, Magnus Westerlund, and the rest 297 involved in the MMUSIC WG and the MSEC WG. 299 8. Author's Addresses 301 Jari Arkko 302 Ericsson 303 02420 Jorvas Phone: +358 40 5079256 304 Finland Email: jari.arkko@ericsson.com 306 Elisabetta Carrara 307 Ericsson Research 308 SE-16480 Stockholm Phone: +46 8 50877040 309 Sweden EMail: elisabetta.carrara@era.ericsson.se 311 Fredrik Lindholm 312 Ericsson Research 313 SE-16480 Stockholm Phone: +46 8 58531705 314 Sweden EMail: fredrik.lindholm@era.ericsson.se 316 Mats Naslund 317 Ericsson Research 318 SE-16480 Stockholm Phone: +46 8 58533739 319 Sweden EMail: mats.naslund@era.ericsson.se 321 Karl Norrman 322 Ericsson Research 323 SE-16480 Stockholm Phone: +46 8 4044502 324 Sweden EMail: karl.norrman@era.ericsson.se 326 9. References 328 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 329 Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft, 330 IETF, Work in progress (MSEC). 332 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 333 Streaming Protocol (RTSP)", RFC 2326, April 1998. 335 [SDP] Handley, M., and Jacobson, V., "Session Description Protocol 336 (SDP)", IETF, RFC2327 338 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 339 "SIP: Session Initiation Protocol", IETF, RFC2543. 341 [SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K., 342 and Oran, D., "The Secure Real Time Transport Protocol", Internet 343 Draft, IETF, Work in Progress (AVT). 345 This Internet-Draft expires in May 2002.