idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-05.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 : ---------------------------------------------------------------------------- == There are 10 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM' ** Obsolete normative reference: RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDPnew' ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KERB') (Obsoleted by RFC 4120, RFC 6649) Summary: 5 errors (**), 0 flaws (~~), 2 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: December 2002 M. Naslund 6 K. Norrman 7 Ericsson 8 June, 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 47 1. Introduction.....................................................2 48 1.1. Notational Conventions.........................................3 49 2. Extensions to SDP and RTSP.......................................3 50 2.1. SDP Extensions.................................................4 51 2.2. RTSP Extensions................................................4 52 3. Usage with SIP and RTSP..........................................5 53 3.1. General SDP processing.........................................5 54 3.2. SIP usage......................................................7 55 3.3. RTSP usage.....................................................7 56 3.4. Example scenarios..............................................8 57 4. Adding further Key management protocols.........................10 58 5. Security Considerations.........................................10 59 6. IANA Considerations.............................................11 60 7. Conclusions.....................................................11 61 8. Acknowledgments.................................................11 62 9. Author's Addresses..............................................11 63 10. References.....................................................12 64 10.1. Normative References.........................................12 65 10.2. Informative References.......................................12 67 1. Introduction 69 There has recently been work to define a security framework for the 70 protection of real-time applications running over RTP, [SRTP]. 71 However, a security protocol needs a key management infrastructure to 72 exchange keys and security parameters, managing and refreshing keys, 73 etc. 75 A key management protocol is executed prior to the security protocol 76 execution. The key management protocol's main goal is to, in a secure 77 and reliable way, establish a so called security association for the 78 security protocol. This includes one or several cryptographic keys 79 and a set of necessary parameters for the security protocol, e.g., 80 cipher and authentication algorithm to be used. The key management 81 protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in 82 the sense that it negotiates necessary information in order to be 83 able to setup the session. 85 The focus in the following sections is to describe SDP attribute 86 extensions and RTSP header extensions to support key management, and 87 a possible integration within SIP and RTSP. A framework is therefore 88 described in the following. Such a framework will need to be 89 completed by one or more key management protocols, to describe how 90 the framework is used, e.g. which is the data to be carried in the 91 extensions. 93 Some of the motivations to create a framework with the possibility to 94 include the key management in the session establishment are: 96 * Just as the codec information is a description of how to encode and 97 decode the audio (or video) stream, the key management data is a 98 description of how to encrypt and decrypt the data. 100 * The possibility to negotiate the security for the entire multimedia 101 session at the same time. 103 * The knowledge of the media at the session establishment makes it 104 easy to tie the key management to the multimedia sessions. 106 * This approach may be more efficient than setting up the security 107 later, as that approach might force extra roundtrips, possibly 108 also a separate set-up for each stream, hence implying more delay 109 to the actual setup of the media session. 111 Currently in SDP [SDPnew], one field exists to transport keys, i.e. 112 the "key=" field. However, this is not enough for a key management 113 protocol. The approach here is to use and extend the SDP description 114 to transport the key management offer/answer and also to associate it 115 with the media sessions. SIP uses the offer/answer model [OAM] 116 whereby extensions to SDP will be enough. However, RTSP [RTSP] does 117 not use the offer/answer model. This makes it impossible to send back 118 an answer to the server. To solve this, a new header is introduced in 119 which the key management data can be included. 121 1.1. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119. 127 2. Extensions to SDP and RTSP 129 This section describes common attributes that are to be included in 130 an SDP description or in an RTSP header when an integrated key 131 management protocol is used. The attribute values MUST follow the 132 general SDP or RTSP guidelines. 134 For the SDP description, the key management attributes MAY be defined 135 at session level (i.e. before the media descriptor lines) and/or at 136 media level. If the key management attributes are defined at media 137 level, they will only apply to that specific media. If the key 138 management attributes are defined at both session and media level, 139 the media level definition overrides the session level definition for 140 that specific media. 142 The following SDP attribute is defined: 144 key-mgmt: 145 is the name of the key management protocol and the opaque-data 146 is a field to transport the key management protocol data. The key 147 management protocol data contains the necessary information to 148 establish the security protocol, e.g., keys and cryptographic 149 parameters. All parameters and keys are protected by the key 150 management. Note that if the key management protocol fails, e.g., the 151 receiver does not accept any of the proposed security parameters, or 152 simply does not understand the key management protocol, the security 153 setup will fail. Consequently, it is impossible to establish a secure 154 session. So, if the key management fails, the offer must be rejected. 156 2.1. SDP Extensions 158 This section provides an Augmented Backus-Naur Form (ABNF) grammar 159 (as used in [SDPnew]) for the key management extensions to SDP. 161 Note that the new definitions are compliant with the definition of an 162 attribute field, i.e. 164 attribute = (att-field ":" att-value) | att-field 166 One new attribute for SDP is defined: 168 key-mgmt = "key-mgmt: " prtcl-name keymgmt-data 170 prtcl-name = non-ws-string 171 ; e.g. "MIKEY" 173 keymgmt-data = text 175 where non-ws-string and text are as defined in SDP [SDPnew]. The 176 attribute may be used at session level, media level or at both 177 levels. An attribute defined at media level overrides an attribute 178 defined at session level. 180 2.2. RTSP Extensions 182 To support the needed attribute described, the following RTSP header 183 is defined: 185 KeyMgmt _ "keymgmt" ":" 1#key-mgmt-spec 187 key-mgmt-spec _ "prot" "=" token ";" "data" "=" quoted-string 189 token and quoted-string are as defined in the RTSP specification 190 [RTSP]. 192 The KeyMgmt header should be possible to use in the messages 193 described in the table below. 195 Method Direction Requirement 196 DESCRIBE C->S required 197 SETUP C->S required 198 ANNOUNCE C->S, S->C optional (required: if re-key should 199 be supported) 201 3. Usage with SIP and RTSP 203 This section gives recommendations of how/when to include the defined 204 key management attribute when SIP and/or RTSP are used together with 205 SDP. 207 When a key management protocol is integrated with SIP/SDP and RTSP, 208 the following requirements are put on the key management: 210 * It MUST be possible to execute the key management protocol in at 211 most one roundtrip in case the answerer accepts the offer. 213 * It MUST be possible from the SIP/SDP and RTSP application, using 214 the key management API, to receive key management data, and 215 information of whether a message is accepted or not. 217 Today, the MIKEY protocol [MIKEY] has adopted the key management 218 extensions to work together with SIP and RTSP. Other protocols MAY 219 use the described attribute and header, e.g. Kerberos [KERB]. 221 3.1. General SDP processing 223 When an SDP message is created, the following procedure should be 224 applied: 226 * The identifier of the key management protocol used (e.g. MIKEY or 227 Kerberos) MUST be put in the prtcl-name field. 229 * The keymgmt-data field MUST be created with the data received from 230 the key management protocol (this data MUST be base64 encoded). 231 The data may e.g. be a MIKEY message or Kerberos ticket. 233 A received SDP message that contains the key management attributes 234 SHOULD process these attributes in the following manner: 236 * The key management protocol used MUST be identified by checking the 237 prtcl-name field in the key management attribute. 239 * The key management data from the keymgmt-data field MUST be 240 extracted and given to the key management protocol. Note that 241 depending on key management protocol, some extra parameters might 242 of course be requested, such as the source/destination network 243 address/port(s) for the specified media. 245 * Depending on the outcome of the key management processing (i.e. 246 whether it was accepted or not), the processing can proceed 247 according to normal processing (e.g. according to the offer/answer 248 model, see also Section 3.2). 250 Note that the attribute MAY be repeated more than once (e.g., one at 251 session level and one at media level). Consequently, the process is 252 repeated for each key management attribute detected. 254 If more than one key management protocol is supported, multiple 255 instances of the key management attribute MAY be included in the 256 initial offer, each transporting a different key management data, 257 thus indicating alternatives supported. 259 If the sender includes more than one key management attributes at 260 session level (analogous for the media level), these SHOULD be listed 261 in order of preference (with the first being the preferred). The 262 receiver chooses the key management protocol it supports. When 263 answering, only the accepted key management attribute MUST be 264 included. If the receiver does not support any of the sender's 265 suggested key management protocols, the receiver answers with an 266 error message (see SIP and RTSP), possibly also listing the supported 267 key management protocols (without any data included). 269 However, the offerer is RECOMMENDED to include only one of the 270 protocols for a specific media. If the answerer cannot support the 271 proposed protocol, it rejects the offer. 273 Note that by placing multiple key management offers in a single 274 message has the disadvantage that the message expands and the 275 computational workload for the offerer will increase drastically. It 276 might be acceptable to use a trial and error approach if the number 277 of key management protocols supported are few. The possibility to 278 support multiple key management protocols may introduce bidding down 279 attacks. It is therefore important that the local policy considers 280 this (e.g., only allows protocols that from a security point of view 281 are equivalent, to be negotiated). 283 What can be done to increase the likelihood for a successful setup is 284 to use a capability discovery mechanism (e.g., used in SIP when using 285 the OPTION message). In this case, the key management protocols 286 supported are expressed at session level without any data (i.e., a 287 list of only the key-mgmt: part is used). 289 v=0 290 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 291 c=IN IP4 lost.somewhere.com 292 a=key-mgmt:mikey 293 a=key-mgmt:coolxchg 294 m=audio 0 RTP/SAVP 98 295 a=rtpmap:98 AMR/8000 296 m=video 0 RTP/SAVP 31 34 297 a=rtpmap:31 H261/90000 298 a=rtpmap:34 H263/90000 300 3.2. SIP usage 302 The offerer SHOULD include the key management data within an offer 303 that contains the media description it should apply to. The answerer 304 MUST check with the key management protocol if the attribute values 305 are valid, and then obtain from the key management the data to 306 include in the answer. 308 If the offer is not accepted, the answerer SHOULD return a "606 Not 309 Acceptable" message, including one or more Warning headers (at least 310 a 306). The offerer MAY then go out with a new (different) offer, 311 depending on the local security policy. 313 Re-keying can be handled as a new offer, i.e. a re-INVITE should be 314 sent with the new proposed parameters. The answerer treats this as a 315 new offer where the key management is the issue of change. In 316 general, the re-INVITE (and the key exchange) must be finalized 317 before the security protocol can change the keys. The synchronization 318 method used when changing keys are dependent on the security and key 319 management protocol used. 321 3.3. RTSP usage 323 RTSP does not use the offer/answer model, as SIP does. This causes 324 some problems as it is not possible (without abusing RTSP) to send 325 back an answer to the server (as the server will in most cases be the 326 one initiating the security parameter exchange). To solve this, a new 327 header has been introduced (Section 2.2). This also assumes that the 328 key management also have some kind of binding to the media, so that 329 the response to the server will be processed as required. 331 The processing of a key management header in RTSP should be done 332 analogous of the SDP message processing. The initial key management 333 message from a server should be sent to the client using SDP. When 334 responding to this, the client uses the new RTSP header to send back 335 an answer (included in the SETUP message). If a server receives a 336 SETUP message in which it expects a key management message, but none 337 is included, a 403 Forbidden SHOULD be returned to the client. 339 The server MAY provide re-keying/updating facilities by sending a new 340 key management message in an ANNOUNCE messages. The ANNOUNCE message 341 contains an SDP message including the key management parameters. The 342 response message is put in the new RTSP header in the response from 343 the client to the server. Note that the ANNOUNCE messages MUST be 344 supported if this feature is to be used. 346 3.4. Example scenarios 348 Example 1 (SIP) 350 A SIP call is taking place between Alice and Bob. Alice sends an 351 Invite message consisting of the following offer: 353 v=0 354 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 355 s=Cool stuff 356 e=alice@w-land.org 357 t=0 0 358 c=IN IP4 lost.somewhere.com 359 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 360 m=audio 49000 RTP/SAVP 98 361 a=rtpmap:98 AMR/8000 362 m=video 52230 RTP/SAVP 31 363 a=rtpmap:31 H261/90000 365 i.e. Alice proposes to set up one audio stream and one video stream 366 that run over SRTP. To set up the security parameters for SRTP, she 367 uses MIKEY. Note that MIKEY is negotiating the crypto suite for both 368 streams (as it is placed at the session level). 370 Bob accepts the offer and sends an answer back to Alice: 372 v=0 373 o=bob 2891092897 2891092897 IN IP4 found.somewhere.com 374 s=Cool stuff 375 e=bob@null.org 376 t=0 0 377 c=IN IP4 found.somewhere.com 378 a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... 379 m=audio 49030 RTP/SAVP 98 380 a=rtpmap:98 AMR/8000 381 m=video 52230 RTP/SAVP 31 382 a=rtpmap:31 H261/90000 384 Example 2 (SDP) 386 This example shows how Alice would have done in the previous example 387 if she wished to protect only the audio stream. 389 v=0 390 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 391 s=Cool stuff 392 e=alice@w-land.org 393 t=0 0 394 c=IN IP4 lost.somewhere.com 395 m=audio 49000 RTP/SAVP 98 396 a=rtpmap:98 AMR/8000 397 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 398 m=video 52230 RTP/AVP 31 399 a=rtpmap:31 H261/90000 401 Note that even if the key management attribute is specified at 402 session level, the video part will not be affected by this (as a 403 security profile is not used). 405 Example 3 (RTSP) 407 A client wants to set up a streaming session and requests a media 408 description from the streaming server. 410 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 411 CSeq: 312 412 Accept: application/sdp 413 From: user@client.com 415 The server sends back an OK message including an SDP description. 417 RTSP/1.0 200 OK 418 CSeq: 312 419 Date: 23 Jan 1997 15:35:06 GMT 420 Content-Type: application/sdp 422 v=0 423 o=actionmovie 2891092738 2891092738 IN IP4 movie.somewhere.com 424 s=Action Movie 425 e=action@movie.somewhere.com 426 t=0 0 427 c=IN IP4 movie.somewhere.com 428 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 429 m=audio 0 RTP/SAVP 98 430 a=rtpmap:98 AMR/8000 431 control:rtsp://movie.somewhere.com/action/audio 432 m=video 0 RTP/SAVP 31 433 a=rtpmap:31 H261/90000 434 control:rtsp://movie.somewhere.com/action/video 436 The client is now ready to setup the sessions. It includes the key 437 management data in the first message going back to the server (i.e. 438 the SETUP message). 440 SETUP rtsp://movie.somewhere.com/action/audio RTSP/1.0 441 CSeq: 313 442 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 443 keymgmt: prot=mikey; data="skaoqDeMkdwRW278HjKVB..." 445 The server processes the request including checking the validity of 446 the key management header. 448 RTSP/1.0 200 OK 449 CSeq: 313 450 Session: 12345678 451 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 452 server_port=5000-5001 454 The RTSP then proceeds as usual (with e.g. a SETUP message for the 455 video followed by a PLAY message). 457 4. Adding further Key management protocols 459 This framework cannot be used with all key management protocols. The 460 key management protocol needs to comply with the requirements 461 described in Section 3. To be able to use a key management protocol 462 with this framework, the following MUST be specified: 464 * the key management protocol name that should be used in the 465 protocol name fields in both SDP and RTSP (e.g. "mikey" for 466 MIKEY). 468 * the information the key management needs from SDP and RTSP (Section 469 3 gives a guideline of what SDP and RTSP needs from the key 470 management). The exact API is implementation specific, but it 471 SHOULD at least support to exchange the specified information. 473 The key management data MUST be base64 encoded in the SDP and RTSP 474 fields. Therefore, considerations of possible conversion from the 475 normal key management representation to base64 SHOULD be taken into 476 consideration. 478 5. Security Considerations 480 The nature of this document is to allow SDP and RTSP to support 481 security of the media sessions. It is therefore not the intention of 482 this document to describe possible security solutions or to define 483 possible security problems. The defined SDP and RTSP extensions are 484 not believed to introduce any new security risks to SDP and RTSP. 486 Note that the purpose of the key management fields is to provide 487 information to secure the media streams. Under the assumption that 488 the key management schemes are secure, the SDP can be passed along 489 unprotected without affecting the key management, and the media 490 streams will still be secure even if some attackers gained knowledge 491 of the SDP contents. 493 However, if the SDP messages are not sent authenticated between the 494 parties, it is possible for an active attacker to change attributes 495 without being detected. As the key management protocol may 496 (indirectly) rely on some of the session information from SDP (e.g., 497 address information), an attack on SDP may have indirect consequences 498 on the key management. In general, it is therefore a good thing, not 499 only to try to secure the session, but also to secure the session 500 setup. 502 6. IANA Considerations 504 New attribute fields for SDP (see Section 2.1) and RTSP header are 505 registered (see Section 2.2). 507 7. Conclusions 509 A security solution for real-time applications needs a key management 510 infrastructure. Integrating the key management scheme with the 511 session establishment protocol could be done efficiently in most of 512 the scenarios. This draft proposes a framework that integrates a key 513 management protocol (e.g., MIKEY) into SIP and RTSP, and which can be 514 accompanied by different key management protocols. A set of new 515 attributes and headers has been defined in SDP and RTSP to support 516 this. 518 8. Acknowledgments 520 Thanks to: Rolf Blom, Magnus Westerlund, and the rest involved in the 521 MMUSIC WG and the MSEC WG. 523 A special thanks to Joerg Ott and Colin Perkins. 525 9. Author's Addresses 527 Jari Arkko 528 Ericsson 529 02420 Jorvas Phone: +358 40 5079256 530 Finland Email: jari.arkko@ericsson.com 532 Elisabetta Carrara 533 Ericsson Research 534 SE-16480 Stockholm Phone: +46 8 50877040 535 Sweden EMail: elisabetta.carrara@era.ericsson.se 537 Fredrik Lindholm 538 Ericsson Research 539 SE-16480 Stockholm Phone: +46 8 58531705 540 Sweden EMail: fredrik.lindholm@era.ericsson.se 541 Mats Naslund 542 Ericsson Research 543 SE-16480 Stockholm Phone: +46 8 58533739 544 Sweden EMail: mats.naslund@era.ericsson.se 546 Karl Norrman 547 Ericsson Research 548 SE-16480 Stockholm Phone: +46 8 4044502 549 Sweden EMail: karl.norrman@era.ericsson.se 551 10. References 553 10.1. Normative References 555 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 556 SDP", Internet Draft, IETF, Work in progress (MMUSIC). 558 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 559 Streaming Protocol (RTSP)", IETF, RFC 2326. 561 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 562 Description Protocol", Internet Draft, IETF, Work in progress 563 (MMUSIC). 565 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 566 "SIP: Session Initiation Protocol", IETF, RFC 2543. 568 10.2. Informative References 570 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 571 Service (V5)", IETF, RFC 1510. 573 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 574 Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft, 575 IETF, Work in progress (MSEC). 577 [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, 578 Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", 579 Internet Draft, IETF, Work in Progress (AVT). 581 This Internet-Draft expires in December 2002.