idnits 2.17.1 draft-ietf-mmusic-securityprecondition-03.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 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 708. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 724), 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 == Line 452 has weird spacing: '...ndition is "n...' == 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.) -- The document date (October 19, 2006) is 6371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDP' is mentioned on line 71, but not defined == Unused Reference: 'RFC2327' is defined on line 636, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 7 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 Updates: RFC3312 (if accepted) October 19, 2006 8 Security Preconditions for 9 Session Description Protocol (SDP) 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 19, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). All Rights Reserved. 41 Abstract 43 This document defines a new security precondition for the Session 44 Description Protocol (SDP) precondition framework described in RFCs 45 3312 and 4032. A security precondition can be used to delay session 46 establishment or modification until media stream security for a 47 secure media stream has been negotiated successfully. 49 1 Notational Conventions............................................2 50 2 Introduction......................................................2 51 3 Security Precondition Definition..................................3 52 4 Examples..........................................................6 53 4.1 SDP Security Descriptions Example.............................6 54 4.2 Key Management Extension for SDP Example......................8 55 5 Security Considerations..........................................11 56 6 IANA Considerations..............................................13 57 7 Acknowledgements.................................................13 58 8 Authors' Addresses...............................................13 59 9 Normative References.............................................13 60 10 Informative References.........................................13 61 11 Intellectual Property Statement................................15 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 a (mandatory) precondition is not met, session 76 progress is delayed until the precondition is satisfied or the 77 session establishment fails. For example, RFC 3312 defines the 78 Quality of Service precondition, which is used to ensure 79 availability of network resources prior to establishing (i.e. 80 alerting) a call. 82 Media streams can either be provided in cleartext and with no 83 integrity protection, or some kind of media security can be applied, 84 e.g., confidentiality and/or message integrity. For example, the 85 Audio/Video profile of the Real-Time Transfer protocol (RTP) 86 [RFC3551] is normally used without any security services whereas the 87 Secure Real-time Transport Protocol (SRTP) [SRTP] is always used 88 with security services. When media stream security is being 89 negotiated, e.g., using the mechanism defined in SDP Security 90 Descriptions [SDESC], both the offerer and the answerer [OFFANS] 91 need to know the cryptographic parameters being used for the media 92 stream; the offerer may provide multiple choices for the 93 cryptographic parameters, or the cryptographic parameters selected 94 by the answerer may differ from those of the offerer (e.g. the key 95 used in one direction versus the other). In such cases, to avoid 96 media clipping, the offerer needs to receive the answer prior to 97 receiving any media packets from the answerer. This can be achieved 98 by using a security precondition, which ensures the successful 99 negotiation of media stream security parameters for a secure media 100 stream prior to session establishment or modification. 102 3 Security Precondition Definition 104 The semantics for a security precondition are that the relevant 105 cryptographic parameters (cipher, key, etc.) for a secure media 106 stream are known to have been negotiated in the direction(s) 107 required. If the security precondition is used with a non-secure 108 media stream, the security precondition is by definition satisfied. 109 A secure media stream is here defined as a media stream that uses 110 some kind of security service, e.g. message integrity, 111 confidentiality or both, regardless of the cryptographic strength of 112 the mechanisms being used. 114 As an extreme example of this, Secure RTP (SRTP) using the NULL 115 encryption algorithm and no message integrity would be considered 116 a secure media stream whereas use of plain RTP would not. Note 117 though, that section 9.5 of [SRTP] discourages the use of SRTP 118 without message integrity. 120 Security preconditions do not guarantee that an established media 121 stream will be secure. They merely guarantee that the recipient of 122 the media stream packets will be able to perform any relevant 123 decryption and integrity checking on those media stream packets. 124 Please refer to Section 5 for further security considerations. 126 The security precondition type is defined by the string "sec" and 127 hence we modify the grammar found in RFC 3312 as follows: 129 precondition-type = "sec" | "qos" | token 131 RFC 3312 defines support for two kinds of status types, namely 132 segmented and end-to-end. The security precondition-type defined 133 here MUST be used with the end-to-end status type; use of the 134 segmented status type is undefined. 136 A security preconditions can use the strength-tag "mandatory", 137 "optional" or "none". 139 When a security precondition with a strength-tag of "mandatory" is 140 received in an offer, session establishment or modification MUST be 141 delayed until the security precondition has been met, i.e. the 142 relevant cryptographic parameters (cipher, key, etc.) for a secure 143 media stream are known to have been negotiated in the direction(s) 144 required. When a mandatory security precondition is offered, and 145 the answerer cannot satisfy the security precondition, e.g. because 146 the offer was for a secure media stream, but it did not include the 147 necessary parameters to establish the secure media stream (keying 148 material for example), the offered media stream MUST be rejected as 149 described in RFC 3312. 151 The delay of session establishment defined here implies that 152 alerting of the called party MUST NOT occur and media for which 153 security is being negotiated MUST NOT be exchanged until the 154 precondition has been satisfied. In cases where secure media and 155 other non-secure data is multiplexed on a media stream, e.g. when 156 Interactive Connectivity Establishment [ICE] is being used, the non- 157 secure data is allowed to be exchanged prior to the security 158 precondition being satisfied. 160 When a security precondition with a strength-tag of "optional" is 161 received in an offer, the answerer MUST generate its answer SDP as 162 soon as possible. Since session progress is not delayed in this 163 case, the answerer does not know when the offerer is able to process 164 secure media stream packets and hence clipping may occur. If the 165 answerer wants to avoid clipping and delay session progress until he 166 knows the offerer has received the answer, the answerer MUST 167 increase the strength of the security precondition by using a 168 strength-tag of "mandatory" in the answer. Note that use of a 169 mandatory precondition requires the presence of a SIP "Require" 170 header field containing the option tag "precondition": Any SIP UA 171 that does not support a mandatory precondition will consequently 172 reject such requests (which also has unintended ramifications for 173 SIP forking that are known as the Heterogeneous Error Response 174 Forking Problem (see e.g. [HERFP]). To get around this, an optional 175 security precondition and the SIP "Supported" header field 176 containing the option tag "precondition" can be used instead. 178 When a security precondition with a strength-tag of "none" is 179 received, processing continues us usual. The "none" strength-tag 180 merely indicates that the offerer supports the security precondition 181 - the answerer MAY upgrade the strength-tag in the answer as 182 described in [RFC3312]. 184 The direction tags defined in RFC 3312 are interpreted as follows: 186 * send: Media stream security negotiation is at a stage where it is 187 possible to send media packets to the other party and the other 188 party will be able to process them correctly from a security point 189 of view, i.e. decrypt and/or integrity check them as necessary. 190 The definition of "media packets" includes all packets that make 191 up the media stream. In the case of Secure RTP for example, it 192 includes SRTP as well as SRTCP. When media and non-media packets 193 are multiplexed on a given media stream, e.g. when ICE is being 194 used, the requirement applies to the media packets only. 196 * recv: Media stream security negotiation is at a stage where it is 197 possible to receive and correctly process media stream packets 198 sent by the other party from a security point of view. 200 The precise criteria for determining when the other party is able to 201 correctly process media stream packets from a security point of view 202 depend on the secure media stream protocol being used as well as the 203 mechanism by which the required cryptographic parameters are 204 negotiated. 206 We here provide details for SRTP negotiated through SDP security 207 descriptions as defined in [SDESC]: 209 * When the offerer requests the "send" security precondition, it 210 needs to receive the answer before the security precondition is 211 satisfied. The reason for this is twofold. First, the offerer 212 needs to know where to send the media to. Secondly, in the case 213 where alternative cryptographic parameters are offered, the 214 offerer needs to know which set was selected. The answerer does 215 not know when the answer is actually received by the offerer 216 (which in turn will satisfy the precondition), and hence the 217 answerer needs to use the confirm-status attribute [RFC3312]. 218 This will make the offerer generate a new offer showing the 219 updated status of the precondition. 221 * When the offerer requests the "recv" security precondition, it 222 also needs to receive the answer before the security precondition 223 is satisfied. The reason for this is straightforward: The answer 224 contains the cryptographic parameters that will be used by the 225 answerer for sending media to the offerer; prior to receipt of 226 these cryptographic parameters the offerer is unable to 227 authenticate or decrypt such media. 229 When security preconditions are used with the Key Management 230 Extensions for Session Description Protocol (SDP) [KMGMT], the 231 details depend on the actual key management protocol being used. 233 After an initial offer/answer exchange in which the security 234 precondition is requested, any subsequent offer/answer sequence for 235 the purpose of updating the status of the precondition for a secure 236 media stream SHOULD use the same key material as the initial 237 offer/answer exchange. This means that the key-mgmt attribute lines 238 [KMGMT] or crypto attribute lines [SDESC] in SDP offers, that are 239 sent in response to SDP answers containing a confirm-status field 240 [RFC3312], SHOULD repeat the same data as that sent in the previous 241 SDP offer. If applicable to the key management protocol or SDP 242 security description, the SDP answers to these SDP offers SHOULD 243 repeat the same data in the key-mgmt attribute lines [KMGMT] or 244 crypto attribute lines [SDESC] as that sent in the previous SDP 245 answer. 247 Of course, this duplication of key exchange during precondition 248 establishment is not to be interpreted as a replay attack. This 249 issue may be solved if, e.g., the SDP implementation recognizes that 250 the key management protocol data is identical in the second 251 offer/answer exchange and avoids forwarding the information to the 252 security layer for further processing. 254 Offers with security preconditions in re-INVITEs or UPDATEs follow 255 the rules given in Section 6 of RFC 3312, i.e.: 257 "Both user agents SHOULD continue using the old session parameters 258 until all the mandatory preconditions are met. At that moment, 259 the user agents can begin using the new session parameters." 261 At that moment, we furthermore require that ser agents MUST start 262 using the new session parameters for media packets being sent. The 263 user agents SHOULD be prepared to process media packets received 264 with either the old or the new session parameters for a short period 265 of time to accommodate media packets in transit. Note that this may 266 involve iterative security processing of the received media packets 267 during that period of time. Section 8 in [OFFANS] lists several 268 techniques to help alleviate the problem of determining when a 269 received media packet was generated according to the old or new 270 offer/answer exchange. 272 4 Examples 274 4.1 SDP Security Descriptions Example 276 The call flow of Figure 1 shows a basic session establishment using 277 the Session Initiation Protocol [SIP] and SDP security descriptions 278 [SDESC] with security descriptions for the secure media stream (SRTP 279 in this case). 281 A B 283 | | 284 |-------------(1) INVITE SDP1--------------->| 285 | | 286 |<------(2) 183 Session Progress SDP2--------| 287 | | 288 |----------------(3) PRACK SDP3------------->| 289 | | 290 |<-----------(4) 200 OK (PRACK) SDP4---------| 291 | | 292 |<-------------(5) 180 Ringing---------------| 293 | | 294 | | 295 | | 297 Figure 1: Security Preconditions with SDP Security 298 Descriptions Example 300 The SDP descriptions of this example are shown below - we have 301 omitted the details of the SDP security descriptions as well as any 302 SIP details for clarity of the security precondition described here: 304 SDP1: A includes a mandatory end-to-end security precondition for 305 both the send and receive direction in the initial offer as well as 306 a "crypto" attribute (see [SDESC]), which includes keying material 307 that can be used by A to generate media packets. Since B does not 308 know any of the security parameters yet, the current status (see RFC 309 3312) is set to "none". A's local status table (see RFC 3312) for 310 the security precondition is as follows: 312 Direction | Current | Desired Strength | Confirm 313 -----------+----------+------------------+---------- 314 send | no | mandatory | no 315 recv | no | mandatory | no 317 and the resulting offer SDP is: 319 m=audio 20000 RTP/SAVP 0 320 c=IN IP4 192.0.2.1 321 a=curr:sec e2e none 322 a=des:sec mandatory e2e sendrecv 323 a=crypto:foo... 325 SDP2: When B receives the offer and generates an answer, B knows the 326 (send and recv) security parameters of both A and B. From a 327 security perspective, B is now able to receive media from A, so B's 328 "recv" security precondition is "yes". However, A does not know any 329 of B's SDP information, so B's "send" security precondition is "no". 330 B's local status table therefore looks as follows: 332 Direction | Current | Desired Strength | Confirm 333 -----------+----------+------------------+---------- 334 send | no | mandatory | no 335 recv | yes | mandatory | no 337 B requests A to confirm when A knows the security parameters used in 338 the send and receive direction (it would suffice for B to ask for 339 confirmation of A's send direction only) and hence the resulting 340 answer SDP becomes: 342 m=audio 30000 RTP/SAVP 0 343 c=IN IP4 192.0.2.4 344 a=curr:sec e2e recv 345 a=des:sec mandatory e2e sendrecv 346 a=conf:sec e2e sendrecv 347 a=crypto:bar... 349 SDP3: When A receives the answer, A updates its local status table 350 based on the rules in RFC 3312. A knows the security parameters of 351 both the send and receive direction and hence A's local status table 352 is updated as follows: 354 Direction | Current | Desired Strength | Confirm 355 -----------+----------+------------------+---------- 356 send | yes | mandatory | yes 357 recv | yes | mandatory | yes 359 Since B requested confirmation of the send and recv security 360 preconditions, and both are now satisfied, A immediately sends an 361 updated offer (3) to B showing that the security preconditions are 362 satisfied: 364 m=audio 20000 RTP/SAVP 0 365 c=IN IP4 192.0.2.1 366 a=curr:sec e2e sendrecv 367 a=des:sec mandatory e2e sendrecv 368 a=crypto:foo... 370 Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] 371 since the precondition is satisfied immediately, and the original 372 offer/answer exchange is complete. 374 SDP4: Upon receiving the updated offer, B updates its local status 375 table based on the rules in RFC 3312 which yields the following: 377 Direction | Current | Desired Strength | Confirm 378 -----------+----------+------------------+---------- 379 send | yes | mandatory | no 380 recv | yes | mandatory | no 382 B responds with an answer (4) which contains the current status of 383 the security precondition (i.e., sendrecv) from B's point of view: 385 m=audio 30000 RTP/SAVP 0 386 c=IN IP4 192.0.2.4 387 a=curr:sec e2e sendrecv 388 a=des:sec mandatory e2e sendrecv 389 a=crypto:bar... 391 B's local status table indicates that all mandatory preconditions 392 have been satisfied, and hence session establishment resumes; B 393 returns a 180 (Ringing) response (5) to indicate alerting. 395 4.2 Key Management Extension for SDP Example 397 The call flow of Figure 2 shows a basic session establishment using 398 the Session Initiation Protocol [SIP] and Key Management Extensions 399 for SDP [KMGMT] with security descriptions for the secure media 400 stream (SRTP in this case): 402 A B 404 | | 405 |-------------(1) INVITE SDP1--------------->| 406 | | 407 |<------(2) 183 Session Progress SDP2--------| 408 | | 409 |----------------(3) PRACK SDP3------------->| 410 | | 411 |<-----------(4) 200 OK (PRACK) SDP4---------| 412 | | 413 |<-------------(5) 180 Ringing---------------| 414 | | 415 | | 416 | | 418 Figure 2: Security Preconditions with Key Management 419 Extensions for SDP Example 421 The SDP descriptions of this example are shown below - we show an 422 example use of MIKEY [MIKEY] with the Key Management Extensions, 423 however we have omitted the details of the MIKEY parameters as well 424 as any SIP details for clarity of the security precondition 425 described here: 427 SDP1: A includes a mandatory end-to-end security precondition for 428 both the send and receive direction in the initial offer as well as 429 a "key-mgmt" attribute (see [KMGMT]), which includes keying material 430 that can be used by A to generate media packets. Since B does not 431 know any of the security parameters yet, the current status (see RFC 432 3312) is set to "none". A's local status table (see RFC 3312) for 433 the security precondition is as follows: 435 Direction | Current | Desired Strength | Confirm 436 -----------+----------+------------------+---------- 437 send | no | mandatory | no 438 recv | no | mandatory | no 440 and the resulting offer SDP is: 442 m=audio 20000 RTP/SAVP 0 443 c=IN IP4 192.0.2.1 444 a=curr:sec e2e none 445 a=des:sec mandatory e2e sendrecv 446 a=key-mgmt:mikey AQAFgM0X... 448 SDP2: When B receives the offer and generates an answer, B knows the 449 (send and recv) security parameters of both A and B. B generates 450 keying material for sending media to A, however, A does not know B's 451 keying material, so the current status of B's "send" security 452 precondition is "no". B does know A's SDP information, so B's 453 "recv" security precondition is "yes". B's local status table 454 therefore looks as follows: 456 Direction | Current | Desired Strength | Confirm 457 -----------+----------+------------------+---------- 458 send | no | mandatory | no 459 recv | yes | mandatory | no 461 B requests A to confirm when A knows the security parameters used in 462 the send and receive direction and hence the resulting answer SDP 463 becomes: 465 m=audio 30000 RTP/SAVP 0 466 c=IN IP4 192.0.2.4 467 a=curr:sec e2e recv 468 a=des:sec mandatory e2e sendrecv 469 a=conf:sec e2e sendrecv 470 a=key-mgmt:mikey AQAFgM0X... 472 Note that the actual MIKEY data in the answer differs from that in 473 the offer, however we have only shown the initial and common part of 474 the MIKEY value in the above. 476 SDP3: When A receives the answer, A updates its local status table 477 based on the rules in RFC 3312. A now knows all the security 478 parameters of both the send and receive direction and hence A's 479 local status table is updated as follows: 481 Direction | Current | Desired Strength | Confirm 482 -----------+----------+------------------+---------- 483 send | yes | mandatory | yes 484 recv | yes | mandatory | yes 486 Since B requested confirmation of the send and recv security 487 preconditions, and both are now satisfied, A immediately sends an 488 updated offer (3) to B showing that the security preconditions are 489 satisfied: 491 m=audio 20000 RTP/SAVP 0 492 c=IN IP4 192.0.2.1 493 a=curr:sec e2e sendrecv 494 a=des:sec mandatory e2e sendrecv 495 a=key-mgmt:mikey AQAFgM0X... 497 SDP4: Upon receiving the updated offer, B updates its local status 498 table based on the rules in RFC 3312 which yields the following: 500 Direction | Current | Desired Strength | Confirm 501 -----------+----------+------------------+---------- 502 send | yes | mandatory | no 503 recv | yes | mandatory | no 505 B responds with an answer (4) which contains the current status of 506 the security precondition (i.e., sendrecv) from B's point of view: 508 m=audio 30000 RTP/SAVP 0 509 c=IN IP4 192.0.2.4 510 a=curr:sec e2e sendrecv 511 a=des:sec mandatory e2e sendrecv 512 a=key-mgmt:mikey AQAFgM0X... 514 B's local status table indicates that all mandatory preconditions 515 have been satisfied, and hence session establishment resumes; B 516 returns a 180 (Ringing) response (5) to indicate alerting. 518 5 Security Considerations 520 In addition to the general security considerations for preconditions 521 provided in RFC 3312, the following security issues should be 522 considered. 524 Security preconditions delay session establishment until 525 cryptographic parameters required to send and/or receive media for a 526 media stream have been negotiated. Negotiation of such parameters 527 can fail for a variety of reasons, including policy preventing use 528 of certain cryptographic algorithms, keys, and other security 529 parameters. If an attacker can remove security preconditions or 530 downgrade the strength-tag from an offer/answer exchange, the 531 attacker can thereby cause user alerting for a session that may have 532 no functioning media. This is likely to cause inconvenience to both 533 the offerer and the answerer. Similarly, security preconditions can 534 be used to prevent clipping due to race conditions between an 535 offer/answer exchange and secure media stream packets based on that 536 offer/answer exchange. If an attacker can remove or downgrade the 537 strength-tag of security preconditions from an offer/answer 538 exchange, the attacker can cause clipping to occur in the associated 539 secure media stream. 541 Conversely, an attacker might add security preconditions to offers 542 that do not contain them or increase their strength-tag. This in 543 turn may lead to session failure (e.g. if the answerer does not 544 support it), heterogeneous error response forking problems, or a 545 delay in session establishment that was not desired. 547 Use of signaling integrity mechanisms can prevent all of the above 548 problems. Where intermediaries on the signaling path (e.g. SIP 549 proxies) are trusted, it is sufficient to use only hop-by-hop 550 integrity protection of signaling, e.g., IPSec or TLS. In all other 551 cases, end-to-end integrity protection of signaling, e.g. S/MIME, 552 MUST be used. Note that the end-to-end integrity protection MUST 553 cover not only the message body, which contains the security 554 preconditions, but also the SIP "Supported" and "Require" headers, 555 which may contain the "precondition" option tag. If only the 556 message body were integrity protected, removal of the "precondition" 557 option tag could lead to clipping (when a security precondition was 558 otherwise to be used), whereas addition of the option tag could lead 559 to session failure (if the other side does not support 560 preconditions). 562 As specified in Section 3, security preconditions do not guarantee 563 that an established media stream will be secure. They merely 564 guarantee that the recipient of the media stream packets will be 565 able to perform any relevant decryption and integrity checking on 566 those media stream packets. If an offer includes a secure and a 567 non-secure media stream as alternatives, this may lead to additional 568 security issues. It is important to understand how security 569 preconditions interact with those. 571 SDP and the offer/answer model currently do not define how such 572 alternatives could be negotiated, however there is work in 573 progress to address that (see e.g. [SDPCN]). Negotiating secure 574 and non-secure media streams as alternatives however introduces 575 several security issues and hence SHOULD NOT be done until a 576 complete specification for doing so has been documented in detail 577 and reviewed properly. Below, we provide general security 578 considerations for security preconditions that may aid in the 579 design and review of such mechanisms. 581 Note that a basic premise of negotiating secure and non-secure media 582 streams as alternatives is that the offerer's security policy allows 583 for non-secure media. If the offer were to include secure and non- 584 secure media streams as alternative offers, and media for either 585 alternative may be received prior to the answer, then the offerer 586 may not know if the answerer accepted the secure alternative. An 587 active attacker thus may be able to inject malicious media stream 588 packets until the answer (indicating the chosen secure alternative) 589 is received. Use of security preconditions (even with a mandatory 590 strength-tag) would not address this vulnerability since security 591 preconditions would apply only to the secure media stream 592 alternatives. 594 6 IANA Considerations 596 IANA is hereby requested to register a RFC 3312 precondition type 597 called "sec" with the name "Security precondition". The reference 598 for this precondition type is the current document. 600 7 Acknowledgements 602 The security precondition was defined in earlier draft versions of 603 RFC 3312. RFC 3312 contains an extensive list of people who worked 604 on those earlier draft versions which are acknowledged here as well. 605 The authors would additionally like to thank David Black, Mark 606 Baugher, Gonzalo Camarillo, Paul Kyzivat and Thomas Stach for their 607 comments on this document. 609 8 Authors' Addresses 611 Flemming Andreasen 612 Cisco Systems, Inc. 613 499 Thornall Street, 8th Floor 614 Edison, New Jersey 08837 USA 615 EMail: fandreas@cisco.com 617 Dan Wing 618 Cisco Systems, Inc. 619 170 West Tasman Drive 620 San Jose, CA 95134 USA 621 EMail: dwing@cisco.com 623 9 Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 629 Resource Management and Session Initiation Protocol (SIP)", RFC 630 3312, October 2002. 632 [RFC4032] G. Camarillo and P. Kyzivat, "Update to the Session 633 Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 634 2005. 636 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 637 Protocol", RFC 2327, April 1998. 639 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 640 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 641 Initiation Protocol", RFC 3261, June 2002. 643 10 Informative References 645 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "Session 646 Description Protocol (SDP) Security Descriptions for Media Streams", 647 RFC 4568, July 2006. 649 [OFFANS] J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model 650 with the Session Description Protocol (SDP)", RFC 3264, June 2002. 652 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 653 Video Conferences with Minimal Control", RFC 3550, July 2003. 655 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. 656 Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 657 2004. 659 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 660 (ICE): A Methodology for Network Address Translator (NAT) Traversal 661 for Multimedia Session Establishment Protocols", IETF, work-in- 662 progress. 664 [KMGMT] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 665 Norrman, "Key Management Extensions for Session Description Protocol 666 (SDP) and Real Time Streaming Protocol (RTSP)", IETF, work-in- 667 progress. 669 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 670 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 672 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 673 Provisional Responses in Session Initiation Protocol (SIP)", RFC 674 3262, June 2002. 676 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) 677 UPDATE Method," RFC 3311, September 2002. 679 [HERFP] R. Mahy, "A Solution to the Heterogeneous Error Response 680 Forking Problem (HERFP) in the Session Initiation Problem (SIP)", 681 Work in Progress, March 2006. 683 [SDPCN] F. Andreasen, "SDP Capability Negotiation", Work in 684 Progress, June 2006. 686 11 Intellectual Property Statement 688 The IETF takes no position regarding the validity or scope of any 689 Intellectual Property Rights or other rights that might be claimed 690 to pertain to the implementation or use of the technology described 691 in this document or the extent to which any license under such 692 rights might or might not be available; nor does it represent that 693 it has made any independent effort to identify any such rights. 694 Information on the IETF's procedures with respect to rights in IETF 695 Documents can be found in BCP 78 and BCP 79. 697 Copies of IPR disclosures made to the IETF Secretariat and any 698 assurances of licenses to be made available, or the result of an 699 attempt made to obtain a general license or permission for the use 700 of such proprietary rights by implementers or users of this 701 specification can be obtained from the IETF on-line IPR repository 702 at http://www.ietf.org/ipr. 704 The IETF invites any interested party to bring to its attention any 705 copyrights, patents or patent applications, or other proprietary 706 rights that may cover technology that may be required to implement 707 this standard. Please address the information to the IETF at 708 ietf-ipr@ietf.org. 710 Disclaimer of Validity 712 This document and the information contained herein are provided on 713 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 714 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 715 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 716 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 717 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 718 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 720 Copyright Statement 722 Copyright (C) The Internet Society (2006). This document is subject 723 to the rights, licenses and restrictions contained in BCP 78, and 724 except as set forth therein, the authors retain all their rights. 726 Acknowledgment 728 Funding for the RFC Editor function is currently provided by the 729 Internet Society.