idnits 2.17.1 draft-ietf-mmusic-securityprecondition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 613. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 629), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'SDP' is mentioned on line 71, but not defined == Unused Reference: 'RFC2327' is defined on line 554, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Flemming Andreasen 3 MMUSIC Working Group Dan Wing 4 Internet-Draft 5 Expires: April 2006 Cisco Systems 6 October, 2005 8 Security Preconditions for 9 Session Description Protocol Media Streams 10 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/lid-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 20, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document defines a new security precondition for the Session 44 Description Protocol precondition framework described in RFCs 3312 45 and 4032. A security precondition can be used to delay session 46 establishment or modification until media stream security has been 47 negotiated successfully. 49 1 Notational Conventions............................................2 50 2 Introduction......................................................2 51 3 Security Precondition Definition..................................3 52 4 Examples..........................................................5 53 4.1 SDP Security Descriptions Example.............................5 54 4.2 Key Management Extension for SDP Example......................8 55 5 Security Considerations..........................................10 56 6 IANA Considerations..............................................11 57 7 Acknowledgements.................................................11 58 8 Authors' Addresses...............................................11 59 9 Normative References.............................................12 60 10 Informative References.........................................12 61 11 Intellectual Property Statement................................14 63 1 Notational Conventions 65 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2 Introduction 71 The concept of a Session Description Protocol (SDP) [SDP] 72 precondition is defined in [RFC3312] as updated by [RFC4032]. A 73 precondition is a condition that has to be satisfied for a given 74 media stream in order for session establishment or modification to 75 proceed. When the precondition is not met, session progress is 76 delayed until the precondition is satisfied or the session 77 establishment fails. For example, RFC 3312 defines the Quality of 78 Service precondition, which is used to ensure availability of 79 network resources prior to establishing (i.e. alerting) a call. 81 Media streams can either be provided in cleartext and with no 82 integrity protection, or some kind of media security can be applied, 83 e.g., confidentiality and/or message integrity. For example, the 84 Audio/Video profile of the Real-Time Transfer protocol (RTP) 85 [RFC3551] is normally used without any security services whereas the 86 Secure Real-time Transport Protocol (SRTP) [SRTP] is always used 87 with security services. When media stream security is being 88 negotiated, e.g., using the mechanism defined in SDP Security 89 Descriptions [SDESC], both the offerer and the answerer need to know 90 the cryptographic parameters being used for the media stream; the 91 offerer may provide multiple choices for the cryptographic 92 parameters, or the cryptographic parameters selected by the answerer 93 may differ from those of the offerer (e.g. the key used in one 94 direction versus the other). In such cases, to avoid media 95 clipping, the offerer must receive the answer prior to receiving any 96 media packets from the answerer. This can be achieved by using a 97 security precondition, which ensures the successful negotiation of 98 media stream security parameters prior to session establishment or 99 modification. 101 3 Security Precondition Definition 103 The security precondition type is defined by the string "sec" and 104 hence we modify the grammar found in RFC 3312 as follows: 106 precondition-type = "sec" | "qos" | token 108 RFC 3312 defines support for two kinds of status types, namely 109 segmented and end-to-end. The security precondition-type defined 110 here MUST be used with the end-to-end status type; use of the 111 segmented status type is undefined. 113 An entity that wishes to delay session establishment or modification 114 until media stream security has been established uses the security 115 precondition-type in an offer. When a mandatory security 116 precondition is received in an offer, session establishment or 117 modification MUST be delayed until the security precondition has 118 been met, i.e. cryptographic parameters (cipher, key, etc.) for a 119 secure media stream are known to have been negotiated in the 120 direction(s) required. A secure media stream is here defined as a 121 media stream that uses some kind of security service, e.g. message 122 integrity, confidentiality or both, regardless of the cryptographic 123 strength of the mechanisms being used. 125 As an extreme example of this, Secure RTP (SRTP) using the NULL 126 encryption algorithm and no message integrity would satisfy the 127 above whereas use of plain RTP would not. Note though, that use 128 of SRTP without authentication is discouraged. 130 The delay of session establishment defined here implies that 131 alerting of the called party MUST NOT occur and media for which 132 security is being negotiated MUST NOT be exchanged until the 133 precondition has been satisfied. In cases where secure media and 134 other non-secure data is multiplexed on a media stream, e.g. when 135 Interactive Connectivity Establishment [ICE] is being used, the non- 136 secure data is allowed to be exchanged prior to the security 137 precondition being satisfied. 139 The direction tags defined in RFC 3312 are interpreted as follows: 141 * send: Media stream security negotiation is at a stage where it is 142 possible to send secure media packets to the other party and the 143 other party will be able to process them correctly. The 144 definition of "media packets" includes all packets that make up 145 the media stream. In the case of Secure RTP for example, it 146 includes SRTP as well as SRTCP. When media and non-media packets 147 are multiplexed on a given media stream, e.g. when ICE is being 148 used, the requirement applies to the media packets only. 150 * recv: Media stream security negotiation is at a stage where it is 151 possible to receive and correctly process secure media stream 152 packets sent by the other party. 154 The precise criteria for determining when the other party is able to 155 correctly process secure media stream packets depends on the secure 156 media stream protocol being used as well as the mechanism by which 157 the required cryptographic parameters are negotiated. 159 We here provide details for SRTP negotiated through SDP security 160 descriptions as defined in [SDESC]: 162 * When the offerer requests the "send" security precondition, it 163 needs to receive the answer before the security precondition is 164 satisfied. The reason for this is twofold. First, the offerer 165 needs to know where to send the media to. Secondly, in the case 166 where alternative cryptographic parameters are offered, the 167 offerer needs to know which set was selected. The answerer does 168 not know when the answer is actually received by the offerer 169 (which in turn will satisfy the precondition), and hence the 170 answerer needs to use the confirm-status attribute [RFC3312]. 171 This will make the offerer generate a new offer showing the 172 updated status of the precondition. 174 * When the offerer requests the "recv" security precondition, it 175 also needs to receive the answer before the security precondition 176 is satisfied. The reason for this is straightforward: The answer 177 contains the cryptographic parameters that will be used by the 178 answerer for sending media to the offerer; prior to receipt of 179 these cryptographic parameters the offerer is unable to 180 authenticate or decrypt media. 182 When security preconditions are used with the Key Management 183 Extensions for Session Description Protocol (SDP) [KMGMT], the 184 details depend on the actual key management protocol being used. 186 After an initial offer/answer sequence in which the security 187 precondition is requested, any subsequent offer/answer sequence for 188 the purpose of updating the status of the precondition SHOULD use 189 the same key material as the initial offer/answer sequence. This 190 means that the key-mgmt attribute lines [KMGMT] or crypto attribute 191 lines [SDESC] in SDP offers that are sent in response to SDP answers 192 containing a confirm-status field [RFC3312] SHOULD repeat the same 193 data as that sent in the previous SDP offer. If applicable to the 194 key management protocol or SDP security description, the SDP answers 195 to these SDP offers SHOULD repeat the same data in the key-mgmt 196 attribute lines [KMGMT] or crypto attribute lines [SDESC] as that 197 sent in the previous SDP answer. 199 Of course, this duplication of key exchange during precondition 200 establishment is not to be interpreted as a replay attack. This 201 issue may be solved if, e.g. the SDP implementation recognizes that 202 the key management protocol data is identical in the second 203 offer/answer exchange and avoids forwarding the information to the 204 security layer for further processing. 206 Security preconditions may have a strength-tag of either "mandatory" 207 or "optional". When a mandatory security precondition is offered, 208 and the answerer cannot satisfy the security precondition, e.g. 209 because the offer does not include any parameters related to 210 establishing a secure media stream, the offer MUST be rejected as 211 described in RFC 3312. When an optional security precondition is 212 offered, the answerer MUST generate its answer SDP as soon as 213 possible; since session progress is not delayed in this case, 214 clipping may occur. If the answerer wants to avoid clipping and 215 delay session progress until the offerer has received the answer, 216 the answerer MUST increase the strength of the security precondition 217 by using a strength-tag of "mandatory" in the answer. 219 Note that use of a "mandatory" precondition requires the presence 220 of a SIP "Require" header with the option tag "precondition": Any 221 SIP UA that does not support a mandatory precondition will 222 consequently reject such requests. To get around this issue, an 223 optional security precondition and the SIP "Supported" header with 224 the option tag "precondition" can be used instead. 226 Offers with security preconditions in re-INVITEs or UPDATEs follow 227 the rules given in Section 6 of RFC 3312, i.e.: 229 "Both user agents SHOULD continue using the old session parameters 230 until all the mandatory preconditions are met. At that moment, 231 the user agents can begin using the new session parameters." 233 4 Examples 235 4.1 SDP Security Descriptions Example 237 The call flow of Figure 1 shows a basic session establishment using 238 the Session Initiation Protocol [SIP] and SDP security descriptions 239 [SDESC] with security descriptions for the secure media stream (SRTP 240 in this case). 242 A B 244 | | 245 |-------------(1) INVITE SDP1--------------->| 246 | | 247 |<------(2) 183 Session Progress SDP2--------| 248 | | 249 |----------------(3) PRACK SDP3------------->| 250 | | 251 |<-----------(4) 200 OK (PRACK) SDP4---------| 252 | | 253 |<-------------(5) 180 Ringing---------------| 254 | | 255 | | 256 | | 258 Figure 1: Security Preconditions with SDP Security 259 Descriptions Example 261 The SDP descriptions of this example are shown below - we have 262 omitted the details of the SDP security descriptions as well as any 263 SIP details for clarity of the security precondition described here: 265 SDP1: A includes a mandatory end-to-end security precondition for 266 both the send and receive direction in the initial offer as well as 267 a "crypto" attribute (see [SDESC]), which includes keying material 268 that can be used by A to generate media packets. Since B does not 269 know any of the security parameters yet, the current status (see RFC 270 3312) is set to "none". A's local status table (see RFC 3312) for 271 the security precondition is as follows: 273 Direction | Current | Desired Strength | Confirm 274 -----------+----------+------------------+---------- 275 send | no | mandatory | no 276 recv | no | mandatory | no 278 and the resulting offer SDP is: 280 m=audio 20000 RTP/SAVP 0 281 c=IN IP4 192.0.2.1 282 a=curr:sec e2e none 283 a=des:sec mandatory e2e sendrecv 284 a=crypto:foo... 286 SDP2: When B receives the offer and generates an answer, B knows the 287 (send and recv) security parameters of both A and B. However, A 288 does not know B's security parameters, so the current status of B's 289 "send" security precondition (which equal A's "recv" security 290 precondition) is "no". Similarly, A does not know any of B's SDP 291 information, so B's "send" security precondition is also "no". B's 292 local status table therefore looks as follows: 294 Direction | Current | Desired Strength | Confirm 295 -----------+----------+------------------+---------- 296 send | no | mandatory | no 297 recv | no | mandatory | no 299 B requests A to confirm when A knows the security parameters used in 300 the send and receive direction and hence the resulting answer SDP 301 becomes: 303 m=audio 30000 RTP/SAVP 0 304 c=IN IP4 192.0.2.4 305 a=curr:sec e2e none 306 a=des:sec mandatory e2e sendrecv 307 a=conf:sec e2e sendrecv 308 a=crypto:bar... 310 SDP3: When A receives the answer, A updates its local status table 311 based on the rules in RFC 3312. A knows the security parameters of 312 both the send and receive direction and hence A's local status table 313 is updated as follows: 315 Direction | Current | Desired Strength | Confirm 316 -----------+----------+------------------+---------- 317 send | yes | mandatory | yes 318 recv | yes | mandatory | yes 320 Since B requested confirmation of the send and recv security 321 preconditions, and both are now satisfied, A immediately sends an 322 updated offer (3) to B showing that the security preconditions are 323 satisfied: 325 m=audio 20000 RTP/SAVP 0 326 c=IN IP4 192.0.2.1 327 a=curr:sec e2e sendrecv 328 a=des:sec mandatory e2e sendrecv 329 a=crypto:foo... 331 Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] 332 since the precondition is satisfied immediately, and the original 333 offer/answer exchange is complete) 335 SDP4: Upon receiving the updated offer, B updates its local status 336 table based on the rules in RFC 3312 which yields the following: 338 Direction | Current | Desired Strength | Confirm 339 -----------+----------+------------------+---------- 340 send | yes | mandatory | no 341 recv | yes | mandatory | no 343 B responds with an answer (4) which contains the current status of 344 the security precondition (i.e., sendrecv) from B's point of view: 346 m=audio 30000 RTP/SAVP 0 347 c=IN IP4 192.0.2.4 348 a=curr:sec e2e sendrecv 349 a=des:sec mandatory e2e sendrecv 350 a=crypto:bar... 352 B's local status table indicates that all mandatory preconditions 353 have been satisfied, and hence session establishment resumes; B 354 returns a 180 (Ringing) response (5) to indicate alerting. 356 4.2 Key Management Extension for SDP Example 358 The call flow of Figure 2 shows a basic session establishment using 359 the Session Initiation Protocol [SIP] and Key Management Extensions 360 for SDP [KMGMT] with security descriptions for the secure media 361 stream (SRTP in this case): 363 A B 365 | | 366 |-------------(1) INVITE SDP1--------------->| 367 | | 368 |<------(2) 183 Session Progress SDP2--------| 369 | | 370 |----------------(3) PRACK SDP3------------->| 371 | | 372 |<-----------(4) 200 OK (PRACK) SDP4---------| 373 | | 374 |<-------------(5) 180 Ringing---------------| 375 | | 376 | | 377 | | 379 Figure 2: Security Preconditions with Key Management 380 Extensions for SDP Example 382 The SDP descriptions of this example are shown below - we show an 383 example use of MIKEY [MIKEY] with the Key Management Extensions, 384 however we have omitted the details of the MIKEY parameters as well 385 as any SIP details for clarity of the security precondition 386 described here: 388 SDP1: A includes a mandatory end-to-end security precondition for 389 both the send and receive direction in the initial offer as well as 390 a "key-mgmt" attribute (see [KMGMT]), which includes keying material 391 that can be used by A to generate media packets. Since B does not 392 know any of the security parameters yet, the current status (see RFC 393 3312) is set to "none". A's local status table (see RFC 3312) for 394 the security precondition is as follows: 396 Direction | Current | Desired Strength | Confirm 397 -----------+----------+------------------+---------- 398 send | no | mandatory | no 399 recv | no | mandatory | no 401 and the resulting offer SDP is: 403 m=audio 20000 RTP/SAVP 0 404 c=IN IP4 192.0.2.1 405 a=curr:sec e2e none 406 a=des:sec mandatory e2e sendrecv 407 a=key-mgmt:mikey AQAFgM0X... 409 SDP2: When B receives the offer and generates an answer, B knows the 410 (send and recv) security parameters of both A and B. B generates 411 keying material for sending media to A, however, A does not know B's 412 keying material, so the current status of B's "send" security 413 precondition (which equal A's "recv" security precondition) is "no". 414 Similarly, A does not know any of B's SDP information, so B's "recv" 415 security precondition is also "no". B's local status table 416 therefore looks as follows: 418 Direction | Current | Desired Strength | Confirm 419 -----------+----------+------------------+---------- 420 send | no | mandatory | no 421 recv | no | mandatory | no 423 B requests A to confirm when A knows the security parameters used in 424 the send and receive direction and hence the resulting answer SDP 425 becomes: 427 m=audio 30000 RTP/SAVP 0 428 c=IN IP4 192.0.2.4 429 a=curr:sec e2e none 430 a=des:sec mandatory e2e sendrecv 431 a=conf:sec e2e sendrecv 432 a=key-mgmt:mikey AQAFgM0X... 434 Note that the actual MIKEY data in the answer differs from that in 435 the offer, however we have only shown the initial and common part of 436 the MIKEY value in the above. 438 SDP3: When A receives the answer, A updates its local status table 439 based on the rules in RFC 3312. A now knows all the security 440 parameters of both the send and receive direction and hence A's 441 local status table is updated as follows: 443 Direction | Current | Desired Strength | Confirm 444 -----------+----------+------------------+---------- 445 send | yes | mandatory | yes 446 recv | yes | mandatory | yes 448 Since B requested confirmation of the send and recv security 449 preconditions, and both are now satisfied, A immediately sends an 450 updated offer (3) to B showing that the security preconditions are 451 satisfied: 453 m=audio 20000 RTP/SAVP 0 454 c=IN IP4 192.0.2.1 455 a=curr:sec e2e sendrecv 456 a=des:sec mandatory e2e sendrecv 457 a=key-mgmt:mikey AQAFgM0X... 459 SDP4: Upon receiving the updated offer, B updates its local status 460 table based on the rules in RFC 3312 which yields the following: 462 Direction | Current | Desired Strength | Confirm 463 -----------+----------+------------------+---------- 464 send | yes | mandatory | no 465 recv | yes | mandatory | no 467 B responds with an answer (4) which contains the current status of 468 the security precondition (i.e., sendrecv) from B's point of view: 470 m=audio 30000 RTP/SAVP 0 471 c=IN IP4 192.0.2.4 472 a=curr:sec e2e sendrecv 473 a=des:sec mandatory e2e sendrecv 474 a=key-mgmt:mikey AQAFgM0X... 476 B's local status table indicates that all mandatory preconditions 477 have been satisfied, and hence session establishment resumes; B 478 returns a 180 (Ringing) response (5) to indicate alerting. 480 5 Security Considerations 482 In addition to the general security for preconditions provided in 483 RFC 3312, the following security issues, which are specific to 484 security preconditions, should be considered. 486 Security preconditions delay session establishment until 487 cryptographic parameters required to send and/or receive media have 488 been negotiated. Negotiation of such parameters can fail for a 489 variety of reasons, including policy preventing use of certain 490 cryptographic algorithms, keys, and other security parameters. If 491 intermediaries can remove security preconditions or downgrade the 492 strength from an offer/answer exchange, they can thereby cause user 493 alerting for a session that may have no functioning media, which is 494 likely to cause inconvenience to the called party. Similarly, 495 security preconditions can be used to prevent clipping due to race 496 conditions between an offer/answer exchange and secure media stream 497 packets based on that offer/answer exchange. If intermediaries can 498 remove or downgrade the strength of security preconditions from an 499 offer/answer exchange, they can cause clipping to occur in the 500 associated secure media stream. 502 Conversely, intermediaries may also add security preconditions to 503 offers that do not contain them or increase their strength. This in 504 turn may lead to session failure or delayed session establishment 505 that was not desired. 507 Use of integrity mechanisms can prevent all of the above problems. 508 Where intermediaries on the signaling path are trusted, it is 509 sufficient to only use hop-by-hop integrity protection, e.g. IPSec 510 or TLS. In all other cases, end-to-end integrity protection, e.g. 511 S/MIME, MUST be used. 513 6 IANA Considerations 515 IANA is hereby requested to register a RFC 3312 precondition type 516 called "sec" with the name "Security precondition". The reference 517 for this precondition type is the current document. 519 7 Acknowledgements 521 The security precondition was defined in earlier draft versions of 522 RFC 3312. RFC 3312 contains an extensive list of people who worked 523 on those earlier draft versions which are acknowledged here as well. 524 The authors would additionally like to thank Mark Baugher, Gonzalo 525 Camarillo, Paul Kyzivat and Thomas Stach for their comments on this 526 document. 528 8 Authors' Addresses 530 Flemming Andreasen 531 Cisco Systems, Inc. 532 499 Thornall Street, 8th Floor 533 Edison, New Jersey 08837 USA 534 EMail: fandreas@cisco.com 535 Dan Wing 536 Cisco Systems, Inc. 537 170 West Tasman Drive 538 San Jose, CA 95134 USA 539 EMail: dwing@cisco.com 541 9 Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 547 Resource Management and Session Initiation Protocol (SIP)", RFC 548 3312, October 2002. 550 [RFC4032] G. Camarillo and P. Kyzivat, "Update to the Session 551 Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 552 2005. 554 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 555 Protocol", RFC 2327, April 1998. 557 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 558 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 559 Initiation Protocol", RFC 3261, June 2002. 561 10 Informative References 563 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security 564 Descriptions for Media Streams", work in progress 566 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 567 Video Conferences with Minimal Control", RFC 3550, July 2003. 569 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 570 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 572 [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A 573 Methodology for Network Address Translator (NAT) Traversal for 574 Multimedia Session Establishment Protocols", IETF, work-in-progress. 576 [KMGMT] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 577 Norrman, "Key Management Extensions for Session Description Protocol 578 (SDP) and Real Time Streaming Protocol (RTSP)", IETF, work-in- 579 progress. 581 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 582 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 584 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 585 Provisional Responses in Session Initiation Protocol (SIP)", RFC 586 3262, June 2002. 588 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 589 UPDATE Method," RFC 3311, September 2002. 591 11 Intellectual Property Statement 593 The IETF takes no position regarding the validity or scope of any 594 Intellectual Property Rights or other rights that might be claimed 595 to pertain to the implementation or use of the technology described 596 in this document or the extent to which any license under such 597 rights might or might not be available; nor does it represent that 598 it has made any independent effort to identify any such rights. 599 Information on the IETF's procedures with respect to rights in IETF 600 Documents can be found in BCP 78 and BCP 79. 602 Copies of IPR disclosures made to the IETF Secretariat and any 603 assurances of licenses to be made available, or the result of an 604 attempt made to obtain a general license or permission for the use 605 of such proprietary rights by implementers or users of this 606 specification can be obtained from the IETF on-line IPR repository 607 at http://www.ietf.org/ipr. 609 The IETF invites any interested party to bring to its attention any 610 copyrights, patents or patent applications, or other proprietary 611 rights that may cover technology that may be required to implement 612 this standard. Please address the information to the IETF at 613 ietf-ipr@ietf.org. 615 Disclaimer of Validity 617 This document and the information contained herein are provided on 618 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 619 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 620 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 621 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 622 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Copyright Statement 627 Copyright (C) The Internet Society (2005). This document is subject 628 to the rights, licenses and restrictions contained in BCP 78, and 629 except as set forth therein, the authors retain all their rights. 631 Acknowledgment 633 Funding for the RFC Editor function is currently provided by the 634 Internet Society.