idnits 2.17.1 draft-fischl-mmusic-sdp-dtls-02.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 (March 4, 2007) is 6255 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 176 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-04 == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sdp-capability-negotiation-reqts-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-mcgrew-tls-srtp-00 ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 4347 (ref. '12') (Obsoleted by RFC 6347) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: September 5, 2007 6 March 4, 2007 8 Session Description Protocol (SDP) Indicators for Datagram Transport 9 Layer Security (DTLS) 10 draft-fischl-mmusic-sdp-dtls-02.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 September 5, 2007. 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/AVP 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 [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 [[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.]] 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [6]. 92 3. DTLS Certificates 94 The two endpoints in the exchange present their identities as part of 95 the DTLS handshake procedure using certificates. This document uses 96 certificates in the same style as described in Comedia over TLS in 97 SDP [2]. 99 If self-signed certificates are used, the content of the 100 subjectAltName attribute inside the certificate MAY use the uniform 101 resource identifier (URI) of the user. This is useful for debugging 102 purposes only and is not required to bind the certificate to one of 103 the communication endpoints. The integrity of the certificate is 104 ensured through the fingerprint attribute in the SDP. The 105 subjectAltName is not an important component of the certificate 106 verification. 108 If the endpoint is also able to make anonymous sessions, a distinct, 109 unique, self-signed certificate SHOULD be provided for this purpose. 111 The generation of public/private key pairs is relatively expensive. 113 Endpoints are not required to generate certificates for each session. 115 The endpoints MAY cache their certificates and reuse them across 116 multiple sessions. 118 [Editor's Note: Certificate lifetime issues will be discussed in a 119 future draft version.] 121 4. SDP 123 In addition to the usual contents of an SDP [13] message, each 'm' 124 line will also contain several attributes as specified in RFC 4145 125 [11] and [2]. 127 The endpoint MUST use the setup and connection attributes defined in 128 "TCP-Based Media Transport in the SDP" [11]. For the purposes of 129 this specification, a setup:active endpoint will act as a DTLS client 130 and a setup:passive endpoint will act as a DTLS server. The 131 connection attribute indicates whether or not to reuse an existing 132 DTLS association. 134 A certificate fingerprint is the output of a one-way hash function 135 computed over the distinguished encoding rules (DER) form of the 136 certificate. The endpoint MUST use the certificate fingerprint 137 attribute as specified in [2]. 139 TODO: The MMUSIC working group is currently studying the problem of 140 signalling in SDP the ability/desire to initiate a secure channel 141 rather than an insecure one [3][4]. We need to use those techniques 142 when they are finalized. 144 5. Session Description for RTP/AVP over DTLS 146 This specification defines new tokens to describe the protocol used 147 in SDP "m=" lines. The new values defined for the proto field are: 148 o When a RTP/AVP stream is transported over DTLS with DCCP, then the 149 token SHALL be DCCP/TLS/RTP/AVP. 150 o When a RTP/AVP stream is transported over DTLS with UDP, the token 151 SHALL be UDP/TLS/RTP/AVP. 152 o When a RTP/AVP stream is transported over TLS with TCP, the token 153 SHALL be TCP/TLS/RTP/AVP. 154 o When media is transported over DTLS with UDP, the token SHALL be 155 UDP/TLS. 156 o When media is transported over DTLS with DCCP, the token SHALL be 157 DCCP/TLS. 159 For RTP profiles other than AVP, a new token should be defined in the 160 form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz where 161 xyz is replaced with an appropriate token for that profile. 163 6. IANA Considerations 165 This specification updates the "Session Description Protocol (SDP) 166 Parameters" registry as defined in Appendix B of RFC 2327 [7]. 167 Specifically it adds the following values to the table for the 168 "proto" field. 170 Type SDP Name Reference 171 ---- ------------------ --------- 172 proto TCP/TLS/RTP/AVP [RFC-XXXX] 173 UDP/TLS/RTP/AVP [RFC-XXXX] 174 DCCP/TLS/RTP/AVP [RFC-XXXX] 175 UDP/TLS [RFC-XXXX] 176 DCCP/TLS [RFC-XXXX] 178 Note to RFC Editor: Please replace RFC-XXXX with the RFC number of 179 this specification. 181 7. Security Considerations 183 When using self signed certificates, the signalling protocol used to 184 transport the SDP MUST ensure the integrity of the SDP so that the 185 fingerprint attribute can not be altered. Failure to do this would 186 allow a attacker to insert themselves in the media channel as a man- 187 in-the-middle. A method of ensuring the integrity of the SDP when 188 transporting over the SIP RFC 3261 [8] signalling protocol is 189 described in [15] 191 8. Acknowledgments 193 Cullen Jennings contributed substantial text and comments to this 194 document. This document benefitted from discussions with Francois 195 Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also 196 for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew, 197 and David Oran. 199 9. References 200 9.1. Normative References 202 [1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 203 draft-ietf-dccp-spec-13 (work in progress), December 2005. 205 [2] Lennox, J., "Connection-Oriented Media Transport over the 206 Transport Layer Security (TLS) Protocol in the Session 207 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06 208 (work in progress), March 2006. 210 [3] Andreasen, F., "SDP Capability Negotiation", 211 draft-ietf-mmusic-sdp-capability-negotiation-04 (work in 212 progress), February 2007. 214 [4] Andreasen, F., "SDP Capability Negotiation: Requirements and 215 Review of Existing Work", 216 draft-ietf-mmusic-sdp-capability-negotiation-reqts-00 (work in 217 progress), December 2006. 219 [5] Rescorla, E. and D. McGrew, "Datagram Transport Layer Security 220 (DTLS) Extension to Establish Keys for Secure Real-time 221 Transport Protocol (SRTP)", draft-mcgrew-tls-srtp-00 (work in 222 progress), June 2006. 224 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 225 Levels", BCP 14, RFC 2119, March 1997. 227 [7] Handley, M. and V. Jacobson, "SDP: Session Description 228 Protocol", RFC 2327, April 1998. 230 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 231 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 232 Session Initiation Protocol", RFC 3261, June 2002. 234 [9] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 235 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 236 RFC 3550, July 2003. 238 [10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 239 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 241 [11] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 242 Session Description Protocol (SDP)", RFC 4145, September 2005. 244 [12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 245 Security", RFC 4347, April 2006. 247 9.2. Informational References 249 [13] Handley, M., "SDP: Session Description Protocol", 250 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 252 [14] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- 253 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06 254 (work in progress), September 2005. 256 [15] Fischl, J., Tschofenig, H., and E. Rescorla, "Session 257 Initiation Protocol (SIP) for Media Over Transport Layer 258 Security (TLS)", June 2006. 260 Authors' Addresses 262 Jason Fischl 263 CounterPath Solutions, Inc. 264 8th Floor, 100 West Pender Street 265 Vancouver, BC V6B 1R8 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).