idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1326. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1332), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 (June 2005) is 6883 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) == Missing Reference: 'RFC3261' is mentioned on line 421, but not defined ** Obsolete normative reference: RFC 2326 (ref. 'RTSP') (Obsoleted by RFC 7826) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-15 ** 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) == Outdated reference: A later version (-04) exists of draft-ono-sipping-end2middle-security-03 -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KERB') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 MMUSIC Working Group E. Carrara 4 INTERNET-DRAFT F. Lindholm 5 Expires: December 2005 M. Naslund 6 K. Norrman 7 Ericsson 8 June 2005 10 Key Management Extensions for Session Description 11 Protocol (SDP) and Real Time Streaming Protocol (RTSP) 12 14 Status of this memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 This document defines general extensions for SDP and RTSP to carry 43 messages, as specified by a key management protocol, in order to 44 secure the media. These extensions are presented as a framework, to 45 be used by one or more key management protocols. As such, their use 46 is meaningful only when complemented by an appropriate key management 47 protocol. 49 General guidelines are also given on how the framework should be used 50 together with SIP and RTSP. The usage with the MIKEY key management 51 protocol is also defined. 53 TABLE OF CONTENTS 55 1. Introduction.....................................................2 56 1.1. Notational Conventions.........................................4 57 2. Applicability....................................................4 58 3. Extensions to SDP and RTSP.......................................4 59 3.1. SDP Extensions.................................................5 60 3.2. RTSP Extensions................................................5 61 4. Usage with SDP, SIP, RTSP, and SAP...............................6 62 4.1. Use of SDP.....................................................7 63 4.1.1 General processing............................................7 64 4.1.2 Use of SDP with offer/answer and SIP..........................9 65 4.1.3 Use of SDP with SAP..........................................12 66 4.1.4 Bidding-down attack prevention...............................12 67 4.2. RTSP usage....................................................13 68 5. Example scenarios...............................................15 69 6. Adding further Key management protocols.........................19 70 7. Integration of MIKEY............................................20 71 7.1 MIKEY Interface................................................21 72 8. Security Considerations.........................................22 73 9. IANA Considerations.............................................23 74 9.1. SDP Attribute Registration....................................23 75 9.2. RTSP Registration.............................................24 76 9.3. Protocol Identifier Registration..............................24 77 10. Acknowledgments................................................25 78 11. Author's Addresses.............................................25 79 12. References.....................................................26 80 12.1. Normative References.........................................26 81 12.2. Informative References.......................................26 83 1. Introduction 85 [RFC Editor remark] All instances of RFC xxxx should be replaced 86 with the RFC number of this document, when published. 88 There has recently been work to define a security profile for the 89 protection of real-time applications running over RTP, [SRTP]. 90 However, a security protocol needs a key management solution to 91 exchange keys and security parameters, manage and refresh keys, etc. 93 A key management protocol is executed prior to the security 94 protocol's execution. The key management protocol's main goal is to, 95 in a secure and reliable way, establish a security association for 96 the security protocol. This includes one or more cryptographic keys 97 and the set of necessary parameters for the security protocol, e.g., 98 cipher and authentication algorithms to be used. The key management 99 protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in 100 the sense that it negotiates necessary information in order to be 101 able to setup the session. 103 The focus in the following sections is to describe a new SDP 104 attribute and RTSP header extension to support key management, and to 105 show how these can be integrated within SIP and RTSP. The resulting 106 framework is completed by one or more key management protocols, which 107 use the extensions provided. 109 Some of the motivations to create a framework with the possibility to 110 include the key management in the session establishment are: 112 * Just as the codec information is a description of how to encode and 113 decode the audio (or video) stream, the key management data is a 114 description of how to encrypt and decrypt the data. 116 * The possibility to negotiate the security for the entire multimedia 117 session at the same time. 119 * The knowledge of the media at session establishment makes it easy 120 to tie the key management to the multimedia sessions. 122 * This approach may be more efficient than setting up the security 123 later, as that approach might force extra roundtrips, possibly 124 also a separate set-up for each stream, hence implying more delay 125 to the actual setup of the media session. 127 * The possibility to negotiate keying material end-to-end without 128 applying end-to-end protection of the SDP (instead, hop-by-hop 129 security mechanisms can be used which may be useful if 130 intermediate proxies needs access to the SDP). 132 Currently in SDP [SDPnew], there exists one field to transport keys, 133 the "k=" field. However, this is not enough for a key management 134 protocol as there are many more parameters that need to be 135 transported, and the "k=" field is not extensible. The approach used 136 is to extend the SDP description through a number of attributes that 137 transport the key management offer/answer and also to associate it 138 with the media sessions. SIP uses the offer/answer model [OAM] 139 whereby extensions to SDP will be enough. However, RTSP [RTSP] does 140 not use the offer/answer model with SDP, so a new RTSP header is 141 introduced to convey key management data. [SDES] uses the approach of 142 extending SDP, to carry the security parameters for the media 143 streams. However, the mechanism defined in [SDES] requires end-to-end 144 protection of the SDP by some security protocol such as S/MIME, in 145 order to get end-to-end protection. The solution described here 146 focuses only on the end-to-end protection of key management 147 parameters and as a consequence does not require external end-to-end 148 protection means. It is important to note though, and we stress this 149 again, that only the key management parameters are protected. 151 The document also defines the use of the described framework together 152 with the key management protocol Multimedia Internet KEYing (MIKEY) 153 [MIKEY]. 155 1.1. Notational Conventions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 2. Applicability 163 [SDES] provides similar cryptographic key distribution capabilities, 164 and it intended for use when keying material is protected along with 165 the signaling. 167 In contrast, this specification expects endpoints to have 168 preconfigured keys or common security infrastructure. It provides its 169 own security, and is independent of the protection of signaling (if 170 any). As a result, it can be applied in environments where signaling 171 protection is not turned on, or used hop-by-hop (i.e., scenarios 172 where the SDP is not protected end-to-end). This specification will 173 independently of the signaling protection applied, ensure end-to-end 174 security establishment for the media. 176 3. Extensions to SDP and RTSP 178 This section describes common attributes that can be included in SDP 179 or RTSP when an integrated key management protocol is used. The 180 attribute values follow the general SDP and RTSP guidelines (see 181 [SDPnew] and [RTSP]). 183 For both SDP and RTSP, the general method of adding the key 184 management protocol is to introduce new attributes, one identifier to 185 identify the specific key management protocol, and one data field 186 where the key management protocol data is placed. The key management 187 protocol data contains the necessary information to establish the 188 security protocol, e.g., keys and cryptographic parameters. All 189 parameters and keys are protected by the key management protocol. 191 The key management data SHALL be base64 [RFC3548] encoded and comply 192 with the base64 grammar as defined in [SDPnew]. The key management 193 protocol identifier, KMPID, is defined as below in Augmented Backus- 194 Naur Form grammar (ABNF) [RFC2234]. 196 KMPID = 1*(ALPHA / DIGIT) 198 Values for the identifier, KMPID, are registered and defined in 199 accordance to Section 8. Note that the KMPID is case sensitive and it 200 is RECOMMENDED that values registered are lower case letters. 202 3.1. SDP Extensions 204 This section provides an ABNF grammar (as used in [SDPnew]) for the 205 key management extensions to SDP. 207 Note that the new definitions are compliant with the definition of an 208 attribute field, i.e. 210 attribute = (att-field ":" att-value) | att-field 212 The ABNF for the key management extensions (conforming to the att- 213 field and att-value) are as follow: 215 key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value 217 key-mgmt-att-field = "key-mgmt" 218 key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data 220 prtcl-id = KMPID 221 ; e.g. "mikey" 223 keymgmt-data = base64 224 SP = 0x20 226 where KMPID is as defined in Section 2 of this memo, base64 is as 227 defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined 228 for KMPID in Section 8. 230 The attribute MAY be used at session level, media level, or at both 231 levels. An attribute defined at media level overrides an attribute 232 defined at session level. In other words, if the media level 233 attribute is present, the session level attribute MUST be ignored for 234 this media. Section 3.1 describes in detail how the attributes are 235 used and how the SDP is handled in different usage scenarios. The 236 choice of the level depends for example on the particular key 237 management protocol. Some protocols may not be able to derive enough 238 key material for all the sessions; furthermore, possibly a different 239 protection to each session could be required. The particular protocol 240 might achieve this only by specifying it at the media level. Other 241 protocols, such as MIKEY, have instead those capabilities (as it can 242 express multiple security policies and derive multiple keys), so it 243 may use the session level. 245 3.2. RTSP Extensions 246 To support the key management attributes, the following RTSP header 247 is defined: 249 KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) 251 key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" <"> rtsp_URL <"> ";"] 252 "data" "=" base64 254 where KMPID is as defined in Section 2 of this memo, "base64" as 255 defined in [SDPnew], and "rtsp_URL" as defined in [RTSP]. 257 The "uri" parameter identifies the context for which the key 258 management data applies, and the RTSP URI SHALL match a (session or 259 media) URI present in the description of the session. If the RTSP 260 aggregated control URI is included it indicates that the key 261 management message is on session level (and similarly the RTSP media 262 control URI, that it applies to the media level). If no "uri" 263 parameter is present in a key-mgmt-spec the specification applies to 264 the context identified by the RTSP request URI. 266 The KeyMgmt header MAY be used in the messages and directions 267 described in the table below. 269 Method | Direction | Requirement 270 --------------------------------------------- 271 DESCRIBE response | S->C | RECOMMENDED 272 SETUP | C->S | REQUIRED 273 SETUP Response | S->C | REQUIRED (error) 275 Note: Section 3.2 describes in detail how the RTSP extensions are 276 used. 278 We define one new RTSP status code to report error due to any failure 279 during the key management processing (Section 3.2): 281 Status-Code = "463" ; Key management failure 283 A 463 response MAY contain a KeyMgmt header with a key management 284 protocol message that further indicates the nature of the error. 286 4. Usage with SDP, SIP, RTSP, and SAP 288 This section gives rules and recommendations of how/when to include 289 the defined key management attribute when SIP and/or RTSP are used 290 together with SDP. 292 When a key management protocol is integrated with SIP/SDP and RTSP, 293 the following general requirements are placed on the key management: 295 * At the current time, it MUST be possible to execute the key 296 management protocol in at most one request-response message 297 exchange. Future relaxation of this requirement is possible but 298 would introduce significant complexity for implementations 299 supporting multi-roundtrip mechanisms. 301 * It MUST be possible from the SIP/SDP and RTSP application, using 302 the key management API, to receive key management data, and 303 information of whether a message is accepted or not. 305 The content of the key management messages depends on the key 306 management protocol that is used. However, the content of such key 307 management messages might be expected to be roughly as follow: the 308 key management Initiator (e.g. the offerer) includes the key 309 management data in a first message, containing the media description 310 it should apply to. This data in general consists of the security 311 parameters (including key material) needed to secure the 312 communication, together with the necessary authentication information 313 (to assure that the message is authentic). 315 At the Responder's side, the key management protocol checks the 316 validity of the key management message, together with the 317 availability of the parameters offered, and then provides the key 318 management data to be included in the answer. This answer may 319 typically authenticate the Responder to the Initiator, and also state 320 if the initial offer was accepted or not. Certain protocols might 321 require the Responder to include a selection of the security 322 parameters that he is willing to support. Again, the actual content 323 of such responses is dependent on the particular key management 324 protocol. 326 Section 6 describes a realization of the MIKEY protocol using these 327 mechanisms. Procedures to be used when mapping new key management 328 protocols onto this framework are described in Section 5. 330 4.1. Use of SDP 332 This section describes the processing rules for the different 333 applications which use SDP for the key management. 335 4.1.1 General processing 337 The processing when SDP is used is slightly different according to 338 the way SDP is transported, and if it uses an offer/answer or 339 announcement. The processing can be divided into four different 340 steps: 342 1) How to create the initial offer. 344 2) How to handle a received offer. 345 3) How to create an answer. 346 4) How to handle a received answer. 348 It should be noted that the last two steps may not always be 349 applicable, as there are cases where an answer can not or will not be 350 sent back. 352 The general processing for creating an initial offer SHALL follow the 353 following actions: 355 * The identifier of the key management protocol used MUST be placed 356 in the prtcl-id field of SDP. A table of legal protocols 357 identifiers is maintained by IANA (see Section 8). 359 * The keymgmt-data field MUST be created as follows: the key 360 management protocol MUST be used to create the key management 361 message. This message SHALL be base64 encoded [RFC3548] by the SDP 362 application and then encapsulated in the keymgmt-data attribute. 363 Note though that the semantics of the encapsulated message is 364 dependent on the key management protocol that is used. 366 The general processing for handling a received offer SHALL follow the 367 following actions: 369 * The key management protocol is identified according to the prtcl-id 370 field. A table of legal protocols identifiers is maintained by 371 IANA (Section 8). 373 * The key management data from the keymgmt-data field MUST be 374 extracted, base64 decoded to reconstruct the original message, and 375 then passed to the key management protocol for processing. Note 376 that depending on key management protocol, some extra parameters 377 might also be requested by the specific API, such as the 378 source/destination network address/port(s) for the specified media 379 (however, this will be implementation specific depending on the 380 actual API). The extra parameters that a key management protocol 381 might need (other than the ones defined here) MUST be documented, 382 describing their use, as well as the interaction of that key 383 management protocol with SDP and RTSP. 385 * If errors occur, or the key management offer is rejected, the 386 session SHALL be aborted. Possible error messages are dependent 387 on the specific session establishment protocol. 389 At this stage, the key management will have either accepted or 390 rejected the offered parameters. This MAY cause a response message to 391 be generated, depending on the key management protocol and the 392 application scenario. 394 If an answer is to be generated, the following general actions SHALL 395 be performed: 397 * The identifier of the key management protocol used MUST be placed 398 in the prtcl-id field. 400 * The keymgmt-data field MUST be created as follows. The key 401 management protocol MUST be used to create the key management 402 message. This message SHALL be base64 encoded [RFC3548] by the SDP 403 application and then encapsulated in the keymgmt-data attribute. 404 The semantics of the encapsulated message is dependent on the key 405 management protocol that is used. 407 The general processing for handling a received answer SHALL follow 408 the following actions: 410 * The key management protocol is identified according to the prtcl-id 411 field. 413 * The key management data from the keymgmt-data field MUST be 414 extracted, base64 decoded to reconstruct the original message, and 415 then passed to the key management protocol for processing. 417 * If the key management offer is rejected and the intent is to re- 418 negotiate it, it MUST be done through another Offer/Answer 419 exchange. It is RECOMMENDED to NOT abort the session in that case, 420 but to re-negotiate using another Offer/Answer exchange. For 421 example, in SIP [RFC3261], the "security precondition" as defined 422 in [SPREC} solves the problem for a session initiation. The 423 procedures in [SPREC] are outside the scope of this document. In 424 an established session, an additional Offer/Answer exchange using 425 a re-INVITE or UPDATE as appropriate MAY be used. 427 * If errors occur, or the key management offer is rejected and there 428 is no intent to re-negotiate it, the session SHALL be aborted. If 429 possible an error message indicating the failure SHOULD be sent 430 back. 432 Otherwise, if all the steps are successful, the normal setup 433 proceeds. 435 4.1.2 Use of SDP with offer/answer and SIP 437 This section defines additional processing rules, to the general 438 rules defined in Section 3.1.1, applicable only to applications using 439 SDP with the offer-answer model [OAM] (and in particular SIP). 441 When an initial offer is created, the following offer-answer specific 442 procedure SHALL be applied: 444 * Before creating the key management data field, the list of protocol 445 identifiers MUST be provided by the SDP application to (each) key 446 management protocol, as defined in Section 3.1.4 (to defeat 447 bidding-down attacks). 449 For a received SDP offer that contains the key management attributes, 450 the following offer-answer specific procedure SHALL be applied: 452 * Before, or in conjunction with, passing the key management data to 453 the key management protocol, the complete list of protocol 454 identifier from the offer message is provided by the SDP 455 application to the key management protocol (as defined in Section 456 3.1.4). 458 When an answer is created, the following offer-answer specific 459 procedure SHALL be applied: 461 * If the key management rejects the offer and the intent is to re- 462 negotiate it, the Answer SHOULD include the cause of failure in an 463 included message from the key management protocol. The 464 renegotiation MUST be done through another Offer/Answer exchange 465 (e.g, using [SPREC]). In an established session, it can also be 466 done through a re-INVITE or UPDATE as appropriate. 468 * If the key management rejects the offer and the session needs to be 469 aborted, the answerer SHOULD return a "488 Not Acceptable Here" 470 message, optionally also including one or more Warning headers (a 471 306 "Attribute not understood" when one of the parameters is not 472 supported, and a 399 "Miscellaneous warning" with arbitrary 473 information to be presented to a human user or logged, see Section 474 20.43 in [SIP]). Further details about the cause of failure MAY be 475 described in an included message from the key management protocol. 476 The session is then aborted (and it is up to local policy or end 477 user to decide how to continue). 479 Note that the key management attribute (related to the same key 480 management protocol) MAY be present both at session level and at 481 media level. Consequently, the process SHALL be repeated for each 482 such key management attribute detected. In case the key management 483 processing of any such attribute does not succeed (e.g. 484 authentication failure, parameters not supported etc.), on either 485 session or media level, the entire session setup SHALL be aborted, 486 including those parts of the session that successfully completed 487 their part of the key management. 489 If more than one key management protocol is supported, multiple 490 instances of the key management attribute MAY be included in the 491 initial offer when using the offer-answer model, each transporting a 492 different key management protocol, thus indicating supported 493 alternatives. 495 If the offerer includes more than one key management protocol 496 attribute at session level (analogous for the media level), these 497 SHOULD be listed in order of preference (the first being the 498 preferred). The answerer selects the key management protocol it 499 wishes to use, and processes only it, on either session or media 500 level, or on both, according to where located. If the answerer does 501 not support any of the offerer's suggested key management protocols, 502 the answerer indicates this to the offerer so a new Offer-Answer can 503 be triggered; alternatevely, it may return a "488 Not Acceptable 504 Here" error message, whereby the sender MUST abort the current setup 505 procedure. 507 Note that the placement of multiple key management offers in a single 508 message has the disadvantage that the message expands and the 509 computational workload for the offerer will increase drastically. 510 Unless the guidelines of Section 3.1.4 are followed, multiple lines 511 may open up bidding-down attacks. Note also that the multiple offer 512 option has been added to optimize signaling overhead in case the 513 Initiator knows some key (e.g. a public key) that the Responder has, 514 but is unsure of what protocol the Responder supports. The mechanism 515 is not intended to negotiate options within one and the same 516 protocol. 518 The offerer MUST include the key management data within an offer that 519 contains the media description it applies to. 521 Re-keying MUST be handled as a new offer, with the new proposed 522 parameters. The answerer treats this as a new offer where the key 523 management is the issue of change. The re-keying exchange MUST be 524 finalized before the security protocol can change the keys. The same 525 key management protocol used in the original offer SHALL also be used 526 in the new offer carrying re-keying. If the new offer carrying re- 527 keying fails (e.g., the authentication verification fails), the 528 answerer SHOULD send a "488 Not Acceptable Here" message, including 529 one or more Warning headers (at least a 306). The offerer MUST then 530 abort the session. 532 Note that, in multicast scenarios, unlike unicast, there is only a 533 single view of the stream [OAM], hence there MUST be a uniform 534 agreement of the security parameters. 536 After the offer is issued, the offerer SHOULD be prepared to receive 537 media, as the media may arrive prior to the answer. However, this 538 brings issues, as the offer does not know yet the answerer�s choice 539 in terms of e.g. algorithms, nor possibly the key is know. This can 540 cause delay or clipping can occur; if this is unacceptable, the 541 offerer SHOULD use mechanisms outside the scope of this document, 542 e.g. the security precondition for SIP [SPREC]. 544 4.1.3 Use of SDP with SAP 546 There are cases where SDP is used without conforming to the 547 offer/answer model; instead it is a one-way SDP distribution (i.e. 548 without back channel), such as when used with SAP and HTTP. 550 The processing follows the two first steps of the general SDP 551 processing (see Section 3.1.1). It can be noted that the processing 552 in this case differs from the offer/answer case in the fact that only 553 one key management protocol SHALL be offered (i.e. no negotiation 554 will be possible). This implies that the bidding down attack is not 555 an issue; therefore the countermeasure is not needed. The key 556 management protocol used MUST support one-way messages. 558 4.1.4 Bidding-down attack prevention 560 The possibility to support multiple key management protocols may, 561 unless properly handled, introduce bidding-down attacks. 562 Specifically, a man-in-the-middle could "peel off" cryptographically 563 strong offers (deleting the key management lines from the message), 564 leaving only weaker ones as the Responder's choice. To avoid this, 565 the list of identifiers of the proposed key management protocols MUST 566 be authenticated. The authentication MUST be done separately by each 567 key management protocol. 569 Accordingly, it MUST be specified (in the key management protocol 570 specification itself or in a companion document) how the list of key 571 management protocol identifiers can be processed to be authenticated 572 from the offerer to the answerer by the specific key management 573 protocol. Note that even if only one key management protocol is used, 574 that still MUST authenticate its own protocol identifier. 576 The list of protocol identifiers MUST then be given to each of the 577 selected (offered) key management protocols by the application with 578 ";" separated identifiers. All the offered protocol identifiers MUST 579 be included, in the same order as they appear in the corresponding 580 SDP description. 582 The protocol list can formally be described as 584 prtcl-list = KMPID *(";" KMPID) 586 where KMPID is as defined in Section 2. 588 For example, if the offered protocols are MIKEY and two yet-to-be- 589 invented protocols KEYP1, KEYP2, the SDP is: 591 v=0 592 o=alice 2891092738 2891092738 IN IP4 lost.example.com 593 s=Secret discussion 594 t=0 0 595 c=IN IP4 lost.example.com 596 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... 597 a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... 598 a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... 599 m=audio 39000 RTP/SAVP 98 600 a=rtpmap:98 AMR/8000 601 m=video 42000 RTP/SAVP 31 602 a=rtpmap:31 H261/90000 604 The protocol list, "mikey;keyp1;keyp2", would be generated from 605 the SDP description and used as input to each specified key 606 management protocol (together with the data for that protocol). 607 Each of the three protocols includes this protocol identifier 608 list in its authentication coverage (according to its protocol 609 specification). 611 If more than one protocol is supported by the offerer, it is 612 RECOMMENDED that all acceptable protocols are included in the first 613 offer, rather than making single, subsequent alternative offers in 614 response to error messages, see "Security Considerations". 616 End-to-end integrity protection of the key-mgmt attributes 617 altogether, provided externally to the key management themselves, 618 also gives protection against this bidding down attack. This is for 619 example the case if SIP uses S/MIME [RFC3851] to end-to-end integrity 620 protect the SDP description. As however this end-to-end protection is 621 not an assumption of the framework, the mechanisms defined in this 622 section SHALL be applied. 624 4.2. RTSP usage 626 RTSP does not use the offer/answer model, as SIP does. This causes 627 some problems, as it is not possible (without modifying RTSP) to send 628 back an answer. To solve this, a new header has been introduced 629 (Section 2.2). This also assumes that the key management also has 630 some kind of binding to the media, so that the response to the server 631 will be processed as required. 633 The server SHALL be the Initiator of the key management exchange for 634 sessions in PLAY mode, i.e. transporting media from server to client. 635 The below text describes the behavior for PLAY mode. For any other 636 mode the behavior is not defined in this specification. 638 To obtain a session description, the client initially contacts the 639 server via a DESCRIBE message. The initial key management message 640 from the RTSP server is sent to the client in the SDP of the 200 OK 641 in response to the DESCRIBE. Note that only one key management 642 protocol SHALL be used per session / media level. A server MAY allow 643 the SDP with key-management attribute(s) to be distributed to the 644 client though other means than RTSP, although this is not specified 645 here. 647 The "uri" parameter of the KeyMgmt header is used to indicate for the 648 key management protocol on what context the carried message applies. 649 For key management messages on the SDP session level, the answer MUST 650 contain the RTSP aggregated control URL to indicate this. For Key 651 management messages initially on SDP media level, the key management 652 response message in the KeyMgmt header MAY use the RTSP media level 653 URL. For RTSP sessions not using aggregated control, i.e. no session 654 level control URI is defined, the key management protocol SHALL only 655 be invoked on individual media streams. In this case also, the key 656 management response SHALL be on individual media streams (i.e. one 657 RTSP key management header per media). 659 When responding to the initial key management message, the client 660 uses the new RTSP header (KeyMgmt) to send back an answer. How this 661 is done depends on the usage context: 663 * Key management protocol responses for the initial establishment of 664 security parameters for an aggregated RTSP session SHALL be sent 665 in the first SETUP of the session. This means that if the key 666 management is declared for the whole session but is setup in non- 667 aggregated fashion, i.e. one media per RTSP session, each SETUP 668 MUST carry the same response for the session level context. When 669 performing a setup of the second or any subsequent media in a RTSP 670 session the same key management parameters as established for the 671 first media also applies to these setups. 673 * Key management responses for the initial establishment of security 674 parameters for an individual media SHALL only be included in SETUP 675 for the corresponding media stream. 677 If a server receives a SETUP message in which it expects a key 678 management message, but none is included, a 403 Forbidden SHOULD be 679 returned to the client, whereby the current setup MUST be aborted. 681 When the server creates an initial SDP message, the procedure SHALL 682 be the same as described in Section 3.1.1. 684 The client processing of the initial SDP message from the server 685 SHALL follow the same procedures as described in Section 3.1.1, 686 except that, if there is an error, the session is aborted (no error 687 is sent back). 689 The client SHALL create the response, using the key management header 690 in RTSP, as follows: 692 * The identifier of the key management protocol used (e.g. MIKEY) 693 MUST be placed in the "prot" field of the header. The prot values 694 are maintained by IANA (Section 8). 696 * The keymgmt-data field MUST be created as follows: the key 697 management protocol MUST be used to create the key management 698 message. This message SHALL be base64 encoded by the RTSP 699 application and then encapsulated in the "data" field of the 700 header. The semantic of the encapsulated message is dependent on 701 the key management protocol that is used. 703 * Include, if necessary, the URL to indicate the context in the "uri" 704 parameter. 706 The server SHALL process a received key management header in RTSP as 707 follow: 709 * The key management protocol is identified according to the "prot" 710 field. 712 * The key management data from the "data" field MUST be extracted, 713 base64 decoded to reconstruct the original message, and then 714 passed to the key management protocol for processing. 716 * If the key management protocol is successful, the processing can 717 proceed according to normal rules. 719 * Otherwise, if the key management fails (e.g. due to authentication 720 failure or parameter not supported), an error is sent back as the 721 SETUP response using RTSP error code 463 (see Section 2.2) and the 722 session is aborted. It is up to the key management protocol to 723 specify (within the RTSP status code message or through key 724 management messages) details about the type of error that 725 occurred. 727 Re-keying within RTSP is for further study, given that media updating 728 mechanisms within RTSP are unspecified at the time this document is 729 written. 731 5. Example scenarios 733 The following examples utilize MIKEY [MIKEY] as the key management 734 protocol to be integrated into SDP and RTSP (see Section 5.1.). 736 Example 1 (SIP/SDP) 738 A SIP call is taking place between Alice and Bob. Alice sends an 739 INVITE message consisting of the following offer: 741 v=0 742 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 743 s=Cool stuff 744 e=alice@w-land.example.com 745 t=0 0 746 c=IN IP4 w-land.example.com 747 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2 748 UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt 749 0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV 750 m=audio 49000 RTP/SAVP 98 751 a=rtpmap:98 AMR/8000 752 m=video 52230 RTP/SAVP 31 753 a=rtpmap:31 H261/90000 755 i.e. Alice proposes to set up one audio stream and one video stream 756 that run over SRTP (signaled by the use of the SAVP profile). She 757 uses MIKEY to set up the security parameters for SRTP (Section 6). 758 The MIKEY message contains the security parameters, together with the 759 necessary key material. Note that MIKEY is exchanging the crypto 760 suite for both streams, as it is placed at the session level. Also, 761 MIKEY provides its own security, i.e. when Bob processes Alice's 762 MIKEY message, he will also find the signaling of the security 763 parameters used to secure the MIKEY exchange. Alice's endpoint's 764 authentication information is also carried within the MIKEY message, 765 to prove that the message is authentic. The above MIKEY message is an 766 example of message when the pre-shared method MIKEY is used. 768 Upon receiving the offer, Bob checks the validity of the received 769 MIKEY message, and, in case of successful verification, he accepts 770 the offer and sends an answer back to Alice (with his authentication 771 information, and, if necessary, also some key material from his 772 side): 774 v=0 775 o=bob 2891092897 2891092897 IN IP4 foo.example.com 776 s=Cool stuff 777 e=bob@foo.example.com 778 t=0 0 779 c=IN IP4 foo.example.com 780 a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2 781 V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc= 782 m=audio 49030 RTP/SAVP 98 783 a=rtpmap:98 AMR/8000 784 m=video 52230 RTP/SAVP 31 785 a=rtpmap:31 H261/90000 787 Upon receiving the answer, Alice verifies the correctness of it. In 788 case of success, at this point Alice and Bob share the security 789 parameters and the keys needed for a secure RTP communication. 791 Example 2 (SDP) 793 This example shows how Alice would have done if she wished to protect 794 only the audio stream. She would have placed the MIKEY line at media 795 level for the audio stream only (also specifying the use of the SRTP 796 profile there, SAVP). The semantic of the MIKEY messages is as in the 797 previous case, but applies only to the audio stream. 799 v=0 800 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 801 s=Cool stuff 802 e=alice@w-land.example.com 803 t=0 0 804 c=IN IP4 w-land.example.com 805 m=audio 49000 RTP/SAVP 98 806 a=rtpmap:98 AMR/8000 807 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... 808 m=video 52230 RTP/AVP 31 809 a=rtpmap:31 H261/90000 811 Bob would then act as described in the previous example, including 812 the MIKEY answer at the media level for the audio stream (as Alice 813 did). 815 Note that even if the key management attribute were specified at 816 session level, the video part would not be affected by this (as a 817 security profile is not used, instead the RTP/AVP profile is 818 signaled). 820 Example 3 (RTSP) 822 A client wants to set up a streaming session and requests a media 823 description from the streaming server. 825 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 826 CSeq: 312 827 Accept: application/sdp 828 From: user@example.com 830 The server sends back an OK message including an SDP description, 831 together with the MIKEY message. The MIKEY message contains the 832 necessary security parameters that the server is willing of offering 833 to the client, together with authentication information (to prove 834 that the message is authentic) and the key material. The SAVP profile 835 also signals the use of SRTP for securing the media sessions. 837 RTSP/1.0 200 OK 838 CSeq: 312 839 Date: 23 Jan 1997 15:35:06 GMT 840 Content-Type: application/sdp 841 Content-Length: 478 843 v=0 844 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 845 s=Action Movie 846 e=action@movie.example.com 847 t=0 0 848 c=IN IP4 movie.example.com 849 a=control:rtsp://movie.example.com/action 850 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... 851 m=audio 0 RTP/SAVP 98 852 a=rtpmap:98 AMR/8000 853 a=control:rtsp://movie.example.com/action/audio 854 m=video 0 RTP/SAVP 31 855 a=rtpmap:31 H261/90000 856 a=control:rtsp://movie.example.com/action/video 858 The client checks the validity of the received MIKEY message, and, in 859 case of successful verification, it accept the message. The client 860 then includes its key management data in the SETUP request going back 861 to the server, the client authentication information (to prove that 862 the message is authentic) and, if necessary, some key material. 864 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 865 CSeq: 313 866 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 867 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action"; 868 data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..." 870 The server processes the request including checking the validity of 871 the key management header. 873 RTSP/1.0 200 OK 874 CSeq: 313 875 Session: 12345678 876 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 877 server_port=5000-5001 879 Note than in this case the key management line was specified at the 880 session level, the key management information only goes into the 881 SETUP related to the first stream. The "uri" indicates to the server 882 that the context is for the whole aggregated session the key 883 management applies. The RTSP client then proceeds setting up the 884 second media (video) in aggregation with the audio. As the two media 885 are run in aggregation and the key context was established in the 886 first exchange, no more key management messages are needed. 888 Example 4 (RTSP) 890 The use of the MIKEY message at the media level would change the 891 previous example as follows. 893 The 200 OK would contain the two distinct SDP attributes for MIKEY at 894 the media level: 896 RTSP/1.0 200 OK 897 CSeq: 312 898 Date: 23 Jan 1997 15:35:06 GMT 899 Content-Type: application/sdp 900 Content-Length: 561 902 v=0 903 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 904 s=Action Movie 905 e=action@movie.example.com 906 t=0 0 907 c=IN IP4 movie.example.com 908 a=control:rtsp://movie.example.com/action 909 m=audio 0 RTP/SAVP 98 910 a=rtpmap:98 AMR/8000 911 a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA... 912 a=control:rtsp://movie.example.com/action/audio 913 m=video 0 RTP/SAVP 31 914 a=rtpmap:31 H261/90000 915 a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA... 916 a=control:rtsp://movie.example.com/action/video 918 Each RTSP header are inserted in the SETUP related to the audio and 919 video separately: 921 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 922 CSeq: 313 923 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 924 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; 925 data="AQEFgM0XflABAAAAAAAAAAAAA..." 927 and similarly for the video session: 929 SETUP rtsp://movie.example.com/action/video RTSP/1.0 930 CSeq: 315 931 Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059 932 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video"; 933 data="AQEFgM0AdlABAAAAAAAAAAAAAA..." 935 Note: The "uri" parameter could be excluded from the two SETUP 936 messages in this example. 938 6. Adding further Key management protocols 940 This framework cannot be used with all key management protocols. The 941 key management protocol needs to comply with the requirements 942 described in Section 3. In addition to this, the following needs to 943 be defined: 945 * The key management protocol identifier to be used as the protocol 946 identifier should be registered at IANA according to Section 8. 948 * The information that the key management needs from SDP and RTSP, 949 and vice versa, as described in Section 3. The exact API is 950 implementation specific, but it MUST at least support the exchange 951 of the specified information. 953 * The key management protocol to be added MUST be such, that the 954 processing in Section 3 (describing its interactions with SDP and 955 RTSP) can be applied. Note in particular, Section 3.1.4 requires 956 each key management protocol to specify how the list of protocol 957 identifiers is authenticated inside that key management protocol. 958 The key management MUST always be given the protocol identifier(s) 959 of the key management protocol(s) included in the offer in the 960 correct order as they appear. 962 Finally, it is obviously crucial to analyze possible security 963 implications induced by the introduction of a new key management 964 protocol in the described framework. 966 Today, the MIKEY protocol [MIKEY] has adopted the key management 967 extensions to work together with SIP and RTSP (see Section 6). Other 968 protocols MAY use the described attribute and header, e.g. Kerberos 969 [KERB], however this is subject to future standardization. 971 7. Integration of MIKEY 973 [MIKEY] describes a key management protocol for real-time 974 applications (both for peer-to-peer communication and group 975 communication). MIKEY carries the security parameters needed for 976 setting up the security protocol (e.g., SRTP) protecting the media 977 stream. MIKEY can be integrated within SDP and RTSP, following the 978 rules and guidelines described in this document. 980 MIKEY satisfies the requirements described in Section 3. The MIKEY 981 message is formed as defined in [MIKEY], then passed from MIKEY to 982 the SDP application that base64 encodes it, and encapsulates it in 983 the keymgmt-data attribute. The examples in Section 4 use MIKEY, 984 where the semantic of the exchange is also briefly explained. 986 The key management protocol identifier (KMPID) to be used as the 987 protocol identifier SHALL be "mikey" and is registered at IANA, see 988 in detail Section 8. 990 The information that the key management needs from SDP and RTSP, and 991 vice versa, follows Section 3. To avoid bidding-down attacks, the 992 directives in Section 3.1.4 are followed. The list of protocol 993 identifiers is authenticated within MIKEY by placing the list in a 994 General Extension Payload (of type "SDP IDs", [MIKEY]), which then 995 automatically will be integrity protected/signed. The receiver SHALL 996 then match the list in the General Extension Payload with the list 997 included in SDP and SHOULD (according to policy) if they differ, or 998 if integrity/signature verification fails, reject the offer. 1000 The server will need to be able to know the identity of the Client 1001 before creating and sending a MIKEY message. To signal the (MIKEY) 1002 identity of the client to the server in the DESCRIBE, it is 1003 RECOMMENDED to include the From header field in RTSP. Other methods 1004 to establish the identity could be using the IP address or retrieving 1005 the identity from the RTSP authentication if used. 1007 7.1 MIKEY Interface 1009 This subsection describes some aspects, which implementers SHOULD 1010 consider. If the MIKEY implementation is separate from the 1011 SDP/SIP/RTSP, an application programming interface (API) between 1012 MIKEY and those protocols is needed with certain functionality 1013 (however, exactly what it looks like is implementation dependent). 1015 The following aspects need to be considered: 1017 * the possibility for MIKEY to receive information about the sessions 1018 negotiated. This is to some extent implementation dependent. But 1019 it is RECOMMENDED that, in the case of SRTP streams, the number of 1020 SRTP streams is included (and the direction of these). It is also 1021 RECOMMENDED to provide the destination addresses and ports to 1022 MIKEY. When referring to streams described in SDP, MIKEY SHALL 1023 allocate two consecutive numbers for the related Crypto Session 1024 indexes (as each stream can be bi-directional). An example: if the 1025 SDP contains two m lines (specifying whatever direction of the 1026 streams), and MIKEY is at the session level, then MIKEY allocates 1027 e.g. the Crypto Sessions Identifiers (CS IDs, see [MIKEY)] '1' and 1028 '2' for the first m line, and '3' and '4' for the second m line. 1030 * the possibility for MIKEY to receive incoming MIKEY messages and 1031 return a status code from/to the SIP/RTSP application. 1033 * the possibility for the SIP or RTSP applications to receive 1034 information from MIKEY. This would typically include the receiving 1035 of the Crypto Session Bundle Identifier (CSB ID, see [MIKEY], to 1036 later be able to identify the active MIKEY session), and the SSRCs 1037 and the rollover counter (ROC, see [SRTP]) for SRTP usage. It is 1038 also RECOMMENDED that extra information about errors can be 1039 received. 1041 * the possibility for the SIP or RTSP application to receive outgoing 1042 MIKEY messages. 1044 * the possibility to tear down a MIKEY CSB (e.g. if the SIP session 1045 is closed, the CSB SHOULD also be closed). 1047 8. Security Considerations 1049 The framework for transfer of key management data as described here 1050 is intended to provide the security parameters for the end-to-end 1051 protection of the media session. It is furthermore good practice to 1052 secure the session setup (e.g. SDP, SIP, RTSP, SAP). However, it 1053 might be that the security of the session setup is not possible to 1054 achieve end-to-end, but only hop-by-hop. For example, SIP requires 1055 intermediate proxies to have access to part of the SIP message, and 1056 sometimes also to the SDP description (c.f. [E2M]), although end-to- 1057 end confidentiality can hide bodies from intermediaries. General 1058 security considerations for the session setup can be found in SDP 1059 [SDPnew], SIP [SIP], and RTSP [RTSP]. The framework defined in this 1060 memo is useful when the session setup is not protected in an end-to- 1061 end fashion, but the media streams needs to be end-to-end protected, 1062 hence the security parameters (such as keys) are not wanted revealed 1063 to nor manipulated by intermediaries. 1065 The security will also depend on the level of security the key 1066 management protocol offers. It follows that, under the assumption 1067 that the key management schemes are secure, the SDP can be passed 1068 along unencrypted without affecting the key management as such, and 1069 the media streams will still be secure even if some attackers gained 1070 knowledge of the SDP contents. Further security considerations can be 1071 found for each key management protocol (for MIKEY these can be found 1072 in [MIKEY]). However, if the SDP messages are not sent integrity 1073 protected between the parties, it is possible for an active attacker 1074 to change attributes without being detected. As the key management 1075 protocol may (indirectly) rely on some of the session information 1076 from SDP (e.g., address information), an attack on SDP may have 1077 indirect consequences on the key management. Even if the key 1078 management protocol does not rely on parameters of SDP and will not 1079 be affected by manipulation of these, different DoS attacks aimed at 1080 SDP may lead to undesired interruption in the setup. See also the 1081 attacks described at the end of this section. 1083 The only integrity protected attribute of the media stream is, in the 1084 framework proposed here, the set of key management protocols. It is 1085 for instance possible to (1) swap key management offers across SDP 1086 messages, or, (2) inject a previous key management offer into a new 1087 SDP message. Making the (necessary) assumption that all involved key 1088 management protocols are secure, the second attack will be detected 1089 by replay protection mechanisms of the key management protocol(s). 1090 Making the further assumption that, according to normal best current 1091 practice, the production of each key management offer is done with 1092 independent (pseudo)random choices (for session keys and other 1093 parameters), the first attack will either be detected in the 1094 Responder's (now incorrect) verification reply message (if such is 1095 used), or, be a pure DoS attack, resulting in Initiator and Responder 1096 using different keys. 1098 It is RECOMMENDED for the identity at the SPD level to be the one 1099 authenticated at the key management protocol level. This might 1100 however need to keep into consideration privacy aspects, which are 1101 out of scope for this famework. 1103 The use of multiple key management protocols in the same offer may 1104 open up the possibility of a bidding-down attack, as specified in 1105 Section 3.1.4. To exclude such possibility, the authentication of the 1106 protocol identifier list is used. Note though, that the security 1107 level of the authenticated protocol identifier will be as high (or 1108 low), as the "weakest" protocol. Therefore, the offer MUST NOT 1109 contain any security protocols (or configurations thereof) weaker 1110 than permitted by local security policy. 1112 Note that it is impossible to assure the authenticity of a declined 1113 offer, since even if it comes from the true respondent, the fact that 1114 the answerer declines the offer usually means that he does not 1115 support the protocol(s) offered, and consequently cannot be expected 1116 to authenticate the response either. This means that if the Initiator 1117 is unsure of which protocol(s) the Responder supports, we RECOMMEND 1118 that the Initiator offers all acceptable protocols in a single offer. 1119 If not, this opens up the possibility for a "man-in-the-middle" 1120 (MITM) to affect the outcome of the eventually agreed upon protocol, 1121 by faking unauthenticated error messages until the Initiator 1122 eventually offers a protocol "to the liking" of the MITM. This is not 1123 really a security problem, but rather a mild form of denial of 1124 service that can be avoided by following the above recommendation. 1125 Note also that the declined offer could be result of an attacker who 1126 sits on the path and removes all the key management offers. The 1127 bidding-down attack prevention, as described above, would not work in 1128 this case (as the answerer receives no key management attribute). 1129 Also here it is impossible to assure the authenticity of a declined 1130 offer, though here the reason is the "peeling-off" attack. It is up 1131 to the local policy to decide the behavior in the case that the 1132 response declines any security (therefore there is impossibility of 1133 authenticating it). If for example the local policy requires a secure 1134 communication and cannot accept an unsecured one, then the session 1135 setup SHALL be aborted. 1137 9. IANA Considerations 1139 9.1. SDP Attribute Registration 1141 The IANA is hereby requested to create a new subregistry for the 1142 purpose of key management protocol integration with SDP. 1144 SDP Attribute Field ("att-field"): 1146 Name: key-mgmt-att-field 1147 Long form: key management protocol attribute field 1148 Type of name: att-field 1149 Type of attribute: Media and session level 1150 Purpose: See RFC xxxx, Section 2. 1151 Reference: RFC xxxx, Section 2.1 1152 Values: See RFC xxxx, Section 2.1 and 8.3. 1154 9.2. RTSP Registration 1156 The IANA is hereby requested to create a new subregistry for the 1157 purpose of key management protocol integration with RTSP. 1159 Following the guidelines of [RTSP], the registration is defined as 1160 follows: 1162 Header name: keymgmt 1163 Header syntax: see RFC xxxx, Section 2.2 1164 Intended usage: see RFC xxxx, Section 2.2 1165 Proxy treatment: Proxies SHALL NOT add, change, or delete the 1166 header. The proxy does not need to read this 1167 header. 1168 Purpose: see RFC xxxx, Section 2 1170 The RTSP Status-Code "463" [RFC xxxx], with the default string "Key 1171 management failure", needs to be registered. 1173 9.3. Protocol Identifier Registration 1175 This document defines one new name space, the "SDP/RTSP key 1176 management protocol identifier", associated with the protocol 1177 identifier, KMPID, defined in Section 2 to be used with the above 1178 registered attributes in SDP and RTSP. 1180 The IANA is hereby requested to create a new subregistry for the 1181 KMPID parameter, with the following registration created initially: 1182 "mikey". 1184 Value name: mikey 1185 Long name: Multimedia Internet KEYing 1186 Purpose: Usage of MIKEY with the key-mgmt-att-field 1187 attribute and the keymgmt RTSP header 1188 Reference: Section 7 in RFC 3830 1190 Note that this registration implies that the protocol identifier, 1191 KMPID, name space will be shared between SDP and RTSP. 1193 Further values may be registered according to the "Specification 1194 Required" policy as defined in [RFC2434]. Each new registration needs 1195 to indicate the parameter name, and register it within IANA. Note 1196 that the parameter name is case sensitive and it is RECOMMENDED that 1197 the name to be in lower case letters. For each new registration, it 1198 is mandatory that a permanent, stable, and publicly accessible 1199 document exists that specifies the semantics of the registered 1200 parameter and the requested details of interaction between the key 1201 management protocol and SDP, as specified in RFC xxxx. 1203 New values MUST be register with IANA. Registrations SHALL include 1204 the following information: 1206 * Contact: the contact name and email address 1207 * Value name: the name of the value being registered (which MUST 1208 comply with the KMPID as defined in Section 2) 1209 * Long Name: long-form name in English 1210 * Purpose: short explanation of the purpose of the registered name. 1211 * Reference: a reference to the specification (e.g. RFC number) 1212 providing the usage guidelines in accordance to Section 5 (and 1213 also complying to the specified requirements). 1215 10. Acknowledgments 1217 The authors would like to thank Francois Audet, Rolf Blom, Johan 1218 Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, 1219 Joerg Ott, Jon Peterson, and Jon-Olov Vatn. A special thanks to Colin 1220 Perkins and Magnus Westerlund, who contributed in many sections. 1222 11. Author's Addresses 1224 Jari Arkko 1225 Ericsson 1226 02420 Jorvas Phone: +358 40 5079256 1227 Finland Email: jari.arkko@ericsson.com 1229 Elisabetta Carrara 1230 Ericsson 1231 SE-16480 Stockholm Phone: +46 8 50877040 1232 Sweden EMail: elisabetta.carrara@ericsson.com 1234 Fredrik Lindholm 1235 Ericsson 1236 SE-16480 Stockholm Phone: +46 8 58531705 1237 Sweden EMail: fredrik.lindholm@ericsson.com 1239 Mats Naslund 1240 Ericsson Research 1241 SE-16480 Stockholm Phone: +46 8 58533739 1242 Sweden EMail: mats.naslund@ericsson.com 1244 Karl Norrman 1245 Ericsson Research 1246 SE-16480 Stockholm Phone: +46 8 4044502 1247 Sweden EMail: karl.norrman@ericsson.com 1249 12. References 1251 12.1. Normative References 1253 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 1254 Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC 3830. 1256 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 1257 the Session Description Protocol (SDP)", IETF, RFC 3264. 1259 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 1260 Streaming Protocol (RTSP)", IETF, RFC 2326. 1262 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1263 Requirement Levels", IETF, RFC 2119. 1265 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 1266 Description Protocol", Internet Draft, IETF, draft-ietf-mmusic-sdp- 1267 new-15.txt. 1269 [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", IETF, RFC 1270 3261. 1272 [RFC2234] Crocker, D. and Overell, P., "Augmented BNF for Syntax 1273 Specifications: ABNF", RFC 2234, November 1997. 1275 [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an 1276 IANA Considerations Section in RFCs", IETF, RFC 2434. 1278 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1279 Encodings", IETF, RFC 3548. 1281 12.2. Informative References 1283 [E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the 1284 Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono- 1285 sipping-end2middle-security-03. 1287 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 1288 Service (V5)", IETF, RFC 1510. 1290 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1291 (S/MIME) Version 3.1 Message Specification", IETF, RFC 3851. 1293 [SDES] Andreasen, F., Baugher, M., Wing, D., "Session Description 1294 Protocol Security Descriptions for Media Streams", work in progress, 1295 February 2005. 1297 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, 1298 K., "The Secure Real-time Transport Protocol", IETF, RFC 3711. 1300 [SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security 1301 Preconditions for Session Description Protocol Media Streams", work 1302 in progress, February 2004. 1304 Intellectual Property Statement 1306 The IETF takes no position regarding the validity or scope of any 1307 Intellectual Property Rights or other rights that might be claimed to 1308 pertain to the implementation or use of the technology described in 1309 this document or the extent to which any license under such rights 1310 might or might not be available; nor does it represent that it has 1311 made any independent effort to identify any such rights. Information 1312 on the procedures with respect to rights in RFC documents can be 1313 found in BCP 78 and BCP 79. 1315 Copies of IPR disclosures made to the IETF Secretariat and any 1316 assurances of licenses to be made available, or the result of an 1317 attempt made to obtain a general license or permission for the use of 1318 such proprietary rights by implementers or users of this 1319 specification can be obtained from the IETF on-line IPR repository at 1320 http://www.ietf.org/ipr. 1322 The IETF invites any interested party to bring to its attention any 1323 copyrights, patents or patent applications, or other proprietary 1324 rights that may cover technology that may be required to implement 1325 this standard. Please address the information to the IETF at ietf- 1326 ipr@ietf.org. 1328 Copyright Notice 1330 Copyright (C) The Internet Society (2005). This document is subject 1331 to the rights, licenses and restrictions contained in BCP 78, and 1332 except as set forth therein, the authors retain all their rights. 1334 Disclaimer of Validity 1336 This document and the information contained herein are provided on an 1337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1339 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1340 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1341 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1344 This Internet-Draft expires in December 2005.