idnits 2.17.1 draft-andreasen-mmusic-securityprecondition-00.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 == 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 103: '... here MUST be used with the end-to-e...' RFC 2119 keyword, line 109: '... establishment or modification MUST be...' RFC 2119 keyword, line 135: '... 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.) -- The document date (October 19, 2003) is 7494 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: '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 256, but no explicit reference was found in the text == Unused Reference: 'RFC2327' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) Summary: 5 errors (**), 0 flaws (~~), 7 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: April 2004 Cisco Systems 6 October 19, 2003 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 (2003). 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......................................7 56 Acknowledgement......................................................8 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. For example, RFC 3312 defines the Quality 70 of Service precondition, which is used to ensure availability of 71 network resources prior to establishing (i.e. alerting) a call. 72 When the precondition is not met, session progress is delayed until 73 the precondition is satisfied, or the session establishment fails. 75 Media streams can either be provided in cleartext and with no 76 integrity checks, or some kind of media security can be applied, 77 e.g. encryption. For example, the Audio/Video profile of the Real- 78 Time Transfer protocol (RTP) [RFC3551] is normally used without any 79 security services whereas the Secure Real-time Transport Protocol 80 (SRTP) [SRTP] is always used with security services. When media 81 stream security is being negotiated, e.g. using the mechanism 82 defined in SDP Security Descriptions [SDESC], both the offerer and 83 the answerer need to know the cryptographic parameters being used 84 for the media stream. If the offerer offers multiple choices for 85 the cryptographic parameters, or the cryptographic parameters 86 selected by the answerer may differ from those of the offerer (e.g. 87 the key used in one direction versus the other), this means the 88 offerer must have access to the answer prior to receiving any media 89 packets from the offerer in order to avoid any clipping. This can 90 be achieved by defining a security precondition, which is used to 91 ensure the successful negotiation of media stream security prior to 92 session establishment or modification. 94 3. Security Precondition Definition 96 The security precondition type is defined by the string "sec" and 97 hence we modify the grammar found in RFC 3312 as follows: 99 precondition-type = "sec" | "qos" | token 101 RFC 3312 defines support for two kinds of status types, namely 102 segmented and end-to-end. The security precondition-type defined 103 here MUST be used with the end-to-end status type; use of the 104 segmented status type is undefined. 106 An entity that wishes to delay session establishment or modification 107 until media stream security has been established uses this 108 precondition-type in an offer. When a security precondition is 109 received in an offer, session establishment or modification MUST be 110 delayed until the security precondition has been met, i.e. a secure 111 media stream is known to have been established by both the offerer 112 and answerer. A secure media stream is here defined as a media 113 stream that uses some kind of security service, e.g. encryption, 114 integrity protection or both, regardless of the cryptographic 115 strength of the mechanisms being used. 117 As an extreme example of this, use of the NULL encryption 118 algorithm would satisfy the above. Use of no encryption mechanism 119 however would not. 121 The direction attributes are interpreted as follows: 123 * send: The offerer/answerer has established security parameters 124 for sending media, and the offerer/answerer knows the other party 125 has enough information to process such packets, e.g. the other 126 party has learned the cryptographic algorithm and key. 128 * recv: The offerer/answerer has established security parameters 129 for receiving media, and the offerer/answerer knows the other 130 party has enough information to generate such packets, e.g. the 131 other party has learned the cryptographic algorithm and key. 133 If it is not possible to satisfy the security precondition, e.g. 134 because the offer does not include any parameters related to 135 establishing a secure media stream, the offer MUST be rejected as 136 described in RFC 3312. 138 4. Examples 140 The call flow of Figure 1 shows a basic session establishment using 141 SDP security descriptions [SDESC] and security descriptions for the 142 secure media stream (SRTP in this case). The SDP descriptions of 143 this example are shown below - we have omitted the details of the 144 SDP security descriptions for clarity of the security precondition 145 described here: 147 SDP1: A includes the end-to-end security precondition in the initial 148 offer as well as a crypto parameter (see [SDESC]), which includes 149 keying material that can be used by A to generate media packets. 150 Since B does not know any of the security parameters yet, the 151 current status is set to none: 153 m=audio 20000 RTP/SAVP 0 154 c=IN IP4 192.0.2.1 155 a=curr:sec e2e none 156 a=des:sec mandatory e2e sendrecv 157 a=crypto:foo... 159 SDP2: When B receives the offer, and generates an answer, B knows 160 the security parameters of both A and B, however A does not know the 161 security parameters that will be used by B, so the current status is 162 set to none. B requests A to confirm when A knows the parameters 163 used in the send and receive direction by both: 165 m=audio 30000 RTP/SAVP 0 166 c=IN IP4 192.0.2.4 167 a=curr:sec e2e none 168 a=des:sec mandatory e2e sendrecv 169 a=conf:sec e2e sendrecv 170 a=crypto:bar... 172 SDP3: When A receives the answer, A now knows the security 173 parameters of both A and B. A also knows that B knows those 174 parameters and hence A immediately sends an updated offer (5) to B 175 showing that the security precondition has been satisfied: 177 m=audio 20000 RTP/SAVP 0 178 c=IN IP4 192.0.2.1 179 a=curr:sec e2e sendrecv 180 a=des:qos mandatory e2e sendrecv 181 a=crypto:foo... 183 SDP4: Upon receiving the updated offer, B now knows that both A and 184 B know the security parameters and hence B responds with an answer 185 (6) which contains the current status of the security precondition 186 (i.e., sendrecv) from B's point of view: 188 m=audio 30000 RTP/SAVP 0 189 c=IN IP4 192.0.2.4 190 a=curr:qos e2e sendrecv 191 a=des:qos mandatory e2e sendrecv 193 At this point in time, session establishment resumes and B returns a 194 180 (Ringing) response (7). 196 A B 198 | | 199 |-------------(1) INVITE SDP1--------------->| 200 | | 201 |<------(2) 183 Session Progress SDP2--------| 202 | | 203 |----------------(3) PRACK------------------>| 204 | | 205 |<-----------(4) 200 OK (PRACK)--------------| 206 | | 207 |-------------(5) UPDATE SDP3--------------->| 208 | | 209 |<--------(6) 200 OK (UPDATE) SDP4-----------| 210 | | 211 |<-------------(7) 180 Ringing---------------| 212 | | 213 | | 214 | | 216 Figure 1: Example using the security precondition 218 5. Security Considerations 220 TBD 222 6. IANA Considerations 224 IANA is hereby requested to register a RFC 3312 precondition type 225 called "sec" with the name "Security precondition". The reference 226 for this precondition type is the current document. 228 7. Acknowledgements 230 The security precondition was defined in earlier draft versions of 231 RFC 3312. RFC 3312 contains an extensive list of people who worked 232 on those earlier draft versions which are acknowledged here as well. 234 8. Authors' Addresses 236 Flemming Andreasen 237 Cisco Systems, Inc. 238 499 Thornall Street, 8th Floor 239 Edison, New Jersey 08837 USA 240 fandreas@cisco.com 241 Mark Baugher 242 5510 SW Orchid Street 243 Portland, Oregon 97219 USA 244 mbaugher@cisco.com 245 +1-408-853-4418 247 Dan Wing 248 Cisco Systems, Inc. 249 170 West Tasman Drive 250 San Jose, CA 95134 USA 251 dwing@cisco.com 252 +1-408-902-3348 254 9. Normative References 256 [RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of 257 Resource Management and Session Initiation Protocol (SIP)", RFC 258 3312, October 2002. 260 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 261 Protocol", RFC 2327, April 1998. 263 10. Informative References 265 [SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security 266 Descriptions for Media Streams", work in progress 268 [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and 269 Video Conferences with Minimal Control", RFC 3550, July 2003. 271 [SRTP] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. 272 Norrman, D. Oran, "The Secure Real-time Transport Protocol", May 273 2003, http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp- 274 08.txt, Work in Progress 276 Intellectual Property Statement 278 The IETF takes no position regarding the validity or scope of any 279 intellectual property or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; neither does it represent that it 283 has made any effort to identify any such rights. Information on the 284 IETF's procedures with respect to rights in standards-track and 285 standards-related documentation can be found in BCP-11. Copies of 286 claims of rights made available for publication and any assurances 287 of licenses to be made available, or the result of an attempt made 288 to obtain a general license or permission for the use of such 289 proprietary rights by implementors or users of this specification 290 can be obtained from the IETF Secretariat. 292 The IETF invites any interested party to bring to its attention any 293 copyrights, patents or patent applications, or other proprietary 294 rights which may cover technology that may be required to practice 295 this standard. Please address the information to the IETF Executive 296 Director. 298 Full Copyright Statement 300 Copyright(C) The Internet Society 2003. All Rights Reserved. 302 This document and translations of it may be copied and furnished to 303 others, and derivative works that comment on or otherwise explain it 304 or assist in its implementation may be prepared, copied, published 305 and distributed, in whole or in part, without restriction of any 306 kind, provided that the above copyright notice and this paragraph 307 are included on all such copies and derivative works. However, this 308 document itself may not be modified in any way, such as by removing 309 the copyright notice or references to the Internet Society or other 310 Internet organizations, except as needed for the purpose of 311 developing Internet standards in which case the procedures for 312 copyrights defined in the Internet Standards process must be 313 followed, or as required to translate it into languages other than 314 English. 316 The limited permissions granted above are perpetual and will not be 317 revoked by the Internet Society or its successors or assigns. 319 This document and the information contained herein is provided on an 320 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 321 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 322 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 323 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 324 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Acknowledgement 328 Funding for the RFC Editor function is currently provided by the 329 Internet Society.