draft-ietf-mmusic-udptl-dtls-01.txt		draft-ietf-mmusic-udptl-dtls-02.txt
	MMUSIC Working Group C. Holmberg		MMUSIC Working Group C. Holmberg
	Internet-Draft I. Sedlacek		Internet-Draft I. Sedlacek
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: May 25, 2014 G. Salgueiro		Expires: June 8, 2014 G. Salgueiro
	Cisco		Cisco
	November 21, 2013		December 5, 2013
	UDP Transport Layer (UDPTL) over Datagram Transport Layer Security		UDP Transport Layer (UDPTL) over Datagram Transport Layer Security
	(DTLS)		(DTLS)
	draft-ietf-mmusic-udptl-dtls-01		draft-ietf-mmusic-udptl-dtls-02
	Abstract		Abstract
	This document specifies how the UDP Transport Layer (UDPTL) protocol		This document specifies how the UDP Transport Layer (UDPTL) protocol
	can be transported over the Datagram Transport Layer Security (DTLS)		can be transported over the Datagram Transport Layer Security (DTLS)
	protocol, how the usage of UDPTL over DTLS is indicated in the		protocol, how the usage of UDPTL over DTLS is indicated in the
	Session Description Protocol (SDP), and how UDPTL over DTLS is		Session Description Protocol (SDP), and how UDPTL over DTLS is
	negotiated in a session established using the Session Initiation		negotiated in a session established using the Session Initiation
	Protocol (SIP).		Protocol (SIP).
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on May 25, 2014.		This Internet-Draft will expire on June 8, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 4		3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5		3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5
	3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 5		3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 6
	4. Miscellaneous Considerations . . . . . . . . . . . . . . . . 6		4. Miscellaneous Considerations . . . . . . . . . . . . . . . . 6
	4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 6		4.1. Anonymous Calls . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Middlebox Interaction . . . . . . . . . . . . . . . . . . 6		4.2. Middlebox Interaction . . . . . . . . . . . . . . . . . . 6
	4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4.2.2. Latching Control without ICE . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
			8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10
	A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.2. Basic Message Flow with Identity . . . . . . . . . . . . 10		A.2. Basic Message Flow with Identity . . . . . . . . . . . . 11
	A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in		A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in
	An Existing Audio-Only Session . . . . . . . . . . . . . 15		An Existing Audio-Only Session . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	While telephony encryption devices have been traditionally used for		While telephony encryption devices have been traditionally used for
	highly sensitive documents, secure fax on the Public Switched		highly sensitive documents, secure fax on the Public Switched
	Telephone Network (PSTN) was not as widely considered or prioritized		Telephone Network (PSTN) was not as widely considered or prioritized
	because of the challenges involved with physical access to telephony		because of the challenges involved with physical access to telephony
	equipment. As real-time communications transition to IP networks,		equipment. As real-time communications transition to IP networks,
	where information might potentially be intercepted or spoofed, an		where information might potentially be intercepted or spoofed, an
	appropriate level of security for fax that offers integrity and		appropriate level of security for fax that offers integrity and
	skipping to change at page 5, line 35		skipping to change at page 5, line 38
	assigns the SDP setup attribute with a setup:actpass value or		assigns the SDP setup attribute with a setup:actpass value or
	setup:passive value, it MUST be prepared to receive a DTLS		setup:passive value, it MUST be prepared to receive a DTLS
	client_hello message before it receives the SDP answer. If the		client_hello message before it receives the SDP answer. If the
	answerer accepts the media stream, then it MUST assign the SDP		answerer accepts the media stream, then it MUST assign the SDP
	setup attribute with either a setup:active value or setup:passive		setup attribute with either a setup:active value or setup:passive
	value, according to the procedures in [RFC4145]. The answerer		value, according to the procedures in [RFC4145]. The answerer
	MUST NOT assign an SDP setup attribute with a setup:holdconn		MUST NOT assign an SDP setup attribute with a setup:holdconn
	value. Whichever party is active, it MUST initiate a DTLS		value. Whichever party is active, it MUST initiate a DTLS
	handshake by sending a ClientHello over each flow (host/port		handshake by sending a ClientHello over each flow (host/port
	quartet).		quartet).
	o The endpoint MUST use the SDP certificate fingerprint attribute		o If the endpoint supports, and is willing to use, a cipher suite
	[RFC4572].		with an associated certificate, it MUST include an SDP fingerprint
	o The certificate presented during the DTLS handshake MUST match the		attribute [RFC4572] in the SDP.
	fingerprint exchanged via the signaling path in the SDP.		o If a cipher suite with an associated certificate is selected
	o If the fingerprint does not match the hashed certificate, then the		during the DTLS handshake, the certificate received during the
	endpoint MUST tear down the media session immediately. Note that		DTLS handshake MUST match the fingerprint received in the SDP
	it is permissible to wait until the other side's fingerprint has		fingerprint attribute. If the fingerprint does not match the
	been received before establishing the connection; however, this		hashed certificate, then the endpoint MUST tear down the media
	may have undesirable latency effects.		session immediately. Note that it is permissible to wait until
			the other side's fingerprint has been received before establishing
			the connection; however, this may have undesirable latency
			effects.
	o The endpoint MUST NOT use the SDP connection attribute [RFC4145].		o The endpoint MUST NOT use the SDP connection attribute [RFC4145].
	3.2. Secure Channel Usage		3.2. Secure Channel Usage
	DTLS is used as specified in [RFC6347]. Once the DTLS handshake is		DTLS is used as specified in [RFC6347]. Once the DTLS handshake is
	completed, the UDPTL packets SHALL be transported in DTLS record		completed, the UDPTL packets SHALL be transported in DTLS record
	layer "application_data" packets.		layer "application_data" packets.
	4. Miscellaneous Considerations		4. Miscellaneous Considerations
	4.1. Anonymous Calls		4.1. Anonymous Calls
	When making anonymous calls, a new self-signed certificate SHOULD be		When making anonymous calls, a new self-signed certificate SHOULD be
	used for each call and the content of the subjectAltName attribute		used for each call and the content of the subjectAltName attribute
	inside the certificate MUST NOT contain information that either		inside the certificate MUST NOT contain information that either
	allows correlation or identification of the user making anonymous		allows correlation or identification of the user making anonymous
	calls.		calls.
	4.2. Middlebox Interaction		4.2. Middlebox Interaction
	The procedures defined for SRTP-DTLS in Section 6.7 of [RFC5763] for		4.2.1. ICE Interaction
	interaction with middleboxes also apply to UDPTL over DTLS.
	The procedures defined for SRTP-DTLS in Section 5.1.2 of [RFC5764]		When ICE [RFC5245] is being used, the ICE connectivity checks are
	for distinguishing DTLS and STUN packets also apply to UDPTL over		performed before the DTLS handshake begins. Note that if aggressive
	DTLS.		nomination mode is used, multiple candidate pairs may be marked valid
			before ICE finally converges on a single candidate pair. UAs MUST
			treat all ICE candidate pairs associated with a single component as
			part of the same DTLS association. Thus, there will be only one DTLS
			handshake even if there are multiple valid candidate pairs. Note
			that this may mean adjusting the endpoint IP addresses if the
			selected candidate pair shifts, just as if the DTLS packets were an
			ordinary media stream.
	Editor's note: The complete SRTP-DTLS implementation is not needed.		4.2.2. Latching Control without ICE
	Only the parts for interaction with middleboxes in RFC5763 and for
	distinguishing DTLS and STUN packets in RFC5764 are needed. Should		When ICE [RFC5245] is not being used and the DTLS handshake has not
	those be copied into this document?		completed upon receiving the other side's SDP, then the passive side
			MUST do a single unauthenticated STUN [RFC5389] connectivity check in
			order to open up the appropriate pinhole. All UAs MUST be prepared
			to answer this request during the handshake period even if they do
			not otherwise do ICE. However, the active side MUST proceed with the
			DTLS handshake as appropriate even if no such STUN check is received
			and the passive MUST NOT wait for a STUN answer before sending its
			ServerHello.
			4.2.3. STUN Interaction
			The UA SHALL send the STUN packets [RFC5389] directly over UDP, not
			over DTLS.
			The UA MUST demultiplex packets arriving on the IP address and port
			associated with the DTLS association as follows:
			o If the value of the first byte of the packet is 0 or 1, then the
			packet is STUN.
			o If the value of the first byte of the packet is between 20 and 63
			(inclusive), the packet is DTLS.
	4.3. Rekeying		4.3. Rekeying
	After the DTLS handshake caused by rekeying has completed, because of		After the DTLS handshake caused by rekeying has completed, because of
	possible packet reordering on the wire, packets protected by the		possible packet reordering on the wire, packets protected by the
	previous set of keys can arrive. To compensate for this fact,		previous set of keys can arrive. To compensate for this fact,
	receivers SHOULD maintain both sets of keys for some time in order to		receivers SHOULD maintain both sets of keys for some time in order to
	be able to decrypt and verify older packets. The duration of		be able to decrypt and verify older packets. The duration of
	maintaining the previous set of keys after the finish of the DTLS		maintaining the previous set of keys after the finish of the DTLS
	handshake is out of scope for this document.		handshake is out of scope for this document.
	skipping to change at page 7, line 43		skipping to change at page 8, line 32
	+-------+---------------+------------+		+-------+---------------+------------+
	Table 3: SDP "proto" field values		Table 3: SDP "proto" field values
	[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this		[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
	document.]		document.]
	7. Acknowledgments		7. Acknowledgments
	Special thanks to Peter Dawes, who provided comments on the initial		Special thanks to Peter Dawes, who provided comments on the initial
	version of the draft, and to Paul E. Jones, James Rafferty and		version of the draft, and to Paul E. Jones, James Rafferty, Albrecht
	Albrecht Schwarz who provided valuable feedback and input on the		Schwarz and Oscar Ohlsson who provided valuable feedback and input on
	MMUSIC mailing list.		the MMUSIC mailing list.
	8. Change Log		8. Change Log
	[RFC EDITOR NOTE: Please remove this section when publishing]		[RFC EDITOR NOTE: Please remove this section when publishing]
			Changes from draft-ietf-mmusic-udptl-dtls-01
			o Usage of the SDP fingerprint attribute depends on whether a cipher
			suite with an associated certificate is used.
			o Editor's note in section 4.2 removed. Procedure text added.
	Changes from draft-ietf-mmusic-udptl-dtls-00		Changes from draft-ietf-mmusic-udptl-dtls-00
	o SDP offerer is allowed to assign an a=setup:active or		o SDP offerer is allowed to assign an a=setup:active or
	a=setup:passive value, in addition to the recommended		a=setup:passive value, in addition to the recommended
	a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/		a=setup:actpass (http://www.ietf.org/mail-archive/web/mmusic/
	current/msg12331.html).		current/msg12331.html).
	o The example for secure fax replacing audio stream in audio-only		o The example for secure fax replacing audio stream in audio-only
	session added (http://www.ietf.org/mail-archive/web/mmusic/current		session added (http://www.ietf.org/mail-archive/web/mmusic/current
	/msg12428.html).		/msg12428.html).
	o Editor's note on the connection attribute resolved by prohibiting		o Editor's note on the connection attribute resolved by prohibiting
	usage of the SDP connection attribute (http://www.ietf.org/mail-		usage of the SDP connection attribute (http://www.ietf.org/mail-
	archive/web/mmusic/current/msg12772.html).		archive/web/mmusic/current/msg12772.html).
	o Editorial corrections.		o Editorial corrections.
	Changes from draft-holmberg-mmusic-udptl-dtls-02		Changes from draft-holmberg-mmusic-udptl-dtls-02
	skipping to change at page 9, line 20		skipping to change at page 10, line 16
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the		[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
	Transport Layer Security (TLS) Protocol in the Session		Transport Layer Security (TLS) Protocol in the Session
	Description Protocol (SDP)", RFC 4572, July 2006.		Description Protocol (SDP)", RFC 4572, July 2006.
			[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
			(ICE): A Protocol for Network Address Translator (NAT)
			Traversal for Offer/Answer Protocols", RFC 5245, April
			2010.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	for Establishing a Secure Real-time Transport Protocol		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	(SRTP) Security Context Using Datagram Transport Layer		October 2008.
	Security (DTLS)", RFC 5763, May 2010.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	[ITU.T30.2005]		[ITU.T30.2005]
	International Telecommunications Union, "Procedures for		International Telecommunications Union, "Procedures for
	document facsimile transmission in the general switched		document facsimile transmission in the general switched
	telephone network", ITU-T Recommendation T.30, September		telephone network", ITU-T Recommendation T.30, September
	2005.		2005.
End of changes. 19 change blocks.
	46 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/