idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-02.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. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Unused Reference: 'MIKEY' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 506, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MIKEY' -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM' ** 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 (~~), 4 warnings (==), 5 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: August 2002 M. Naslund 6 K. Norrman 7 Ericsson 8 February, 2002 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 This document defines general extensions for SDP and RTSP to carry 36 the security information needed by a key management protocol, in 37 order to secure the media. These extensions are presented as a 38 framework, to be used by one or more key management protocols. As 39 such, its use is meaningful only when it is completed by the key 40 management protocol in use. 42 General guidelines are also given on how the framework should be used 43 together with SIP and RTSP. 45 TABLE OF CONTENTS 46 1. Introduction.................................................. 2 47 1.1. Notational Conventions...................................... 3 48 2. Extensions to SDP and RTSP.................................... 3 49 2.1. SDP Extensions.............................................. 4 50 2.2. RTSP Extensions............................................. 4 51 3. Usage with SIP and RTSP....................................... 5 52 3.1. General SDP processing...................................... 5 53 3.2. SIP usage................................................... 6 54 3.3. RTSP usage.................................................. 6 55 3.4. Example scenarios........................................... 7 56 4. Security Considerations....................................... 9 57 5. IANA Considerations...........................................10 58 6. Conclusions...................................................10 59 7. Acknowledgments...............................................10 60 8. Author's Addresses............................................10 61 9. References....................................................11 63 1. Introduction 65 There has recently been work to define a security framework for the 66 protection of real-time applications running over RTP, [SRTP]. 67 However, a security protocol needs a key management infrastructure to 68 exchange keys and security parameters, managing and refreshing keys, 69 etc. 71 The focus in the following sections is to describe SDP attribute 72 extensions and RTSP header extensions to support key management, and 73 a possible integration within SIP and RTSP. A framework is therefore 74 described in the following, that will need to be accompanied by one 75 or more key management protocols. 77 Some of the motivations to create a framework with the possibility to 78 include the key management in the session establishment are: 80 * Just as the codec information is a description of how to encode 81 and decode the audio (or video) stream, the key management data 82 is a description of how to encrypt and decrypt the data. 84 * The possibility to negotiate the security for the entire 85 multimedia session at the same time. 87 * The knowledge of the media at the session establishment makes it 88 easy to tie the key management to the multimedia sessions. 90 * This approach may be more efficient than setting up the security 91 later, as that approach might force extra roundtrips, possibly 92 also a separate set-up for each stream, hence implying more delay 93 to the actual setup of the media session. 95 Currently in SDP [SDP], one field exists to transport keys, i.e. the 96 "key=" field. However, this is not enough for a key management 97 protocol. The approach here is to use and extend the SDP description 98 to transport the key management offer/answer and also to associate it 99 with the media sessions. SIP uses the offer/answer model [OAM] 100 whereby extensions to SDP will be enough. An extra RTSP header is 101 also defined. 103 1.1. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC-2119. 109 2. Extensions to SDP and RTSP 111 This section describes common attributes that are to be included in 112 an SDP description or in an RTSP header when an integrated key 113 management protocol is used. All attribute values MUST follow the 114 general SDP or RTSP guideline. 116 For the SDP description, the key management attributes may be defined 117 at session level (i.e. before the media descriptor lines) and/or at 118 media level. If the key management attributes are defined at media 119 level, they will only apply to that specific media. If the key 120 management attributes are defined at both session and media level, 121 the media level definition overrides the session level definition for 122 that specific media. 124 The extensions were defined in a way to: 126 * give a minimal impact on current SDP implementations, i.e. only 127 minimal modifications MUST be built into an existing SDP stack in 128 order to support the key management. 130 * make it easy to use another key management protocol, or a new 131 version, without having to redefine the attributes or add new 132 ones. 134 The following set of attributes have been identified as necessary to 135 support: 137 * key management protocol identifier, to indicate the key 138 management protocol used ("keymgmt-prtcl") 140 * key management raw data field, to transport the key management 141 protocol data ("keymgmt-data") 143 * in the case of SDP, an extra (optional) authentication attribute 144 to be able to tie the key management data to the surrounding 145 media definitions ("key-extra-auth"). 147 2.1. SDP Extensions 149 This section provides an Augmented Backus-Naur Form (ABNF) grammar 150 (as used in [SDP]) for the key management extensions to SDP. 152 Note that the new definitions are compliant with the definition of an 153 attribute field, i.e. 155 attribute = (att-field ":" att-value) | att-field 157 Three new attributes are defined, keymgmt-prtcl, keymgmt-data, and 158 key-extra-auth. 160 keymgmt-prtcl = "keymgmt-prot:" prtcl-name 162 prtcl-name = 1*(safe) 163 ; e.g. "MIKEY" 165 keymgmt-data = "keymgmt-data:" byte-string 167 key-extra-auth = "keymgmt-auth:" byte-string 169 where safe and byte-string are as defined in SDP [SDP]. 171 2.2. RTSP Extensions 173 To support the three different attributes described, the following 174 RTSP header is defined: 176 KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data 178 stream-url = "url" "=" url ";" 180 protocol = "Prot" "=" token ";" 182 data = "Data" "=" quoted-string 184 url, token and quoted-string are as defined in the RTSP specification 185 [RTSP]. The url indicates the stream URL, which the parameters 186 correspond to. 188 The KeyMgmt header should be possible to use in both request and 189 response messages of the following methods: 190 * DESCRIBE 191 * ANNOUNCE 192 * SETUP 193 * PLAY 194 * RECORD 195 * SET_PARAMETER 196 * GET_PARAMETER 197 * OPTIONS 199 3. Usage with SIP and RTSP 201 This section gives recommendations of how/when to include the defined 202 key management attributes when SIP and/or RTSP are used together with 203 SDP. 205 Some general requirements MUST be set on the key management protocol 206 if it has to be suitable to work together with SIP and RTSP: 208 * It MUST be possible to execute the key management protocol in at 209 most one roundtrip in case the answerer accepts the offer. 211 * The protocol MUST return, to SDP/RTSP, a valid answer whether the 212 provided offer was accepted or not. 214 * There MUST be a possibility for the key management protocol to 215 tie the media sessions to the negotiated parameters (i.e. an 216 interface between the key management and the SDP and RTSP 217 implementation MUST exist). 219 Today, the MIKEY protocol has adopted the key management extensions 220 to work together with SIP and RTSP. Other protocols may use the 221 described attributes and header, e.g. Kerberos. 223 3.1. General SDP processing 225 When an SDP message is created, the following procedure should be 226 applied: 228 * The "keymgmt-prot" attribute is filled in with the identifier of 229 the key management protocol used (e.g. MIKEY or Kerberos). 231 * The "keymgmt-data" attribute is filled in by using the key 232 management protocol interface to obtain key management data. The 233 data may e.g. be a MIKEY message or Kerberos ticket. 235 * If used, the "keymgmt-auth" attribute is filled in by using the 236 key management protocol interface to obtain key management data. 237 Note that what data from SDP are supposed to be provided to the 238 interface MUST be specified by the key management protocol 239 itself. 241 A received SDP message that contains the key management attributes 242 SHOULD process these attributes in the following manner: 244 * Detect the key management protocol used by parsing the "keymgmt- 245 prot" attribute. 247 * Extract the key management data from the "keymgmt-data" attribute 248 and call the key management interface with the extracted data. 249 Note that depending on key management protocol, some extra 250 parameters might of course be requested, such as the 251 source/destination network address/port(s) for the specified 252 media. 254 * Depending on the outcome of the key management processing (i.e. 255 whether it was accepted or not), SDP processing can proceed 256 according to normal processing (e.g. according to the 257 offer/answer model, see also Section 3.2.). 259 * If the optional "keymgmt-auth" attribute is included, this is 260 processed as the "keymgmt-data". 262 3.2. SIP usage 264 The offerer should include the key management data within an offer 265 that contains the media description it should apply to. The answerer 266 MUST check with the key management protocol if the attribute values 267 are valid, and then obtain from the key management the data to 268 include in the answer. If the offer is not accepted, the answerer 269 returns a notification message and the offerer may go out with a new 270 (different) offer, depending on the local security policy. 272 Re-keying should be handled as a new offer, i.e. a re-INVITE should 273 be sent with the new proposed parameters. The answerer treats this as 274 a new offer where the key management is the issue of change. 276 3.3. RTSP usage 278 RTSP does not use the offer/answer model, as SIP does. This causes 279 some problems as it is not possible (without abusing RTSP) to send 280 back an answer to the server (as the server will in most cases be the 281 one initiating the security parameter exchange). To solve this, a new 282 header has been introduced (Section 2.2). 284 The processing of a key management header in RTSP should be done 285 analogous of the SDP message processing. The only differences will be 286 that the url has been introduced and that there is no corresponding 287 parameter for the extra authentication. The url should be processed 288 as a standard RTSP stream url, i.e. to identify the session. It is 289 however not mandatory to use. 291 The initial key management message from a server should be sent to 292 the client using SDP. When responding to this, the client uses the 293 new RTSP header to send back an answer (included in either the SETUP 294 or the PLAY message). 296 The server may provide re-keying facilities by sending a new key 297 management message in a SET_PARAMETER or ANNOUNCE messages. In the 298 latter, the RTSP header is not used if the ANNOUNCE message includes 299 a SDP description where the data can be provided in. The response 300 message is then put in the new RTSP header in the response message 301 from the client to the server. Note that the SET PARAMETER and the 302 ANNOUNCE messages are not mandatory to support for the servers. 304 3.4. Example scenarios 306 Example 1 (SIP) 308 A SIP call is taking place between Alice and Bob. Alice sends an 309 Invite message consisting of the following offer: 311 v=0 312 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 313 s=Cool stuff 314 e=alice@w-land.org 315 t=0 0 316 c=IN IP4 lost.somewhere.com 317 a=keymgmt-prot:MIKEY 318 a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 319 m=audio 49000 RTP/SAVP 98 320 a=rtpmap:98 AMR/8000 321 m=video 52230 RTP/SAVP 31 322 a=rtpmap:31 H261/90000 324 i.e. Alice proposes to set up one audio stream and one video stream 325 that run over SRTP. To set up the security parameters for SRTP, she 326 uses MIKEY. Note that MIKEY is negotiating the crypto suite for both 327 streams (as it is placed at the session level). 329 Bob accepts the offer and sends an answer back to Alice: 331 v=0 332 o=bob 2891092897 2891092897 IN IP4 found.somewhere.com 333 s=Cool stuff 334 e=bob@null.org 335 t=0 0 336 c=IN IP4 found.somewhere.com 337 a=keymgmt-prot:MIKEY 338 a=keymgmt-data:skaoqDeMkdwRW278HjKVB... 339 m=audio 49030 RTP/SAVP 98 340 a=rtpmap:98 AMR/8000 341 m=video 52230 RTP/SAVP 31 342 a=rtpmap:31 H261/90000 344 Example 2 (SDP) 346 This example shows how Alice would have done in the previous example 347 if she wished to protect only the audio stream. 349 v=0 350 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 351 s=Cool stuff 352 e=alice@w-land.org 353 t=0 0 354 c=IN IP4 lost.somewhere.com 355 m=audio 49000 RTP/SAVP 98 356 a=rtpmap:98 AMR/8000 357 a=keymgmt-prot:MIKEY 358 a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 359 m=video 52230 RTP/AVP 31 360 a=rtpmap:31 H261/90000 362 Example 3 (RTSP) 364 A client wants to set up a streaming session and requests a media 365 description from the streaming server. 367 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 368 CSeq: 312 369 Accept: application/sdp 370 From: user@client.com 372 The server sends back an OK message including a SDP description. As 373 the server 375 RTSP/1.0 200 OK 376 CSeq: 312 377 Date: 23 Jan 1997 15:35:06 GMT 378 Content-Type: application/sdp 379 v=0 380 o=actionmovie 2891092738 2891092738 IN IP4 movie.somewhere.com 381 s=Action Movie 382 e=action@movie.somewhere.com 383 t=0 0 384 c=IN IP4 movie.somewhere.com 385 a=keymgmt-prot:MIKEY 386 a=keymgmt-data:uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 387 m=audio 0 RTP/SAVP 98 388 a=rtpmap:98 AMR/8000 389 control:rtsp://movie.somewhere.com/action/audio 390 m=video 0 RTP/SAVP 31 391 a=rtpmap:31 H261/90000 392 control:rtsp://movie.somewhere.com/action/video 394 The client is now ready to setup the sessions. It includes the key 395 management data in the first message going back to the server (i.e. 396 the SETUP message). 398 SETUP rtsp://movie.somewhere.com/action/audio RTSP/1.0 399 CSeq: 313 400 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 401 KeyMgmt: Prot=MIKEY;Data="skaoqDeMkdwRW278HjKVB..." 403 The server processes the request including checking the validity of 404 the key management header. 406 RTSP/1.0 200 OK 407 CSeq: 313 408 Session: 12345678 409 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 410 server_port=5000-5001 412 The RTSP is then proceeded as usual (with e.g. a SETUP message for 413 the video followed by a PLAY message). 415 4. Security Considerations 417 The nature of this document is to allow SDP and RTSP to support 418 security of the media sessions. It is therefore not the intention of 419 this document to describe possible security solution or to define 420 possible security problems. The defined SDP and RTSP extensions are 421 not believed to introduce any new security risks to SDP and RTSP. 423 The "keymgmt-auth" attribute may be (optionally) used to guarantee an 424 authenticated binding between the session(s) and the security 425 parameters, e.g. authenticating both the key management lines and 426 (parts of) the surrounding SDP description. Each key management 427 specifies the coverage of such "keymgmt-auth" attribute. A denial-of- 428 service attack may be open if such authenticated binding is not 429 provided. Note however, the "keymgmt-auth" cannot work when NATs are 430 present. 432 Note that the purpose of the key management fields is to secure the 433 media streams themselves. Under the assumption that the key 434 management schemes are secure, the SDP payloads can be passed along 435 unprotected, and the media streams will still be secure even if some 436 attackers gained knowledge of the SDP contents. There may however, be 437 other reasons to protect the SDP payloads such as preventing 438 attackers from gaining any information regarding the session or the 439 used equipment. 441 5. IANA Considerations 443 Three new attributes fields for SDP (see Section 2.1) and one new 444 RTSP header are registered (see Section 2.2). 446 6. Conclusions 448 A security solution for real-time applications needs a key management 449 infrastructure. Integrating the key management scheme with the 450 session establishment protocol could be done efficiently in most of 451 the scenarios. This draft proposes a framework that integrates a key 452 management protocol (e.g. MIKEY) into SIP and RTSP, and which can be 453 accompanied by different key management protocols. A set of new 454 attributes and headers has been defined in SDP and RTSP to support 455 this. 457 7. Acknowledgments 459 Thanks to: Rolf Blom, Magnus Westerlund, and the rest involved in the 460 MMUSIC WG and the MSEC WG. 462 A special thanks to Joerg Ott and Colin Perkins. 464 8. Author's Addresses 466 Jari Arkko 467 Ericsson 468 02420 Jorvas Phone: +358 40 5079256 469 Finland Email: jari.arkko@ericsson.com 471 Elisabetta Carrara 472 Ericsson Research 473 SE-16480 Stockholm Phone: +46 8 50877040 474 Sweden EMail: elisabetta.carrara@era.ericsson.se 476 Fredrik Lindholm 477 Ericsson Research 478 SE-16480 Stockholm Phone: +46 8 58531705 479 Sweden EMail: fredrik.lindholm@era.ericsson.se 481 Mats Naslund 482 Ericsson Research 483 SE-16480 Stockholm Phone: +46 8 58533739 484 Sweden EMail: mats.naslund@era.ericsson.se 486 Karl Norrman 487 Ericsson Research 488 SE-16480 Stockholm Phone: +46 8 4044502 489 Sweden EMail: karl.norrman@era.ericsson.se 491 9. References 493 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 494 Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft, 495 IETF, Work in progress (MSEC). 497 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 498 SDP", Internet Draft, IETF, Work in progress (MMUSIC). 500 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 501 Streaming Protocol (RTSP)", RFC 2326, April 1998. 503 [SDP] Handley, M., and Jacobson, V., "Session Description Protocol 504 (SDP)", IETF, RFC2327 506 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 507 "SIP: Session Initiation Protocol", IETF, RFC2543. 509 [SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K., 510 and Oran, D., "The Secure Real Time Transport Protocol", Internet 511 Draft, IETF, Work in Progress (AVT). 513 This Internet-Draft expires in August 2002.