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