< draft-fischl-mmusic-sdp-dtls-03.txt		draft-fischl-mmusic-sdp-dtls-04.txt >
	Network Working Group J. Fischl		Network Working Group J. Fischl
	Internet-Draft CounterPath Solutions, Inc.		Internet-Draft CounterPath Solutions, Inc.
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: January 10, 2008		Expires: May 22, 2008
	July 9, 2007		November 19, 2007
	Session Description Protocol (SDP) Indicators for Datagram Transport		Session Description Protocol (SDP) Indicators for Datagram Transport
	Layer Security (DTLS)		Layer Security (DTLS)
	draft-fischl-mmusic-sdp-dtls-03.txt		draft-fischl-mmusic-sdp-dtls-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 10, 2008.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This specification defines how to use the Session Description		This specification defines how to use the Session Description
	Protocol (SDP) to signal that media will be transported over Datagram		Protocol (SDP) to signal that media will be transported over Datagram
	Transport Layer Security (DTLS) or where the SRTP security context is		Transport Layer Security (DTLS) or where the SRTP security context is
	established using DTLS and. It reuses the syntax and semantics for		established using DTLS and. It reuses the syntax and semantics for
	an SDP 'fingerprint' attribute that identifies the certificate which		an SDP 'fingerprint' attribute that identifies the certificate which
	will be presented during the DTLS handshake.		will be presented during the DTLS handshake.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. DTLS Certificates . . . . . . . . . . . . . . . . . . . . . . . 3		3. DTLS Certificates . . . . . . . . . . . . . . . . . . . . . . . 3
	4. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Session Description for RTP/AVP over DTLS . . . . . . . . . . . 4		5. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	9.2. Informational References . . . . . . . . . . . . . . . . . 7		9.2. Informational References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Session Description Protocol (SDP) RFC 2327 [7] has been used to set		Session Description Protocol (SDP) RFC 2327 [6] has been used to set
	up the transport of various types of media with RTP [9] over UDP		up the transport of various types of media with RTP [8] over UDP [9],
	[10], TCP [14], and TLS [2]. DTLS [12] is a protocol for applying		TCP [14], and TLS [12]. DTLS [11] is a protocol for applying TLS
	TLS security to datagram protocols such as UDP and DCCP [1]. This		security to datagram protocols such as UDP and DCCP [1]. This
	specification defines new SDP protocol syntax that allow SDP to		specification defines new SDP protocol syntax that allow SDP to
	indicate that DTLS should be used to transport the media when TLS is		indicate that DTLS should be used to transport the media when TLS is
	used.		used.
	The handling of TLS sessions in SDP is defined in [2] that discusses		The handling of TLS sessions in SDP is defined in [12] that discusses
	only TLS over TCP. This document extends that specification to also		only TLS over TCP. This document extends that specification to also
	deal with TLS over datagram protocols such as UDP and DCCP and when		deal with TLS over datagram protocols such as UDP and DCCP and when
	(D)TLS is used to establish keys for SRTP as in [5]		(D)TLS is used to establish keys for SRTP as in [4]
	[[NOTE: This document has a major dependency on work currently going		[[NOTE: This document has a major dependency on work currently going
	on in the MMUSIC WG to mechanisms for SDP capability negotiation		on in the MMUSIC WG to mechanisms for SDP capability negotiation
	which will enable this sort of best-effort encryption. When that		which will enable this sort of best-effort encryption. When that
	work is finished, this draft will be harmonized with it.		work is finished, this draft will be harmonized with it.
	Furthermore, the contents of this document will be integrated into		Furthermore, the contents of this document will be integrated into
	[5]]]		[4]]]
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [6].		document are to be interpreted as described in RFC 2119 [5].
	3. DTLS Certificates		3. DTLS Certificates
	The two endpoints in the exchange present their identities as part of		The two endpoints in the exchange present their identities as part of
	the DTLS handshake procedure using certificates. This document uses		the DTLS handshake procedure using certificates. This document uses
	certificates in the same style as described in Comedia over TLS in		certificates in the same style as described in Comedia over TLS in
	SDP [2].		SDP [12].
	If self-signed certificates are used, the content of the		If self-signed certificates are used, the content of the
	subjectAltName attribute inside the certificate MAY use the uniform		subjectAltName attribute inside the certificate MAY use the uniform
	resource identifier (URI) of the user. This is useful for debugging		resource identifier (URI) of the user. This is useful for debugging
	purposes only and is not required to bind the certificate to one of		purposes only and is not required to bind the certificate to one of
	the communication endpoints. The integrity of the certificate is		the communication endpoints. The integrity of the certificate is
	ensured through the fingerprint attribute in the SDP. The		ensured through the fingerprint attribute in the SDP. The
	subjectAltName is not an important component of the certificate		subjectAltName is not an important component of the certificate
	verification.		verification.
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	The endpoints MAY cache their certificates and reuse them across		The endpoints MAY cache their certificates and reuse them across
	multiple sessions.		multiple sessions.
	[Editor's Note: Certificate lifetime issues will be discussed in a		[Editor's Note: Certificate lifetime issues will be discussed in a
	future draft version.]		future draft version.]
	4. SDP		4. SDP
	In addition to the usual contents of an SDP [13] message, each 'm'		In addition to the usual contents of an SDP [13] message, each 'm'
	line will also contain several attributes as specified in RFC 4145		line will also contain several attributes as specified in RFC 4145
	[11] and [2].		[10] and [12].
	The endpoint MUST use the setup and connection attributes defined in		The endpoint MUST use the setup and connection attributes defined in
	"TCP-Based Media Transport in the SDP" [11]. For the purposes of		"TCP-Based Media Transport in the SDP" [10]. For the purposes of
	this specification, a setup:active endpoint will act as a DTLS client		this specification, a setup:active endpoint will act as a DTLS client
	and a setup:passive endpoint will act as a DTLS server. The		and a setup:passive endpoint will act as a DTLS server. The
	connection attribute indicates whether or not to reuse an existing		connection attribute indicates whether or not to reuse an existing
	DTLS association.		DTLS association.
	A certificate fingerprint is the output of a one-way hash function		A certificate fingerprint is the output of a one-way hash function
	computed over the distinguished encoding rules (DER) form of the		computed over the distinguished encoding rules (DER) form of the
	certificate. The endpoint MUST use the certificate fingerprint		certificate. The endpoint MUST use the certificate fingerprint
	attribute as specified in [2].		attribute as specified in [12].
	TODO: The MMUSIC working group is currently studying the problem of		TODO: The MMUSIC working group is currently studying the problem of
	signalling in SDP the ability/desire to initiate a secure channel		signalling in SDP the ability/desire to initiate a secure channel
	rather than an insecure one [3][4]. We need to use those techniques		rather than an insecure one [2][3]. We need to use those techniques
	when they are finalized.		when they are finalized.
	5. Session Description for RTP/AVP over DTLS		5. Session Description for RTP/SAVP over DTLS
	This specification defines new tokens to describe the protocol used		This specification defines new tokens to describe the protocol used
	in SDP "m=" lines. The new values defined for the proto field are:		in SDP "m=" lines. The new values defined for the proto field are:
	o When a RTP/AVP stream is transported over DTLS with DCCP, then the		o When a RTP/SAVP stream is transported over DTLS with DCCP, then
	token SHALL be DCCP/TLS/RTP/AVP.		the token SHALL be DCCP/TLS/RTP/SAVP.
	o When a RTP/AVP stream is transported over DTLS with UDP, the token		o When a RTP/SAVP stream is transported over DTLS with UDP, the
	SHALL be UDP/TLS/RTP/AVP.		token SHALL be UDP/TLS/RTP/SAVP.
	o When a RTP/AVP stream is transported over TLS with TCP, the token		o When a RTP/SAVP stream is transported over TLS with TCP, the token
	SHALL be TCP/TLS/RTP/AVP.		SHALL be TCP/TLS/RTP/SAVP.
	o When media is transported over DTLS with UDP, the token SHALL be		o When media is transported over DTLS with UDP, the token SHALL be
	UDP/TLS.		UDP/TLS.
	o When media is transported over DTLS with DCCP, the token SHALL be		o When media is transported over DTLS with DCCP, the token SHALL be
	DCCP/TLS.		DCCP/TLS.
	For RTP profiles other than AVP, a new token should be defined in the		For RTP profiles other than SAVP, a new token should be defined in
	form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz where		the form of DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz
	xyz is replaced with an appropriate token for that profile.		where xyz is replaced with an appropriate token for that profile.
	6. IANA Considerations		6. IANA Considerations
	This specification updates the "Session Description Protocol (SDP)		This specification updates the "Session Description Protocol (SDP)
	Parameters" registry as defined in Appendix B of RFC 2327 [7].		Parameters" registry as defined in Appendix B of RFC 2327 [6].
	Specifically it adds the following values to the table for the		Specifically it adds the following values to the table for the
	"proto" field.		"proto" field.
	Type SDP Name Reference		Type SDP Name Reference
	---- ------------------ ---------		---- ------------------ ---------
	proto TCP/TLS/RTP/AVP [RFC-XXXX]		proto TCP/TLS/RTP/SAVP [RFC-XXXX]
	UDP/TLS/RTP/AVP [RFC-XXXX]		UDP/TLS/RTP/SAVP [RFC-XXXX]
	DCCP/TLS/RTP/AVP [RFC-XXXX]		DCCP/TLS/RTP/SAVP [RFC-XXXX]
	UDP/TLS [RFC-XXXX]		UDP/TLS [RFC-XXXX]
	DCCP/TLS [RFC-XXXX]		DCCP/TLS [RFC-XXXX]
	Note to RFC Editor: Please replace RFC-XXXX with the RFC number of		Note to RFC Editor: Please replace RFC-XXXX with the RFC number of
	this specification.		this specification.
	7. Security Considerations		7. Security Considerations
	When using self signed certificates, the signalling protocol used to		When using self signed certificates, the signalling protocol used to
	transport the SDP MUST ensure the integrity of the SDP so that the		transport the SDP MUST ensure the integrity of the SDP so that the
	fingerprint attribute can not be altered. Failure to do this would		fingerprint attribute can not be altered. Failure to do this would
	allow a attacker to insert themselves in the media channel as a man-		allow a attacker to insert themselves in the media channel as a man-
	in-the-middle. A method of ensuring the integrity of the SDP when		in-the-middle. A method of ensuring the integrity of the SDP when
	transporting over the SIP RFC 3261 [8] signalling protocol is		transporting over the SIP RFC 3261 [7] signalling protocol is
	described in [15]		described in [15]
	8. Acknowledgments		8. Acknowledgments
	Cullen Jennings contributed substantial text and comments to this		Cullen Jennings contributed substantial text and comments to this
	document. This document benefitted from discussions with Francois		document. This document benefitted from discussions with Francois
	Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also		Audet, Nagendra Modadugu, Eric Rescorla, and Dan Wing. Thanks also
	for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew,		for useful comments by Flemming Andreasen, Rohan Mahy, David McGrew,
	and David Oran.		and David Oran.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",		[1] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
	draft-ietf-dccp-spec-13 (work in progress), December 2005.		draft-ietf-dccp-spec-13 (work in progress), December 2005.
	[2] Lennox, J., "Connection-Oriented Media Transport over the		[2] Andreasen, F., "SDP Capability Negotiation",
	Transport Layer Security (TLS) Protocol in the Session		draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
	Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06		progress), October 2007.
	(work in progress), March 2006.
	[3] Andreasen, F., "SDP Capability Negotiation",
	draft-ietf-mmusic-sdp-capability-negotiation-05 (work in
	progress), March 2007.
	[4] Andreasen, F., "SDP Capability Negotiation: Requirements and		[3] Andreasen, F., "SDP Capability Negotiation: Requirements and
	Review of Existing Work",		Review of Existing Work",
	draft-ietf-mmusic-sdp-capability-negotiation-reqts-01 (work in		draft-ietf-mmusic-sdp-capability-negotiation-reqts-01 (work in
	progress), March 2007.		progress), March 2007.
	[5] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security		[4] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
	(DTLS) Extension to Establish Keys for Secure Real-time		(DTLS) Extension to Establish Keys for Secure Real-time
	Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-00 (work		Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work
	in progress), July 2007.		in progress), November 2007.
	[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[7] Handley, M. and V. Jacobson, "SDP: Session Description		[6] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[9] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,		[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for Real-Time Applications", STD 64,		"RTP: A Transport Protocol for Real-Time Applications", STD 64,
	RFC 3550, July 2003.		RFC 3550, July 2003.
	[10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video		[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
	Conferences with Minimal Control", STD 65, RFC 3551, July 2003.		Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
	[11] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the		[10] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
	Session Description Protocol (SDP)", RFC 4145, September 2005.		Session Description Protocol (SDP)", RFC 4145, September 2005.
	[12] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[11] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
			[12] Lennox, J., "Connection-Oriented Media Transport over the
			Transport Layer Security (TLS) Protocol in the Session
			Description Protocol (SDP)", RFC 4572, July 2006.
	9.2. Informational References		9.2. Informational References
	[13] Handley, M., "SDP: Session Description Protocol",		[13] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.		Description Protocol", RFC 4566, July 2006.
	[14] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-		[14] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and
	Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06		RTP Control Protocol (RTCP) Packets over Connection-Oriented
	(work in progress), September 2005.		Transport", RFC 4571, July 2006.
	[15] Fischl, J., Tschofenig, H., and E. Rescorla, "Session		[15] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
	Initiation Protocol (SIP) for Media Over Transport Layer		Establishing an SRTP Security Context using DTLS", June 2006.
	Security (TLS)", June 2006.
	Authors' Addresses		Authors' Addresses
	Jason Fischl		Jason Fischl
	CounterPath Solutions, Inc.		CounterPath Solutions, Inc.
	Suite 300, One Bentall Centre, 505 Burrard Street		Suite 300, One Bentall Centre, 505 Burrard Street
	Vancouver, BC V7X 1M3		Vancouver, BC V7X 1M3
	Canada		Canada
	Phone: +1 604 320-3340		Phone: +1 604 320-3340
End of changes. 35 change blocks.
	60 lines changed or deleted		58 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/