idnits 2.17.1 draft-andreasen-mmusic-securityprecondition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 104: '... here MUST be used with the end-to-e...' RFC 2119 keyword, line 110: '... establishment or modification MUST be...' RFC 2119 keyword, line 136: '... stream, the offer MUST be rejected as...' 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 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 63, but not defined == Missing Reference: 'SDP' is mentioned on line 67, but not defined == Unused Reference: 'RFC3312' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 256, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 Mark Baugher 4 INTERNET-DRAFT Dan Wing 5 EXPIRES: August 2004 Cisco Systems 6 February, 2004 8 Security Preconditions for 9 Session Description Protocol Media Streams 10 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines a new security precondition for the Session 40 Description Protocol precondition framework described in RFC 3312. 41 A security precondition can be used to delay session establishment 42 or modification until media stream security has been negotiated 43 successfully. 45 1. Notational Conventions..........................................2 46 2. Introduction....................................................2 47 3. Security Precondition Definition................................3 48 4. Examples........................................................3 49 5. Security Considerations.........................................5 50 6. IANA Considerations.............................................5 51 7. Acknowledgements................................................5 52 8. Authors' Addresses..............................................5 53 9. Normative References............................................6 54 10. Informative References..........................................6 55 Intellectual Property Statement......................................6 56 Acknowledgement......................................................7 58 1. Notational Conventions 60 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 2. Introduction 66 RFC 3312 defines the concept of a Session Description Protocol (SDP) 67 [SDP] precondition, which is a condition that has to be satisfied 68 for a given media stream in order for session establishment or 69 modification to proceed. When the precondition is not met, session 70 progress is delayed until the precondition is satisfied, or the 71 session establishment fails. For example, RFC 3312 defines the 72 Quality of Service precondition, which is used to ensure 73 availability of network resources prior to establishing (i.e. 74 alerting) a call. 76 Media streams can either be provided in cleartext and with no 77 integrity checks, or some kind of media security can be applied, 78 e.g. encryption. For example, the Audio/Video profile of the Real- 79 Time Transfer protocol (RTP) [RFC3551] is normally used without any 80 security services whereas the Secure Real-time Transport Protocol 81 (SRTP) [SRTP] is always used with security services. When media 82 stream security is being negotiated, e.g. using the mechanism 83 defined in SDP Security Descriptions [SDESC], both the offerer and 84 the answerer need to know the cryptographic parameters being used 85 for the media stream. If the offerer offers multiple choices for 86 the cryptographic parameters, or the cryptographic parameters 87 selected by the answerer may differ from those of the offerer (e.g. 88 the key used in one direction versus the other). In such cases, to 89 avoid clipping, the offerer must receive the answer prior to 90 receiving any media packets from the answerer. This can be achieved 91 by using a security precondition, which is used to ensure the 92 successful negotiation of media stream security prior to session 93 establishment or modification. 95 3. Security Precondition Definition 97 The security precondition type is defined by the string "sec" and 98 hence we modify the grammar found in RFC 3312 as follows: 100 precondition-type = "sec" | "qos" | token 102 RFC 3312 defines support for two kinds of status types, namely 103 segmented and end-to-end. The security precondition-type defined 104 here MUST be used with the end-to-end status type; use of the 105 segmented status type is undefined. 107 An entity that wishes to delay session establishment or modification 108 until media stream security has been established uses this 109 precondition-type in an offer. When a security precondition is 110 received in an offer, session establishment or modification MUST be 111 delayed until the security precondition has been met, i.e. a secure 112 media stream is known to have been established by both the offerer 113 and answerer. A secure media stream is here defined as a media 114 stream that uses some kind of security service, e.g. encryption, 115 integrity protection or both, regardless of the cryptographic 116 strength of the mechanisms being used. 118 As an extreme example of this, use of the NULL encryption 119 algorithm would satisfy the above. Use of no encryption mechanism 120 however would not. 122 The direction attributes are interpreted as follows: 124 * send: The offerer/answerer has established security parameters 125 for sending media, and the offerer/answerer knows the other party 126 has enough information to process such packets, e.g. the other 127 party has learned the cryptographic algorithm and key. 129 * recv: The offerer/answerer has established security parameters 130 for receiving media, and the offerer/answerer knows the other 131 party has enough information to generate such packets, e.g. the 132 other party has learned the cryptographic algorithm and key. 134 If it is not possible to satisfy the security precondition, e.g. 135 because the offer does not include any parameters related to 136 establishing a secure media stream, the offer MUST be rejected as 137 described in RFC 3312. 139 4. Examples 141 The call flow of Figure 1 shows a basic session establishment using 142 SDP security descriptions [SDESC] and security descriptions for the 143 secure media stream (SRTP in this case). The SDP descriptions of 144 this example are shown below - we have omitted the details of the 145 SDP security descriptions for clarity of the security precondition 146 described here: 148 SDP1: A includes the end-to-end security precondition in the initial 149 offer as well as a crypto parameter (see [SDESC]), which includes 150 keying material that can be used by A to generate media packets. 151 Since B does not know any of the security parameters yet, the 152 current status is set to none: 154 m=audio 20000 RTP/SAVP 0 155 c=IN IP4 192.0.2.1 156 a=curr:sec e2e none 157 a=des:sec mandatory e2e sendrecv 158 a=crypto:foo... 160 SDP2: When B receives the offer, and generates an answer, B knows 161 the security parameters of both A and B, however A does not know the 162 security parameters that will be used by B, so the current status is 163 set to none. B requests A to confirm when A knows the parameters 164 used in the send and receive direction by both: 166 m=audio 30000 RTP/SAVP 0 167 c=IN IP4 192.0.2.4 168 a=curr:sec e2e none 169 a=des:sec mandatory e2e sendrecv 170 a=conf:sec e2e sendrecv 171 a=crypto:bar... 173 SDP3: When A receives the answer, A now knows the security 174 parameters of both A and B. A also knows that B knows those 175 parameters and hence A immediately sends an updated offer (3) to B 176 showing that the security precondition has been satisfied: 178 m=audio 20000 RTP/SAVP 0 179 c=IN IP4 192.0.2.1 180 a=curr:sec e2e sendrecv 181 a=des:sec mandatory e2e sendrecv 182 a=crypto:foo... 184 SDP4: Upon receiving the updated offer, B now knows that both A and 185 B know the security parameters and hence B responds with an answer 186 (4) which contains the current status of the security precondition 187 (i.e., sendrecv) from B's point of view: 189 m=audio 30000 RTP/SAVP 0 190 c=IN IP4 192.0.2.4 191 a=curr:sec e2e sendrecv 192 a=des:sec mandatory e2e sendrecv 194 At this point in time, session establishment resumes and B returns a 195 180 (Ringing) response (5). 197 A B 199 | | 200 |-------------(1) INVITE SDP1--------------->| 201 | | 202 |<------(2) 183 Session Progress SDP2--------| 203 | | 204 |----------------(3) PRACK SDP3------------->| 205 | | 206 |<-----------(4) 200 OK (PRACK) SDP4---------| 207 | | 208 |<-------------(5) 180 Ringing---------------| 209 | | 210 | | 211 | | 213 Figure 1: Example using the security precondition 215 5. Security Considerations 217 TBD 219 6. IANA Considerations 221 IANA is hereby requested to register a RFC 3312 precondition type 222 called "sec" with the name "Security precondition". The reference 223 for this precondition type is the current document. 225 7. Acknowledgements 227 The security precondition was defined in earlier draft versions of 228 RFC 3312. RFC 3312 contains an extensive list of people who worked 229 on those earlier draft versions which are acknowledged here as well. 230 Thanks to Paul Kyzivat who optimized the example message flow. 232 8. Authors' Addresses 234 Flemming Andreasen 235 Cisco Systems, Inc. 236 499 Thornall Street, 8th Floor 237 Edison, New Jersey 08837 USA 238 EMail: fandreas@cisco.com 239 Mark Baugher 240 5510 SW Orchid Street 241 Portland, Oregon 97219 USA 242 EMail: mbaugher@cisco.com 244 Dan Wing 245 Cisco Systems, Inc. 246 170 West Tasman Drive 247 San Jose, CA 95134 USA 248 EMail: dwing@cisco.com 250 9. Normative References 252 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 253 Resource Management and Session Initiation Protocol (SIP)", RFC 254 3312, October 2002. 256 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 257 Protocol", RFC 2327, April 1998. 259 10. Informative References 261 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security 262 Descriptions for Media Streams", work in progress 264 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 265 Video Conferences with Minimal Control", RFC 3550, July 2003. 267 [SRTP] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. 268 Norrman, D. Oran, "The Secure Real-time Transport Protocol", May 269 2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- 270 08.txt, Work in Progress 272 Intellectual Property Statement 274 The IETF takes no position regarding the validity or scope of any 275 intellectual property or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; neither does it represent that it 279 has made any effort to identify any such rights. Information on the 280 IETF's procedures with respect to rights in standards-track and 281 standards-related documentation can be found in BCP-11. Copies of 282 claims of rights made available for publication and any assurances 283 of licenses to be made available, or the result of an attempt made 284 to obtain a general license or permission for the use of such 285 proprietary rights by implementors or users of this specification 286 can be obtained from the IETF Secretariat. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights which may cover technology that may be required to practice 291 this standard. Please address the information to the IETF Executive 292 Director. 294 Full Copyright Statement 296 Copyright(C) The Internet Society 2004. All Rights Reserved. 298 This document and translations of it may be copied and furnished to 299 others, and derivative works that comment on or otherwise explain it 300 or assist in its implementation may be prepared, copied, published 301 and distributed, in whole or in part, without restriction of any 302 kind, provided that the above copyright notice and this paragraph 303 are included on all such copies and derivative works. However, this 304 document itself may not be modified in any way, such as by removing 305 the copyright notice or references to the Internet Society or other 306 Internet organizations, except as needed for the purpose of 307 developing Internet standards in which case the procedures for 308 copyrights defined in the Internet Standards process must be 309 followed, or as required to translate it into languages other than 310 English. 312 The limited permissions granted above are perpetual and will not be 313 revoked by the Internet Society or its successors or assigns. 315 This document and the information contained herein is provided on an 316 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 317 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 318 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 319 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 320 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Acknowledgement 324 Funding for the RFC Editor function is currently provided by the 325 Internet Society.