idnits 2.17.1 draft-ietf-mmusic-sdp-dtls-00.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 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 315. 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 (January 23, 2008) is 5938 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 171 ** Obsolete normative reference: RFC 4572 (ref. '2') (Obsoleted by RFC 8122) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-08 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-01 ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 4347 (ref. '12') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '13') (Obsoleted by RFC 8866) == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-00 Summary: 4 errors (**), 0 flaws (~~), 4 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: July 26, 2008 Nokia Siemens Networks 6 January 23, 2008 8 Session Description Protocol (SDP) Indicators for Datagram Transport 9 Layer Security (DTLS) 10 draft-ietf-mmusic-sdp-dtls-00.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 July 26, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 9.2. Informational References . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Intellectual Property and Copyright Statements . . . . . . . . . . 8 66 1. Introduction 68 Session Description Protocol (SDP) RFC 2327 [7] has been used to set 69 up the transport of various types of media with RTP [9] over UDP 70 [10], TCP [14], and TLS [2]. DTLS [12] is a protocol for applying 71 TLS 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 [2] 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 [5] 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [6]. 87 3. DTLS Certificates 89 The two endpoints in the exchange present their identities as part of 90 the DTLS handshake procedure using certificates. This document uses 91 certificates in the same style as described in Comedia over TLS in 92 SDP [2]. 94 If self-signed certificates are used, the content of the 95 subjectAltName attribute inside the certificate MAY use the uniform 96 resource identifier (URI) of the user. This is useful for debugging 97 purposes only and is not required to bind the certificate to one of 98 the communication endpoints. The integrity of the certificate is 99 ensured through the fingerprint attribute in the SDP. The 100 subjectAltName is not an important component of the certificate 101 verification. 103 If the endpoint is also able to make anonymous sessions, a distinct, 104 unique, self-signed certificate SHOULD be provided for this purpose. 106 The generation of public/private key pairs is relatively expensive. 107 Endpoints are not required to generate certificates for each session. 109 The endpoints MAY cache their certificates and reuse them across 110 multiple sessions. 112 [Editor's Note: Certificate lifetime issues will be discussed in a 113 future draft version.] 115 4. SDP 117 In addition to the usual contents of an SDP [13] message, each 'm' 118 line will also contain several attributes as specified in RFC 4145 119 [11] and [2]. 121 The endpoint MUST use the setup and connection attributes defined in 122 "TCP-Based Media Transport in the SDP" [11]. For the purposes of 123 this specification, a setup:active endpoint will act as a DTLS client 124 and a setup:passive endpoint will act as a DTLS server. The 125 connection attribute indicates whether or not to reuse an existing 126 DTLS association. 128 A certificate fingerprint is the output of a one-way hash function 129 computed over the distinguished encoding rules (DER) form of the 130 certificate. The endpoint MUST use the certificate fingerprint 131 attribute as specified in [2]. 133 TODO: The MMUSIC working group is currently studying the problem of 134 signalling in SDP the ability/desire to initiate a secure channel 135 rather than an insecure one [3][4]. We need to use those techniques 136 when they are finalized. 138 5. Session Description for RTP/SAVP over DTLS 140 This specification defines new tokens to describe the protocol used 141 in SDP "m=" lines. The new values defined for the proto field are: 143 o When a RTP/SAVP stream is transported over DTLS with DCCP, then 144 the token SHALL be DCCP/TLS/RTP/SAVP. 145 o When a RTP/SAVP stream is transported over DTLS with UDP, the 146 token SHALL be UDP/TLS/RTP/SAVP. 147 o When a RTP/SAVP stream is transported over TLS with TCP, the token 148 SHALL be TCP/TLS/RTP/SAVP. 149 o When media is transported over DTLS with UDP, the token SHALL be 150 UDP/TLS. 151 o When media is transported over DTLS with DCCP, the token SHALL be 152 DCCP/TLS. 154 For RTP profiles other than AVP, a new token should be defined in the 155 form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz where 156 xyz is replaced with an appropriate token for that profile. 158 6. IANA Considerations 160 This specification updates the "Session Description Protocol (SDP) 161 Parameters" registry as defined in Appendix B of RFC 2327 [7]. 162 Specifically it adds the following values to the table for the 163 "proto" field. 165 Type SDP Name Reference 166 ---- ------------------ --------- 167 proto TCP/TLS/RTP/SAVP [RFC-XXXX] 168 UDP/TLS/RTP/SAVP [RFC-XXXX] 169 DCCP/TLS/RTP/SAVP [RFC-XXXX] 170 UDP/TLS [RFC-XXXX] 171 DCCP/TLS [RFC-XXXX] 173 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 174 this specification. 176 7. Security Considerations 178 When using self signed certificates, the signalling protocol used to 179 transport the SDP MUST ensure the integrity of the SDP so that the 180 fingerprint attribute can not be altered. Failure to do this would 181 allow a attacker to insert themselves in the media channel as a man- 182 in-the-middle. A method of ensuring the integrity of the SDP when 183 transporting over the SIP RFC 3261 [8] signalling protocol is 184 described in [15] 186 8. Acknowledgments 188 Cullen Jennings contributed substantial text and comments to this 189 document. This document benefitted from discussions with Francois 190 Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also 191 for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, 192 and David Oran. 194 9. References 196 9.1. Normative References 198 [1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 199 draft-ietf-dccp-spec-13 (work in progress), December 2005. 201 [2] Lennox, J., "Connection-Oriented Media Transport over the 202 Transport Layer Security (TLS) Protocol in the Session 203 Description Protocol (SDP)", RFC 4572, July 2006. 205 [3] Andreasen, F., "SDP Capability Negotiation", 206 draft-ietf-mmusic-sdp-capability-negotiation-08 (work in 207 progress), December 2007. 209 [4] Andreasen, F., "SDP Capability Negotiation: Requirements and 210 Review of Existing Work", 211 draft-ietf-mmusic-sdp-capability-negotiation-reqts-01 (work in 212 progress), March 2007. 214 [5] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security 215 (DTLS) Extension to Establish Keys for Secure Real-time 216 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work 217 in progress), November 2007. 219 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 220 Levels", BCP 14, RFC 2119, March 1997. 222 [7] Handley, M. and V. Jacobson, "SDP: Session Description 223 Protocol", RFC 2327, April 1998. 225 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 226 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 227 Session Initiation Protocol", RFC 3261, June 2002. 229 [9] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 230 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 231 RFC 3550, July 2003. 233 [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 234 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 236 [11] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 237 Session Description Protocol (SDP)", RFC 4145, September 2005. 239 [12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 240 Security", RFC 4347, April 2006. 242 9.2. Informational References 244 [13] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 245 Description Protocol", RFC 4566, July 2006. 247 [14] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and 248 RTP Control Protocol (RTCP) Packets over Connection-Oriented 249 Transport", RFC 4571, July 2006. 251 [15] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for 252 Establishing an SRTP Security Context using DTLS", 253 draft-ietf-sip-dtls-srtp-framework-00 (work in progress), 254 November 2007. 256 Authors' Addresses 258 Jason Fischl 259 CounterPath Solutions, Inc. 260 Suite 300, One Bentall Centre, 505 Burrard Street 261 Vancouver, BC V7X 1M3 262 Canada 264 Phone: +1 604 320-3340 265 Email: jason@counterpath.com 267 Hannes Tschofenig 268 Nokia Siemens Networks 269 Linnoitustie 6 270 Espoo 02600 271 Finland 273 Phone: +358 (50) 4871445 274 Email: Hannes.Tschofenig@nsn.com 275 URI: http://www.tschofenig.com 277 Full Copyright Statement 279 Copyright (C) The IETF Trust (2008). 281 This document is subject to the rights, licenses and restrictions 282 contained in BCP 78, and except as set forth therein, the authors 283 retain all their rights. 285 This document and the information contained herein are provided on an 286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 288 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 289 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 290 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 293 Intellectual Property 295 The IETF takes no position regarding the validity or scope of any 296 Intellectual Property Rights or other rights that might be claimed to 297 pertain to the implementation or use of the technology described in 298 this document or the extent to which any license under such rights 299 might or might not be available; nor does it represent that it has 300 made any independent effort to identify any such rights. Information 301 on the procedures with respect to rights in RFC documents can be 302 found in BCP 78 and BCP 79. 304 Copies of IPR disclosures made to the IETF Secretariat and any 305 assurances of licenses to be made available, or the result of an 306 attempt made to obtain a general license or permission for the use of 307 such proprietary rights by implementers or users of this 308 specification can be obtained from the IETF on-line IPR repository at 309 http://www.ietf.org/ipr. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights that may cover technology that may be required to implement 314 this standard. Please address the information to the IETF at 315 ietf-ipr@ietf.org. 317 Acknowledgment 319 Funding for the RFC Editor function is provided by the IETF 320 Administrative Support Activity (IASA).