idnits 2.17.1 draft-ietf-mmusic-kmgmt-ext-11.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.5 on line 1206. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1196), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 806 has weird spacing: '... client then ...' -- 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 (April 2004) is 7315 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIKEY' ** 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-01 -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. 'KERB') (Obsoleted by RFC 4120, RFC 6649) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 MMUSIC Working Group E. Carrara 4 INTERNET-DRAFT F. Lindholm 5 Expires: October 2004 M. Naslund 6 K. Norrman 7 Ericsson 8 April 2004 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, I certify that any applicable 17 patent or other IPR claims of which I am (we are) aware have been 18 disclosed, and any of which I (we) become aware will be disclosed, in 19 accordance with RFC 3668 (BCP 79). 21 By submitting this Internet-Draft, I accept the provisions of Section 22 3 of RFC 3667 (BCP 78). 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as 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 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/lid-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document defines general extensions for SDP and RTSP to carry 46 messages, as specified by a key management protocol, in order to 47 secure the media. These extensions are presented as a framework, to 48 be used by one or more key management protocols. As such, their use 49 is meaningful only when complemented by an appropriate key management 50 protocol. 52 General guidelines are also given on how the framework should be used 53 together with SIP and RTSP. The usage with the MIKEY key management 54 protocol is also defined. 56 TABLE OF CONTENTS 58 1. Introduction.....................................................2 59 1.1. Notational Conventions.........................................4 60 2. Extensions to SDP and RTSP.......................................4 61 2.1. SDP Extensions.................................................4 62 2.2. RTSP Extensions................................................5 63 3. Usage with SDP, SIP, RTSP, and SAP...............................6 64 3.1. Use of SDP.....................................................7 65 3.1.1 General processing............................................7 66 3.1.2 Use of SDP with offer/answer and SIP..........................9 67 3.1.3 Use of SDP with SAP..........................................10 68 3.1.4 Bidding-down attack prevention...............................11 69 3.2. RTSP usage....................................................12 70 4. Example scenarios...............................................14 71 5. Adding further Key management protocols.........................18 72 6. Integration of MIKEY............................................19 73 6.1 MIKEY Interface................................................19 74 7. Security Considerations.........................................20 75 8. IANA Considerations.............................................21 76 8.1. SDP Attribute Registration....................................21 77 8.2. RTSP Registration.............................................22 78 8.3. Protocol Identifier Registration..............................22 79 9. Acknowledgments.................................................23 80 10. Author's Addresses.............................................23 81 11. References.....................................................24 82 11.1. Normative References.........................................24 83 11.2. Informative References.......................................24 85 1. Introduction 87 [RFC Editor remark] All instances of RFC xxxx should be replaced 88 with the RFC number of this document, when published. Furthermore, 89 all instances of RFC yyyy should be replaced with the RFC number 90 of the MIKEY (Multimedia Internet KEYing) document [MIKEY], when 91 published. 93 There has recently been work to define a security profile for the 94 protection of real-time applications running over RTP, [SRTP]. 95 However, a security protocol needs a key management solution to 96 exchange keys and security parameters, manage and refresh keys, etc. 98 A key management protocol is executed prior to the security 99 protocol's execution. The key management protocol's main goal is to, 100 in a secure and reliable way, establish a security association for 101 the security protocol. This includes one or more cryptographic keys 102 and the set of necessary parameters for the security protocol, e.g., 103 cipher and authentication algorithms to be used. The key management 104 protocol has similarities with, e.g., SIP [SIP] and RTSP [RTSP] in 105 the sense that it negotiates necessary information in order to be 106 able to setup the session. 108 The focus in the following sections is to describe a new SDP 109 attribute and RTSP header extension to support key management, and to 110 show how these can be integrated within SIP and RTSP. The resulting 111 framework is completed by one or more key management protocols, which 112 use the extensions provided. 114 Some of the motivations to create a framework with the possibility to 115 include the key management in the session establishment are: 117 * Just as the codec information is a description of how to encode and 118 decode the audio (or video) stream, the key management data is a 119 description of how to encrypt and decrypt the data. 121 * The possibility to negotiate the security for the entire multimedia 122 session at the same time. 124 * The knowledge of the media at session establishment makes it easy 125 to tie the key management to the multimedia sessions. 127 * This approach may be more efficient than setting up the security 128 later, as that approach might force extra roundtrips, possibly 129 also a separate set-up for each stream, hence implying more delay 130 to the actual setup of the media session. 132 * The possibility to negotiate keying material end-to-end without 133 applying end-to-end protection of the SDP (instead, hop-by-hop 134 security mechanisms can be used which may be useful if 135 intermediate proxies needs access to the SDP). 137 Currently in SDP [SDPnew], there exists one field to transport keys, 138 the "k=" field. However, this is not enough for a key management 139 protocol as there are many more parameters that need to be 140 transported, and the "k=" field is not extendible. The approach used 141 is to extend the SDP description through a number of attributes that 142 transport the key management offer/answer and also to associate it 143 with the media sessions. SIP uses the offer/answer model [OAM] 144 whereby extensions to SDP will be enough. However, RTSP [RTSP] does 145 not use the offer/answer model with SDP, so a new RTSP header is 146 introduced to convey key management data. 148 The document also defines the use of the described framework together 149 with the key management protocol Multimedia Internet KEYing (MIKEY) 150 [MIKEY]. 152 1.1. Notational Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Extensions to SDP and RTSP 160 This section describes common attributes that can be included in SDP 161 or RTSP when an integrated key management protocol is used. The 162 attribute values follow the general SDP and RTSP guidelines (see 163 [SDPnew] and [RTSP]). 165 For both SDP and RTSP, the general method of adding the key 166 management protocol is to introduce new attributes, one identifier to 167 identify the specific key management protocol, and one data field 168 where the key management protocol data is placed. The key management 169 protocol data contains the necessary information to establish the 170 security protocol, e.g., keys and cryptographic parameters. All 171 parameters and keys are protected by the key management protocol. 173 The key management data SHALL be base64 [RFC3548] encoded and comply 174 with the base64 grammar as defined in [SDPnew]. The key management 175 protocol identifier, KMID, is defined as below in Augmented Backus- 176 Naur Form grammar (ABNF) [RFC2234]. 178 KMID = 1*(ALPHA / DIGIT) 180 Values for the identifier, KMID, are registered and defined in 181 accordance to Section 8. Note that the KMID is case sensitive and it 182 is RECOMMENDED that values registered are lower case letters. 184 2.1. SDP Extensions 186 This section provides an ABNF grammar (as used in [SDPnew]) for the 187 key management extensions to SDP. 189 Note that the new definitions are compliant with the definition of an 190 attribute field, i.e. 192 attribute = (att-field ":" att-value) | att-field 194 The att-field and att-value for the key management extensions are as 195 follow: 197 key-mgmt-att-field = "key-mgmt" 198 key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data 200 prtcl-id = KMID 201 ; e.g. "mikey" 203 keymgmt-data = base64 204 SP = 0x20 206 where KMID is as defined in Section 2 of this memo, base64 is as 207 defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined 208 for KMID in Section 8. 210 The attribute MAY be used at session level, media level, or at both 211 levels. An attribute defined at media level overrides an attribute 212 defined at session level. In other words, if the media level 213 attribute is present, the session level attribute MUST be ignored for 214 this media. Section 3.1 describes in detail how the attributes are 215 used and how the SDP is handled in different usage scenarios. 217 2.2. RTSP Extensions 219 To support the key management attributes, the following RTSP header 220 is defined: 222 KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) 224 key-mgmt-spec = "prot" "=" KMID ";" ["uri" "=" <"> rtsp_URL <"> ";"] 225 "data" "=" base64 227 where KMID is as defined in Section 2 of this memo, "base64" as 228 defined in [SDPnew], and "rtsp_URL" as defined in [RTSP]. 230 The "uri" parameter identifies the context for which the key 231 management data applies, and the RTSP URI SHALL match a (session or 232 media) URI present in the description of the session. If the RTSP 233 aggregated control URI is included it indicates that the key 234 management message is on session level (and similarly the RTSP media 235 control URI, that it applies to the media level). If no "uri" 236 parameter is present in a key-mgmt-spec the specification applies to 237 the context identified by the RTSP request URI. 239 The KeyMgmt header MAY be used in the messages and directions 240 described in the table below. 242 Method | Direction | Requirement 243 --------------------------------------------- 244 DESCRIBE response | S->C | RECOMMENDED 245 SETUP | C->S | REQUIRED 246 SETUP Response | S->C | REQUIRED (error) 248 Note: Section 3.2 describes in detail how the RTSP extensions are 249 used. 251 We define one new RTSP status code to report error due to any failure 252 during the key management processing (Section 3.2): 254 Status-Code = "463" ; Key management failure 256 A 463 response MAY contain a KeyMgmt header with a key management 257 protocol message that further indicates the nature of the error. 259 3. Usage with SDP, SIP, RTSP, and SAP 261 This section gives rules and recommendations of how/when to include 262 the defined key management attribute when SIP and/or RTSP are used 263 together with SDP. 265 When a key management protocol is integrated with SIP/SDP and RTSP, 266 the following general requirements are placed on the key management: 268 * It MUST be possible to execute the key management protocol in at 269 most one request-response message exchange. 271 * It MUST be possible from the SIP/SDP and RTSP application, using 272 the key management API, to receive key management data, and 273 information of whether a message is accepted or not. 275 The content of the key management messages depends on the key 276 management protocol that is used. However, the content of such key 277 management messages might be expected to be roughly as follow: the 278 key management Initiator (e.g. the offerer) includes the key 279 management data in a first message, containing the media description 280 it should apply to. This data in general consists of the security 281 parameters (including key material) needed to secure the 282 communication, together with the necessary authentication information 283 (to assure that the message is authentic). 285 At the Responder's side, the key management protocol checks the 286 validity of the key management message, together with the 287 availability of the parameters offered, and then provides the key 288 management data to be included in the answer. This answer may 289 typically authenticate the Responder to the Initiator, and also state 290 if the initial offer was accepted or not. Certain protocols might 291 require the Responder to include a selection of the security 292 parameters that he is willing to support. Again, the actual content 293 of such response is dependent on the particular key management 294 protocol. 296 Section 6 describes a realization of the MIKEY protocol using these 297 mechanisms. Procedures to be used when mapping new key management 298 protocols onto this framework are described in Section 5. 300 3.1. Use of SDP 302 This section describes the processing rules for the different 303 applications which use SDP for the key management. 305 3.1.1 General processing 307 The processing when SDP is used is slightly different according to 308 the way SDP is transported, and if it uses an offer/answer or 309 announcement. The processing can be divided into four different 310 steps: 312 1) How to create the initial offer. 313 2) How to handle a received offer. 314 3) How to create an answer. 315 4) How to handle a received answer. 317 It should be noted that the last two steps may not always be 318 applicable, as there are cases where an answer can not or will not be 319 sent back. 321 The general processing for creating an initial offer SHALL follow the 322 following actions: 324 * The identifier of the key management protocol used MUST be placed 325 in the prtcl-id field of SDP. A table of legal protocols 326 identifiers is maintained by IANA (see Section 8). 328 * The keymgmt-data field MUST be created as follows: the key 329 management protocol MUST be used to create the key management 330 message. This message SHALL be base64 encoded [RFC3548] by the SDP 331 application and then encapsulated in the keymgmt-data attribute. 332 Note though that the semantics of the encapsulated message is 333 dependent on the key management protocol that is used. 335 The general processing for handling a received offer SHALL follow the 336 following actions: 338 * The key management protocol is identified according to the prtcl-id 339 field. A table of legal protocols identifiers is maintained by 340 IANA (Section 8). 342 * The key management data from the keymgmt-data field MUST be 343 extracted, base64 decoded to reconstruct the original message, and 344 then passed to the key management protocol for processing. Note 345 that depending on key management protocol, some extra parameters 346 might also be requested by the specific API, such as the 347 source/destination network address/port(s) for the specified media 348 (however, this will be implementation specific depending on the 349 actual API). The extra parameters that a key management protocol 350 might need (other than the ones defined here) MUST be documented, 351 describing their use, as well as the interaction of that key 352 management protocol with SDP and RTSP. 354 * If errors occur, or the key management offer is rejected, the 355 session SHALL be aborted. Possible error messages are dependent 356 on the specific session establishment protocol. 358 At this stage, the key management will have either accepted or 359 rejected the offered parameters. This MAY cause a response message to 360 be generated, depending on the key management protocol and the 361 application scenario. 363 If an answer is to be generated, the following general actions SHALL 364 be performed: 366 * The identifier of the key management protocol used MUST be placed 367 in the prtcl-id field. 369 * The keymgmt-data field MUST be created as follows. The key 370 management protocol MUST be used to create the key management 371 message. This message SHALL be base64 encoded [RFC3548] by the SDP 372 application and then encapsulated in the keymgmt-data attribute. 373 The semantics of the encapsulated message is dependent on the key 374 management protocol that is used. 376 The general processing for handling a received answer SHALL follow 377 the following actions: 379 * The key management protocol is identified according to the prtcl-id 380 field. 382 * The key management data from the keymgmt-data field MUST be 383 extracted, base64 decoded to reconstruct the original message, and 384 then passed to the key management protocol for processing. 386 * If errors occur, or the key management offer is rejected, the 387 session SHALL be aborted. If possible an error message indicating 388 the failure SHOULD be sent back. 390 Otherwise, if all the steps are successful, the normal setup 391 proceeds. 393 3.1.2 Use of SDP with offer/answer and SIP 395 This section defines additional processing rules, to the general 396 rules defined in Section 3.1.1, applicable only to applications using 397 SDP with the offer-answer model [OAM] (and in particular SIP). 399 When an initial offer is created, the following offer-answer specific 400 procedure SHALL be applied: 402 * Before creating the key management data field, the list of protocol 403 identifiers MUST be provided by the SDP application to (each) key 404 management protocol, as defined in Section 3.1.4 (to defeat 405 bidding-down attacks). 407 For a received SDP offer that contains the key management attributes, 408 the following offer-answer specific procedure SHALL be applied: 410 * Before, or in conjunction with, passing the key management data to 411 the key management protocol, the complete list of protocol 412 identifier from the offer message is provided by the SDP 413 application to the key management protocol (as defined in Section 414 3.1.4). 416 When an answer is created, the following offer-answer specific 417 procedure SHALL be applied: 419 * If the key management rejects the offer, the answerer SHOULD return 420 a "606 Not Acceptable" message, optionally also including one or 421 more Warning headers (a 306 "Attribute not understood" when one of 422 the parameters is not supported, and a 399 "Miscellaneous warning" 423 with arbitrary information to be presented to a human user or 424 logged, see Section 20.43 in [SIP]). Further details about the 425 cause of failure MAY be described in an included message from the 426 key management protocol. The session is then aborted (and it is up 427 to local policy or end user to decide how to continue). 429 Note that the key management attribute (related to the same key 430 management protocol) MAY be present both at session level and at 431 media level. Consequently, the process SHALL be repeated for each 432 such key management attribute detected. In case the key management 433 processing of any such attribute does not succeed (e.g. 434 authentication failure, parameters not supported etc.), on either 435 session or media level, the entire session setup SHALL be aborted, 436 including those parts of the session which successfully completed 437 their part of the key management. 439 If more than one key management protocol is supported, multiple 440 instances of the key management attribute MAY be included in the 441 initial offer when using the offer-answer model, each transporting a 442 different key management protocol, thus indicating supported 443 alternatives. 445 If the offerer includes more than one key management protocol 446 attribute at session level (analogous for the media level), these 447 SHOULD be listed in order of preference (the first being the 448 preferred). The answerer selects the key management protocol it 449 wishes to use, and processes only it, on either session or media 450 level, or on both, according to where located. If the answerer does 451 not support any of the offerer's suggested key management protocols, 452 the receiver returns a "606 Not Acceptable" error message, whereby 453 the sender MUST abort the current setup procedure. 455 Note that the placement of multiple key management offers in a single 456 message has the disadvantage that the message expands and the 457 computational workload for the offerer will increase drastically. 458 Unless the guidelines of Section 3.1.4 are followed, multiple lines 459 may open up bidding-down attacks. 461 The offerer MUST include the key management data within an offer that 462 contains the media description it applies to. 464 Re-keying MUST be handled as a new offer, with the new proposed 465 parameters. The answerer treats this as a new offer where the key 466 management is the issue of change. The re-keying exchange MUST be 467 finalized before the security protocol can change the keys. The same 468 key management protocol used in the original offer SHALL also be used 469 in the new offer carrying re-keying. If the new offer carrying re- 470 keying fails (e.g., the authentication verification fails), the 471 answerer SHOULD send a "606 Not Acceptable" message, including one or 472 more Warning headers (at least a 306). The offerer MUST then abort 473 the session. 475 Note that, in multicast scenarios, unlike unicast, there is only a 476 single view of the stream [OAM], hence there MUST be a uniform 477 agreement of the security parameters. 479 3.1.3 Use of SDP with SAP 481 There are cases where SDP is used without conforming to the 482 offer/answer model; instead it is a one-way SDP distribution (i.e. 483 without back channel), such as when used with SAP and HTTP. 485 The processing follows the two first steps of the general SDP 486 processing (see Section 3.1.1). It can be noted that the processing 487 in this case differs from the offer/answer case in the fact that only 488 one key management protocol SHALL be offered (i.e. no negotiation 489 will be possible). This implies that the bidding down attack is not 490 an issue; therefore the countermeasure is not needed. The key 491 management protocol used MUST support one-way messages. 493 3.1.4 Bidding-down attack prevention 495 The possibility to support multiple key management protocols may, 496 unless properly handled, introduce bidding-down attacks. 497 Specifically, a man-in-the-middle could "peel off" cryptographically 498 strong offers (deleting the key management lines from the message), 499 leaving only weaker ones as the Responder's choice. To avoid this, 500 the list of identifiers of the proposed key management protocols MUST 501 be authenticated. The authentication MUST be done separately by each 502 key management protocol. 504 Accordingly, it MUST be specified (in the key management protocol 505 specification itself or in a companion document) how the list of key 506 management protocol identifiers can be processed to be authenticated 507 from the offerer to the answerer by the specific key management 508 protocol. Note that even if only one key management protocol is used, 509 that still MUST authenticate its own protocol identifier. 511 The list of protocol identifiers MUST then be given to each of the 512 selected (offered) key management protocols by the application with 513 ";" separated identifiers. All the offered protocol identifiers MUST 514 be included, in the same order as they appear in the corresponding 515 SDP description. 517 The protocol list can formally be described as 519 prtcl-list = KMID *(";" KMID) 521 where KMID is as defined in Section 2. 523 For example, if the offered protocols are MIKEY and two yet-to-be- 524 invented protocols KEYP1, KEYP2, the SDP is: 526 v=0 527 o=alice 2891092738 2891092738 IN IP4 lost.example.com 528 s=Secret discussion 529 t=0 0 530 c=IN IP4 lost.example.com 531 a=key-mgmt:mikey ddOoF9sdhskd727ghuiSDsdhsoKko7eWsnDSJD... 532 a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... 533 a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... 534 m=audio 39000 RTP/SAVP 98 535 a=rtpmap:98 AMR/8000 536 m=video 42000 RTP/SAVP 31 537 a=rtpmap:31 H261/90000 539 The protocol list, "mikey;keyp1;keyp2", would be generated from 540 the SDP description and used as input to each specified key 541 management protocol (together with the data for that protocol). 542 Each of the three protocols includes this protocol identifier 543 list in its authentication coverage (according to its protocol 544 specification). 546 If more than one protocol is supported by the offerer, it is 547 RECOMMENDED that all acceptable protocols are included in the first 548 offer, rather than making single, subsequent alternative offers in 549 response to error messages, see "Security Considerations". 551 3.2. RTSP usage 553 RTSP does not use the offer/answer model, as SIP does. This causes 554 some problems, as it is not possible (without modifying RTSP) to send 555 back an answer. To solve this, a new header has been introduced 556 (Section 2.2). This also assumes that the key management also has 557 some kind of binding to the media, so that the response to the server 558 will be processed as required. 560 The server SHALL be the Initiator of the key management exchange for 561 sessions in PLAY mode, i.e. transporting media from server to client. 562 The below text describes the behavior for PLAY mode. For any other 563 mode the behavior is not defined in this specification. 565 To obtain a session description, the client initially contacts the 566 server via a DESCRIBE message. The initial key management message 567 from the RTSP server is sent to the client in the SDP of the 200 OK 568 in response to the DESCRIBE. Note that only one key management 569 protocol SHALL be used per session / media level. A server MAY allow 570 the SDP with key-management attribute(s) to be distributed to the 571 client though other means than RTSP, although this is not specified 572 here. 574 The "uri" parameter of the KeyMgmt header is used to indicate for the 575 key management protocol on what context the carried message applies. 576 For key management messages on the SDP session level, the answer MUST 577 contain the RTSP aggregated control URL to indicate this. For Key 578 management messages initially on SDP media level, the key management 579 response message in the KeyMgmt header MAY use the RTSP media level 580 URL. For RTSP sessions not using aggregated control, i.e. no session 581 level control URI is defined, the key management protocol SHALL only 582 be invoked on individual media streams. In this case also, the key 583 management response SHALL be on individual media streams (i.e. one 584 RTSP key management header per media). 586 When responding to the initial key management message, the client 587 uses the new RTSP header (KeyMgmt) to send back an answer. How this 588 is done depends on the usage context: 590 * Key management protocol responses for the initial establishment of 591 security parameters for an aggregated RTSP session SHALL be sent 592 in the first SETUP of the session. This means that if the key 593 management is declared for the whole session but is setup in non- 594 aggregated fashion, i.e. one media per RTSP session, each SETUP 595 MUST carry the same response for the session level context. When 596 performing a setup of the second or any subsequent media in a RTSP 597 session the same key management parameters as established for the 598 first media also applies to these setups. 600 * Key management responses for the initial establishment of security 601 parameters for an individual media SHALL only be included in SETUP 602 for the corresponding media stream. 604 If a server receives a SETUP message in which it expects a key 605 management message, but none is included, a 403 Forbidden SHOULD be 606 returned to the client, whereby the current setup MUST be aborted. 608 When the server creates an initial SDP message, the procedure SHALL 609 be the same as described in Section 3.1.1. 611 The client processing of the initial SDP message from the server 612 SHALL follow the same procedures as described in Section 3.1.1, 613 except that, if there is an error, the session is aborted (no error 614 is sent back). 616 The client SHALL create the response, using the key management header 617 in RTSP, as follows: 619 * The identifier of the key management protocol used (e.g. MIKEY) 620 MUST be placed in the "prot" field of the header. The prot values 621 are maintained by IANA (Section 8). 623 * The keymgmt-data field MUST be created as follows: the key 624 management protocol MUST be used to create the key management 625 message. This message SHALL be base64 encoded by the RTSP 626 application and then encapsulated in the "data" field of the 627 header. The semantic of the encapsulated message is dependent on 628 the key management protocol that is used. 630 * Include, if necessary, the URL to indicate the context in the "uri" 631 parameter. 633 The server SHALL process a received key management header in RTSP as 634 follow: 636 * The key management protocol is identified according to the "prot" 637 field. 639 * The key management data from the "data" field MUST be extracted, 640 base64 decoded to reconstruct the original message, and then 641 passed to the key management protocol for processing. 643 * If the key management protocol is successful, the processing can 644 proceed according to normal rules. 646 * Otherwise, if the key management fails (e.g. due to authentication 647 failure or parameter not supported), an error is sent back as the 648 SETUP response using RTSP error code 463 (see Section 2.2) and the 649 session is aborted. It is up to the key management protocol to 650 specify (within the RTSP status code message or through key 651 management messages) details about the type of error that 652 occurred. 654 Re-keying within RTSP is for further study, given that media updating 655 mechanisms within RTSP are unspecified at the time this document is 656 written. 658 4. Example scenarios 660 The following examples utilize MIKEY [MIKEY] as the key management 661 protocol to be integrated into SDP and RTSP (see Section 5.1.). 663 Example 1 (SIP/SDP) 665 A SIP call is taking place between Alice and Bob. Alice sends an 666 Invite message consisting of the following offer: 668 v=0 669 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 670 s=Cool stuff 671 e=alice@w-land.example.com 672 t=0 0 673 c=IN IP4 w-land.example.com 674 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 675 m=audio 49000 RTP/SAVP 98 676 a=rtpmap:98 AMR/8000 677 m=video 52230 RTP/SAVP 31 678 a=rtpmap:31 H261/90000 680 i.e. Alice proposes to set up one audio stream and one video stream 681 that run over SRTP (signaled by the use of the SAVP profile). She 682 uses MIKEY to set up the security parameters for SRTP (Section 6). 683 The MIKEY message contains the security parameters, together with the 684 necessary key material. Note that MIKEY is exchanging the crypto 685 suite for both streams, as it is placed at the session level. Also, 686 MIKEY provides its own security, i.e. when Bob processes Alice's 687 MIKEY message, he will also find the signaling of the security 688 parameters used to secure the MIKEY exchange. Alice's authentication 689 information is also carried within the MIKEY message, to prove that 690 the message is authentic. 692 Upon receiving the offer, Bob checks the validity of the received 693 MIKEY message, and, in case of successful verification, he accepts 694 the offer and sends an answer back to Alice (with his authentication 695 information, and, if necessary, also some key material from his 696 side): 698 v=0 699 o=bob 2891092897 2891092897 IN IP4 foo.example.com 700 s=Cool stuff 701 e=bob@foo.example.com 702 t=0 0 703 c=IN IP4 foo.example.com 704 a=key-mgmt:mikey skaoqDeMkdwRW278HjKVB... 705 m=audio 49030 RTP/SAVP 98 706 a=rtpmap:98 AMR/8000 707 m=video 52230 RTP/SAVP 31 708 a=rtpmap:31 H261/90000 710 Upon receiving the answer, Alice verifies the correctness of it. In 711 case of success, at this point Alice and Bob share the security 712 parameters and the keys needed for a secure RTP communication. 714 Example 2 (SDP) 716 This example shows how Alice would have done if she wished to protect 717 only the audio stream. She would have placed the MIKEY line at media 718 level for the audio stream only (also specifying the use of the SRTP 719 profile there, SAVP). The semantic of the MIKEY messages is as in the 720 previous case, but applies only to the audio stream. 722 v=0 723 o=alice 2891092738 2891092738 IN IP4 w-land.example.com 724 s=Cool stuff 725 e=alice@w-land.example.com 726 t=0 0 727 c=IN IP4 w-land.example.com 728 m=audio 49000 RTP/SAVP 98 729 a=rtpmap:98 AMR/8000 730 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 731 m=video 52230 RTP/AVP 31 732 a=rtpmap:31 H261/90000 734 Bob would then act as described in the previous example, including 735 the MIKEY answer at the media level for the audio stream (as Alice 736 did). 738 Note that even if the key management attribute were specified at 739 session level, the video part would not be affected by this (as a 740 security profile is not used, instead the RTP/AVP profile is 741 signaled). 743 Example 3 (RTSP) 745 A client wants to set up a streaming session and requests a media 746 description from the streaming server. 748 DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 749 CSeq: 312 750 Accept: application/sdp 751 From: user@example.com 753 The server sends back an OK message including an SDP description, 754 together with the MIKEY message. The MIKEY message contains the 755 necessary security parameters that the server is willing of offering 756 to the client, together with authentication information (to prove 757 that the message is authentic) and the key material. The SAVP profile 758 also signals the use of SRTP for securing the media sessions. 760 RTSP/1.0 200 OK 761 CSeq: 312 762 Date: 23 Jan 1997 15:35:06 GMT 763 Content-Type: application/sdp 764 Content-Length: 478 766 v=0 767 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 768 s=Action Movie 769 e=action@movie.example.com 770 t=0 0 771 c=IN IP4 movie.example.com 772 a=control:rtsp://movie.example.com/action 773 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. 774 m=audio 0 RTP/SAVP 98 775 a=rtpmap:98 AMR/8000 776 a=control:rtsp://movie.example.com/action/audio 777 m=video 0 RTP/SAVP 31 778 a=rtpmap:31 H261/90000 779 a=control:rtsp://movie.example.com/action/video 781 The client checks the validity of the received MIKEY message, and, in 782 case of successful verification, it accept the message. The client 783 then includes its key management data in the SETUP request going back 784 to the server, the client authentication information (to prove that 785 the message is authentic) and, if necessary, some key material. 787 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 788 CSeq: 313 789 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 790 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action"; 791 data="skaoqDeMkdwRW278HjKVB..." 793 The server processes the request including checking the validity of 794 the key management header. 796 RTSP/1.0 200 OK 797 CSeq: 313 798 Session: 12345678 799 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057; 800 server_port=5000-5001 802 Note than in this case the key management line was specified at the 803 session level, the key management information only goes into the 804 SETUP related to the first stream. The "uri" indicates to the server 805 that the context is for the whole aggregated session the key 806 management applies. The RTSP client then proceeds setting up the 807 second media (video) in aggregation with the audio. As the two media 808 are run in aggregation and the key context was established in the 809 first exchange, no more key management messages are needed. 811 Example 4 (RTSP) 813 The use of the MIKEY message at the media level would change the 814 previous example as follows. 816 The 200 OK would contain the two distinct SDP attributes for MIKEY at 817 the media level: 819 RTSP/1.0 200 OK 820 CSeq: 312 821 Date: 23 Jan 1997 15:35:06 GMT 822 Content-Type: application/sdp 823 Content-Length: 561 825 v=0 826 o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com 827 s=Action Movie 828 e=action@movie.example.com 829 t=0 0 830 c=IN IP4 movie.example.com 831 a=control:rtsp://movie.example.com/action 832 m=audio 0 RTP/SAVP 98 833 a=rtpmap:98 AMR/8000 834 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. 835 a=control:rtsp://movie.example.com/action/audio 836 m=video 0 RTP/SAVP 31 837 a=rtpmap:31 H261/90000 838 a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. 839 a=control:rtsp://movie.example.com/action/video 840 Each RTSP header are inserted in the SETUP related to the audio and 841 video separately: 843 SETUP rtsp://movie.example.com/action/audio RTSP/1.0 844 CSeq: 313 845 Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 846 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio"; 847 data="skaoqDeMkdwRW278HjKVB..." 849 and similarly for the video session: 851 SETUP rtsp://movie.example.com/action/video RTSP/1.0 852 CSeq: 315 853 Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059 854 keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video"; 855 data="RW278HjKVBskaoqDeMkdw..." 857 Note: The "uri" parameter could be excluded from the two SETUP 858 messages in this example. 860 5. Adding further Key management protocols 862 This framework cannot be used with all key management protocols. The 863 key management protocol needs to comply with the requirements 864 described in Section 3. In addition to this, the following needs to 865 be defined: 867 * The key management protocol identifier to be used as the protocol 868 identifier should be registered at IANA according to Section 8. 870 * The information that the key management needs from SDP and RTSP, 871 and vice versa, as described in Section 3. The exact API is 872 implementation specific, but it MUST at least support the exchange 873 of the specified information. 875 * The key management protocol to be added MUST be such, that the 876 processing in Section 3 (describing its interactions with SDP and 877 RTSP) can be applied. Note in particular, Section 3.1.4 requires 878 each key management protocol to specify how the list of protocol 879 identifiers is authenticated inside that key management protocol. 880 The key management MUST always be given the protocol identifier(s) 881 of the key management protocol(s) included in the offer in the 882 correct order as they appear. 884 Finally, it is obviously crucial to analyze possible security 885 implications induced by the introduction of a new key management 886 protocol in the described framework. 888 Today, the MIKEY protocol [MIKEY] has adopted the key management 889 extensions to work together with SIP and RTSP (see Section 6). Other 890 protocols MAY use the described attribute and header, e.g. Kerberos 891 [KERB], however this is subject to future standardization. 893 6. Integration of MIKEY 895 [MIKEY] describes a key management protocol for real-time 896 applications (both for peer-to-peer communication and group 897 communication). MIKEY can be integrated within SDP and RTSP, 898 following the rules and guidelines described in this document. 900 MIKEY satisfies the requirements described in Section 3. The MIKEY 901 message is formed as defined in [MIKEY], then passed from MIKEY to 902 the SDP application that base64 encodes it, and encapsulates it in 903 the keymgmt-data attribute. The examples in Section 4 use MIKEY, 904 where the semantic of the exchange is also briefly explained. 906 The key management protocol identifier (KMID) to be used as the 907 protocol identifier SHALL be "mikey" and is registered at IANA, see 908 in detail Section 8. 910 The information that the key management needs from SDP and RTSP, and 911 vice versa, follows Section 3. To avoid bidding-down attacks, the 912 directives in Section 3.1.4 are followed. The list of protocol 913 identifiers is authenticated within MIKEY by placing the list in a 914 General Extension Payload (of type "SDP IDs", [MIKEY]), which then 915 automatically will be integrity protected/signed. The receiver SHALL 916 then match the list in the General Extension Payload with the list 917 included in SDP and SHOULD (according to policy) if they differ, or 918 if integrity/signature verification fails, reject the offer. 920 The server will need to be able to know the identity of the Client 921 before creating and sending a MIKEY message. To signal the (MIKEY) 922 identity of the client to the server in the DESCRIBE, it is 923 RECOMMENDED to include the From header field in RTSP. Other methods 924 to establish the identity could be using the IP address or retrieving 925 the identity from the RTSP authentication if used. 927 6.1 MIKEY Interface 929 This subsection describes some aspects, which implementers SHOULD 930 consider. If the MIKEY implementation is separate from the 931 SDP/SIP/RTSP, an application programming interface (API) between 932 MIKEY and those protocols is needed with certain functionality 933 (however, exactly what it looks like is implementation dependent). 935 Implementers of MIKEY are RECOMMENDED to consider providing at least 936 the following functionality: 938 * the possibility for MIKEY to receive information about the sessions 939 negotiated. This is to some extent implementation dependent. But 940 it is RECOMMENDED that, in the case of SRTP streams, the number of 941 SRTP streams is included (and the direction of these). It is also 942 RECOMMENDED to provide the destination addresses and ports to 943 MIKEY. When referring to streams described in SDP, MIKEY allocated 944 two consecutive numbers for the related Crypto Session indexes (as 945 each stream can be bi-directional). An example: if the SDP 946 contains two m lines (specifying whatever direction of the 947 streams), and MIKEY is at the session level, then MIKEY allocates 948 e.g. the Crypto Sessions Identifiers (CS IDs, see [MIKEY)] '1' and 949 '2' for the first m line, and '3' and '4' for the second m line. 951 * the possibility for MIKEY to receive incoming MIKEY messages and 952 return a status code from/to the SIP/RTSP application. 954 * the possibility for the SIP or RTSP applications to receive 955 information from MIKEY. This would typically include the receiving 956 of the Crypto Session Bundle Identifier (CSB ID, see [MIKEY], to 957 later be able to identify the active MIKEY session), and the SSRCs 958 and the rollover counter (ROC, see [SRTP]) for SRTP usage. It is 959 also RECOMMENDED that extra information about errors can be 960 received. 962 * the possibility for the SIP or RTSP application to receive outgoing 963 MIKEY messages. 965 * the possibility to tear down a MIKEY CSB (e.g. if the SIP session 966 is closed, the CSB SHOULD also be closed). 968 7. Security Considerations 970 The framework for transfer of key management data as described here 971 is intended to provide the security parameters for the end-to-end 972 protection of the media session. It is furthermore good practice to 973 secure the session setup (e.g. SDP, SIP, RTSP, SAP). However, it 974 might be that the security of the session setup is not possible to 975 achieve end-to-end, but only hop-by-hop. For example, SIP requires 976 intermediate proxies to have access to part of the SIP message, and 977 sometimes also to the SDP description (c.f. [E2M]). General security 978 considerations for the session setup can be found in SDP [SDPnew], 979 SIP [SIP], and RTSP [RTSP]. The framework defined in this memo is 980 useful when the session setup is not protected in an end-to-end 981 fashion, but the media streams needs to be end-to-end protected, 982 hence the security parameters such as keys are not wanted revealed to 983 intermediaries. 985 The security will also depend on the encapsulated level of security 986 the key management protocol offers. It follows that, under the 987 assumption that the key management schemes are secure, the SDP can be 988 passed along unprotected without affecting the key management as 989 such, and the media streams will still be secure even if some 990 attackers gained knowledge of the SDP contents. Further security 991 considerations can be found for each key management protocol (for 992 MIKEY these can be found in [MIKEY]). 994 However, if the SDP messages are not sent authenticated between the 995 parties, it is possible for an active attacker to change attributes 996 without being detected. As the key management protocol may 997 (indirectly) rely on some of the session information from SDP (e.g., 998 address information), an attack on SDP may have indirect consequences 999 on the key management. Even if the key management protocol does not 1000 rely on parameters of SDP and will not be affected by manipulation of 1001 these, different DoS attacks aimed at SDP may lead to undesired 1002 interruption in the setup. 1004 The use of multiple key management protocols in the same offer may 1005 open up the possibility of a bidding-down attack, as specified in 1006 Section 3.1.4. To exclude such possibility, the authentication of the 1007 protocol identifier list is used. Note though, that the security 1008 level of the authenticated protocol identifier will be as high (or 1009 low), as the "weakest" protocol. Therefore, it is discouraged to 1010 offer protocols with too different security levels. 1012 Note that it is impossible to assure the authenticity of a declined 1013 offer, since even if it comes from the true respondent, the fact that 1014 the answerer declines the offer usually means that he does not 1015 support the protocol(s) offered, and consequently cannot be expected 1016 to authenticate the response either. This means that if the Initiator 1017 is unsure of which protocol(s) the Responder supports, we RECOMMEND 1018 that the Initiator offers all acceptable protocols in a single offer. 1019 If not, this opens up the possibility for a "man-in-the-middle" 1020 (MITM) to affect the outcome of the eventually agreed upon protocol, 1021 by faking unauthenticated error messages until the Initiator 1022 eventually offers a protocol "to the liking" of the MITM. This is not 1023 really a security problem, but rather a mild form of denial of 1024 service that can be avoided by following the above recommendation. In 1025 the case that the response declines any security (therefore there is 1026 impossibility of authenticating it), the session setup SHALL be 1027 aborted. 1029 8. IANA Considerations 1031 8.1. SDP Attribute Registration 1033 A new SDP attribute needs to be registered for the purpose of key 1034 management protocol integration with SDP. 1036 Contact: Fredrik Lindholm 1037 mailto: fredrik.lindholm@ericsson.com 1038 tel: +46 8 58531705 1040 SDP Attribute Field ("att-field"): 1042 Name: key-mgmt-att-field 1043 Long form: key management protocol attribute field 1044 Type of name: att-field 1045 Type of attribute: Media and session level 1046 Purpose: See RFC xxxx, Section 2. 1047 Reference: RFC xxxx, Section 2.1 1048 Values: See RFC xxxx, Section 2.1 and 8.3. 1050 8.2. RTSP Registration 1052 A new RTSP Header needs to be registered for the purpose of key 1053 management protocol integration with RTSP. 1055 Following the guidelines of [RTSP], the registration is defined as 1056 follows: 1058 Header name: keymgmt 1059 Header syntax: see RFC xxxx, Section 2.2 1060 Intended usage: see RFC xxxx, Section 2.2 1061 Proxy treatment: Proxies SHALL NOT add, change, or delete the 1062 header. The proxy does not need to read this 1063 header. 1064 Purpose: see RFC xxxx, Section 2 1066 The RTSP Status-Code "463" [RFC xxxx], with the default string "Key 1067 management failure", needs to be registered. 1069 8.3. Protocol Identifier Registration 1071 This document defines one new name space, the "SDP/RTSP key 1072 management protocol identifier", associated with the protocol 1073 identifier, KMID, defined in Section 2 to be used with the above 1074 registered attributes in SDP and RTSP. 1076 A new registry needs to be set up for the KMID parameter, with the 1077 following registration created initially: "mikey". 1079 Contact: Fredrik Lindholm 1080 mailto: fredrik.lindholm@ericsson.com 1081 tel: +46 8 58531705 1083 Value name: mikey 1084 Long name: Multimedia Internet KEYing 1085 Purpose: Usage of MIKEY with the key-mgmt-att-field 1086 attribute and the keymgmt RTSP header 1087 Reference: Section 7 in RFC yyyy 1089 Note that this registration implies that the protocol identifier, 1090 KMID, name space will be shared between SDP and RTSP. 1092 Further values may be registered according to the "Specification 1093 Required" policy as defined in [RFC2434]. Each new registration needs 1094 to indicate the parameter name, and register it within IANA. Note 1095 that the parameter name is case sensitive and it is RECOMMENDED that 1096 the name to be in lower case letters. For each new registration, it 1097 is mandatory that a permanent, stable, and publicly accessible 1098 document exists that specifies the semantics of the registered 1099 parameter and the requested details of interaction between the key 1100 management protocol and SDP, as specified in RFC xxxx. 1102 New values MUST be register with IANA. Registrations SHALL include 1103 the following information: 1105 * Contact: the contact name and email address 1106 * Value name: the name of the value being registered (which MUST 1107 comply with the KMID as defined in Section 2) 1108 * Long Name: long-form name in English 1109 * Purpose: short explanation of the purpose of the registered name. 1110 * Reference: a reference to the specification (e.g. RFC number) 1111 providing the usage guidelines in accordance to Section 5 (and 1112 also complying to the specified requirements). 1114 9. Acknowledgments 1116 The authors would like to thank Joerg Ott, Rolf Blom, Magnus Brolin, 1117 Johan Bilien, Jon-Olov Vatn, and Erik Eliasson. A special thanks to 1118 Colin Perkins and Magnus Westerlund, who contributed in many 1119 sections. 1121 10. Author's Addresses 1123 Jari Arkko 1124 Ericsson 1125 02420 Jorvas Phone: +358 40 5079256 1126 Finland Email: jari.arkko@ericsson.com 1128 Elisabetta Carrara 1129 Ericsson Research 1130 SE-16480 Stockholm Phone: +46 8 50877040 1131 Sweden EMail: elisabetta.carrara@ericsson.com 1133 Fredrik Lindholm 1134 Ericsson Research 1135 SE-16480 Stockholm Phone: +46 8 58531705 1136 Sweden EMail: fredrik.lindholm@ericsson.com 1137 Mats Naslund 1138 Ericsson Research 1139 SE-16480 Stockholm Phone: +46 8 58533739 1140 Sweden EMail: mats.naslund@ericsson.com 1142 Karl Norrman 1143 Ericsson Research 1144 SE-16480 Stockholm Phone: +46 8 4044502 1145 Sweden EMail: karl.norrman@ericsson.com 1147 11. References 1149 11.1. Normative References 1151 [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and 1152 Norrman, K., "MIKEY: Multimedia Internet KEYing", IETF, RFC yyyy, 1153 [Internet Draft, ]. 1155 [OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with 1156 the Session Description Protocol (SDP)", IETF, RFC 3264. 1158 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time 1159 Streaming Protocol (RTSP)", IETF, RFC 2326. 1161 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1162 Requirement Levels", IETF, RFC 2119. 1164 [SDPnew] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 1165 Description Protocol", Internet Draft, IETF, draft-ietf-mmusic-sdp- 1166 new-15.txt. 1168 [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", IETF, RFC 1169 3261. 1171 [RFC2234] Crocker, D. and Overell, P., "Augmented BNF for Syntax 1172 Specifications: ABNF", RFC 2234, November 1997. 1174 [RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an 1175 IANA Considerations Section in RFCs", IETF, RFC 2434. 1177 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1178 Encodings", IETF, RFC 3548. 1180 11.2. Informative References 1182 [E2M] Ono, K. and Tachimoto, S., "End-to-middle security in the 1183 Session Initiation Protocol (SIP)", Internet Draft, IETF, draft-ono- 1184 sipping-end2middle-security-01. 1186 [KERB] Kohl, J., Neuman, C., "The Kerberos Network Authentication 1187 Service (V5)", IETF, RFC 1510. 1189 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., Norrman, 1190 K., "The Secure Real-time Transport Protocol", IETF, RFC 3711. 1192 Copyright Notice 1194 Copyright (C) The Internet Society (2004). This document is subject 1195 to the rights, licenses and restrictions contained in BCP 78, and 1196 except as set forth therein, the authors retain all their rights. 1198 Disclaimer of Validity 1200 This document and the information contained herein are provided on an 1201 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1202 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1203 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1204 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1205 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1206 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1208 This Internet-Draft expires in October 2004.