idnits 2.17.1 draft-ietf-mmusic-securityprecondition-02.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 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 711), 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 627, 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: December 2006 Cisco Systems 6 June, 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 December 25, 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..............................................12 57 7 Acknowledgements.................................................12 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 need to know 91 the cryptographic parameters being used for the media stream; the 92 offerer may provide multiple choices for the cryptographic 93 parameters, or the cryptographic parameters selected by the answerer 94 may differ from those of the offerer (e.g. the key used in one 95 direction versus the other). In such cases, to avoid media 96 clipping, the offerer needs to receive the answer prior to receiving 97 any media packets from the answerer. This can be achieved by using 98 a security precondition, which ensures the successful negotiation of 99 media stream security parameters for a secure media stream prior to 100 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 use of SRTP without authentication is discouraged. 119 Security preconditions do not guarantee that an established media 120 stream will be secure. They merely guarantee that the recipient of 121 the media stream packets will be able to perform any relevant 122 decryption and integrity checking on those media stream packets. 123 Please refer to Section 5 for further security considerations. 125 The security precondition type is defined by the string "sec" and 126 hence we modify the grammar found in RFC 3312 as follows: 128 precondition-type = "sec" | "qos" | token 130 RFC 3312 defines support for two kinds of status types, namely 131 segmented and end-to-end. The security precondition-type defined 132 here MUST be used with the end-to-end status type; use of the 133 segmented status type is undefined. 135 A security preconditions can use the strength-tag "mandatory", 136 "optional" or "none". 138 When a security precondition with a strength-tag of "mandatory" is 139 received in an offer, session establishment or modification MUST be 140 delayed until the security precondition has been met, i.e. the 141 relevant cryptographic parameters (cipher, key, etc.) for a secure 142 media stream are known to have been negotiated in the direction(s) 143 required. When a mandatory security precondition is offered, and 144 the answerer cannot satisfy the security precondition, e.g. because 145 the offer was for a secure media stream, but it did not include the 146 necessary parameters to establish the secure media stream (keying 147 material for example), the offered media stream MUST be rejected as 148 described in RFC 3312. 150 The delay of session establishment defined here implies that 151 alerting of the called party MUST NOT occur and media for which 152 security is being negotiated MUST NOT be exchanged until the 153 precondition has been satisfied. In cases where secure media and 154 other non-secure data is multiplexed on a media stream, e.g. when 155 Interactive Connectivity Establishment [ICE] is being used, the non- 156 secure data is allowed to be exchanged prior to the security 157 precondition being satisfied. 159 When a security precondition with a strength-tag of "optional" is 160 received in an offer, the answerer MUST generate its answer SDP as 161 soon as possible. Since session progress is not delayed in this 162 case, the answerer does not know when the offerer is able to process 163 secure media stream packets and hence clipping may occur. If the 164 answerer wants to avoid clipping and delay session progress until he 165 knows the offerer has received the answer, the answerer MUST 166 increase the strength of the security precondition by using a 167 strength-tag of "mandatory" in the answer. Note that use of a 168 mandatory precondition requires the presence of a SIP "Require" 169 header field containing the option tag "precondition": Any SIP UA 170 that does not support a mandatory precondition will consequently 171 reject such requests (which also has unintended ramifications for 172 SIP forking that are known as the Heterogeneous Error Response 173 Forking Problem (see e.g. [HERFP]). To get around this, an optional 174 security precondition and the SIP "Supported" header field 175 containing the option tag "precondition" can be used instead. 177 When a security precondition with a strength-tag of "none" is 178 received, processing continues us usual. The "none" strength-tag 179 merely indicates that the offerer supports the security precondition 180 - the answerer MAY upgrade the strength-tag in the answer as 181 described in [RFC3312]. 183 The direction tags defined in RFC 3312 are interpreted as follows: 185 * send: Media stream security negotiation is at a stage where it is 186 possible to send media packets to the other party and the other 187 party will be able to process them correctly from a security point 188 of view, i.e. decrypt and/or integrity check them as necessary. 189 The definition of "media packets" includes all packets that make 190 up the media stream. In the case of Secure RTP for example, it 191 includes SRTP as well as SRTCP. When media and non-media packets 192 are multiplexed on a given media stream, e.g. when ICE is being 193 used, the requirement applies to the media packets only. 195 * recv: Media stream security negotiation is at a stage where it is 196 possible to receive and correctly process media stream packets 197 sent by the other party from a security point of view. 199 The precise criteria for determining when the other party is able to 200 correctly process media stream packets from a security point of view 201 depend on the secure media stream protocol being used as well as the 202 mechanism by which the required cryptographic parameters are 203 negotiated. 205 We here provide details for SRTP negotiated through SDP security 206 descriptions as defined in [SDESC]: 208 * When the offerer requests the "send" security precondition, it 209 needs to receive the answer before the security precondition is 210 satisfied. The reason for this is twofold. First, the offerer 211 needs to know where to send the media to. Secondly, in the case 212 where alternative cryptographic parameters are offered, the 213 offerer needs to know which set was selected. The answerer does 214 not know when the answer is actually received by the offerer 215 (which in turn will satisfy the precondition), and hence the 216 answerer needs to use the confirm-status attribute [RFC3312]. 217 This will make the offerer generate a new offer showing the 218 updated status of the precondition. 220 * When the offerer requests the "recv" security precondition, it 221 also needs to receive the answer before the security precondition 222 is satisfied. The reason for this is straightforward: The answer 223 contains the cryptographic parameters that will be used by the 224 answerer for sending media to the offerer; prior to receipt of 225 these cryptographic parameters the offerer is unable to 226 authenticate or decrypt such media. 228 When security preconditions are used with the Key Management 229 Extensions for Session Description Protocol (SDP) [KMGMT], the 230 details depend on the actual key management protocol being used. 232 After an initial offer/answer exchange in which the security 233 precondition is requested, any subsequent offer/answer sequence for 234 the purpose of updating the status of the precondition for a secure 235 media stream SHOULD use the same key material as the initial 236 offer/answer exchange. This means that the key-mgmt attribute lines 237 [KMGMT] or crypto attribute lines [SDESC] in SDP offers, that are 238 sent in response to SDP answers containing a confirm-status field 239 [RFC3312], SHOULD repeat the same data as that sent in the previous 240 SDP offer. If applicable to the key management protocol or SDP 241 security description, the SDP answers to these SDP offers SHOULD 242 repeat the same data in the key-mgmt attribute lines [KMGMT] or 243 crypto attribute lines [SDESC] as that sent in the previous SDP 244 answer. 246 Of course, this duplication of key exchange during precondition 247 establishment is not to be interpreted as a replay attack. This 248 issue may be solved if, e.g., the SDP implementation recognizes that 249 the key management protocol data is identical in the second 250 offer/answer exchange and avoids forwarding the information to the 251 security layer for further processing. 253 Offers with security preconditions in re-INVITEs or UPDATEs follow 254 the rules given in Section 6 of RFC 3312, i.e.: 256 "Both user agents SHOULD continue using the old session parameters 257 until all the mandatory preconditions are met. At that moment, 258 the user agents can begin using the new session parameters." 260 4 Examples 262 4.1 SDP Security Descriptions Example 264 The call flow of Figure 1 shows a basic session establishment using 265 the Session Initiation Protocol [SIP] and SDP security descriptions 266 [SDESC] with security descriptions for the secure media stream (SRTP 267 in this case). 269 A B 271 | | 272 |-------------(1) INVITE SDP1--------------->| 273 | | 274 |<------(2) 183 Session Progress SDP2--------| 275 | | 276 |----------------(3) PRACK SDP3------------->| 277 | | 278 |<-----------(4) 200 OK (PRACK) SDP4---------| 279 | | 280 |<-------------(5) 180 Ringing---------------| 281 | | 282 | | 283 | | 285 Figure 1: Security Preconditions with SDP Security 286 Descriptions Example 288 The SDP descriptions of this example are shown below - we have 289 omitted the details of the SDP security descriptions as well as any 290 SIP details for clarity of the security precondition described here: 292 SDP1: A includes a mandatory end-to-end security precondition for 293 both the send and receive direction in the initial offer as well as 294 a "crypto" attribute (see [SDESC]), which includes keying material 295 that can be used by A to generate media packets. Since B does not 296 know any of the security parameters yet, the current status (see RFC 297 3312) is set to "none". A's local status table (see RFC 3312) for 298 the security precondition is as follows: 300 Direction | Current | Desired Strength | Confirm 301 -----------+----------+------------------+---------- 302 send | no | mandatory | no 303 recv | no | mandatory | no 305 and the resulting offer SDP is: 307 m=audio 20000 RTP/SAVP 0 308 c=IN IP4 192.0.2.1 309 a=curr:sec e2e none 310 a=des:sec mandatory e2e sendrecv 311 a=crypto:foo... 313 SDP2: When B receives the offer and generates an answer, B knows the 314 (send and recv) security parameters of both A and B. However, A 315 does not know B's security parameters, so the current status of B's 316 "send" security precondition (which equal A's "recv" security 317 precondition) is "no". Similarly, A does not know any of B's SDP 318 information, so B's "send" security precondition is also "no". B's 319 local status table therefore looks as follows: 321 Direction | Current | Desired Strength | Confirm 322 -----------+----------+------------------+---------- 323 send | no | mandatory | no 324 recv | no | mandatory | no 326 B requests A to confirm when A knows the security parameters used in 327 the send and receive direction and hence the resulting answer SDP 328 becomes: 330 m=audio 30000 RTP/SAVP 0 331 c=IN IP4 192.0.2.4 332 a=curr:sec e2e none 333 a=des:sec mandatory e2e sendrecv 334 a=conf:sec e2e sendrecv 335 a=crypto:bar... 337 SDP3: When A receives the answer, A updates its local status table 338 based on the rules in RFC 3312. A knows the security parameters of 339 both the send and receive direction and hence A's local status table 340 is updated as follows: 342 Direction | Current | Desired Strength | Confirm 343 -----------+----------+------------------+---------- 344 send | yes | mandatory | yes 345 recv | yes | mandatory | yes 347 Since B requested confirmation of the send and recv security 348 preconditions, and both are now satisfied, A immediately sends an 349 updated offer (3) to B showing that the security preconditions are 350 satisfied: 352 m=audio 20000 RTP/SAVP 0 353 c=IN IP4 192.0.2.1 354 a=curr:sec e2e sendrecv 355 a=des:sec mandatory e2e sendrecv 356 a=crypto:foo... 358 Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] 359 since the precondition is satisfied immediately, and the original 360 offer/answer exchange is complete) 362 SDP4: Upon receiving the updated offer, B updates its local status 363 table based on the rules in RFC 3312 which yields the following: 365 Direction | Current | Desired Strength | Confirm 366 -----------+----------+------------------+---------- 367 send | yes | mandatory | no 368 recv | yes | mandatory | no 370 B responds with an answer (4) which contains the current status of 371 the security precondition (i.e., sendrecv) from B's point of view: 373 m=audio 30000 RTP/SAVP 0 374 c=IN IP4 192.0.2.4 375 a=curr:sec e2e sendrecv 376 a=des:sec mandatory e2e sendrecv 377 a=crypto:bar... 379 B's local status table indicates that all mandatory preconditions 380 have been satisfied, and hence session establishment resumes; B 381 returns a 180 (Ringing) response (5) to indicate alerting. 383 4.2 Key Management Extension for SDP Example 385 The call flow of Figure 2 shows a basic session establishment using 386 the Session Initiation Protocol [SIP] and Key Management Extensions 387 for SDP [KMGMT] with security descriptions for the secure media 388 stream (SRTP in this case): 390 A B 392 | | 393 |-------------(1) INVITE SDP1--------------->| 394 | | 395 |<------(2) 183 Session Progress SDP2--------| 396 | | 397 |----------------(3) PRACK SDP3------------->| 398 | | 399 |<-----------(4) 200 OK (PRACK) SDP4---------| 400 | | 401 |<-------------(5) 180 Ringing---------------| 402 | | 403 | | 404 | | 406 Figure 2: Security Preconditions with Key Management 407 Extensions for SDP Example 409 The SDP descriptions of this example are shown below - we show an 410 example use of MIKEY [MIKEY] with the Key Management Extensions, 411 however we have omitted the details of the MIKEY parameters as well 412 as any SIP details for clarity of the security precondition 413 described here: 415 SDP1: A includes a mandatory end-to-end security precondition for 416 both the send and receive direction in the initial offer as well as 417 a "key-mgmt" attribute (see [KMGMT]), which includes keying material 418 that can be used by A to generate media packets. Since B does not 419 know any of the security parameters yet, the current status (see RFC 420 3312) is set to "none". A's local status table (see RFC 3312) for 421 the security precondition is as follows: 423 Direction | Current | Desired Strength | Confirm 424 -----------+----------+------------------+---------- 425 send | no | mandatory | no 426 recv | no | mandatory | no 428 and the resulting offer SDP is: 430 m=audio 20000 RTP/SAVP 0 431 c=IN IP4 192.0.2.1 432 a=curr:sec e2e none 433 a=des:sec mandatory e2e sendrecv 434 a=key-mgmt:mikey AQAFgM0X... 436 SDP2: When B receives the offer and generates an answer, B knows the 437 (send and recv) security parameters of both A and B. B generates 438 keying material for sending media to A, however, A does not know B's 439 keying material, so the current status of B's "send" security 440 precondition (which equal A's "recv" security precondition) is "no". 441 Similarly, A does not know any of B's SDP information, so B's "recv" 442 security precondition is also "no". B's local status table 443 therefore looks as follows: 445 Direction | Current | Desired Strength | Confirm 446 -----------+----------+------------------+---------- 447 send | no | mandatory | no 448 recv | no | mandatory | no 450 B requests A to confirm when A knows the security parameters used in 451 the send and receive direction and hence the resulting answer SDP 452 becomes: 454 m=audio 30000 RTP/SAVP 0 455 c=IN IP4 192.0.2.4 456 a=curr:sec e2e none 457 a=des:sec mandatory e2e sendrecv 458 a=conf:sec e2e sendrecv 459 a=key-mgmt:mikey AQAFgM0X... 461 Note that the actual MIKEY data in the answer differs from that in 462 the offer, however we have only shown the initial and common part of 463 the MIKEY value in the above. 465 SDP3: When A receives the answer, A updates its local status table 466 based on the rules in RFC 3312. A now knows all the security 467 parameters of both the send and receive direction and hence A's 468 local status table is updated as follows: 470 Direction | Current | Desired Strength | Confirm 471 -----------+----------+------------------+---------- 472 send | yes | mandatory | yes 473 recv | yes | mandatory | yes 475 Since B requested confirmation of the send and recv security 476 preconditions, and both are now satisfied, A immediately sends an 477 updated offer (3) to B showing that the security preconditions are 478 satisfied: 480 m=audio 20000 RTP/SAVP 0 481 c=IN IP4 192.0.2.1 482 a=curr:sec e2e sendrecv 483 a=des:sec mandatory e2e sendrecv 484 a=key-mgmt:mikey AQAFgM0X... 486 SDP4: Upon receiving the updated offer, B updates its local status 487 table based on the rules in RFC 3312 which yields the following: 489 Direction | Current | Desired Strength | Confirm 490 -----------+----------+------------------+---------- 491 send | yes | mandatory | no 492 recv | yes | mandatory | no 494 B responds with an answer (4) which contains the current status of 495 the security precondition (i.e., sendrecv) from B's point of view: 497 m=audio 30000 RTP/SAVP 0 498 c=IN IP4 192.0.2.4 499 a=curr:sec e2e sendrecv 500 a=des:sec mandatory e2e sendrecv 501 a=key-mgmt:mikey AQAFgM0X... 503 B's local status table indicates that all mandatory preconditions 504 have been satisfied, and hence session establishment resumes; B 505 returns a 180 (Ringing) response (5) to indicate alerting. 507 5 Security Considerations 509 In addition to the general security considerations for preconditions 510 provided in RFC 3312, the following security issues should be 511 considered. 513 Security preconditions delay session establishment until 514 cryptographic parameters required to send and/or receive media for a 515 media stream have been negotiated. Negotiation of such parameters 516 can fail for a variety of reasons, including policy preventing use 517 of certain cryptographic algorithms, keys, and other security 518 parameters. If an attacker can remove security preconditions or 519 downgrade the strength-tag from an offer/answer exchange, the 520 attacker can thereby cause user alerting for a session that may have 521 no functioning media. This is likely to cause inconvenience to both 522 the offerer and the answerer. Similarly, security preconditions can 523 be used to prevent clipping due to race conditions between an 524 offer/answer exchange and secure media stream packets based on that 525 offer/answer exchange. If an attacker can remove or downgrade the 526 strength-tag of security preconditions from an offer/answer 527 exchange, the attacker can cause clipping to occur in the associated 528 secure media stream. 530 Conversely, an attacker might add security preconditions to offers 531 that do not contain them or increase their strength-tag. This in 532 turn may lead to session failure (e.g. if the answerer does not 533 support it), heterogeneous error response forking problems, or a 534 delay in session establishment that was not desired. 536 Use of signaling integrity mechanisms can prevent all of the above 537 problems. Where intermediaries on the signaling path (e.g. SIP 538 proxies) are trusted, it is sufficient to use only hop-by-hop 539 integrity protection of signaling, e.g., IPSec or TLS. In all other 540 cases, end-to-end integrity protection of signaling, e.g. S/MIME, 541 MUST be used. Note that the end-to-end integrity protection MUST 542 cover not only the message body, which contains the security 543 preconditions, but also the SIP "Supported" and "Require" headers, 544 which may contain the "precondition" option tag. If only the 545 message body were integrity protected, removal of the "precondition" 546 option tag could lead to clipping (when a security precondition was 547 otherwise to be used), whereas addition of the option tag could lead 548 to session failure (if the other side does not support 549 preconditions). 551 As specified in Section 3, security preconditions do not guarantee 552 that an established media stream will be secure. They merely 553 guarantee that the recipient of the media stream packets will be 554 able to perform any relevant decryption and integrity checking on 555 those media stream packets. If an offer includes a secure and a 556 non-secure media stream as alternatives, this may lead to additional 557 security issues. It is important to understand how security 558 preconditions interact with those. 560 SDP and the offer/answer model currently do not define how such 561 alternatives could be negotiated, however there is work in 562 progress to address that (see e.g. [SDPCN]). Below, we provide 563 general security considerations for security preconditions with 564 such mechanisms. 566 If the offer were to include secure and non-secure media streams as 567 alternative offers, and media for either alternative may be received 568 prior to the answer, then the offerer may not know if the answerer 569 accepted the secure alternative. An active attacker thus may be 570 able to inject malicious media stream packets until the answer is 571 received. Use of security preconditions would not address this 572 vulnerability since security preconditions do not guarantee that a 573 media stream established is secure, even if the strength-tag is 574 "mandatory". 576 In the above scenario with secure and non-secure media streams as 577 alternatives, the offerer may also be concerned about a passive 578 attacker performing eavesdropping on the media stream. Security 579 preconditions can help here by ensuring that clipping will not occur 580 if the answerer supports the secure media stream and furthermore 581 accepts it. Still, they would not guarantee that the media stream 582 established is secure and hence by themselves would not protect 583 against eavesdropping. 585 6 IANA Considerations 587 IANA is hereby requested to register a RFC 3312 precondition type 588 called "sec" with the name "Security precondition". The reference 589 for this precondition type is the current document. 591 7 Acknowledgements 593 The security precondition was defined in earlier draft versions of 594 RFC 3312. RFC 3312 contains an extensive list of people who worked 595 on those earlier draft versions which are acknowledged here as well. 596 The authors would additionally like to thank Mark Baugher, Gonzalo 597 Camarillo, Paul Kyzivat and Thomas Stach for their comments on this 598 document. 600 8 Authors' Addresses 602 Flemming Andreasen 603 Cisco Systems, Inc. 604 499 Thornall Street, 8th Floor 605 Edison, New Jersey 08837 USA 606 EMail: fandreas@cisco.com 608 Dan Wing 609 Cisco Systems, Inc. 610 170 West Tasman Drive 611 San Jose, CA 95134 USA 612 EMail: dwing@cisco.com 614 9 Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 620 Resource Management and Session Initiation Protocol (SIP)", RFC 621 3312, October 2002. 623 [RFC4032] G. Camarillo and P. Kyzivat, "Update to the Session 624 Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 625 2005. 627 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 628 Protocol", RFC 2327, April 1998. 630 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 631 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 632 Initiation Protocol", RFC 3261, June 2002. 634 10 Informative References 636 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security 637 Descriptions for Media Streams", work in progress 639 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 640 Video Conferences with Minimal Control", RFC 3550, July 2003. 642 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. 643 Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March 644 2004. 646 [ICE] J. Rosenberg, "Interactive Connectivity Establishment 647 (ICE): A Methodology for Network Address Translator (NAT) Traversal 648 for Multimedia Session Establishment Protocols", IETF, work-in- 649 progress. 651 [KMGMT] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 652 Norrman, "Key Management Extensions for Session Description Protocol 653 (SDP) and Real Time Streaming Protocol (RTSP)", IETF, work-in- 654 progress. 656 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 657 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 659 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 660 Provisional Responses in Session Initiation Protocol (SIP)", RFC 661 3262, June 2002. 663 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) 664 UPDATE Method," RFC 3311, September 2002. 666 [HERFP] R. Mahy, "A Solution to the Heterogeneous Error Response 667 Forking Problem (HERFP) in the Session Initiation Problem (SIP)", 668 Work in Progress, March 2006. 670 [SDPCN] F. Andreasen, "SDP Capability Negotiation", Work in 671 Progress, June 2006. 673 11 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed 677 to pertain to the implementation or use of the technology described 678 in this document or the extent to which any license under such 679 rights might or might not be available; nor does it represent that 680 it has made any independent effort to identify any such rights. 681 Information on the IETF's procedures with respect to rights in IETF 682 Documents can be found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use 687 of such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository 689 at http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided on 700 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 701 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 702 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 703 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 704 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Copyright Statement 709 Copyright (C) The Internet Society (2006). This document is subject 710 to the rights, licenses and restrictions contained in BCP 78, and 711 except as set forth therein, the authors retain all their rights. 713 Acknowledgment 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.