idnits 2.17.1 draft-fischl-mmusic-sdp-dtls-04.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, updated by RFC 4748 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 313. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 19, 2007) is 6002 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) -- Looks like a reference, but probably isn't: 'RFC-XXXX' on line 178 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-07 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-01 ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 4347 (ref. '11') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4572 (ref. '12') (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '13') (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fischl 3 Internet-Draft CounterPath Solutions, Inc. 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 22, 2008 6 November 19, 2007 8 Session Description Protocol (SDP) Indicators for Datagram Transport 9 Layer Security (DTLS) 10 draft-fischl-mmusic-sdp-dtls-04.txt 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 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to 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/1id-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 May 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines how to use the Session Description 44 Protocol (SDP) to signal that media will be transported over Datagram 45 Transport Layer Security (DTLS) or where the SRTP security context is 46 established using DTLS and. It reuses the syntax and semantics for 47 an SDP 'fingerprint' attribute that identifies the certificate which 48 will be presented during the DTLS handshake. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DTLS Certificates . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 9.2. Informational References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Intellectual Property and Copyright Statements . . . . . . . . . . 8 66 1. Introduction 68 Session Description Protocol (SDP) RFC 2327 [6] has been used to set 69 up the transport of various types of media with RTP [8] over UDP [9], 70 TCP [14], and TLS [12]. DTLS [11] is a protocol for applying TLS 71 security to datagram protocols such as UDP and DCCP [1]. This 72 specification defines new SDP protocol syntax that allow SDP to 73 indicate that DTLS should be used to transport the media when TLS is 74 used. 76 The handling of TLS sessions in SDP is defined in [12] that discusses 77 only TLS over TCP. This document extends that specification to also 78 deal with TLS over datagram protocols such as UDP and DCCP and when 79 (D)TLS is used to establish keys for SRTP as in [4] 81 [[NOTE: This document has a major dependency on work currently going 82 on in the MMUSIC WG to mechanisms for SDP capability negotiation 83 which will enable this sort of best-effort encryption. When that 84 work is finished, this draft will be harmonized with it. 85 Furthermore, the contents of this document will be integrated into 86 [4]]] 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [5]. 94 3. DTLS Certificates 96 The two endpoints in the exchange present their identities as part of 97 the DTLS handshake procedure using certificates. This document uses 98 certificates in the same style as described in Comedia over TLS in 99 SDP [12]. 101 If self-signed certificates are used, the content of the 102 subjectAltName attribute inside the certificate MAY use the uniform 103 resource identifier (URI) of the user. This is useful for debugging 104 purposes only and is not required to bind the certificate to one of 105 the communication endpoints. The integrity of the certificate is 106 ensured through the fingerprint attribute in the SDP. The 107 subjectAltName is not an important component of the certificate 108 verification. 110 If the endpoint is also able to make anonymous sessions, a distinct, 111 unique, self-signed certificate SHOULD be provided for this purpose. 113 The generation of public/private key pairs is relatively expensive. 114 Endpoints are not required to generate certificates for each session. 116 The endpoints MAY cache their certificates and reuse them across 117 multiple sessions. 119 [Editor's Note: Certificate lifetime issues will be discussed in a 120 future draft version.] 122 4. SDP 124 In addition to the usual contents of an SDP [13] message, each 'm' 125 line will also contain several attributes as specified in RFC 4145 126 [10] and [12]. 128 The endpoint MUST use the setup and connection attributes defined in 129 "TCP-Based Media Transport in the SDP" [10]. For the purposes of 130 this specification, a setup:active endpoint will act as a DTLS client 131 and a setup:passive endpoint will act as a DTLS server. The 132 connection attribute indicates whether or not to reuse an existing 133 DTLS association. 135 A certificate fingerprint is the output of a one-way hash function 136 computed over the distinguished encoding rules (DER) form of the 137 certificate. The endpoint MUST use the certificate fingerprint 138 attribute as specified in [12]. 140 TODO: The MMUSIC working group is currently studying the problem of 141 signalling in SDP the ability/desire to initiate a secure channel 142 rather than an insecure one [2][3]. We need to use those techniques 143 when they are finalized. 145 5. Session Description for RTP/SAVP over DTLS 147 This specification defines new tokens to describe the protocol used 148 in SDP "m=" lines. The new values defined for the proto field are: 149 o When a RTP/SAVP stream is transported over DTLS with DCCP, then 150 the token SHALL be DCCP/TLS/RTP/SAVP. 151 o When a RTP/SAVP stream is transported over DTLS with UDP, the 152 token SHALL be UDP/TLS/RTP/SAVP. 153 o When a RTP/SAVP stream is transported over TLS with TCP, the token 154 SHALL be TCP/TLS/RTP/SAVP. 155 o When media is transported over DTLS with UDP, the token SHALL be 156 UDP/TLS. 158 o When media is transported over DTLS with DCCP, the token SHALL be 159 DCCP/TLS. 161 For RTP profiles other than SAVP, a new token should be defined in 162 the form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz 163 where xyz is replaced with an appropriate token for that profile. 165 6. IANA Considerations 167 This specification updates the "Session Description Protocol (SDP) 168 Parameters" registry as defined in Appendix B of RFC 2327 [6]. 169 Specifically it adds the following values to the table for the 170 "proto" field. 172 Type SDP Name Reference 173 ---- ------------------ --------- 174 proto TCP/TLS/RTP/SAVP [RFC-XXXX] 175 UDP/TLS/RTP/SAVP [RFC-XXXX] 176 DCCP/TLS/RTP/SAVP [RFC-XXXX] 177 UDP/TLS [RFC-XXXX] 178 DCCP/TLS [RFC-XXXX] 180 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 181 this specification. 183 7. Security Considerations 185 When using self signed certificates, the signalling protocol used to 186 transport the SDP MUST ensure the integrity of the SDP so that the 187 fingerprint attribute can not be altered. Failure to do this would 188 allow a attacker to insert themselves in the media channel as a man- 189 in-the-middle. A method of ensuring the integrity of the SDP when 190 transporting over the SIP RFC 3261 [7] signalling protocol is 191 described in [15] 193 8. Acknowledgments 195 Cullen Jennings contributed substantial text and comments to this 196 document. This document benefitted from discussions with Francois 197 Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also 198 for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, 199 and David Oran. 201 9. References 202 9.1. Normative References 204 [1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 205 draft-ietf-dccp-spec-13 (work in progress), December 2005. 207 [2] Andreasen, F., "SDP Capability Negotiation", 208 draft-ietf-mmusic-sdp-capability-negotiation-07 (work in 209 progress), October 2007. 211 [3] Andreasen, F., "SDP Capability Negotiation: Requirements and 212 Review of Existing Work", 213 draft-ietf-mmusic-sdp-capability-negotiation-reqts-01 (work in 214 progress), March 2007. 216 [4] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security 217 (DTLS) Extension to Establish Keys for Secure Real-time 218 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work 219 in progress), November 2007. 221 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", BCP 14, RFC 2119, March 1997. 224 [6] Handley, M. and V. Jacobson, "SDP: Session Description 225 Protocol", RFC 2327, April 1998. 227 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 228 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 229 Session Initiation Protocol", RFC 3261, June 2002. 231 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 232 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 233 RFC 3550, July 2003. 235 [9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 236 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 238 [10] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 239 Session Description Protocol (SDP)", RFC 4145, September 2005. 241 [11] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 242 Security", RFC 4347, April 2006. 244 [12] Lennox, J., "Connection-Oriented Media Transport over the 245 Transport Layer Security (TLS) Protocol in the Session 246 Description Protocol (SDP)", RFC 4572, July 2006. 248 9.2. Informational References 250 [13] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 251 Description Protocol", RFC 4566, July 2006. 253 [14] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and 254 RTP Control Protocol (RTCP) Packets over Connection-Oriented 255 Transport", RFC 4571, July 2006. 257 [15] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 258 Establishing an SRTP Security Context using DTLS", June 2006. 260 Authors' Addresses 262 Jason Fischl 263 CounterPath Solutions, Inc. 264 Suite 300, One Bentall Centre, 505 Burrard Street 265 Vancouver, BC V7X 1M3 266 Canada 268 Phone: +1 604 320-3340 269 Email: jason@counterpath.com 271 Hannes Tschofenig 273 Email: Hannes.Tschofenig@gmx.net 275 Full Copyright Statement 277 Copyright (C) The IETF Trust (2007). 279 This document is subject to the rights, licenses and restrictions 280 contained in BCP 78, and except as set forth therein, the authors 281 retain all their rights. 283 This document and the information contained herein are provided on an 284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 286 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 287 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 288 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 Intellectual Property 293 The IETF takes no position regarding the validity or scope of any 294 Intellectual Property Rights or other rights that might be claimed to 295 pertain to the implementation or use of the technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; nor does it represent that it has 298 made any independent effort to identify any such rights. Information 299 on the procedures with respect to rights in RFC documents can be 300 found in BCP 78 and BCP 79. 302 Copies of IPR disclosures made to the IETF Secretariat and any 303 assurances of licenses to be made available, or the result of an 304 attempt made to obtain a general license or permission for the use of 305 such proprietary rights by implementers or users of this 306 specification can be obtained from the IETF on-line IPR repository at 307 http://www.ietf.org/ipr. 309 The IETF invites any interested party to bring to its attention any 310 copyrights, patents or patent applications, or other proprietary 311 rights that may cover technology that may be required to implement 312 this standard. Please address the information to the IETF at 313 ietf-ipr@ietf.org. 315 Acknowledgment 317 Funding for the RFC Editor function is provided by the IETF 318 Administrative Support Activity (IASA).