idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-09.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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7499 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-13 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KERB') (Obsoleted by RFC 4120, RFC 6649) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: April 2004 M. Naslund 6 K. Norrman 7 Ericsson 8 October 2003 10 Key Management Extensions for Session Description 11 Protocol (SDP) and Real Time Streaming Protocol (RTSP) 12 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines general extensions for SDP and RTSP to carry 41 messages as specified by a key management protocol, in order to 42 secure the media. These extensions are presented as a framework, to 43 be used by one or more key management protocols. As such, its use is 44 meaningful only when it is completed by the key management protocol 45 in use. 47 General guidelines are also given on how the framework should be used 48 together with SIP and RTSP. 50 TABLE OF CONTENTS 52 1. Introduction.....................................................2 53 1.1. Notational Conventions.........................................3 54 2. Extensions to SDP and RTSP.......................................4 55 2.1. SDP Extensions.................................................4 56 2.2. RTSP Extensions................................................5 57 3. Usage with SIP and RTSP..........................................5 58 3.1. General SDP processing.........................................6 59 3.2. SIP usage......................................................7 60 3.3. RTSP usage.....................................................8 61 3.4. Bidding-down attack prevention.................................9 62 3.5. Example scenarios.............................................10 63 4. Adding further Key management protocols.........................13 64 5. Security Considerations.........................................13 65 6. IANA Considerations.............................................14 66 6.1. SDP Attribute Registration....................................14 67 6.2. RTSP Header Registration......................................15 68 6.3. Protocol Identifier Registration..............................15 69 7. Acknowledgments.................................................16 70 8. Author's Addresses..............................................16 71 9. References......................................................17 72 9.1. Normative References..........................................17 73 9.2. Informative References........................................17 75 1. Introduction 77 [Editor remark] All instances of RFC xxxx should be replaced with 78 the RFC number of this document, when published. Furthermore, all 79 instances of RFC yyyy should be replaced with the RFC number of 80 the MIKEY (Multimedia Internet KEYing) document [MIKEY], when 81 published. 83 There has recently been work to define a security framework for the 84 protection of real-time applications running over RTP, [SRTP]. 85 However, a security protocol needs a key management solution to 86 exchange keys and security parameters, manage and refresh keys, etc. 88 A key management protocol is executed prior to the security protocol 89 execution. The key management protocol's main goal is to, in a secure 90 and reliable way, establish a security association for the security 91 protocol. This includes one or more cryptographic keys and the set of 92 necessary parameters for the security protocol, e.g., cipher and 93 authentication algorithm to be used. The key management protocol has 94 similarities with, e.g., SIP [SIP] and RTSP [RTSP] in the sense that 95 it negotiates necessary information in order to be able to setup the 96 session. 98 The focus in the following sections is to describe a new SDP 99 attribute and RTSP header extension to support key management, and 100 the integration within SIP and RTSP. A framework is therefore 101 described in the following. This framework is completed by one or 102 more key management protocols, to describe how the framework is used, 103 e.g. which is the data to be carried in the extensions. 105 Some of the motivations to create a framework with the possibility to 106 include the key management in the session establishment are: 108 * Just as the codec information is a description of how to encode and 109 decode the audio (or video) stream, the key management data is a 110 description of how to encrypt and decrypt the data. 112 * The possibility to negotiate the security for the entire multimedia 113 session at the same time. 115 * The knowledge of the media at the session establishment makes it 116 easy to tie the key management to the multimedia sessions. 118 * This approach may be more efficient than setting up the security 119 later, as that approach might force extra roundtrips, possibly 120 also a separate set-up for each stream, hence implying more delay 121 to the actual setup of the media session. 123 * The possibility to negotiate keying material end-to-end without 124 applying end-to-end protection of the SDP (instead, hop-by-hop 125 security mechanisms can be used which may be useful if 126 intermediate proxies needs access to the SDP). 128 Currently in SDP [SDPnew], one field exists to transport keys, i.e. 129 the "k=" field. However, this is not enough for a key management 130 protocol as there are many more parameters that need to be 131 transported. The approach here is to use and extend the SDP 132 description to transport the key management offer/answer and also to 133 associate it with the media sessions. SIP uses the offer/answer model 134 [OAM] whereby extensions to SDP will be enough. However, RTSP [RTSP] 135 does not use the offer/answer model with SDP, so a new header is 136 introduced to convey key management data. 138 1.1. Notational Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Extensions to SDP and RTSP 146 This section describes common attributes that are to be included in 147 an SDP description or in an RTSP header when an integrated key 148 management protocol is used. The attribute values MUST follow the 149 general SDP or RTSP guidelines (see [SDPnew] and [RTSP]). 151 For both SDP and RTSP, the general method of adding the key 152 management protocol is to introduce new attributes, one identifier to 153 identify the specific key management protocol, and one data field 154 where the key management protocol data is placed. The key management 155 protocol data contains the necessary information to establish the 156 security protocol, e.g., keys and cryptographic parameters. All 157 parameters and keys are protected by the key management protocol. 159 The key management data SHALL be base64 encoded and comply with the 160 base64 grammar as defined in [SDPnew]. The key management protocol 161 identifier, KMID, is defined as below (where ALPHA and DIGIT are as 162 defined in [RFC2234]). 164 KMID = 1*(ALPHA/DIGIT) 166 Values for the identifier, KMID, are registered and defined in 167 accordance to Section 6. Note that the KMID will be case sensitive 168 and it is therefore RECOMMENDED that values registered are lower case 169 letters. 171 2.1. SDP Extensions 173 This section provides an Augmented Backus-Naur Form (ABNF) grammar 174 (as used in [SDPnew]) for the key management extensions to SDP. 176 Note that the new definitions are compliant with the definition of an 177 attribute field, i.e. 179 attribute = (att-field ":" att-value) | att-field 181 One new attribute for SDP is defined: 183 key-mgmt = "key-mgmt: " prtcl-id keymgmt-data 185 prtcl-id = KMID 186 ; e.g. "mikey" 188 keymgmt-data = text 190 where KMID is as previously defined, "text" is as defined in SDP 191 [SDPnew]. Prtcl-id refers to the set of values defined for KMID in 192 Section 6. "text" is consistent with the requirement of base64- 193 encoded data, and KMID is consistent with the standard definition of 194 non-ws-string. 196 The attribute may be used at session level, media level, or at both 197 levels. An attribute defined at media level overrides an attribute 198 defined at session level. Section 3 describes in detail how the 199 attributes are used and how the SDP is handled in different usage 200 scenarios. 202 2.2. RTSP Extensions 204 To support the needed attribute, the following RTSP header is 205 defined: 207 KeyMgmt = "keymgmt" ":" 1#key-mgmt-spec 209 key-mgmt-spec = "prot" "=" KMID ";" "data" "=" quoted-string 211 where KMID is as previously defined and "quoted-string" as defined in 212 the RTSP specification [RTSP]. "quoted-string" is consistent with the 213 requirement of base64-encoded data, and KMID is consistent with the 214 standard definition of token. 216 The KeyMgmt header should be possible to use in the messages 217 described in the table below. 219 Method Direction Requirement 220 DESCRIBE C->S optional 221 SETUP C->S required 222 ANNOUNCE C->S, S->C optional (required: if re-key is supported) 224 Note: Section 3 describes in detail how the RTSP extensions are used. 226 3. Usage with SIP and RTSP 228 This section gives recommendations of how/when to include the defined 229 key management attribute when SIP and/or RTSP are used together with 230 SDP. 232 When a key management protocol is integrated with SIP/SDP and RTSP, 233 the following requirements are placed on the key management: 235 * It MUST be possible to execute the key management protocol in at 236 most one roundtrip in case the answerer accepts the offer. 238 * It MUST be possible from the SIP/SDP and RTSP application, using 239 the key management API, to receive key management data, and 240 information of whether a message is accepted or not. 242 Today, the MIKEY protocol [MIKEY] has adopted the key management 243 extensions to work together with SIP and RTSP. Other protocols MAY 244 use the described attribute and header, e.g. Kerberos [KERB], however 245 this is subject to future standardization. 247 3.1. General SDP processing 249 When an SDP message is created, the following procedure SHALL be 250 applied: 252 * The identifier of the key management protocol used MUST be placed 253 in the prtcl-id field. The protocol identifier values are 254 specified by IANA (see Section 6). 256 * The list of protocol identifiers is provided by the SDP application 257 to (each) key management protocol, as defined in Section 3.4. (to 258 defeat bidding-down attacks). 260 * The keymgmt-data field MUST be created as follows. The key 261 management protocol MUST be used to create the key management 262 message. This message SHALL be base64 encoded [RFC3548] by the SDP 263 application and then encapsulated in the keymgmt-data attribute. 264 The data may e.g. be a MIKEY message (see [MIKEY], Section 7). 266 A received SDP message that contains the key management attributes 267 SHALL be processed in the following manner: 269 * The key management protocol is identified according to the prtcl-id 270 field. The protocol identifier values are specified by IANA 271 (Section 6). 273 * The key management data from the keymgmt-data field MUST be 274 extracted, base64 decoded to reconstruct the original message, and 275 then passed to the key management protocol. 277 * The list of protocol identifiers is provided by the SDP application 278 to the key management protocol, as defined in Section 3.4. Note 279 that depending on key management protocol, some extra parameters 280 might also be requested by the specific API, such as the 281 source/destination network address/port(s) for the specified media 282 (however, this will be implementation specific depending on the 283 actual API). The extra parameters that a key management protocol 284 might need (other than the ones defined here) SHOULD be 285 documented, describing their use, as well as the interaction of 286 that key management protocol with SDP and RTSP. 288 * If the key management processing is successful, then the answerer 289 sends back the answer. Otherwise, if the key management rejects 290 the offer, an error is sent back ("606 Not Acceptable") and the 291 session is aborted. See Section 3.2 for further details. 293 Note that the key management attribute MAY be repeated more than once 294 (e.g., one at session level and one at media level). Consequently, 295 the process is repeated for each key management attribute detected. 296 However, in case of failure of the key management (on either session 297 or media level), the session setup SHALL be aborted (see also Section 298 3.2 and Section 3.3 for more details). 300 In the Offer/Answer case, and in general when there is an answer, if 301 more than one key management protocol is supported, multiple 302 instances of the key management attribute MAY be included in the 303 initial offer, each transporting a different key management data, 304 thus indicating supported alternatives. 306 If the sender includes more than one key management protocol 307 attribute at session level (analogous for the media level), these 308 SHOULD be listed in order of preference (the first being the 309 preferred). The receiver selects the key management protocol it 310 wishes to use and includes only that attribute in the answer. If the 311 receiver does not support any of the sender's suggested key 312 management protocols, the receiver returns an error message (see 313 section 3.2 and section 3.3), whereby the sender MUST abort the 314 current setup procedure. 316 Note that the placement of multiple key management offers in a single 317 message has the disadvantage that the message expands and the 318 computational workload for the offerer will increase drastically. 319 Unless the guidelines of Section 3.4 are followed, multiple lines may 320 open up for bidding-down attacks. 322 The following Sections describe the specific use with SIP and RTSP 323 respectively. There are of course other cases where SDP is used, such 324 as SAP and HTTP. If SDP is transported in an Offer-Answer model 325 fashion, then the guidelines in Section 3.2 can be used. However, for 326 one-way SDP distribution (i.e. without back channel), the above 327 guidelines can be used though with certain restrictions. First, the 328 key management protocol MUST support one-way messages, and secondly, 329 only one key management protocol SHALL be offered (i.e. no 330 negotiation will be possible). 332 This document does NOT address one-to-many distribution scenarios, as 333 this would require different types of key management protocols. The 334 support for such scenarios is for future standardization. 336 3.2. SIP usage 338 When used with SIP and the offer/answer model, the offerer SHOULD 339 include the key management data within an offer that contains the 340 media description it should apply to. At the answerer's side, the key 341 management protocol checks the validity of the key management 342 message, together with the availability of the offered attribute 343 values, and then provides the key management data to be included in 344 the answer. 346 If the offer is not accepted, the answerer SHOULD return a "606 Not 347 Acceptable" message, including one or more Warning headers (e.g. a 348 306 "Attribute not understood" when one of the parameters is not 349 supported). The session is then aborted (and it is up to local policy 350 or end user to decide how to continue). 352 Re-keying can be handled as a new offer, i.e. a re-INVITE should be 353 sent with the new proposed parameters. The answerer treats this as a 354 new offer where the key management is the issue of change. In 355 general, the re-INVITE (and the key exchange) must be finalized 356 before the security protocol can change the keys. The same key 357 management protocol used in the original INVITE SHALL also be used in 358 the re-INVITE carrying re-keying. If the re-INVITE carrying re-keying 359 fails (e.g., the authentication verification fails), the answerer 360 SHOULD send a "606 Not Acceptable" message, including one or more 361 Warning headers (at least a 306). The offerer MUST then abort the 362 security setup. 364 3.3. RTSP usage 366 RTSP does not use the offer/answer model, as SIP does. This causes 367 some problems, as it is not possible (without abusing RTSP) to send 368 back an answer to the server (as the server will in most cases be the 369 one initiating the security parameter exchange). To solve this, a new 370 header has been introduced (Section 2.2). This also assumes that the 371 key management also has some kind of binding to the media, so that 372 the response to the server will be processed as required. 374 To obtain a session description, the client initially contacts the 375 server via a DESCRIBE message (according to RTSP, a media description 376 could also be obtained by other means e.g. using http). The initial 377 key management message from the RTSP server is sent to the client in 378 the SDP of the 200 OK in response to the DESCRIBE. When responding to 379 this, the client uses the new RTSP header to send back an answer 380 (included in the SETUP message). If a server receives a SETUP message 381 in which it expects a key management message, but none is included, a 382 403 Forbidden SHOULD be returned to the client, whereby the current 383 setup MUST be aborted. 385 The processing of creating a key management header in RTSP SHALL be 386 as follow: 388 * The identifier of the key management protocol used (e.g. MIKEY) 389 MUST be placed in the "prot" field of the header. The prot values 390 are specified by IANA (Section 6). 392 * The list of protocol identifiers is sent by the RTSP application to 393 (each) key management protocol as described in Section 3.4. (to 394 defeat bidding-down attacks). 396 * The keymgmt-data field MUST be created as follows. The key 397 management protocol MUST be used to create the key management 398 message. This message SHALL be base64 encoded by the SDP 399 application and then encapsulated in the "data" field of the 400 header. The data may e.g. be a MIKEY message (see [MIKEY], Section 401 7). 403 A received key management header SHALL be processed in the following 404 manner: 406 * The key management protocol is identified according to the "prot" 407 field. 409 * The key management data from the "data" field MUST be extracted, 410 base64 decoded to reconstruct the original message, and then 411 passed to the key management protocol. Note that depending on the 412 key management protocol, some extra parameters might of course be 413 requested by the specific API, such as the source/destination 414 network address/port(s) for the specified media (however, this 415 will be implementation specific depending on the actual API). 417 * Depending on the outcome of the key management processing (i.e. 418 whether it was successful or not), the processing can proceed 419 according to normal rules (see also below). 421 The server MAY provide re-keying/updating facilities by sending a new 422 key management message in an ANNOUNCE message. The ANNOUNCE message 423 contains an SDP message including the key management parameters. The 424 response message is put in the new RTSP header in the response from 425 the client to the server. Note that the ANNOUNCE messages MUST be 426 supported if this feature is to be used. 428 3.4. Bidding-down attack prevention 430 The possibility to support multiple key management protocols may, 431 unless properly handled, introduce so-called bidding-down attacks. 432 Specifically, a man-in-the-middle could "peel off" cryptographically 433 strong offers (deleting key-mgmt lines from the message), leaving 434 only weaker ones as the responder�s choice. To avoid this, the list 435 of identifiers of the proposed key management protocols MUST be 436 authenticated. The authentication MUST be done separately by each key 437 management protocol (see e.g. Section 7.1 in [MIKEY]). 439 Accordingly, it MUST be specified (in the key management protocol 440 specification itself or in a companion document) how the list of key 441 management protocol identifiers can be processed to be authenticated 442 from the offerer to the answerer by the specific key management 443 protocol. Note that even if only one key management protocol is used, 444 that still MUST authenticate its own protocol identifier. 446 The list of protocol identifiers MUST then be given to each of the 447 selected (offered) key management protocols by the application with 448 ";" separated identifiers. All the offered protocol identifiers MUST 449 be included, in the same order as they appear in the corresponding 450 SDP description. 452 The protocol list can formally be described as 454 prtcl-list = KMID *(";" KMID) 456 where KMID is as defined in Section 2. 458 For example, if the offered protocols are MIKEY and two yet-to-be- 459 invented protocols KEYP1, KEYP2, the SDP is: 461 v=0 462 o=alice 2891092738 2891092738 IN IP4 lost.example.com 463 s=Secret discussion 464 t=0 0 465 c=IN IP4 lost.example.com 466 a=key-mgmt:mikey 467 a=key-mgmt:keyp1 468 a=key-mgmt:keyp2 469 m=audio 39000 RTP/SAVP 98 470 a=rtpmap:98 AMR/8000 471 m=video 42000 RTP/SAVP 31 472 a=rtpmap:31 H261/90000 474 The protocol list, "mikey;keyp1;keyp2", would be generated from 475 the SDP description and used as input to each specified key 476 management protocol (together with the data for that protocol). 477 Each of the three protocols includes this protocol identifier 478 list in its authentication coverage (according to its protocol 479 specification). 481 If more than one protocol are supported by the offerer, it is 482 RECOMMENDED that all acceptable protocols are included in the first 483 offer, rather than making single, subsequent alternative offers in 484 response to error messages, see "Security Considerations". 486 3.5. Example scenarios 488 Example 1 (SIP) 490 A SIP call is taking place between Alice and Bob. Alice sends an 491 Invite message consisting of the following offer: 493 v=0 494 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 495 s=Cool stuff 496 e=alice@w-land.example.com 497 t=0 0 498 c=IN IP4 w-land.example.com 499 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 500 m=audio 49000 RTP/SAVP 98 501 a=rtpmap:98 AMR/8000 502 m=video 52230 RTP/SAVP 31 503 a=rtpmap:31 H261/90000 505 i.e. Alice proposes to set up one audio stream and one video stream 506 that run over SRTP. To set up the security parameters for SRTP, she 507 uses MIKEY. Note that MIKEY is negotiating the crypto suite for both 508 streams (as it is placed at the session level). 510 Bob accepts the offer and sends an answer back to Alice: 512 v=0 513 o=bob 2891092897 2891092897 IN IP4 foo.example.com 514 s=Cool stuff 515 e=bob@foo.example.com 516 t=0 0 517 c=IN IP4 foo.example.com 518 a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... 519 m=audio 49030 RTP/SAVP 98 520 a=rtpmap:98 AMR/8000 521 m=video 52230 RTP/SAVP 31 522 a=rtpmap:31 H261/90000 524 Example 2 (SDP) 526 This example shows how Alice would have done if she wished to protect 527 only the audio stream. 529 v=0 530 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 531 s=Cool stuff 532 e=alice@w-land.example.com 533 t=0 0 534 c=IN IP4 w-land.example.com 535 m=audio 49000 RTP/SAVP 98 536 a=rtpmap:98 AMR/8000 537 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 538 m=video 52230 RTP/AVP 31 539 a=rtpmap:31 H261/90000 541 Note that even if the key management attribute were specified at 542 session level, the video part would not be affected by this (as a 543 security profile is not used). 545 Example 3 (RTSP) 547 A client wants to set up a streaming session and requests a media 548 description from the streaming server. 550 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 551 CSeq: 312 552 Accept: application/sdp 553 From: user@example.com 555 The server sends back an OK message including an SDP description. 557 RTSP/1.0 200 OK 558 CSeq: 312 559 Date: 23 Jan 1997 15:35:06 GMT 560 Content-Type: application/sdp 562 v=0 563 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 564 s=Action Movie 565 e=action@movie.example.com 566 t=0 0 567 c=IN IP4 movie.example.com 568 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 569 m=audio 0 RTP/SAVP 98 570 a=rtpmap:98 AMR/8000 571 control:rtsp://movie.example.com/action/audio 572 m=video 0 RTP/SAVP 31 573 a=rtpmap:31 H261/90000 574 control:rtsp://movie.example.com/action/video 576 The client is now ready to setup the sessions. It includes the key 577 management data in the first message going back to the server (i.e. 578 the SETUP message). 580 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 581 CSeq: 313 582 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 583 keymgmt: prot=mikey; data="skaoqDeMkdwRW278HjKVB..." 585 The server processes the request including checking the validity of 586 the key management header. 588 RTSP/1.0 200 OK 589 CSeq: 313 590 Session: 12345678 591 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 592 server_port=5000-5001 594 The RTSP then proceeds as usual (with e.g. a SETUP message for the 595 video followed by a PLAY message). 597 4. Adding further Key management protocols 599 This framework cannot be used with all key management protocols. The 600 key management protocol needs to comply with the requirements 601 described in Section 3. In addition to this, the following needs to 602 be defined: 604 * The key management protocol identifier to be used as the protocol 605 identifier should be registered at IANA according to Section 6 606 (e.g. "mikey" for MIKEY). 608 * The information that the key management needs from SDP and RTSP, 609 and vice versa, as described in Section 3. The exact API is 610 implementation specific, but it SHOULD at least support to 611 exchange the specified information. 613 * The key management protocol to be added MUST be such, that the 614 processing in Section 3 (describing its interactions with SDP and 615 RTSP) can be applied. Note in particular, Section 3.4 requires 616 each key management protocol to specify how the list of protocol 617 identifiers is authenticated inside that key management protocol. 618 The key management MUST always be given the protocol identifier(s) 619 of the key management protocol(s) included in the offer in the 620 correct order as they appear. 622 Finally, it is obviously crucial to analyze possible security 623 implications induced by the introduction of a new key management 624 protocol in the described framework. 626 5. Security Considerations 628 As a general practice, it is a good thing, not only to try to secure 629 the session, but also to secure the session setup. However, the 630 security of the session setup might not possible on an end-to-end 631 basis, but the setup may require to be protected on a hop-by-hop 632 basis (this is generally the case for SIP/SDP when intermediate 633 proxies needs to obtain information about the sessions etc, c.f. 634 [E2M]). In fact, the focus of this framework is mainly when end-to- 635 end protection of the session setup is not used, but where the media 636 streams needs to be end-to-end protected. General security 637 considerations for the session setup can be found in SDP [SDPnew], 638 SIP [SIP], and RTSP [RTSP]. 640 The security will also depend on the encapsulated level of security 641 the key management protocol offers. It follows that, under the 642 assumption that the key management schemes are secure, the SDP can be 643 passed along unprotected without affecting the key management as 644 such, and the media streams will still be secure even if some 645 attackers gained knowledge of the SDP contents. Further security 646 considerations can be found for each key management protocol (for 647 MIKEY these can be found in [MIKEY]). 649 However, if the SDP messages are not sent authenticated between the 650 parties, it is possible for an active attacker to change attributes 651 without being detected. As the key management protocol may 652 (indirectly) rely on some of the session information from SDP (e.g., 653 address information), an attack on SDP may have indirect consequences 654 on the key management. Even if the key management protocol does not 655 rely on parameters of SDP and will not be affected by manipulation of 656 these, different DoS attacks aimed at SDP (e.g. the SIMCAP 657 extensions) may lead to undesired interruption in the setup. 659 The use of multiple key management protocols in the same offer may 660 open up the possibility of a bidding-down attack, as specified in 661 Section 3.4. To exclude such possibility, the authentication of the 662 protocol identifier list is used. Note though, that the security 663 level of the authenticated protocol identifier will be as high (or 664 low), as the "weakest" protocol. Therefore, it is discouraged to 665 offer protocols with too different security levels. 667 Note that it is impossible to assure the authenticity of a declined 668 offer, since even if it comes from the true respondent, the fact that 669 the answerer declines the offer usually means that he does not 670 support the protocol(s) offered, and consequently cannot be expected 671 to authenticate the response either. This means that if the initiator 672 is unsure of which protocol(s) the responder supports, we RECOMMEND 673 that the initiator offers all acceptable protocols in a single offer. 674 If not, this opens up the possibility for a "man-in-the-middle" 675 (MITM) to affect the outcome of the eventually agreed upon protocol, 676 by faking unauthenticated error messages until the initiator 677 eventually offers a protocol "to the liking" of the MITM. This is not 678 really a security problem, but rather a mild form of denial of 679 service that can be avoided by following the above recommendation. In 680 the case that the response declines any security (therefore there is 681 impossibility of authenticating it), the session setup SHALL be 682 aborted. 684 6. IANA Considerations 686 6.1. SDP Attribute Registration 688 A new SDP attribute needs to be registered for the purpose of key 689 management protocol integration with SDP. 691 Contact: Fredrik Lindholm 692 mailto: fredrik.lindholm@ericsson.com 693 tel: +46 8 58531705 695 SDP Attribute ("att-field"): 697 Name: key-mgmt 698 Long form: key management protocol 699 Type of name: att-field 700 Type of attribute: Media and session level 701 Purpose: See RFC xxxx, Section 2. 702 Reference: RFC xxxx, Section 2.1 703 Values: See Section 6.3 705 6.2. RTSP Header Registration 707 A new RTSP Header needs to be registered for the purpose of key 708 management protocol integration with RTSP. 710 Following the guidelines of [RTSP], the registration is defined as 711 follows: 713 Header name: keymgmt 714 Header syntax: see RFC xxxx, Section 2.2 715 Intended usage: see RFC xxxx, Section 2.2 716 Proxy treatment: Proxies SHOULD forward the header 717 Purpose: see RFC xxxx, Section 2 719 6.3. Protocol Identifier Registration 721 This document defines one new name space associated with the protocol 722 identifier, KMID, defined in Section 2 to be used with the above 723 registered key-mgmt attributes in SDP and RTSP. 725 A new registry needs to be set up for the KMID parameter, with the 726 following registration created initially: "mikey". 728 Contact: Fredrik Lindholm 729 mailto: fredrik.lindholm@ericsson.com 730 tel: +46 8 58531705 732 Value name: mikey 733 Long name: Multimedia Internet KEYing 734 Purpose: Usage of MIKEY with the key-mgmt attribute 735 Reference: Section 7 in RFC yyyy 737 Note that this registration will imply that the protocol identifier, 738 KMID, name space will be shared between SDP and RTSP. 740 Further values may be registered according to the "Specification 741 Required" policy as defined in [RFC2434]. Each new registration needs 742 to indicate the parameter name, and register it within IANA. Note 743 that the parameter name is case sensitive and it is recommended that 744 the name should be in lower case letters. For each new registration, 745 it is mandatory that a permanent, stable, and publicly accessible 746 document exists that specifies the semantics of the registered 747 parameter and the requested details of interaction between the key 748 management protocol and SDP, as specified in RFC xxxx. 750 The registration itself of new values should be sent to IANA. 751 Registrations should include the following information: 752 * Contact: the contact name and email address 753 * Value name: the name of the value being registered (which MUST 754 comply with the KMID as defined in Section 2) 755 * Long Name: long-form name in English (optional) 756 * Purpose: short explanation of the purpose of the registered name. 757 * Reference: a reference to the specification (e.g. RFC number) of 758 the draft providing the usage guidelines in accordance to Section 759 4 (and also complying to the specified requirements). 761 7. Acknowledgments 763 Thanks to: Rolf Blom and Magnus Westerlund. A special thanks to Joerg 764 Ott and Colin Perkins. 766 8. Author's Addresses 768 Jari Arkko 769 Ericsson 770 02420 Jorvas Phone: +358 40 5079256 771 Finland Email: jari.arkko@ericsson.com 773 Elisabetta Carrara 774 Ericsson Research 775 SE-16480 Stockholm Phone: +46 8 50877040 776 Sweden EMail: elisabetta.carrara@ericsson.com 778 Fredrik Lindholm 779 Ericsson Research 780 SE-16480 Stockholm Phone: +46 8 58531705 781 Sweden EMail: fredrik.lindholm@ericsson.com 783 Mats Naslund 784 Ericsson Research 785 SE-16480 Stockholm Phone: +46 8 58533739 786 Sweden EMail: mats.naslund@ericsson.com 788 Karl Norrman 789 Ericsson Research 790 SE-16480 Stockholm Phone: +46 8 4044502 791 Sweden EMail: karl.norrman@ericsson.com 793 9. References 795 9.1. Normative References 797 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 798 the Session Description Protocol (SDP)", IETF, RFC 3264. 800 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 801 Streaming Protocol (RTSP)", IETF, RFC 2326. 803 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 804 Requirement Levels", IETF, RFC 2119. 806 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 807 Description Protocol", Internet Draft, IETF, Work in progress 808 (MMUSIC), draft-ietf-mmusic-sdp-new-13.txt. 810 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 811 "SIP: Session Initiation Protocol", IETF, RFC 3261. 813 [RFC2234] Crocker, D. and Overell, P., "Augmented BNF for Syntax 814 Specifications: ABNF", RFC 2234, November 1997. 816 [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an 817 IANA Considerations Section in RFCs", IETF, RFC 2434. 819 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 820 Encodings", IETF, RFC 3548. 822 9.2. Informative References 824 [E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the 825 Session Initiation Protocol (SIP)", Internet Draft, IETF, Work in 826 Progress. 828 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 829 Service (V5)", IETF, RFC 1510. 831 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 832 Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC yyyy, 833 [Internet Draft, Work in progress (MSEC)]. 835 [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, 836 Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", 837 Internet Draft, IETF, Work in Progress (AVT). 839 Copyright Notice 841 Copyright (C) The Internet Society (2003). All Rights Reserved. 843 This document and translations of it may be copied and furnished to 844 others, and derivative works that comment on or otherwise explain it 845 or assist in its implementation may be prepared, copied, published 846 and distributed, in whole or in part, without restriction of any 847 kind, provided that the above copyright notice and this paragraph are 848 included on all such copies and derivative works. However, this 849 document itself may not be modified in any way, such as by removing 850 the copyright notice or references to the Internet Society or other 851 Internet organizations, except as needed for the purpose of 852 developing Internet standards in which case the procedures for 853 copyrights defined in the Internet Standards process must be 854 followed, or as required to translate it into languages other than 855 English. 857 The limited permissions granted above are perpetual and will not be 858 revoked by the Internet Society or its successors or assigns. 860 This document and the information contained herein is provided on an 861 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 862 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 863 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 864 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 865 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 867 This Internet-Draft expires in April 2004.