idnits 2.17.1 draft-andreasen-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.5 on line 48. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 48), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 430. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == 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? ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 118: '... here MUST be used with the end-to-e...' RFC 2119 keyword, line 124: '... establishment or modification MUST be...' RFC 2119 keyword, line 176: '... stream, the offer MUST be rejected as...' RFC 2119 keyword, line 177: '...ptional security preconditions MUST be...' RFC 2119 keyword, line 325: '... S/MIME, MUST be used....' Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -- 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: 'RFC2119' is mentioned on line 76, but not defined == Missing Reference: 'SDP' is mentioned on line 80, but not defined == Unused Reference: 'RFC2327' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Flemming Andreasen 2 MMUSIC Working Group Mark Baugher 3 INTERNET-DRAFT Dan Wing 4 EXPIRES: April 2005 Cisco Systems 5 October, 2004 7 Security Preconditions for 8 Session Description Protocol Media Streams 9 11 Status of this memo 13 By submitting this Internet-Draft, the authors certify that any 14 applicable patent or other IPR claims of which we are aware have been 15 disclosed, and any of which we become aware will be disclosed, in 16 accordance with RFC 3668 (BCP 79). 18 By submitting this Internet-Draft, the authors accept the provisions 19 of Section 3 of RFC 3667 (BCP 78). 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or 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/lid-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (year). This document is subject 39 to the rights, licenses and restrictions contained in BCP 78, and 40 except as set forth therein, the authors retain all their rights. 42 This document and the information contained herein are provided on an 43 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 44 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 45 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 46 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 47 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 48 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 50 Abstract 52 This document defines a new security precondition for the Session 53 Description Protocol precondition framework described in RFC 3312. 54 A security precondition can be used to delay session establishment 55 or modification until media stream security has been negotiated 56 successfully. 58 1. Notational Conventions..........................................2 59 2. Introduction....................................................2 60 3. Security Precondition Definition................................3 61 4. Examples........................................................4 62 5. Security Considerations.........................................6 63 6. IANA Considerations.............................................7 64 7. Acknowledgements................................................7 65 8. Authors' Addresses..............................................7 66 9. Normative References............................................8 67 10. Informative References..........................................8 68 Intellectual Property Statement......................................9 69 Acknowledgement.....................................................10 71 1. Notational Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 RFC 3312 defines the concept of a Session Description Protocol (SDP) 80 [SDP] precondition, which is a condition that has to be satisfied 81 for a given media stream in order for session establishment or 82 modification to proceed. When the precondition is not met, session 83 progress is delayed until the precondition is satisfied, or the 84 session establishment fails. For example, RFC 3312 defines the 85 Quality of Service precondition, which is used to ensure 86 availability of network resources prior to establishing (i.e. 87 alerting) a call. 89 Media streams can either be provided in cleartext and with no 90 integrity checks, or some kind of media security can be applied, 91 e.g. confidentiality and/or message integrity. For example, the 92 Audio/Video profile of the Real-Time Transfer protocol (RTP) 93 [RFC3551] is normally used without any security services whereas the 94 Secure Real-time Transport Protocol (SRTP) [SRTP] is always used 95 with security services. When media stream security is being 96 negotiated, e.g. using the mechanism defined in SDP Security 97 Descriptions [SDESC], both the offerer and the answerer need to know 98 the cryptographic parameters being used for the media stream; the 99 offerer may provide multiple choices for the cryptographic 100 parameters, or the cryptographic parameters selected by the answerer 101 may differ from those of the offerer (e.g. the key used in one 102 direction versus the other). In such cases, to avoid clipping, the 103 offerer must receive the answer prior to receiving any media packets 104 from the answerer. This can be achieved by using a security 105 precondition, which is used to ensure the successful negotiation of 106 media stream security prior to session establishment or 107 modification. 109 3. Security Precondition Definition 111 The security precondition type is defined by the string "sec" and 112 hence we modify the grammar found in RFC 3312 as follows: 114 precondition-type = "sec" | "qos" | token 116 RFC 3312 defines support for two kinds of status types, namely 117 segmented and end-to-end. The security precondition-type defined 118 here MUST be used with the end-to-end status type; use of the 119 segmented status type is undefined. 121 An entity that wishes to delay session establishment or modification 122 until media stream security has been established uses the security 123 precondition-type in an offer. When a security precondition is 124 received in an offer, session establishment or modification MUST be 125 delayed until the security precondition has been met, i.e. 126 parameters for a secure media stream are known to have been 127 negotiated in the direction(s) required. A secure media stream is 128 here defined as a media stream that uses some kind of security 129 service, e.g. message integrity, confidentiality or both, regardless 130 of the cryptographic strength of the mechanisms being used. 132 As an extreme example of this, Secure RTP (SRTP) using the NULL 133 encryption algorithm and no message authentication/integrity would 134 satisfy the above whereas use of plain RTP would not. Note 135 though, that use of SRTP without authentication is discouraged. 137 The direction tags defined in RFC 3312 are interpreted as follows: 139 * send: Media stream security negotiation is at a stage where it is 140 possible to send secure media packets to the other party and the 141 other party will be able to process them correctly. The 142 definition of "media packets" includes all packets that make up 143 the media stream. In the case of Secure RTP for example, it 144 includes SRTP as well as SRTCP. 146 * recv: Media stream security negotiation is at a stage where it is 147 possible to receive and correctly process secure media stream 148 packets sent by the other party. 150 The precise criteria for determining when the other party is able to 151 correctly process secure media stream packets depends on the secure 152 media stream protocol being used as well as the mechanism by which 153 the required cryptographic parameters are negotiated. We here 154 provide details for SRTP negotiated through SDP security 155 descriptions [SDESC]. 157 When the offerer requests the "send" security precondition, it needs 158 to receive the answer before the security precondition is satisfied. 159 The reason for this is twofold. First, the offerer needs to know 160 where to send the media to. Secondly, in the case where alternative 161 cryptographic parameters are offered, the offerer needs to know 162 which set was selected. The answerer does not know when the answer 163 is actually received by the offerer (which in turn will satisfy the 164 precondition), and hence the answerer needs to use the confirm- 165 status attribute [RFC3312]. This will make the offerer generate a 166 new offer showing the updated status of the precondition. 168 When the offerer requests the "recv" security precondition, it also 169 needs to receive the answer before the security precondition is 170 satisfied. The reason for this is straightforward: The answer 171 contains the cryptographic parameters that will be used by the 172 answerer for sending media to the offerer. 174 If it is not possible to satisfy a mandatory security precondition, 175 e.g. because the offer does not include any parameters related to 176 establishing a secure media stream, the offer MUST be rejected as 177 described in RFC 3312. Optional security preconditions MUST be 178 rejected. 180 4. Examples 182 The call flow of Figure 1 shows a basic session establishment using 183 the Session Initiation Protocol [SIP] and SDP security descriptions 184 [SDESC] with security descriptions for the secure media stream (SRTP 185 in this case). The SDP descriptions of this example are shown below 186 - we have omitted the details of the SDP security descriptions as 187 well as any SIP details for clarity of the security precondition 188 described here: 190 A B 192 | | 193 |-------------(1) INVITE SDP1--------------->| 194 | | 195 |<------(2) 183 Session Progress SDP2--------| 196 | | 197 |----------------(3) PRACK SDP3------------->| 198 | | 199 |<-----------(4) 200 OK (PRACK) SDP4---------| 200 | | 201 |<-------------(5) 180 Ringing---------------| 202 | | 203 | | 204 | | 206 Figure 1: Example using the security precondition 208 SDP1: A includes a mandatory end-to-end security precondition for 209 both the send and receive direction in the initial offer as well as 210 a "crypto" attribute (see [SDESC]), which includes keying material 211 that can be used by A to generate media packets. Since B does not 212 know any of the security parameters yet, the current status (see RFC 213 3312) is set to "none". A's local status table (see RFC 3312) for 214 the security precondition is as follows: 216 Direction | Current | Desired Strength | Confirm 217 -----------+----------+------------------+---------- 218 send | no | mandatory | no 219 recv | no | mandatory | no 221 and the resulting offer SDP is: 223 m=audio 20000 RTP/SAVP 0 224 c=IN IP4 192.0.2.1 225 a=curr:sec e2e none 226 a=des:sec mandatory e2e sendrecv 227 a=crypto:foo... 229 SDP2: When B receives the offer and generates an answer, B knows the 230 (send and recv) security parameters of both A and B. However, A 231 does not know B's security parameters, so the current status of B's 232 "send" security precondition (which equal A's "recv" security 233 precondition) is "no". Similarly, A does not know any of B's SDP 234 information, so B's "send" security precondition is also "no". B's 235 local status table therefore looks as follows: 237 Direction | Current | Desired Strength | Confirm 238 -----------+----------+------------------+---------- 239 send | no | mandatory | no 240 recv | no | mandatory | no 242 B requests A to confirm when A knows the security parameters used in 243 the send and receive direction and hence the resulting answer SDP 244 becomes: 246 m=audio 30000 RTP/SAVP 0 247 c=IN IP4 192.0.2.4 248 a=curr:sec e2e none 249 a=des:sec mandatory e2e sendrecv 250 a=conf:sec e2e sendrecv 251 a=crypto:bar... 253 SDP3: When A receives the answer, A updates its local status table 254 based on the rules in RFC 3312. A knows the security parameters of 255 both the send and receive direction and hence A's local status table 256 is updated as follows: 258 Direction | Current | Desired Strength | Confirm 259 -----------+----------+------------------+---------- 260 send | yes | mandatory | yes 261 recv | yes | mandatory | yes 263 Since B requested confirmation of the send and recv security 264 preconditions, and both are now satisfied, A immediately sends an 265 updated offer (3) to B showing that the security preconditions are 266 satisfied: 268 m=audio 20000 RTP/SAVP 0 269 c=IN IP4 192.0.2.1 270 a=curr:sec e2e sendrecv 271 a=des:sec mandatory e2e sendrecv 272 a=crypto:foo... 274 SDP4: Upon receiving the updated offer, B updates its local status 275 table based on the rules in RFC 3312 which yields the following: 277 Direction | Current | Desired Strength | Confirm 278 -----------+----------+------------------+---------- 279 send | yes | mandatory | no 280 recv | yes | mandatory | no 282 B responds with an answer (4) which contains the current status of 283 the security precondition (i.e., sendrecv) from B's point of view: 285 m=audio 30000 RTP/SAVP 0 286 c=IN IP4 192.0.2.4 287 a=curr:sec e2e sendrecv 288 a=des:sec mandatory e2e sendrecv 290 B's local status table indicates that all mandatory preconditions 291 have been satisfied, and hence session establishment resumes; B 292 returns a 180 (Ringing) response (5) to indicate alerting. 294 5. Security Considerations 296 In addition to the general security for preconditions provided in 297 RFC 3312, the following security issues, which are specific to 298 security preconditions, should be considered. 300 Security preconditions delay session establishment until 301 cryptographic parameters required to send and/or receive media have 302 been negotiated. Negotiation of such parameters can fail for a 303 variety of reasons, including policy preventing use of certain 304 cryptographic algorithms, keys, and other security parameters. If 305 intermediaries can remove security preconditions or downgrade the 306 strength from an offer/answer exchange, they can therefore cause 307 user alerting for session that will abandoned, which is likely to 308 cause inconvenience to the called party. Similarly, security 309 preconditions can be used to prevent clipping due to race conditions 310 between an offer/answer exchange and secure media stream packets 311 based on that offer/answer exchange. If intermediaries can remove 312 or downgrade the strength of security preconditions from an 313 offer/answer exchange, they can cause clipping to occur in the 314 associated secure media stream. 316 Conversely, intermediaries may also add security preconditions to 317 offers that do not contain them or increase their strength. This in 318 turn may lead to session failure or delayed session establishment 319 that was not desired. 321 Use of integrity mechanisms can prevent all of the above problems. 322 Where intermediaries on the signaling path are trusted, it is 323 sufficient to only use hop-by-hop integrity protection, e.g. IPSec 324 or TLS. In all other cases, end-to-end integrity protection, e.g. 325 S/MIME, MUST be used. 327 6. IANA Considerations 329 IANA is hereby requested to register a RFC 3312 precondition type 330 called "sec" with the name "Security precondition". The reference 331 for this precondition type is the current document. 333 7. Acknowledgements 335 The security precondition was defined in earlier draft versions of 336 RFC 3312. RFC 3312 contains an extensive list of people who worked 337 on those earlier draft versions which are acknowledged here as well. 338 Thanks to Paul Kyzivat who optimized the example message flow. 340 8. Authors' Addresses 342 Flemming Andreasen 343 Cisco Systems, Inc. 344 499 Thornall Street, 8th Floor 345 Edison, New Jersey 08837 USA 346 EMail: fandreas@cisco.com 348 Mark Baugher 349 5510 SW Orchid Street 350 Portland, Oregon 97219 USA 351 EMail: mbaugher@cisco.com 352 Dan Wing 353 Cisco Systems, Inc. 354 170 West Tasman Drive 355 San Jose, CA 95134 USA 356 EMail: dwing@cisco.com 358 9. Normative References 360 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 361 Resource Management and Session Initiation Protocol (SIP)", RFC 362 3312, October 2002. 364 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 365 Protocol", RFC 2327, April 1998. 367 10. Informative References 369 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security 370 Descriptions for Media Streams", work in progress 372 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 373 Video Conferences with Minimal Control", RFC 3550, July 2003. 375 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 376 "The Secure Real-time Transport Protocol", RFC 3711, March 2004. 378 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 379 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 380 Initiation Protocol", RFC 3261, June 2002. 382 Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 intellectual property or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; neither does it represent that it 389 has made any effort to identify any such rights. Information on the 390 IETF's procedures with respect to rights in standards-track and 391 standards-related documentation can be found in BCP-11. Copies of 392 claims of rights made available for publication and any assurances 393 of licenses to be made available, or the result of an attempt made 394 to obtain a general license or permission for the use of such 395 proprietary rights by implementors or users of this specification 396 can be obtained from the IETF Secretariat. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights which may cover technology that may be required to practice 401 this standard. Please address the information to the IETF Executive 402 Director. 404 Full Copyright Statement 406 Copyright(C) The Internet Society 2004. All Rights Reserved. 408 This document and translations of it may be copied and furnished to 409 others, and derivative works that comment on or otherwise explain it 410 or assist in its implementation may be prepared, copied, published 411 and distributed, in whole or in part, without restriction of any 412 kind, provided that the above copyright notice and this paragraph 413 are included on all such copies and derivative works. However, this 414 document itself may not be modified in any way, such as by removing 415 the copyright notice or references to the Internet Society or other 416 Internet organizations, except as needed for the purpose of 417 developing Internet standards in which case the procedures for 418 copyrights defined in the Internet Standards process must be 419 followed, or as required to translate it into languages other than 420 English. 422 The limited permissions granted above are perpetual and will not be 423 revoked by the Internet Society or its successors or assigns. 425 This document and the information contained herein is provided on an 426 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 427 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 428 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 429 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 430 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 432 Acknowledgement 434 Funding for the RFC Editor function is currently provided by the 435 Internet Society.