idnits 2.17.1 draft-fischl-mmusic-sdp-dtls-01.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 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (June 25, 2006) is 6509 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 170 ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 4347 (ref. '9') (Obsoleted by RFC 6347) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Expires: December 27, 2006 H. Tschofenig 6 June 25, 2006 8 Session Description Protocol (SDP) Indicators for Datagram Transport 9 Layer Security (DTLS) 10 draft-fischl-mmusic-sdp-dtls-01.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 December 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 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 defines new SDP protocol identifiers. 47 It reuses the syntax and semantics for an SDP 'fingerprint' attribute 48 that identifies the certificate which will be presented during the 49 DTLS handshake. This allows security provided by the existing DTLS 50 specification to also be applicable to data that is transported over 51 a datagram oriented transport. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. DTLS Certificates . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Session Description for RTP/AVP over DTLS . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 9.2. Informational References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction 71 Session Description Protocol (SDP) RFC 2327 [4] has been used to set 72 up the transport of various types of media with RTP [6] over UDP [7], 73 TCP [11], and TLS [2]. DTLS [9] is a protocol for applying TLS 74 security to datagram protocols such as UDP and DCCP [1]. This 75 specification defines new SDP protocol identifiers that allow SDP to 76 indicate that DTLS should be used to transport the media when TLS is 77 used. 79 The handling of TLS sessions in SDP is defined in [2] that discusses 80 only TLS over TCP. This document extends that specification to also 81 deal with TLS over datagram protocols such as UDP and DCCP. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [3]. 89 3. DTLS Certificates 91 The two endpoints in the exchange present their identities as part of 92 the DTLS handshake procedure using certificates. This document uses 93 certificates in the same style as described in Comedia over TLS in 94 SDP [2]. 96 If self-signed certificates are used, the content of the 97 subjectAltName attribute inside the certificate MAY use the uniform 98 resource identifier (URI) of the user. This is useful for debugging 99 purposes only and is not required to bind the certificate to one of 100 the communication endpoints. The integrity of the certificate is 101 ensured through the fingerprint attribute in the SDP. The 102 subjectAltName is not an important component of the certificate 103 verification. 105 If the endpoint is also able to make anonymous sessions, a distinct, 106 unique, self-signed certificate SHOULD be provided for this purpose. 108 The generation of public/private key pairs is relatively expensive. 109 Endpoints are not required to generate certificates for each session. 111 The endpoints MAY cache their certificates and reuse them across 112 multiple sessions. 114 [Editor's Note: Certificate lifetime issues will be discussed in a 115 future draft version.] 117 4. SDP 119 In addition to the usual contents of an SDP [10] message, each 'm' 120 line will also contain several attributes as specified in RFC 4145 121 [8] and [2]. 123 The endpoint MUST use the setup and connection attributes defined in 124 "TCP-Based Media Transport in the SDP" [8]. For the purposes of this 125 specification, a setup:active endpoint will act as a DTLS client and 126 a setup:passive endpoint will act as a DTLS server. The connection 127 attribute indicates whether or not to reuse an existing DTLS 128 association. 130 A certificate fingerprint is the output of a one-way hash function 131 computed over the distinguished encoding rules (DER) form of the 132 certificate. The endpoint MUST use the certificate fingerprint 133 attribute as specified in [2]. 135 The proto field of the "m=" line MUST be set to the appropriate 136 transport protocol as defined in this specification. 138 5. Session Description for RTP/AVP 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: 142 o When a RTP/AVP stream is transported over DTLS with DCCP, then the 143 token SHALL be DCCP/TLS/RTP/AVP. 144 o When a RTP/AVP stream is transported over DTLS with UDP, the token 145 SHALL be UDP/TLS/RTP/AVP. 146 o When a RTP/AVP stream is transported over TLS with TCP, the token 147 SHALL be TCP/TLS/RTP/AVP. 148 o When media is transported over DTLS with UDP, the token SHALL be 149 UDP/TLS. 150 o When media is transported over DTLS with DCCP, the token SHALL be 151 DCCP/TLS. 153 For RTP profiles other than AVP, a new token should be defined in the 154 form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz where 155 xyz is replaced with an appropriate token for that profile. 157 6. IANA Considerations 159 This specification updates the "Session Description Protocol (SDP) 160 Parameters" registry as defined in Appendix B of RFC 2327 [4]. 161 Specifically it adds the following values to the table for the 162 "proto" field. 164 Type SDP Name Reference 165 ---- ------------------ --------- 166 proto TCP/TLS/RTP/AVP [RFC-XXXX] 167 UDP/TLS/RTP/AVP [RFC-XXXX] 168 DCCP/TLS/RTP/AVP [RFC-XXXX] 169 UDP/TLS [RFC-XXXX] 170 DCCP/TLS [RFC-XXXX] 172 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 173 this specification. 175 7. Security Considerations 177 When using self signed certificates, the signalling protocol used to 178 transport the SDP MUST ensure the integrity of the SDP so that the 179 fingerprint attribute can not be altered. Failure to do this would 180 allow a attacker to insert themselves in the media channel as a man- 181 in-the-middle. A method of ensuring the integrity of the SDP when 182 transporting over the SIP RFC 3261 [5] signalling protocol is 183 described in [12] 185 8. Acknowledgments 187 Cullen Jennings contributed substantial text and comments to this 188 document. This document benefitted from discussions with Francois 189 Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also 190 for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, 191 and David Oran. 193 9. References 195 9.1. Normative References 197 [1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 198 draft-ietf-dccp-spec-13 (work in progress), December 2005. 200 [2] Lennox, J., "Connection-Oriented Media Transport over the 201 Transport Layer Security (TLS) Protocol in the Session 202 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06 203 (work in progress), March 2006. 205 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 206 Levels", BCP 14, RFC 2119, March 1997. 208 [4] Handley, M. and V. Jacobson, "SDP: Session Description 209 Protocol", RFC 2327, April 1998. 211 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 212 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 213 Session Initiation Protocol", RFC 3261, June 2002. 215 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 216 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 217 RFC 3550, July 2003. 219 [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 220 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 222 [8] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 223 Session Description Protocol (SDP)", RFC 4145, September 2005. 225 [9] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 226 Security", RFC 4347, April 2006. 228 9.2. Informational References 230 [10] Handley, M., "SDP: Session Description Protocol", 231 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 233 [11] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 234 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06 235 (work in progress), September 2005. 237 [12] Fischl, J., Tschofenig, H., and E. Rescorla, "Session 238 Initiation Protocol (SIP) for Media Over Transport Layer 239 Security (TLS)", June 2006. 241 Authors' Addresses 243 Jason Fischl 244 CounterPath Solutions, Inc. 245 8th Floor, 100 West Pender Street 246 Vancouver, BC V6B 1R8 247 Canada 249 Phone: +1 604 320-3340 250 Email: jason@counterpath.com 252 Hannes Tschofenig 254 Email: Hannes.Tschofenig@gmx.net 256 Intellectual Property Statement 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the procedures with respect to rights in RFC documents can be 265 found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at 278 ietf-ipr@ietf.org. 280 Disclaimer of Validity 282 This document and the information contained herein are provided on an 283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Copyright Statement 292 Copyright (C) The Internet Society (2006). This document is subject 293 to the rights, licenses and restrictions contained in BCP 78, and 294 except as set forth therein, the authors retain all their rights. 296 Acknowledgment 298 Funding for the RFC Editor function is currently provided by the 299 Internet Society.