idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-06.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 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) -- 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: August 2003 M. Naslund 6 K. Norrman 7 Ericsson 8 February, 2003 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......................................................6 55 3.3. RTSP usage.....................................................7 56 3.4. Example scenarios..............................................7 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 as there are many more parameters that need to be 114 transported. The approach here is to use and extend the SDP 115 description to transport the key management offer/answer and also to 116 associate it with the media sessions. SIP uses the offer/answer model 117 [OAM] whereby extensions to SDP will be enough. However, RTSP [RTSP] 118 does not use the offer/answer model. This makes it impossible to send 119 back an answer to the server. To solve this, a new header is 120 introduced in which the key management data can be included. 122 1.1. Notational Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119. 128 2. Extensions to SDP and RTSP 130 This section describes common attributes that are to be included in 131 an SDP description or in an RTSP header when an integrated key 132 management protocol is used. The attribute values MUST follow the 133 general SDP or RTSP guidelines. 135 For the SDP description, the key management attributes MAY be defined 136 at session level (i.e. before the media descriptor lines) and/or at 137 media level. If the key management attributes are defined at media 138 level, they will only apply to that specific media. If the key 139 management attributes are defined at both session and media level, 140 the media level definition overrides the session level definition for 141 that specific media. 143 The following SDP attribute is defined: 145 key-mgmt: 147 is the name of the key management protocol and the 148 opaque-data is a field to transport the key management protocol data. 149 The key management protocol data contains the necessary information 150 to establish the security protocol, e.g., keys and cryptographic 151 parameters. All parameters and keys are protected by the key 152 management. Note that if the key management protocol fails, e.g., the 153 receiver does not accept any of the proposed security parameters, or 154 simply does not understand the key management protocol, the security 155 setup will fail. Consequently, it is impossible to establish a secure 156 session. So, if the key management fails, the offer must be rejected. 158 2.1. SDP Extensions 160 This section provides an Augmented Backus-Naur Form (ABNF) grammar 161 (as used in [SDPnew]) for the key management extensions to SDP. 163 Note that the new definitions are compliant with the definition of an 164 attribute field, i.e. 166 attribute = (att-field ":" att-value) | att-field 168 One new attribute for SDP is defined: 170 key-mgmt = "key-mgmt: " prtcl-id keymgmt-data 172 prtcl-id = non-ws-string 173 ; e.g. "mikey" 175 keymgmt-data = text 177 where non-ws-string and text are as defined in SDP [SDPnew]. The 178 attribute may be used at session level, media level or at both 179 levels. An attribute defined at media level overrides an attribute 180 defined at session level. 182 2.2. RTSP Extensions 184 To support the needed attribute described, the following RTSP header 185 is defined: 187 KeyMgmt = "keymgmt" ":" 1#key-mgmt-spec 189 key-mgmt-spec = "prot" "=" token ";" "data" "=" quoted-string 191 token and quoted-string are as defined in the RTSP specification 192 [RTSP]. 194 The KeyMgmt header should be possible to use in the messages 195 described in the table below. 197 Method Direction Requirement 198 DESCRIBE C->S required 199 SETUP C->S required 200 ANNOUNCE C->S, S->C optional (required: if re-key should 201 be supported) 203 3. Usage with SIP and RTSP 205 This section gives recommendations of how/when to include the defined 206 key management attribute when SIP and/or RTSP are used together with 207 SDP. 209 When a key management protocol is integrated with SIP/SDP and RTSP, 210 the following requirements are put on the key management: 212 * It MUST be possible to execute the key management protocol in at 213 most one roundtrip in case the answerer accepts the offer. 215 * It MUST be possible from the SIP/SDP and RTSP application, using 216 the key management API, to receive key management data, and 217 information of whether a message is accepted or not. 219 Today, the MIKEY protocol [MIKEY] has adopted the key management 220 extensions to work together with SIP and RTSP. Other protocols MAY 221 use the described attribute and header, e.g. Kerberos [KERB]. 223 3.1. General SDP processing 225 When an SDP message is created, the following procedure should be 226 applied: 228 * The identifier of the key management protocol used (e.g. MIKEY or 229 Kerberos) MUST be put in the prtcl-id field. 231 * The keymgmt-data field MUST be created with the data received from 232 the key management protocol (this data MUST be base64 encoded). 233 The data may e.g. be a MIKEY message or Kerberos ticket. 235 A received SDP message that contains the key management attributes 236 SHOULD process these attributes in the following manner: 238 * The key management protocol used MUST be identified by checking the 239 prtcl-id field in the key management attribute. 241 * The key management data from the keymgmt-data field MUST be 242 extracted and given to the key management protocol. Note that 243 depending on key management protocol, some extra parameters might 244 of course be requested, such as the source/destination network 245 address/port(s) for the specified media. 247 * Depending on the outcome of the key management processing (i.e. 248 whether it was accepted or not), the processing can proceed 249 according to normal processing (e.g. according to the offer/answer 250 model, see also Section 3.2). 252 Note that the attribute MAY be repeated more than once (e.g., one at 253 session level and one at media level). Consequently, the process is 254 repeated for each key management attribute detected. 256 If more than one key management protocol is supported, multiple 257 instances of the key management attribute MAY be included in the 258 initial offer, each transporting a different key management data, 259 thus indicating alternatives supported. 261 If the sender includes more than one key management protocol 262 attributes at session level (analogous for the media level), these 263 SHOULD be listed in order of preference (with the first being the 264 preferred). The receiver chooses the key management protocol it 265 supports. When answering, only the accepted key management protocol 266 attribute MUST be included. If the receiver does not support any of 267 the sender's suggested key management protocols, the receiver answers 268 with an error message (see SIP and RTSP), whereby the sender MUST put 269 down the current setup procedure. 271 Note that by placing multiple key management offers in a single 272 message has the disadvantage that the message expands and the 273 computational workload for the offerer will increase drastically. The 274 possibility to support multiple key management protocols may 275 introduce bidding down attacks. To avoid this, the list of 276 identifiers of the proposed key management protocols MUST be 277 authenticated, which MUST be done by each key management. This puts 278 the requirement that it MUST be specified (in the key management 279 protocol itself or in a companion document) how the protocol 280 identifiers could be authenticated from the offerer to the responder 281 by the use of the specific key management protocol. Note that even if 282 only one key management protocol is used, that still must 283 authenticate its own protocol identifier. 285 If more than one protocol is supported by the offerer, it is 286 RECOMMENDED that he offers all to him acceptable protocols in the 287 first offer, rather than making single, subsequent alternative offers 288 in response to error messages, see "Security Considerations". 290 3.2. SIP usage 292 The offerer SHOULD include the key management data within an offer 293 that contains the media description it should apply to. The answerer 294 MUST check with the key management protocol if the attribute values 295 are valid, and then obtain from the key management the data to 296 include in the answer. 298 If the offer is not accepted, the answerer SHOULD return a "606 Not 299 Acceptable" message, including one or more Warning headers (at least 300 a 306). The offer MUST then abort the security setup. 302 Re-keying can be handled as a new offer, i.e. a re-INVITE should be 303 sent with the new proposed parameters. The answerer treats this as a 304 new offer where the key management is the issue of change. In 305 general, the re-INVITE (and the key exchange) must be finalized 306 before the security protocol can change the keys. The synchronization 307 method used when changing keys are dependent on the security and key 308 management protocol used. 310 3.3. RTSP usage 312 RTSP does not use the offer/answer model, as SIP does. This causes 313 some problems, as it is not possible (without abusing RTSP) to send 314 back an answer to the server (as the server will in most cases be the 315 one initiating the security parameter exchange). To solve this, a new 316 header has been introduced (Section 2.2). This also assumes that the 317 key management also has some kind of binding to the media, so that 318 the response to the server will be processed as required. 320 The processing of a key management header in RTSP should be done 321 analogous of the SDP message processing. The initial key management 322 message from a server should be sent to the client using SDP. When 323 responding to this, the client uses the new RTSP header to send back 324 an answer (included in the SETUP message). If a server receives a 325 SETUP message in which it expects a key management message, but none 326 is included, a 403 Forbidden SHOULD be returned to the client, 327 whereby the current setup MUST be aborted. 329 The server MAY provide re-keying/updating facilities by sending a new 330 key management message in an ANNOUNCE messages. The ANNOUNCE message 331 contains an SDP message including the key management parameters. The 332 response message is put in the new RTSP header in the response from 333 the client to the server. Note that the ANNOUNCE messages MUST be 334 supported if this feature is to be used. 336 3.4. Example scenarios 338 Example 1 (SIP) 340 A SIP call is taking place between Alice and Bob. Alice sends an 341 Invite message consisting of the following offer: 343 v=0 344 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 345 s=Cool stuff 346 e=alice@w-land.org 347 t=0 0 348 c=IN IP4 lost.somewhere.com 349 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 350 m=audio 49000 RTP/SAVP 98 351 a=rtpmap:98 AMR/8000 352 m=video 52230 RTP/SAVP 31 353 a=rtpmap:31 H261/90000 355 i.e. Alice proposes to set up one audio stream and one video stream 356 that run over SRTP. To set up the security parameters for SRTP, she 357 uses MIKEY. Note that MIKEY is negotiating the crypto suite for both 358 streams (as it is placed at the session level). 360 Bob accepts the offer and sends an answer back to Alice: 362 v=0 363 o=bob 2891092897 2891092897 IN IP4 found.somewhere.com 364 s=Cool stuff 365 e=bob@null.org 366 t=0 0 367 c=IN IP4 found.somewhere.com 368 a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... 369 m=audio 49030 RTP/SAVP 98 370 a=rtpmap:98 AMR/8000 371 m=video 52230 RTP/SAVP 31 372 a=rtpmap:31 H261/90000 374 Example 2 (SDP) 376 This example shows how Alice would have done in the previous example 377 if she wished to protect only the audio stream. 379 v=0 380 o=alice 2891092738 2891092738 IN IP4 lost.somewhere.com 381 s=Cool stuff 382 e=alice@w-land.org 383 t=0 0 384 c=IN IP4 lost.somewhere.com 385 m=audio 49000 RTP/SAVP 98 386 a=rtpmap:98 AMR/8000 387 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 388 m=video 52230 RTP/AVP 31 389 a=rtpmap:31 H261/90000 391 Note that even if the key management attribute is specified at 392 session level, the video part will not be affected by this (as a 393 security profile is not used). 395 Example 3 (RTSP) 396 A client wants to set up a streaming session and requests a media 397 description from the streaming server. 399 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 400 CSeq: 312 401 Accept: application/sdp 402 From: user@client.com 404 The server sends back an OK message including an SDP description. 406 RTSP/1.0 200 OK 407 CSeq: 312 408 Date: 23 Jan 1997 15:35:06 GMT 409 Content-Type: application/sdp 411 v=0 412 o=actionmovie 2891092738 2891092738 IN IP4 movie.somewhere.com 413 s=Action Movie 414 e=action@movie.somewhere.com 415 t=0 0 416 c=IN IP4 movie.somewhere.com 417 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 418 m=audio 0 RTP/SAVP 98 419 a=rtpmap:98 AMR/8000 420 control:rtsp://movie.somewhere.com/action/audio 421 m=video 0 RTP/SAVP 31 422 a=rtpmap:31 H261/90000 423 control:rtsp://movie.somewhere.com/action/video 425 The client is now ready to setup the sessions. It includes the key 426 management data in the first message going back to the server (i.e. 427 the SETUP message). 429 SETUP rtsp://movie.somewhere.com/action/audio RTSP/1.0 430 CSeq: 313 431 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 432 keymgmt: prot=mikey; data="skaoqDeMkdwRW278HjKVB..." 434 The server processes the request including checking the validity of 435 the key management header. 437 RTSP/1.0 200 OK 438 CSeq: 313 439 Session: 12345678 440 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 441 server_port=5000-5001 443 The RTSP then proceeds as usual (with e.g. a SETUP message for the 444 video followed by a PLAY message). 446 4. Adding further Key management protocols 448 This framework cannot be used with all key management protocols. The 449 key management protocol needs to comply with the requirements 450 described in Section 3. To be able to use a key management protocol 451 with this framework, the following MUST be specified: 453 * the key management protocol identifier that should be used in the 454 protocol identifier fields in both SDP and RTSP (e.g. "mikey" for 455 MIKEY). 457 * the information the key management needs from SDP and RTSP (Section 458 3 gives a guideline of what SDP and RTSP needs from the key 459 management). The exact API is implementation specific, but it 460 SHOULD at least support to exchange the specified information. 461 Note that in particular, the key management MUST always be given 462 the protocol identifier(s) of the key management protocol(s) 463 included in the offer in the correct order as they appear. 465 The key management data MUST be base64 encoded in the SDP and RTSP 466 fields. Therefore, considerations of possible conversion from the 467 normal key management representation to base64 SHOULD be taken into 468 account. 470 5. Security Considerations 472 The nature of this document is to allow SDP and RTSP to support 473 security of the media sessions. It is therefore not a primary 474 intention of this document to describe possible security solutions or 475 to define possible security problems. The defined SDP and RTSP 476 extensions are not believed to introduce any new security risks to 477 SDP and RTSP, if used as specified. 479 Note that the purpose of the key management fields is to provide 480 information to secure the media streams. Under the assumption that 481 the key management schemes are secure, the SDP can be passed along 482 unprotected without affecting the key management, and the media 483 streams will still be secure even if some attackers gained knowledge 484 of the SDP contents. 486 However, if the SDP messages are not sent authenticated between the 487 parties, it is possible for an active attacker to change attributes 488 without being detected. As the key management protocol may 489 (indirectly) rely on some of the session information from SDP (e.g., 490 address information), an attack on SDP may have indirect consequences 491 on the key management. In general, it is therefore a good thing, not 492 only to try to secure the session, but also to secure the session 493 setup. 495 Note that it is impossible to assure the authenticity of a declined 496 offer, since even if it comes from the true respondent, the fact that 497 he/she declines the offer usually means that he/she does not support 498 the protocol(s) offered, and consequently cannot be expected to 499 authenticate the response either. This means that if the initiator is 500 unsure of which protocol(s) the responder supports, we RECOMMEND that 501 the initiator offers all acceptable protocols in a single offer. If 502 not, this opens up the possibility for a "man-in-the-middle" (MITM) 503 to affect the outcome of the eventually agreed upon protocol, by 504 faking unauthenticated error messages until the initiator eventually 505 offers a protocol "to the liking" of the MITM. This is not really a 506 security problem, but rather a mild form of denial of service that 507 can be avoided by following the above recommendation. 509 6. IANA Considerations 511 New attribute fields for SDP (see Section 2.1) and RTSP header are 512 registered (see Section 2.2). 514 7. Conclusions 516 A security solution for real-time applications needs a key management 517 infrastructure. Integrating the key management scheme with the 518 session establishment protocol could be done efficiently in most of 519 the scenarios. This draft proposes a framework that integrates a key 520 management protocol (e.g., MIKEY) into SIP and RTSP, and which can be 521 accompanied by different key management protocols. A set of new 522 attributes and headers has been defined in SDP and RTSP to support 523 this. 525 8. Acknowledgments 527 Thanks to: Rolf Blom, Magnus Westerlund, and the rest involved in the 528 MMUSIC WG and the MSEC WG. 530 A special thanks to Joerg Ott and Colin Perkins. 532 9. Author's Addresses 534 Jari Arkko 535 Ericsson 536 02420 Jorvas Phone: +358 40 5079256 537 Finland Email: jari.arkko@ericsson.com 539 Elisabetta Carrara 540 Ericsson Research 541 SE-16480 Stockholm Phone: +46 8 50877040 542 Sweden EMail: elisabetta.carrara@era.ericsson.se 544 Fredrik Lindholm 545 Ericsson Research 546 SE-16480 Stockholm Phone: +46 8 58531705 547 Sweden EMail: fredrik.lindholm@era.ericsson.se 549 Mats Naslund 550 Ericsson Research 551 SE-16480 Stockholm Phone: +46 8 58533739 552 Sweden EMail: mats.naslund@era.ericsson.se 554 Karl Norrman 555 Ericsson Research 556 SE-16480 Stockholm Phone: +46 8 4044502 557 Sweden EMail: karl.norrman@era.ericsson.se 559 10. References 561 10.1. Normative References 563 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 564 the Session Description Protocol (SDP)", IETF, 3264. 566 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 567 Streaming Protocol (RTSP)", IETF, RFC 2326. 569 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 570 Description Protocol", Internet Draft, IETF, Work in progress 571 (MMUSIC). 573 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 574 "SIP: Session Initiation Protocol", IETF, RFC 2543. 576 10.2. Informative References 578 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 579 Service (V5)", IETF, RFC 1510. 581 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 582 Norrman, K., "MIKEY: Multimedia Internet KEYing", Internet Draft, 583 IETF, Work in progress (MSEC). 585 [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, 586 Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", 587 Internet Draft, IETF, Work in Progress (AVT). 589 This Internet-Draft expires in August 2003.