idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-08.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 : ---------------------------------------------------------------------------- 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 (August 2003) is 7559 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 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: 6 errors (**), 0 flaws (~~), 3 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: February 2004 M. Naslund 6 K. Norrman 7 Ericsson 8 August 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 the security information needed by a key management protocol, in 42 order to secure the media. These extensions are presented as a 43 framework, to be used by one or more key management protocols. As 44 such, its use is meaningful only when it is completed by the key 45 management protocol 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................................................4 57 3. Usage with SIP and RTSP..........................................5 58 3.1. General SDP processing.........................................5 59 3.2. SIP usage......................................................7 60 3.3. RTSP usage.....................................................8 61 3.4. Example scenarios..............................................9 62 4. Adding further Key management protocols.........................11 63 5. Security Considerations.........................................12 64 6. IANA Considerations.............................................13 65 6.1. SDP Attribute Registration....................................13 66 6.2. Protocol Identifier Registration..............................13 67 8. Acknowledgments.................................................14 68 9. Author's Addresses..............................................14 69 10. References.....................................................15 70 10.1. Normative References.........................................15 71 10.2. Informative References.......................................15 73 1. Introduction 75 [Editor remark] All instances of RFC xxxx should be replaced with 76 the RFC number of this document, when published. Furthermore, all 77 instances of RFC yyyy should be replaced with the RFC number of 78 the MIKEY (Multimedia Internet KEYing) document [MIKEY], when 79 published. 81 There has recently been work to define a security framework for the 82 protection of real-time applications running over RTP, [SRTP]. 83 However, a security protocol needs a key management infrastructure to 84 exchange keys and security parameters, manage and refresh keys, etc. 86 A key management protocol is executed prior to the security protocol 87 execution. The key management protocol's main goal is to, in a secure 88 and reliable way, establish a security association for the security 89 protocol. This includes one or more cryptographic keys and the set of 90 necessary parameters for the security protocol, e.g., cipher and 91 authentication algorithm to be used. The key management protocol has 92 similarities with, e.g., SIP [SIP] and RTSP [RTSP] in the sense that 93 it negotiates necessary information in order to be able to setup the 94 session. 96 The focus in the following sections is to describe a new SDP 97 attribute and RTSP header extension to support key management, and 98 the integration within SIP and RTSP. A framework is therefore 99 described in the following. This framework is completed by one or 100 more key management protocols, to describe how the framework is used, 101 e.g. which is the data to be carried in the extensions. 103 Some of the motivations to create a framework with the possibility to 104 include the key management in the session establishment are: 106 * Just as the codec information is a description of how to encode and 107 decode the audio (or video) stream, the key management data is a 108 description of how to encrypt and decrypt the data. 110 * The possibility to negotiate the security for the entire multimedia 111 session at the same time. 113 * The knowledge of the media at the session establishment makes it 114 easy to tie the key management to the multimedia sessions. 116 * This approach may be more efficient than setting up the security 117 later, as that approach might force extra roundtrips, possibly 118 also a separate set-up for each stream, hence implying more delay 119 to the actual setup of the media session. 121 * The possibility to negotiate keying material end-to-end without 122 applying end-to-end protection of the SDP (instead, hop-by-hop 123 security mechanisms can be used which may be useful if 124 intermediate proxies needs access to the SDP). 126 Currently in SDP [SDPnew], one field exists to transport keys, i.e. 127 the "k=" field. However, this is not enough for a key management 128 protocol as there are many more parameters that need to be 129 transported. The approach here is to use and extend the SDP 130 description to transport the key management offer/answer and also to 131 associate it with the media sessions. SIP uses the offer/answer model 132 [OAM] whereby extensions to SDP will be enough. However, RTSP 133 [RTSP]does not use the offer/answer model with SDP, so a new header 134 is introduced to convey key management data. 136 1.1. Notational Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Extensions to SDP and RTSP 144 This section describes common attributes that are to be included in 145 an SDP description or in an RTSP header when an integrated key 146 management protocol is used. The attribute values MUST follow the 147 general SDP or RTSP guidelines (see [SDPnew] and [RTSP]). 149 For both SDP and RTSP, the general method of adding the key 150 management protocol is to introduce new attributes, one identifier to 151 identify the specific key management protocol, and one data field 152 where the key management protocol data is placed. The key management 153 protocol data contains the necessary information to establish the 154 security protocol, e.g., keys and cryptographic parameters. All 155 parameters and keys are protected by the key management. 157 2.1. SDP Extensions 159 This section provides an Augmented Backus-Naur Form (ABNF) grammar 160 (as used in [SDPnew]) for the key management extensions to SDP. 162 Note that the new definitions are compliant with the definition of an 163 attribute field, i.e. 165 attribute = (att-field ":" att-value) | att-field 167 One new attribute for SDP is defined: 169 key-mgmt = "key-mgmt: " prtcl-id keymgmt-data 171 prtcl-id = non-ws-string 172 ; e.g. "mikey" 174 keymgmt-data = text 176 where non-ws-string and text are as defined in SDP [SDPnew]. The 177 attribute may be used at session level, media level, or at both 178 levels. An attribute defined at media level overrides an attribute 179 defined at session level. Note that the prtcl-id name will be case 180 sensitive and it is therefore RECOMMENDED that attributes registered 181 are in lower case letters. Section 3 describes in detail how the 182 attributes are used and how the SDP is handled in different usage 183 scenarios. 185 2.2. RTSP Extensions 187 To support the needed attribute, the following RTSP header is 188 defined: 190 KeyMgmt = "keymgmt" ":" 1#key-mgmt-spec 192 key-mgmt-spec = "prot" "=" token ";" "data" "=" quoted-string 193 "token" and "quoted-string" are as defined in the RTSP specification 194 [RTSP]. 196 The KeyMgmt header should be possible to use in the messages 197 described in the table below. 199 Method Direction Requirement 200 DESCRIBE C->S required 201 SETUP C->S required 202 ANNOUNCE C->S, S->C optional (required: if re-key is supported) 204 Note: Section 3 describes in detail how the RTSP extensions are used. 206 3. Usage with SIP and RTSP 208 This section gives recommendations of how/when to include the defined 209 key management attribute when SIP and/or RTSP are used together with 210 SDP. 212 When a key management protocol is integrated with SIP/SDP and RTSP, 213 the following requirements are placed on the key management: 215 * It MUST be possible to execute the key management protocol in at 216 most one roundtrip in case the answerer accepts the offer. 218 * It MUST be possible from the SIP/SDP and RTSP application, using 219 the key management API, to receive key management data, and 220 information of whether a message is accepted or not. 222 Today, the MIKEY protocol [MIKEY] has adopted the key management 223 extensions to work together with SIP and RTSP. Other protocols MAY 224 use the described attribute and header, e.g. Kerberos [KERB]. 226 3.1. General SDP processing 228 When an SDP message is created, the following procedure should be 229 applied: 231 * The identifier of the key management protocol used (e.g. MIKEY or 232 Kerberos) MUST be placed in the prtcl-id field. 234 * The keymgmt-data field MUST be created as follows. The key 235 management protocol MUST be used to create the key management 236 message. This message SHALL be base64 encoded [RFC3548] by the SDP 237 application and then encapsulated in the keymgmt-data attribute. 238 The data may e.g. be a MIKEY message (see [MIKEY], Section 7) or 239 Kerberos ticket. 241 A received SDP message that contains the key management attributes 242 SHOULD be processed in the following manner: 244 * The key management protocol is identified according to the prtcl-id 245 field. 247 * The key management data from the keymgmt-data field MUST be 248 extracted, base64 decoded to reconstruct the original message, and 249 then passed to the key management protocol. Note that depending on 250 key management protocol, some extra parameters might of course be 251 requested by the specific API, such as the source/destination 252 network address/port(s) for the specified media (however, this 253 will be implementation specific depending on the actual API). 255 * Depending on the outcome of the key management processing (i.e. 256 whether it was successful or not), the processing can proceed 257 according to normal rules (e.g. according to the offer/answer 258 model, see also Section 3.2). 260 Note that the key management attribute MAY be repeated more than once 261 (e.g., one at session level and one at media level). Consequently, 262 the process is repeated for each key management attribute detected. 263 However, in case of failure of the key management (on either session 264 or media level), the session setup SHALL be aborted (see also Section 265 3.2 and Section 3.3 for more details). 267 If more than one key management protocol is supported, multiple 268 instances of the key management attribute MAY be included in the 269 initial offer, each transporting a different key management data, 270 thus indicating supported alternatives. 272 If the sender includes more than one key management protocol 273 attribute at session level (analogous for the media level), these 274 SHOULD be listed in order of preference (the first being the 275 preferred). The receiver selects the key management protocol it 276 wishes to use and includes only that attribute in the answer. If the 277 receiver does not support any of the sender's suggested key 278 management protocols, the receiver returns an error message (see 279 section 3.2 and section 3.3), whereby the sender MUST abort the 280 current setup procedure. 282 Note that the placement of multiple key management offers in a single 283 message has the disadvantage that the message expands and the 284 computational workload for the offerer will increase drastically. 286 The possibility to support multiple key management protocols may 287 introduce bidding down attacks. To avoid this, the list of 288 identifiers of the proposed key management protocols MUST be 289 authenticated. The authentication MUST be done separately by each key 290 management protocol (see e.g. Section 7.1 in [MIKEY]). 292 Accordingly, it MUST be specified (in the key management protocol 293 specification itself or in a companion document) how the list of key 294 management protocol identifiers can be authenticated from the offerer 295 to the answerer by the specific key management protocol. Note that 296 even if only one key management protocol is used, that still MUST 297 authenticate its own protocol identifier. 299 The list of protocol identifiers MUST be given to the selected key 300 management protocol by the SDP application with ";" separated 301 identifiers. All the offered protocol identifiers MUST be included, 302 in the same order as they appear in the corresponding SDP 303 description. 305 The protocol list can formally be described as 307 prtcl-list = prtcl-id *(";" prtcl-id) 309 prtcl-id = non-ws-string 311 For example, if the SDP is: 313 v=0 314 o=alice 2891092738 2891092738 IN IP4 lost.example.com 315 s=Secret discussion 316 t=0 0 317 c=IN IP4 lost.example.com 318 a=key-mgmt:mikey 319 a=key-mgmt:keyp1 320 a=key-mgmt:keyp2 321 m=audio 39000 RTP/SAVP 98 322 a=rtpmap:98 AMR/8000 323 m=video 42000 RTP/SAVP 31 324 a=rtpmap:31 H261/90000 326 The protocol list, "mikey;keyp1;keyp2", would be generated from 327 the SDP description and used as input to each specified key 328 management protocol (together with the data for that protocol). 330 If more than one protocol is supported by the offerer, it is 331 RECOMMENDED that all acceptable protocols are included in the first 332 offer, rather than making single, subsequent alternative offers in 333 response to error messages, see "Security Considerations". 335 3.2. SIP usage 337 When used with SIP and the offer/answer model, the offerer SHOULD 338 include the key management data within an offer that contains the 339 media description it should apply to. The answerer MUST check with 340 the key management protocol if the attribute values are valid, and 341 then obtain from the key management the data to include in the 342 answer. 344 If the offer is not accepted, the answerer SHOULD return a "606 Not 345 Acceptable" message, including one or more Warning headers (at least 346 a 306 "Attribute not understood"). The session is then aborted (and 347 it is up to local policy or end user to decide how to continue). 349 Re-keying can be handled as a new offer, i.e. a re-INVITE should be 350 sent with the new proposed parameters. The answerer treats this as a 351 new offer where the key management is the issue of change. In 352 general, the re-INVITE (and the key exchange) must be finalized 353 before the security protocol can change the keys. The same key 354 management protocol used in the original INVITE SHALL also be used in 355 the re-INVITE carrying re-keying. If the re-INVITE carrying re-keying 356 fails (e.g., the authentication verification fails), the answerer 357 SHOULD send a "606 Not Acceptable" message, including one or more 358 Warning headers (at least a 306). The offer MUST then abort the 359 security setup. 361 3.3. RTSP usage 363 RTSP does not use the offer/answer model, as SIP does. This causes 364 some problems, as it is not possible (without abusing RTSP) to send 365 back an answer to the server (as the server will in most cases be the 366 one initiating the security parameter exchange). To solve this, a new 367 header has been introduced (Section 2.2). This also assumes that the 368 key management also has some kind of binding to the media, so that 369 the response to the server will be processed as required. 371 The initial key management message from a server should be sent to 372 the client using SDP. When responding to this, the client uses the 373 new RTSP header to send back an answer (included in the SETUP 374 message). If a server receives a SETUP message in which it expects a 375 key management message, but none is included, a 403 Forbidden SHOULD 376 be returned to the client, whereby the current setup MUST be aborted. 378 The processing of creating a key management header in RTSP SHOULD be 379 as follow: 381 * The identifier of the key management protocol used (e.g. MIKEY or 382 Kerberos) MUST be placed in the "prot" field of the header. 384 * The keymgmt-data field MUST be created as follows. The key 385 management protocol MUST be used to create the key management 386 message. This message SHALL be base64 encoded by the SDP 387 application and then encapsulated in the "data" field of the 388 header. The data may e.g. be a MIKEY message (see [MIKEY], Section 389 7) or Kerberos ticket. 391 A received key management header SHOULD be processed in the following 392 manner: 394 * The key management protocol is identified according to the "prot" 395 field. 397 * The key management data from the "data" field MUST be extracted, 398 base64 decoded to reconstruct the original message, and then 399 passed to the key management protocol. Note that depending on the 400 key management protocol, some extra parameters might of course be 401 requested by the specific API, such as the source/destination 402 network address/port(s) for the specified media (however, this 403 will be implementation specific depending on the actual API). 405 * Depending on the outcome of the key management processing (i.e. 406 whether it was successful or not), the processing can proceed 407 according to normal rules (see also below). 409 The server MAY provide re-keying/updating facilities by sending a new 410 key management message in an ANNOUNCE messages. The ANNOUNCE message 411 contains an SDP message including the key management parameters. The 412 response message is put in the new RTSP header in the response from 413 the client to the server. Note that the ANNOUNCE messages MUST be 414 supported if this feature is to be used. 416 3.4. Example scenarios 418 Example 1 (SIP) 420 A SIP call is taking place between Alice and Bob. Alice sends an 421 Invite message consisting of the following offer: 423 v=0 424 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 425 s=Cool stuff 426 e=alice@w-land.example.com 427 t=0 0 428 c=IN IP4 w-land.example.com 429 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 430 m=audio 49000 RTP/SAVP 98 431 a=rtpmap:98 AMR/8000 432 m=video 52230 RTP/SAVP 31 433 a=rtpmap:31 H261/90000 435 i.e. Alice proposes to set up one audio stream and one video stream 436 that run over SRTP. To set up the security parameters for SRTP, she 437 uses MIKEY. Note that MIKEY is negotiating the crypto suite for both 438 streams (as it is placed at the session level). 440 Bob accepts the offer and sends an answer back to Alice: 442 v=0 443 o=bob 2891092897 2891092897 IN IP4 foo.example.com 444 s=Cool stuff 445 e=bob@foo.example.com 446 t=0 0 447 c=IN IP4 foo.example.com 448 a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... 449 m=audio 49030 RTP/SAVP 98 450 a=rtpmap:98 AMR/8000 451 m=video 52230 RTP/SAVP 31 452 a=rtpmap:31 H261/90000 454 Example 2 (SDP) 456 This example shows how Alice would have done if she wished to protect 457 only the audio stream. 459 v=0 460 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 461 s=Cool stuff 462 e=alice@w-land.example.com 463 t=0 0 464 c=IN IP4 w-land.example.com 465 m=audio 49000 RTP/SAVP 98 466 a=rtpmap:98 AMR/8000 467 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 468 m=video 52230 RTP/AVP 31 469 a=rtpmap:31 H261/90000 471 Note that even if the key management attribute were specified at 472 session level, the video part would not be affected by this (as a 473 security profile is not used). 475 Example 3 (RTSP) 477 A client wants to set up a streaming session and requests a media 478 description from the streaming server. 480 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 481 CSeq: 312 482 Accept: application/sdp 483 From: user@example.com 485 The server sends back an OK message including an SDP description. 487 RTSP/1.0 200 OK 488 CSeq: 312 489 Date: 23 Jan 1997 15:35:06 GMT 490 Content-Type: application/sdp 491 v=0 492 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 493 s=Action Movie 494 e=action@movie.example.com 495 t=0 0 496 c=IN IP4 movie.example.com 497 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 498 m=audio 0 RTP/SAVP 98 499 a=rtpmap:98 AMR/8000 500 control:rtsp://movie.example.com/action/audio 501 m=video 0 RTP/SAVP 31 502 a=rtpmap:31 H261/90000 503 control:rtsp://movie.example.com/action/video 505 The client is now ready to setup the sessions. It includes the key 506 management data in the first message going back to the server (i.e. 507 the SETUP message). 509 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 510 CSeq: 313 511 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 512 keymgmt: prot=mikey; data="skaoqDeMkdwRW278HjKVB..." 514 The server processes the request including checking the validity of 515 the key management header. 517 RTSP/1.0 200 OK 518 CSeq: 313 519 Session: 12345678 520 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 521 server_port=5000-5001 523 The RTSP then proceeds as usual (with e.g. a SETUP message for the 524 video followed by a PLAY message). 526 4. Adding further Key management protocols 528 This framework cannot be used with all key management protocols. The 529 key management protocol needs to comply with the requirements 530 described in Section 3. To be able to use a key management protocol 531 with this framework, the following MUST be specified: 533 * the key management protocol identifier that should be used in the 534 protocol identifier fields in both SDP and RTSP (e.g. "mikey" for 535 MIKEY). 537 * the information the key management needs from SDP and RTSP (Section 538 3 gives a guideline of what SDP and RTSP needs from the key 539 management). The exact API is implementation specific, but it 540 SHOULD at least support to exchange the specified information. 542 Note that in particular, the key management MUST always be given 543 the protocol identifier(s) of the key management protocol(s) 544 included in the offer in the correct order as they appear. 546 The key management data MUST be base64 encoded in the SDP and RTSP 547 fields. Therefore, considerations of possible conversion from the 548 normal key management representation to base64 SHOULD be taken into 549 account. 551 5. Security Considerations 553 The nature of this document is to allow SDP and RTSP to support 554 negotiation of the security of the media sessions. It is therefore 555 not a primary intention of this document to describe possible 556 security solutions or to define possible security problems. The 557 defined SDP and RTSP extensions are not believed to introduce any new 558 security risks to SDP and RTSP, if used as specified. 560 Note that the purpose of the key management fields is to provide 561 information to secure the media streams. Under the assumption that 562 the key management schemes are secure, the SDP can be passed along 563 unprotected without affecting the key management, and the media 564 streams will still be secure even if some attackers gained knowledge 565 of the SDP contents. 567 However, if the SDP messages are not sent authenticated between the 568 parties, it is possible for an active attacker to change attributes 569 without being detected. As the key management protocol may 570 (indirectly) rely on some of the session information from SDP (e.g., 571 address information), an attack on SDP may have indirect consequences 572 on the key management. Even if the key management protocol does not 573 rely on parameters of SDP and will not be affected by manipulation of 574 these, different DoS attacks aimed at SDP (e.g. the SIMCAP 575 extensions) may lead to undesired interruption in the setup. 577 In general, it is therefore a good thing, not only to try to secure 578 the session, but also to secure the session setup. However, the 579 security of the session setup might not possible on an end-to-end 580 basis, but may require to be protected on a hop-by-hop basis (this is 581 generally the case for SIP/SDP when intermediate proxies needs to 582 obtain information about the sessions etc). In fact, the focus of 583 this framework is mainly when end-to-end protection of the session 584 setup is not used, but where the media streams needs to be end-to-end 585 protected. 587 Note that it is impossible to assure the authenticity of a declined 588 offer, since even if it comes from the true respondent, the fact that 589 the answerer declines the offer usually means that he does not 590 support the protocol(s) offered, and consequently cannot be expected 591 to authenticate the response either. This means that if the initiator 592 is unsure of which protocol(s) the responder supports, we RECOMMEND 593 that the initiator offers all acceptable protocols in a single offer. 594 If not, this opens up the possibility for a "man-in-the-middle" 595 (MITM) to affect the outcome of the eventually agreed upon protocol, 596 by faking unauthenticated error messages until the initiator 597 eventually offers a protocol "to the liking" of the MITM. This is not 598 really a security problem, but rather a mild form of denial of 599 service that can be avoided by following the above recommendation. 601 6. IANA Considerations 603 6.1. SDP Attribute Registration 605 A new SDP attribute needs to be registered for the purpose of key 606 management protocol integration with SDP. 608 Contact: Fredrik Lindholm 609 mailto: fredrik.lindholm@ericsson.com 610 tel: +46 8 58531705 612 SDP Attribute ("att-field"): 614 Name: key-mgmt 615 Long form: key management protocol 616 Type of name: att-field 617 Type of attribute: Media and session level 618 Purpose: See RFC xxxx, Section 2. 619 Reference: RFC xxxx, Section 2.1 620 Values: See registrations below 622 6.2. Protocol Identifier Registration 624 This document defines one new name space associated with the above 625 registered key-mgmt attribute i.e., the protocol identifier (see also 626 Section 2.1 and Section 2.2). 628 A new registry needs to be set up for "prtcl-id" parameter of the 629 "key-mgmt" attribute, with the following registration created 630 initially: "mikey". 632 Contact: Fredrik Lindholm 633 mailto: fredrik.lindholm@ericsson.com 634 tel: +46 8 58531705 636 Value name: mikey 637 Long name: Multimedia Internet KEYing 638 Purpose: Usage of MIKEY with the key-mgmt attribute 639 Reference: Section 7 in RFC yyyy 641 Further entries may be registered according to the "Specification 642 Required" policy as defined in [RFC2434]. Each new registration needs 643 to indicate the parameter name and the syntax of possible additional 644 arguments. Note that the parameter name is case sensitive and it is 645 recommended that the name should be in lower case letters. For each 646 new registration, it is mandatory that a permanent, stable, and 647 publicly accessible document exists that specifies the semantics of 648 the registered parameter, the syntax and semantics of its parameters 649 as well as all the requested details of interaction between the key 650 management protocol and SDP, as specified in this document. 652 8. Acknowledgments 654 Thanks to: Rolf Blom, Magnus Westerlund, and the rest involved in the 655 MMUSIC WG and the MSEC WG. 657 A special thanks to Joerg Ott and Colin Perkins. 659 9. Author's Addresses 661 Jari Arkko 662 Ericsson 663 02420 Jorvas Phone: +358 40 5079256 664 Finland Email: jari.arkko@ericsson.com 666 Elisabetta Carrara 667 Ericsson Research 668 SE-16480 Stockholm Phone: +46 8 50877040 669 Sweden EMail: elisabetta.carrara@ericsson.com 671 Fredrik Lindholm 672 Ericsson Research 673 SE-16480 Stockholm Phone: +46 8 58531705 674 Sweden EMail: fredrik.lindholm@ericsson.com 676 Mats Naslund 677 Ericsson Research 678 SE-16480 Stockholm Phone: +46 8 58533739 679 Sweden EMail: mats.naslund@ericsson.com 681 Karl Norrman 682 Ericsson Research 683 SE-16480 Stockholm Phone: +46 8 4044502 684 Sweden EMail: karl.norrman@ericsson.com 686 10. References 688 10.1. Normative References 690 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 691 the Session Description Protocol (SDP)", IETF, RFC 3264. 693 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 694 Streaming Protocol (RTSP)", IETF, RFC 2326. 696 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 697 Requirement Levels", IETF, RFC 2119. 699 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 700 Description Protocol", Internet Draft, IETF, Work in progress 701 (MMUSIC), draft-ietf-mmusic-sdp-new-13.txt. 703 [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 704 "SIP: Session Initiation Protocol", IETF, RFC 3261. 706 [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an 707 IANA Considerations Section in RFCs", IETF, RFC 2434. 709 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 710 Encodings", IETF, RFC 3548. 712 10.2. Informative References 714 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 715 Service (V5)", IETF, RFC 1510. 717 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 718 Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC yyyy, 719 [Internet Draft, Work in progress (MSEC)]. 721 [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, 722 Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", 723 Internet Draft, IETF, Work in Progress (AVT). 725 Copyright Notice 727 Copyright (C) The Internet Society (2003). All Rights Reserved. 729 This document and translations of it may be copied and furnished to 730 others, and derivative works that comment on or otherwise explain it 731 or assist in its implementation may be prepared, copied, published 732 and distributed, in whole or in part, without restriction of any 733 kind, provided that the above copyright notice and this paragraph are 734 included on all such copies and derivative works. However, this 735 document itself may not be modified in any way, such as by removing 736 the copyright notice or references to the Internet Society or other 737 Internet organizations, except as needed for the purpose of 738 developing Internet standards in which case the procedures for 739 copyrights defined in the Internet Standards process must be 740 followed, or as required to translate it into languages other than 741 English. 743 The limited permissions granted above are perpetual and will not be 744 revoked by the Internet Society or its successors or assigns. 746 This document and the information contained herein is provided on an 747 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 748 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 749 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 750 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 751 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 753 This Internet-Draft expires in February 2004.