idnits 2.17.1 draft-ietf-mmusic-securityprecondition-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 733. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 IETF Trust Copyright Line does not match the current year == Line 454 has weird spacing: '...ndition is "n...' -- 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 (July 8, 2007) is 6130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Duplicate reference: RFC3264, mentioned in 'OFFANS', was also mentioned in 'RFC3264'. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 Intended Status: Proposed Standard 6 Expires: January 2008 Cisco Systems 7 Updates: RFC3312 (if accepted) July 8, 2007 9 Security Preconditions for 10 Session Description Protocol (SDP) Media Streams 11 13 Status of this memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 8, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines a new security precondition for the Session 45 Description Protocol (SDP) precondition framework described in RFCs 46 3312 and 4032. A security precondition can be used to delay session 47 establishment or modification until media stream security for a 48 secure media stream has been negotiated successfully. 50 1 Notational Conventions............................................2 51 2 Introduction......................................................2 52 3 Security Precondition Definition..................................3 53 4 Examples..........................................................6 54 4.1 SDP Security Descriptions Example.............................6 55 4.2 Key Management Extension for SDP Example......................8 56 5 Security Considerations..........................................11 57 6 IANA Considerations..............................................13 58 7 Acknowledgements.................................................13 59 8 Authors' Addresses...............................................13 60 9 Change Log.......................................................13 61 9.1 draft-ietf-mmusic-securityprecondition-04....................13 62 10 Normative References...........................................13 63 11 Informative References.........................................14 65 1 Notational Conventions 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2 Introduction 73 The concept of a Session Description Protocol (SDP) [RFC4566] 74 precondition is defined in [RFC3312] as updated by [RFC4032]. A 75 precondition is a condition that has to be satisfied for a given 76 media stream in order for session establishment or modification to 77 proceed. When a (mandatory) precondition is not met, session 78 progress is delayed until the precondition is satisfied or the 79 session establishment fails. For example, RFC 3312 defines the 80 Quality of Service precondition, which is used to ensure 81 availability of network resources prior to establishing (i.e. 82 alerting) a call. 84 Media streams can either be provided in cleartext and with no 85 integrity protection, or some kind of media security can be applied, 86 e.g., confidentiality and/or message integrity. For example, the 87 Audio/Video profile of the Real-Time Transfer protocol (RTP) 88 [RFC3551] is normally used without any security services whereas the 89 Secure Real-time Transport Protocol (SRTP) [SRTP] is always used 90 with security services. When media stream security is being 91 negotiated, e.g., using the mechanism defined in SDP Security 92 Descriptions [SDESC], both the offerer and the answerer [OFFANS] 93 need to know the cryptographic parameters being used for the media 94 stream; the offerer may provide multiple choices for the 95 cryptographic parameters, or the cryptographic parameters selected 96 by the answerer may differ from those of the offerer (e.g. the key 97 used in one direction versus the other). In such cases, to avoid 98 media clipping, the offerer needs to receive the answer prior to 99 receiving any media packets from the answerer. This can be achieved 100 by using a security precondition, which ensures the successful 101 negotiation of media stream security parameters for a secure media 102 stream prior to session establishment or modification. 104 3 Security Precondition Definition 106 The semantics for a security precondition are that the relevant 107 cryptographic parameters (cipher, key, etc.) for a secure media 108 stream are known to have been negotiated in the direction(s) 109 required. If the security precondition is used with a non-secure 110 media stream, the security precondition is by definition satisfied. 111 A secure media stream is here defined as a media stream that uses 112 some kind of security service, e.g. message integrity, 113 confidentiality or both, regardless of the cryptographic strength of 114 the mechanisms being used. 116 As an extreme example of this, Secure RTP (SRTP) using the NULL 117 encryption algorithm and no message integrity would be considered 118 a secure media stream whereas use of plain RTP would not. Note 119 though, that section 9.5 of [SRTP] discourages the use of SRTP 120 without message integrity. 122 Security preconditions do not guarantee that an established media 123 stream will be secure. They merely guarantee that the recipient of 124 the media stream packets will be able to perform any relevant 125 decryption and integrity checking on those media stream packets. 126 Please refer to Section 5 for further security considerations. 128 The security precondition type is defined by the string "sec" and 129 hence we modify the grammar found in RFC 3312 as follows: 131 precondition-type = "sec" | "qos" | token 133 RFC 3312 defines support for two kinds of status types, namely 134 segmented and end-to-end. The security precondition-type defined 135 here MUST be used with the end-to-end status type; use of the 136 segmented status type is undefined. 138 A security precondition can use the strength-tag "mandatory", 139 "optional" or "none". 141 When a security precondition with a strength-tag of "mandatory" is 142 received in an offer, session establishment or modification MUST be 143 delayed until the security precondition has been met, i.e. the 144 relevant cryptographic parameters (cipher, key, etc.) for a secure 145 media stream are known to have been negotiated in the direction(s) 146 required. When a mandatory security precondition is offered, and 147 the answerer cannot satisfy the security precondition, e.g. because 148 the offer was for a secure media stream, but it did not include the 149 necessary parameters to establish the secure media stream (keying 150 material for example), the offered media stream MUST be rejected as 151 described in RFC 3312. 153 The delay of session establishment defined here implies that 154 alerting of the called party MUST NOT occur and media for which 155 security is being negotiated MUST NOT be exchanged until the 156 precondition has been satisfied. In cases where secure media and 157 other non-secure data is multiplexed on a media stream, e.g. when 158 Interactive Connectivity Establishment [ICE] is being used, the non- 159 secure data is allowed to be exchanged prior to the security 160 precondition being satisfied. 162 When a security precondition with a strength-tag of "optional" is 163 received in an offer, the answerer MUST generate its answer SDP as 164 soon as possible. Since session progress is not delayed in this 165 case, the answerer does not know when the offerer is able to process 166 secure media stream packets and hence clipping may occur. If the 167 answerer wants to avoid clipping and delay session progress until he 168 knows the offerer has received the answer, the answerer MUST 169 increase the strength of the security precondition by using a 170 strength-tag of "mandatory" in the answer. Note that use of a 171 mandatory precondition requires the presence of a SIP "Require" 172 header field containing the option tag "precondition": Any SIP UA 173 that does not support a mandatory precondition will consequently 174 reject such requests (which also has unintended ramifications for 175 SIP forking that are known as the Heterogeneous Error Response 176 Forking Problem (see e.g. [HERFP]). To get around this, an optional 177 security precondition and the SIP "Supported" header field 178 containing the option tag "precondition" can be used instead. 180 When a security precondition with a strength-tag of "none" is 181 received, processing continues us usual. The "none" strength-tag 182 merely indicates that the offerer supports the security precondition 183 - the answerer MAY upgrade the strength-tag in the answer as 184 described in [RFC3312]. 186 The direction tags defined in RFC 3312 are interpreted as follows: 188 * send: Media stream security negotiation is at a stage where it is 189 possible to send media packets to the other party and the other 190 party will be able to process them correctly from a security point 191 of view, i.e. decrypt and/or integrity check them as necessary. 192 The definition of "media packets" includes all packets that make 193 up the media stream. In the case of Secure RTP for example, it 194 includes SRTP as well as SRTCP. When media and non-media packets 195 are multiplexed on a given media stream, e.g. when ICE is being 196 used, the requirement applies to the media packets only. 198 * recv: Media stream security negotiation is at a stage where it is 199 possible to receive and correctly process media stream packets 200 sent by the other party from a security point of view. 202 The precise criteria for determining when the other party is able to 203 correctly process media stream packets from a security point of view 204 depend on the secure media stream protocol being used as well as the 205 mechanism by which the required cryptographic parameters are 206 negotiated. 208 We here provide details for SRTP negotiated through SDP security 209 descriptions as defined in [SDESC]: 211 * When the offerer requests the "send" security precondition, it 212 needs to receive the answer before the security precondition is 213 satisfied. The reason for this is twofold. First, the offerer 214 needs to know where to send the media to. Secondly, in the case 215 where alternative cryptographic parameters are offered, the 216 offerer needs to know which set was selected. The answerer does 217 not know when the answer is actually received by the offerer 218 (which in turn will satisfy the precondition), and hence the 219 answerer needs to use the confirm-status attribute [RFC3312]. 220 This will make the offerer generate a new offer showing the 221 updated status of the precondition. 223 * When the offerer requests the "recv" security precondition, it 224 also needs to receive the answer before the security precondition 225 is satisfied. The reason for this is straightforward: The answer 226 contains the cryptographic parameters that will be used by the 227 answerer for sending media to the offerer; prior to receipt of 228 these cryptographic parameters the offerer is unable to 229 authenticate or decrypt such media. 231 When security preconditions are used with the Key Management 232 Extensions for Session Description Protocol (SDP) [KMGMT], the 233 details depend on the actual key management protocol being used. 235 After an initial offer/answer exchange in which the security 236 precondition is requested, any subsequent offer/answer sequence for 237 the purpose of updating the status of the precondition for a secure 238 media stream SHOULD use the same key material as the initial 239 offer/answer exchange. This means that the key-mgmt attribute lines 240 [KMGMT] or crypto attribute lines [SDESC] in SDP offers, that are 241 sent in response to SDP answers containing a confirm-status field 242 [RFC3312], SHOULD repeat the same data as that sent in the previous 243 SDP offer. If applicable to the key management protocol or SDP 244 security description, the SDP answers to these SDP offers SHOULD 245 repeat the same data in the key-mgmt attribute lines [KMGMT] or 246 crypto attribute lines [SDESC] as that sent in the previous SDP 247 answer. 249 Of course, this duplication of key exchange during precondition 250 establishment is not to be interpreted as a replay attack. This 251 issue may be solved if, e.g., the SDP implementation recognizes that 252 the key management protocol data is identical in the second 253 offer/answer exchange and avoids forwarding the information to the 254 security layer for further processing. 256 Offers with security preconditions in re-INVITEs or UPDATEs follow 257 the rules given in Section 6 of RFC 3312, i.e.: 259 "Both user agents SHOULD continue using the old session parameters 260 until all the mandatory preconditions are met. At that moment, 261 the user agents can begin using the new session parameters." 263 At that moment, we furthermore require that user agents MUST start 264 using the new session parameters for media packets being sent. The 265 user agents SHOULD be prepared to process media packets received 266 with either the old or the new session parameters for a short period 267 of time to accommodate media packets in transit. Note that this may 268 involve iterative security processing of the received media packets 269 during that period of time. Section 8 in [OFFANS] lists several 270 techniques to help alleviate the problem of determining when a 271 received media packet was generated according to the old or new 272 offer/answer exchange. 274 4 Examples 276 4.1 SDP Security Descriptions Example 278 The call flow of Figure 1 shows a basic session establishment using 279 the Session Initiation Protocol [SIP] and SDP security descriptions 280 [SDESC] with security descriptions for the secure media stream (SRTP 281 in this case). 283 A B 285 | | 286 |-------------(1) INVITE SDP1--------------->| 287 | | 288 |<------(2) 183 Session Progress SDP2--------| 289 | | 290 |----------------(3) PRACK SDP3------------->| 291 | | 292 |<-----------(4) 200 OK (PRACK) SDP4---------| 293 | | 294 |<-------------(5) 180 Ringing---------------| 295 | | 296 | | 297 | | 299 Figure 1: Security Preconditions with SDP Security 300 Descriptions Example 302 The SDP descriptions of this example are shown below - we have 303 omitted the details of the SDP security descriptions as well as any 304 SIP details for clarity of the security precondition described here: 306 SDP1: A includes a mandatory end-to-end security precondition for 307 both the send and receive direction in the initial offer as well as 308 a "crypto" attribute (see [SDESC]), which includes keying material 309 that can be used by A to generate media packets. Since B does not 310 know any of the security parameters yet, the current status (see RFC 311 3312) is set to "none". A's local status table (see RFC 3312) for 312 the security precondition is as follows: 314 Direction | Current | Desired Strength | Confirm 315 -----------+----------+------------------+---------- 316 send | no | mandatory | no 317 recv | no | mandatory | no 319 and the resulting offer SDP is: 321 m=audio 20000 RTP/SAVP 0 322 c=IN IP4 192.0.2.1 323 a=curr:sec e2e none 324 a=des:sec mandatory e2e sendrecv 325 a=crypto:foo... 327 SDP2: When B receives the offer and generates an answer, B knows the 328 (send and recv) security parameters of both A and B. From a 329 security perspective, B is now able to receive media from A, so B's 330 "recv" security precondition is "yes". However, A does not know any 331 of B's SDP information, so B's "send" security precondition is "no". 332 B's local status table therefore looks as follows: 334 Direction | Current | Desired Strength | Confirm 335 -----------+----------+------------------+---------- 336 send | no | mandatory | no 337 recv | yes | mandatory | no 339 B requests A to confirm when A knows the security parameters used in 340 the send and receive direction (it would suffice for B to ask for 341 confirmation of A's send direction only) and hence the resulting 342 answer SDP becomes: 344 m=audio 30000 RTP/SAVP 0 345 c=IN IP4 192.0.2.4 346 a=curr:sec e2e recv 347 a=des:sec mandatory e2e sendrecv 348 a=conf:sec e2e sendrecv 349 a=crypto:bar... 351 SDP3: When A receives the answer, A updates its local status table 352 based on the rules in RFC 3312. A knows the security parameters of 353 both the send and receive direction and hence A's local status table 354 is updated as follows: 356 Direction | Current | Desired Strength | Confirm 357 -----------+----------+------------------+---------- 358 send | yes | mandatory | yes 359 recv | yes | mandatory | yes 361 Since B requested confirmation of the send and recv security 362 preconditions, and both are now satisfied, A immediately sends an 363 updated offer (3) to B showing that the security preconditions are 364 satisfied: 366 m=audio 20000 RTP/SAVP 0 367 c=IN IP4 192.0.2.1 368 a=curr:sec e2e sendrecv 369 a=des:sec mandatory e2e sendrecv 370 a=crypto:foo... 372 Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] 373 since the precondition is satisfied immediately, and the original 374 offer/answer exchange is complete. 376 SDP4: Upon receiving the updated offer, B updates its local status 377 table based on the rules in RFC 3312 which yields the following: 379 Direction | Current | Desired Strength | Confirm 380 -----------+----------+------------------+---------- 381 send | yes | mandatory | no 382 recv | yes | mandatory | no 384 B responds with an answer (4) which contains the current status of 385 the security precondition (i.e., sendrecv) from B's point of view: 387 m=audio 30000 RTP/SAVP 0 388 c=IN IP4 192.0.2.4 389 a=curr:sec e2e sendrecv 390 a=des:sec mandatory e2e sendrecv 391 a=crypto:bar... 393 B's local status table indicates that all mandatory preconditions 394 have been satisfied, and hence session establishment resumes; B 395 returns a 180 (Ringing) response (5) to indicate alerting. 397 4.2 Key Management Extension for SDP Example 399 The call flow of Figure 2 shows a basic session establishment using 400 the Session Initiation Protocol [SIP] and Key Management Extensions 401 for SDP [KMGMT] with security descriptions for the secure media 402 stream (SRTP in this case): 404 A B 406 | | 407 |-------------(1) INVITE SDP1--------------->| 408 | | 409 |<------(2) 183 Session Progress SDP2--------| 410 | | 411 |----------------(3) PRACK SDP3------------->| 412 | | 413 |<-----------(4) 200 OK (PRACK) SDP4---------| 414 | | 415 |<-------------(5) 180 Ringing---------------| 416 | | 417 | | 418 | | 420 Figure 2: Security Preconditions with Key Management 421 Extensions for SDP Example 423 The SDP descriptions of this example are shown below - we show an 424 example use of MIKEY [MIKEY] with the Key Management Extensions, 425 however we have omitted the details of the MIKEY parameters as well 426 as any SIP details for clarity of the security precondition 427 described here: 429 SDP1: A includes a mandatory end-to-end security precondition for 430 both the send and receive direction in the initial offer as well as 431 a "key-mgmt" attribute (see [KMGMT]), which includes keying material 432 that can be used by A to generate media packets. Since B does not 433 know any of the security parameters yet, the current status (see RFC 434 3312) is set to "none". A's local status table (see RFC 3312) for 435 the security precondition is as follows: 437 Direction | Current | Desired Strength | Confirm 438 -----------+----------+------------------+---------- 439 send | no | mandatory | no 440 recv | no | mandatory | no 442 and the resulting offer SDP is: 444 m=audio 20000 RTP/SAVP 0 445 c=IN IP4 192.0.2.1 446 a=curr:sec e2e none 447 a=des:sec mandatory e2e sendrecv 448 a=key-mgmt:mikey AQAFgM0X... 450 SDP2: When B receives the offer and generates an answer, B knows the 451 (send and recv) security parameters of both A and B. B generates 452 keying material for sending media to A, however, A does not know B's 453 keying material, so the current status of B's "send" security 454 precondition is "no". B does know A's SDP information, so B's 455 "recv" security precondition is "yes". B's local status table 456 therefore looks as follows: 458 Direction | Current | Desired Strength | Confirm 459 -----------+----------+------------------+---------- 460 send | no | mandatory | no 461 recv | yes | mandatory | no 463 B requests A to confirm when A knows the security parameters used in 464 the send and receive direction and hence the resulting answer SDP 465 becomes: 467 m=audio 30000 RTP/SAVP 0 468 c=IN IP4 192.0.2.4 469 a=curr:sec e2e recv 470 a=des:sec mandatory e2e sendrecv 471 a=conf:sec e2e sendrecv 472 a=key-mgmt:mikey AQAFgM0X... 474 Note that the actual MIKEY data in the answer differs from that in 475 the offer, however we have only shown the initial and common part of 476 the MIKEY value in the above. 478 SDP3: When A receives the answer, A updates its local status table 479 based on the rules in RFC 3312. A now knows all the security 480 parameters of both the send and receive direction and hence A's 481 local status table is updated as follows: 483 Direction | Current | Desired Strength | Confirm 484 -----------+----------+------------------+---------- 485 send | yes | mandatory | yes 486 recv | yes | mandatory | yes 488 Since B requested confirmation of the send and recv security 489 preconditions, and both are now satisfied, A immediately sends an 490 updated offer (3) to B showing that the security preconditions are 491 satisfied: 493 m=audio 20000 RTP/SAVP 0 494 c=IN IP4 192.0.2.1 495 a=curr:sec e2e sendrecv 496 a=des:sec mandatory e2e sendrecv 497 a=key-mgmt:mikey AQAFgM0X... 499 SDP4: Upon receiving the updated offer, B updates its local status 500 table based on the rules in RFC 3312 which yields the following: 502 Direction | Current | Desired Strength | Confirm 503 -----------+----------+------------------+---------- 504 send | yes | mandatory | no 505 recv | yes | mandatory | no 507 B responds with an answer (4) which contains the current status of 508 the security precondition (i.e., sendrecv) from B's point of view: 510 m=audio 30000 RTP/SAVP 0 511 c=IN IP4 192.0.2.4 512 a=curr:sec e2e sendrecv 513 a=des:sec mandatory e2e sendrecv 514 a=key-mgmt:mikey AQAFgM0X... 516 B's local status table indicates that all mandatory preconditions 517 have been satisfied, and hence session establishment resumes; B 518 returns a 180 (Ringing) response (5) to indicate alerting. 520 5 Security Considerations 522 In addition to the general security considerations for preconditions 523 provided in RFC 3312, the following security issues should be 524 considered. 526 Security preconditions delay session establishment until 527 cryptographic parameters required to send and/or receive media for a 528 media stream have been negotiated. Negotiation of such parameters 529 can fail for a variety of reasons, including policy preventing use 530 of certain cryptographic algorithms, keys, and other security 531 parameters. If an attacker can remove security preconditions or 532 downgrade the strength-tag from an offer/answer exchange, the 533 attacker can thereby cause user alerting for a session that may have 534 no functioning media. This is likely to cause inconvenience to both 535 the offerer and the answerer. Similarly, security preconditions can 536 be used to prevent clipping due to race conditions between an 537 offer/answer exchange and secure media stream packets based on that 538 offer/answer exchange. If an attacker can remove or downgrade the 539 strength-tag of security preconditions from an offer/answer 540 exchange, the attacker can cause clipping to occur in the associated 541 secure media stream. 543 Conversely, an attacker might add security preconditions to offers 544 that do not contain them or increase their strength-tag. This in 545 turn may lead to session failure (e.g. if the answerer does not 546 support it), heterogeneous error response forking problems, or a 547 delay in session establishment that was not desired. 549 Use of signaling integrity mechanisms can prevent all of the above 550 problems. Where intermediaries on the signaling path (e.g. SIP 551 proxies) are trusted, it is sufficient to use only hop-by-hop 552 integrity protection of signaling, e.g., IPSec or TLS. In all other 553 cases, end-to-end integrity protection of signaling, e.g. S/MIME, 554 MUST be used. Note that the end-to-end integrity protection MUST 555 cover not only the message body, which contains the security 556 preconditions, but also the SIP "Supported" and "Require" headers, 557 which may contain the "precondition" option tag. If only the 558 message body were integrity protected, removal of the "precondition" 559 option tag could lead to clipping (when a security precondition was 560 otherwise to be used), whereas addition of the option tag could lead 561 to session failure (if the other side does not support 562 preconditions). 564 As specified in Section 3, security preconditions do not guarantee 565 that an established media stream will be secure. They merely 566 guarantee that the recipient of the media stream packets will be 567 able to perform any relevant decryption and integrity checking on 568 those media stream packets. 570 Current SDP [RFC4566] and associated offer/answer procedures 571 [RFC3264] allows only a single type of transport protocol to be 572 negotiated for a given media stream in an offer/answer exchange. 573 Negotiation of alternative transport protocols, e.g. plain and 574 secure RTP, is currently not defined. Thus, if the transport 575 protocol offered (e.g. secure RTP) is not supported, the offered 576 media stream will simply be rejected. There is however work in 577 progress to address that. For example, the SDP Capability 578 Negotiation framework [SDPCN] defines a method for negotiating use 579 of a secure or a non-secure transport protocol by use of SDP and the 580 offer/answer model with various extensions. 582 Such a mechanism introduces a number of security considerations in 583 general, however use of SDP Security Preconditions with such a 584 mechanism introduces the following security precondition specific 585 security considerations: 587 A basic premise of negotiating secure and non-secure media streams 588 as alternatives is that the offerer's security policy allows for 589 non-secure media. If the offer were to include secure and non- 590 secure media streams as alternative offers, and media for either 591 alternative may be received prior to the answer, then the offerer 592 may not know if the answerer accepted the secure alternative. An 593 active attacker thus may be able to inject malicious media stream 594 packets until the answer (indicating the chosen secure alternative) 595 is received. From a security point of view, it is important to note 596 that use of security preconditions (even with a mandatory strength- 597 tag) would not address this vulnerability since security 598 preconditions would effectively apply only to the secure media 599 stream alternatives. If the non-secure media stream alternative was 600 selected by the answerer, the security precondition would be 601 satisfied by definition, the session could progress and (non-secure) 602 media could be received prior to the answer being received. 604 6 IANA Considerations 606 IANA is hereby requested to register a RFC 3312 precondition type 607 called "sec" with the name "Security precondition". The reference 608 for this precondition type is the current document. 610 7 Acknowledgements 612 The security precondition was defined in earlier draft versions of 613 RFC 3312. RFC 3312 contains an extensive list of people who worked 614 on those earlier draft versions which are acknowledged here as well. 615 The authors would additionally like to thank David Black, Mark 616 Baugher, Gonzalo Camarillo, Paul Kyzivat and Thomas Stach for their 617 comments on this document. 619 8 Authors' Addresses 621 Flemming Andreasen 622 Cisco Systems, Inc. 623 499 Thornall Street, 8th Floor 624 Edison, New Jersey 08837 USA 625 EMail: fandreas@cisco.com 627 Dan Wing 628 Cisco Systems, Inc. 629 170 West Tasman Drive 630 San Jose, CA 95134 USA 631 EMail: dwing@cisco.com 633 9 Change Log 635 9.1 draft-ietf-mmusic-securityprecondition-04 637 o Updated security considerations to better address security 638 precondition interaction with capability negotiation of secure 639 and non-secure media stream alternatives. 641 10 Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 647 Resource Management and Session Initiation Protocol 648 (SIP)", RFC 3312, October 2002. 650 [RFC4032] G. Camarillo and P. Kyzivat, "Update to the Session 651 Initiation Protocol (SIP) Preconditions Framework", RFC 652 4032, March 2005. 654 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 655 J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: 656 Session Initiation Protocol", RFC 3261, June 2002. 658 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 659 Description Protocol", RFC 4566, July 2006. 661 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 662 with Session Description Protocol (SDP)", RFC 3264, June 663 2002. 665 11 Informative References 667 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "Session 668 Description Protocol (SDP) Security Descriptions for Media 669 Streams", RFC 4568, July 2006. 671 [OFFANS] J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model 672 with the Session Description Protocol (SDP)", RFC 3264, 673 June 2002. 675 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 676 Video Conferences with Minimal Control", RFC 3550, July 677 2003. 679 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 680 "The Secure Real-time Transport Protocol", RFC 3711, March 681 2004. 683 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 684 (ICE): A Methodology for Network Address Translator (NAT) 685 Traversal for Multimedia Session Establishment Protocols", 686 IETF, work-in-progress. 688 [KMGMT] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 689 Norrman, "Key Management Extensions for Session 690 Description Protocol (SDP) and Real Time Streaming 691 Protocol (RTSP)", IETF, work-in-progress. 693 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 694 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 695 August 2004. 697 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 698 Provisional Responses in Session Initiation Protocol 699 (SIP)", RFC 3262, June 2002. 701 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) 702 UPDATE Method," RFC 3311, September 2002. 704 [HERFP] R. Mahy, "A Solution to the Heterogeneous Error Response 705 Forking Problem (HERFP) in the Session Initiation Problem 706 (SIP)", Work in Progress, March 2006. 708 [SDPCN] F. Andreasen, "SDP Capability Negotiation", Work in 709 Progress, July 2007. 711 Intellectual Property Statement 713 The IETF takes no position regarding the validity or scope of any 714 Intellectual Property Rights or other rights that might be claimed 715 to pertain to the implementation or use of the technology 716 described in this document or the extent to which any license 717 under such rights might or might not be available; nor does it 718 represent that it has made any independent effort to identify any 719 such rights. Information on the procedures with respect to rights 720 in RFC documents can be found in BCP 78 and BCP 79. 722 Copies of IPR disclosures made to the IETF Secretariat and any 723 assurances of licenses to be made available, or the result of an 724 attempt made to obtain a general license or permission for the use 725 of such proprietary rights by implementers or users of this 726 specification can be obtained from the IETF on-line IPR repository 727 at http://www.ietf.org/ipr. 729 The IETF invites any interested party to bring to its attention 730 any copyrights, patents or patent applications, or other 731 proprietary rights that may cover technology that may be required 732 to implement this standard. Please address the information to the 733 IETF at ietf-ipr@ietf.org. 735 Full Copyright Statement 737 Copyright (C) The IETF Trust (2007). 739 This document is subject to the rights, licenses and restrictions 740 contained in BCP 78, and except as set forth therein, the authors 741 retain all their rights. 743 This document and the information contained herein are provided on 744 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 745 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 746 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 747 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 748 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 749 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 750 FOR A PARTICULAR PURPOSE. 752 Acknowledgment 754 Funding for the RFC Editor function is currently provided by the 755 Internet Society.