draft-ietf-mmusic-udptl-dtls-03.txt		draft-ietf-mmusic-udptl-dtls-04.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: July 21, 2014 G. Salgueiro		Expires: August 5, 2014 G. Salgueiro
	Cisco		Cisco
	January 17, 2014		February 1, 2014
	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-03		draft-ietf-mmusic-udptl-dtls-04
	Abstract		Abstract
	This document specifies how the UDP Transport Layer (UDPTL) protocol,		This document specifies how the UDP Transport Layer (UDPTL) protocol,
	the predominant transport protocol for T.38 fax, can be transported		the predominant transport protocol for T.38 fax, can be transported
	over the Datagram Transport Layer Security (DTLS) protocol, how the		over the Datagram Transport Layer Security (DTLS) protocol, how the
	usage of UDPTL over DTLS is indicated in the Session Description		usage of UDPTL over DTLS is indicated in the Session Description
	Protocol (SDP), and how UDPTL over DTLS is negotiated in a session		Protocol (SDP), and how UDPTL over DTLS is negotiated in a session
	established using the Session Initiation Protocol (SIP).		established using the Session Initiation 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 July 21, 2014.		This Internet-Draft will expire on August 5, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5		3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5		3.1. Secure Channel Establishment . . . . . . . . . . . . . . 5
	3.2. Secure Channel Usage . . . . . . . . . . . . . . . . . . 6		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.2.1. ICE Interaction . . . . . . . . . . . . . . . . . . . 6		4.2.1. NAT Traversal With ICE . . . . . . . . . . . . . . . 6
	4.2.2. Latching Control without ICE . . . . . . . . . . . . 6		4.2.2. NAT Traversal Without ICE . . . . . . . . . . . . . . 6
	4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7		4.2.3. STUN Interaction . . . . . . . . . . . . . . . . . . 7
	4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11		A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 11		A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . 17		An Existing Audio-Only Session . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	While it is possible to transmit highly sensitive documents using		While it is possible to transmit highly sensitive documents using
	traditional telephony encryption devices, secure fax on the Public		traditional telephony encryption devices, secure fax on the Public
	Switched Telephone Network (PSTN) was never widely considered or		Switched Telephone Network (PSTN) was never widely considered or
	prioritized. This was mainly because of the challenges involved with		prioritized. This was mainly because of the challenges involved with
	physical access to telephony equipment. As real-time communications		malevolent physical access to telephony equipment. As real-time
	transition to IP networks, where information might potentially be		communications transition to IP networks, where information might
	intercepted or spoofed, an appropriate level of security for fax that		potentially be intercepted or spoofed, an appropriate level of
	offers integrity and confidentiality protection is vital.		security for fax that offers integrity and confidentiality protection
			is vital.
	The overwhelmingly predominant fax transport protocol is UDPTL-based		The overwhelmingly predominant fax transport protocol is UDPTL-based
	[ITU.T38.2010]. The protocol stack for fax transport using UDPTL is		[ITU.T38.2010]. The protocol stack for fax transport using UDPTL is
	shown in Table 1.		shown in Table 1.
	+-----------------------------+		+-----------------------------+
	| Internet facsimile protocol |		| Internet facsimile protocol |
	+-----------------------------+		+-----------------------------+
	| UDPTL |		| UDPTL |
	+-----------------------------+		+-----------------------------+
	skipping to change at page 4, line 22		skipping to change at page 4, line 22
	DTLS layer between the UDPTL layer and the UDP layer, as shown in		DTLS layer between the UDPTL layer and the UDP layer, as shown in
	Table 2. The UDPTL layer and layers above UDPTL layer require no		Table 2. The UDPTL layer and layers above UDPTL layer require no
	modification.		modification.
	o UDPTL [ITU.T38.2010] is by far the most widely deployed fax		o UDPTL [ITU.T38.2010] is by far the most widely deployed fax
	transport protocol in IP networks.		transport protocol in IP networks.
	o 3GPP and the IP fax community need a mechanism to transport UDPTL		o 3GPP and the IP fax community need a mechanism to transport UDPTL
	over DTLS in order to provide secure fax in IMS and other SIP-		over DTLS in order to provide secure fax in IMS and other SIP-
	based networks.		based networks.
	This document specifies the transport of UDPTL over DTLS using the		This document specifies the transport of UDPTL over DTLS using the
	DTLS record layer "application_data" packets [RFC6347].		DTLS record layer "application_data" packets [RFC5246] [RFC6347].
	Since the DTLS record layer "application_data" packet does not		Since the DTLS record layer "application_data" packet does not
	indicate whether it carries UDPTL, or some other protocol, the usage		indicate whether it carries UDPTL, or some other protocol, the usage
	of a dedicated DTLS association for transport of UDPTL needs to be		of a dedicated DTLS association for transport of UDPTL needs to be
	negotiated, e.g. using the Session Description Protocol (SDP)		negotiated, e.g. using the Session Description Protocol (SDP)
	[RFC4566] and the SDP offer/answer mechanism [RFC3264].		[RFC4566] and the SDP offer/answer mechanism [RFC3264].
	Therefore, this document specifies a new <proto> value [RFC4566] for		Therefore, this document specifies a new <proto> value [RFC4566] for
	the SDP media description ("m=" line) [RFC3264], in order to indicate		the SDP media description ("m=" line) [RFC3264], in order to indicate
	UDPTL over DTLS in SDP messages [RFC4566].		UDPTL over DTLS in SDP messages [RFC4566].
	skipping to change at page 6, line 17		skipping to change at page 6, line 17
	DTLS is used as specified in [RFC6347]. Once the DTLS handshake is		DTLS is used as specified in [RFC6347]. Once the DTLS handshake is
	successfully completed (in order to prevent facsimile data from being		successfully completed (in order to prevent facsimile data from being
	transmitted insecurely), the UDPTL packets SHALL be transported in		transmitted insecurely), the UDPTL packets SHALL be transported in
	DTLS record layer "application_data" packets.		DTLS record 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 attributes inside the certificate SHALL NOT
	inside the certificate MUST NOT contain information that either		contain information that either allows correlation or identification
	allows correlation or identification of the user making anonymous		of the user making anonymous calls. This is particularly important
	calls.		for the subjectAltName and commonName attributes.
	4.2. Middlebox Interaction		4.2. Middlebox Interaction
	4.2.1. ICE Interaction		4.2.1. NAT Traversal With ICE
	When ICE [RFC5245] is being used, the ICE connectivity checks are		When ICE [RFC5245] is being used, the ICE connectivity checks are
	performed before the DTLS handshake begins. Note that if aggressive		performed before the DTLS handshake begins. Note that if aggressive
	nomination mode is used, multiple candidate pairs may be marked valid		nomination mode is used, multiple candidate pairs may be marked valid
	before ICE finally converges on a single candidate pair. UAs MUST		before ICE finally converges on a single candidate pair. UAs MUST
	treat all ICE candidate pairs associated with a single component as		treat all ICE candidate pairs associated with a single component as
	part of the same DTLS association. Thus, there will be only one DTLS		part of the same DTLS association. Thus, there will be only one DTLS
	handshake even if there are multiple valid candidate pairs. Note		handshake even if there are multiple valid candidate pairs. Note
	that this may mean adjusting the endpoint IP addresses if the		that this may mean adjusting the endpoint IP addresses if the
	selected candidate pair shifts, just as if the DTLS packets were an		selected candidate pair shifts, just as if the DTLS packets were an
	ordinary media stream.		ordinary media stream.
	4.2.2. Latching Control without ICE		4.2.2. NAT Traversal Without ICE
	When ICE [RFC5245] is not being used and the DTLS handshake has not		When ICE [RFC5245] is not being used and the DTLS handshake has not
	completed upon receiving the other side's SDP, then the passive side		completed upon receiving the other side's SDP, then the passive side
	MUST do a single unauthenticated STUN [RFC5389] connectivity check in		MUST do a single unauthenticated STUN [RFC5389] connectivity check in
	order to open up the appropriate pinhole. All UAs MUST be prepared		order to open up the appropriate pinhole. All UAs MUST be prepared
	to answer this request during the handshake period even if they do		to answer this request during the handshake period even if they do
	not otherwise do ICE. However, the active side MUST proceed with the		not otherwise do ICE. However, the active side MUST proceed with the
	DTLS handshake as appropriate even if no such STUN check is received		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		and the passive side MUST NOT wait for a STUN answer before sending
	ServerHello.		its ServerHello.
	4.2.3. STUN Interaction		4.2.3. STUN Interaction
	The UA SHALL send the STUN packets [RFC5389] directly over UDP, not		The UA SHALL send the STUN packets [RFC5389] directly over UDP, not
	over DTLS.		over DTLS.
	The UA MUST demultiplex packets arriving on the IP address and port		The UA MUST demultiplex packets arriving on the IP address and port
	associated with the DTLS association as follows:		associated with the DTLS association, e.g. as follows:
	o If the value of the first byte of the packet is 0 or 1, then the		o If the value of the first byte of the packet is 0 or 1, then the
	packet is STUN.		packet is STUN.
	o If the value of the first byte of the packet is between 20 and 63		o If the value of the first byte of the packet is between 20 and 63
	(inclusive), the packet is DTLS.		(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 MUST 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.
	5. Security Considerations		5. Security Considerations
	Fax may be used to transmit a wide range of sensitive data, including		Fax may be used to transmit a wide range of sensitive data, including
	personal, corporate, and governmental information. It is therefore		personal, corporate, and governmental information. It is therefore
	critical to be able to protect against threats to the confidentiality		critical to be able to protect against threats to the confidentiality
	and integrity of the transmitted data.		and integrity of the transmitted data.
	skipping to change at page 8, line 39		skipping to change at page 8, line 39
	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, Albrecht		version of the draft, and to Paul E. Jones, James Rafferty, Albrecht
	Schwarz, Oscar Ohlsson and David Hanes who provided valuable feedback		Schwarz, Oscar Ohlsson, David Hanes, Adam Gensler and Ari Keraenen
	and input on the MMUSIC mailing list.		who provided valuable feedback and input on 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-03
			o Changes based on comments by Adam Gensler (http://www.ietf.org/
			mail-archive/web/mmusic/current/msg12945.html)
			o -Indicating that, in case of rekeying, entities MUST maintain both
			set of keys for some time (previously SHOULD).
			o -Explicit mentioning of the commonName attribute in text about
			correlation/identification of users.
			o Changes based on comments by Ari Keraenen (http://www.ietf.org/
			mail-archive/web/mmusic/current/msg12966.html)
			o -Informative reference to RFC 5246 added.
			o -Re-naming of sections 4.2.1 and 4.2.2.
			o -Clarifying that documented STUN/DTLS demux mechanism is only one
			way of doing the demux.
			o -Editorial corrections.
	Changes from draft-ietf-mmusic-udptl-dtls-02		Changes from draft-ietf-mmusic-udptl-dtls-02
	o Editorial comments based on review comments by James Rafferty		o Editorial comments based on review comments by James Rafferty
	(http://www.ietf.org/mail-archive/web/mmusic/current/		(http://www.ietf.org/mail-archive/web/mmusic/current/
	msg12890.html)		msg12890.html)
	o Editorial comments based on review comments by David Hanes (http:/		o Editorial comments based on review comments by David Hanes (http:/
	/www.ietf.org/mail-archive/web/mmusic/current/msg12886.html)		/www.ietf.org/mail-archive/web/mmusic/current/msg12886.html)
	o Editorial comments based on review comments by Oscar Ohlsson		o Editorial comments based on review comments by Oscar Ohlsson
	(http://www.ietf.org/mail-archive/web/mmusic/current/		(http://www.ietf.org/mail-archive/web/mmusic/current/
	msg12882.html)		msg12882.html)
	o Editorial comments based on review comments by Albrecht Schwartz		o Editorial comments based on review comments by Albrecht Schwartz
	(http://www.ietf.org/mail-archive/web/mmusic/current/		(http://www.ietf.org/mail-archive/web/mmusic/current/
	msg12900.html)		msg12900.html)
	Changes from draft-ietf-mmusic-udptl-dtls-01		Changes from draft-ietf-mmusic-udptl-dtls-01
	skipping to change at page 11, line 21		skipping to change at page 11, line 35
	telephone network", ITU-T Recommendation T.30, September		telephone network", ITU-T Recommendation T.30, September
	2005.		2005.
	[ITU.T38.2010]		[ITU.T38.2010]
	International Telecommunications Union, "Procedures for		International Telecommunications Union, "Procedures for
	real-time Group 3 facsimile communication over IP		real-time Group 3 facsimile communication over IP
	networks", ITU-T Recommendation T.38, September 2010.		networks", ITU-T Recommendation T.38, September 2010.
	9.2. Informative References		9.2. Informative References
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,		[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
	"Requirements and Analysis of Media Security Management		"Requirements and Analysis of Media Security Management
	Protocols", RFC 5479, April 2009.		Protocols", RFC 5479, April 2009.
	Appendix A. Examples		Appendix A. Examples
	A.1. General		A.1. General
	Prior to establishing the session, both Alice and Bob generate self-		Prior to establishing the session, both Alice and Bob generate self-
	signed certificates which are used for a single session or, more		signed certificates which are used for a single session or, more
	skipping to change at page 17, line 42		skipping to change at page 17, line 42
	Alice sends the SIP ACK request to Bob.		Alice sends the SIP ACK request to Bob.
	Message (8):		Message (8):
	At this point, Bob and Alice can exchange T.38 fax securely		At this point, Bob and Alice can exchange T.38 fax securely
	transported using UDPTL over DTLS.		transported using UDPTL over DTLS.
	A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An		A.3. Message Flow Of T.38 Fax Replacing Audio Media Stream in An
	Existing Audio-Only Session		Existing Audio-Only Session
	Traditionally, most session with non-secure transport of T.38 fax,		Traditionally, most sessions with non-secure transport of T.38 fax,
	transported using UDPTL, are established by modifying an ongoing		transported using UDPTL, are established by modifying an ongoing
	audio session into a fax session. Figure 6 shows an example message		audio session into a fax session. Figure 6 shows an example message
	flow of modifying an existing audio session into a session with T.38		flow of modifying an existing audio session into a session with T.38
	fax securely transported using UDPTL over DTLS.		fax securely transported using UDPTL over DTLS.
	In this example flow, Alice acts as the passive endpoint of the DTLS		In this example flow, Alice acts as the passive endpoint of the DTLS
	association and Bob acts as the active endpoint of the DTLS		association and Bob acts as the active endpoint of the DTLS
	association.		association.
	Alice Proxies Bob		Alice Proxies Bob
End of changes. 19 change blocks.
	26 lines changed or deleted		46 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/