draft-ietf-mmusic-udptl-dtls-02.txt		draft-ietf-mmusic-udptl-dtls-03.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: June 8, 2014 G. Salgueiro		Expires: July 21, 2014 G. Salgueiro
	Cisco		Cisco
	December 5, 2013		January 17, 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-02		draft-ietf-mmusic-udptl-dtls-03
	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)		the predominant transport protocol for T.38 fax, can be transported
	protocol, how the usage of UDPTL over DTLS is indicated in the		over the Datagram Transport Layer Security (DTLS) protocol, how the
	Session Description Protocol (SDP), and how UDPTL over DTLS is		usage of UDPTL over DTLS is indicated in the Session Description
	negotiated in a session established using the Session Initiation		Protocol (SDP), and how UDPTL over DTLS is negotiated in a session
	Protocol (SIP).		established using the Session Initiation Protocol (SIP).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 8, 2014.		This Internet-Draft will expire on July 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	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
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	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. ICE Interaction . . . . . . . . . . . . . . . . . . . 6
	4.2.2. Latching Control without ICE . . . . . . . . . . . . 6		4.2.2. Latching Control 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11		A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.2. Basic Message Flow with Identity . . . . . . . . . . . . 11		A.2. Basic Message Flow . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 16		An Existing Audio-Only Session . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	While telephony encryption devices have been traditionally used for		While it is possible to transmit highly sensitive documents using
	highly sensitive documents, secure fax on the Public Switched		traditional telephony encryption devices, secure fax on the Public
	Telephone Network (PSTN) was not as widely considered or prioritized		Switched Telephone Network (PSTN) was never widely considered or
	because of the challenges involved with physical access to telephony		prioritized. This was mainly because of the challenges involved with
	equipment. As real-time communications transition to IP networks,		physical access to telephony equipment. As real-time communications
	where information might potentially be intercepted or spoofed, an		transition to IP networks, where information might potentially be
	appropriate level of security for fax that offers integrity and		intercepted or spoofed, an appropriate level of security for fax that
	confidentiality protection is vital. Some of the security mechanisms		offers integrity and confidentiality protection is vital.
	for securing fax include:
	o [ITU.T30.2005] Annex H specifies integrity and confidentiality
	protection of fax in application layer, independent of protocol
	for fax transport.
	o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables
	integrity and confidentiality protection of fax in IP network.
	Despite these mechanisms to secure fax, there is no transport layer		The overwhelmingly predominant fax transport protocol is UDPTL-based
	security offering integrity and confidentiality protection for UDPTL		[ITU.T38.2010]. The protocol stack for fax transport using UDPTL is
	[ITU.T38.2010], the overwhelmingly predominant fax transport		shown in Table 1.
	protocol. The protocol stack for fax transport using UDPTL is shown
	in Table 1.
	+-----------------------------+		+-----------------------------+
	| Protocol |
	+-----------------------------+
	| Internet facsimile protocol |		| Internet facsimile protocol |
	+-----------------------------+		+-----------------------------+
	| UDPTL |		| UDPTL |
	+-----------------------------+		+-----------------------------+
	| UDP |		| UDP |
	+-----------------------------+		+-----------------------------+
	| IP |		| IP |
	+-----------------------------+		+-----------------------------+
	Table 1: Protocol stack for UDPTL over UDP		Table 1: Protocol stack for UDPTL over UDP
	The 3rd Generation Partnership Project (3GPP) has performed a study		Implementations exist today for securing this fax transport type.
	on how to provide secure fax in the IP Multimedia Subsystem (IMS) and		Some of these mechanisms are:
	concluded that secure fax shall be transported using UDPTL over DTLS.
			o [ITU.T30.2005] Annex H specifies integrity and confidentiality
			protection of fax in the application layer, independent of
			protocol for fax transport.
			o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables
			integrity and confidentiality protection of fax in IP network.
			Despite these mechanisms to secure fax, there is no transport layer
			security offering integrity and confidentiality protection for UDPTL.
			This issue was addressed in a study by the 3rd Generation Partnership
			Project (3GPP) on how to provide secure fax in the IP Multimedia
			Subsystem (IMS). They concluded that secure fax shall be transported
			using UDPTL over DTLS.
	This document specifies fax transport using UDPTL over DTLS		This document specifies fax transport using UDPTL over DTLS
	[RFC6347], which enables integrity and confidentiality protection of		[RFC6347], which enables integrity and confidentiality protection of
	fax in IP networks. The protocol stack for integrity and		fax in IP networks. The protocol stack which enhances fax transport
	confidentiality protected fax transport using UDPTL over DTLS is		to offer integrity and confidentiality using UDPTL over DTLS is shown
	shown in Table 2.		in Table 2.
	+-----------------------------+		+-----------------------------+
	| Protocol |
	+-----------------------------+
	| Internet facsimile protocol |		| Internet facsimile protocol |
	+-----------------------------+		+-----------------------------+
	| UDPTL |		| UDPTL |
	+-----------------------------+		+-----------------------------+
	| DTLS |		| DTLS |
	+-----------------------------+		+-----------------------------+
	| UDP |		| UDP |
	+-----------------------------+		+-----------------------------+
	| IP |		| IP |
	+-----------------------------+		+-----------------------------+
	Table 2: Protocol stack for UDPTL over UDP		Table 2: Protocol stack for UDPTL over DTLS over UDP
	The primary motivations for the mechanism in this document are:		The primary motivations for the mechanism in this document are:
	o The design of DTLS [RFC6347] is clearly defined, well understood		o The design of DTLS [RFC6347] is clearly defined, well understood
	and implementations are widely available.		and implementations are widely available.
	o No DTLS extensions are required in order to enable UDPTL transport		o No DTLS extensions are required in order to enable UDPTL transport
	over DTLS.		over DTLS.
	o Fax transport using UDPTL over DTLS only requires insertion of the		o Fax transport using UDPTL over DTLS only requires insertion of the
	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 needs a mechanism to transport UDPTL over DTLS, in order to		o 3GPP and the IP fax community need a mechanism to transport UDPTL
	provide secure fax in IMS networks.		over DTLS in order to provide secure fax in IMS and other SIP-
			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 [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].
	skipping to change at page 4, line 42		skipping to change at page 4, line 43
	2. Conventions		2. Conventions
	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 BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	DTLS uses the term "session" to refer to a long-lived set of keying		DTLS uses the term "session" to refer to a long-lived set of keying
	material that spans DTLS associations. In this document, in order to		material that spans DTLS associations. In this document, in order to
	be consistent with SIP/SDP usage of "session" terminology, we use it		be consistent with SIP/SDP usage of "session" terminology, we use
	to refer to a multimedia session and use the term "DTLS session" to		"session" to refer to a multimedia session and use the term "DTLS
	refer to the DTLS construct. We use the term "DTLS association" to		session" to refer to the DTLS construct. We use the term "DTLS
	refer to a particular DTLS cipher suite and keying material set that		association" to refer to a particular DTLS cipher suite and keying
	is associated with a single host/port quartet. The same DTLS session		material set that is associated with a single host/port quartet. The
	can be used to establish the keying material for multiple DTLS		same DTLS session can be used to establish the keying material for
	associations. For consistency with other SIP/SDP usage, we use the		multiple DTLS associations. For consistency with other SIP/SDP
	term "connection" when what's being referred to is a multimedia		usage, we use the term "connection" when what's being referred to is
	stream that is not specifically DTLS.		a multimedia stream that is not specifically DTLS.
	3. Secure Channel		3. Secure Channel
	3.1. Secure Channel Establishment		3.1. Secure Channel Establishment
	The SDP offer/answer mechanism [RFC3264] is used by other protocols,		The SDP offer/answer mechanism [RFC3264] is used by other protocols,
	e.g. the Session Initiation Protocol (SIP) [RFC3261], to negotiate		e.g. the Session Initiation Protocol (SIP) [RFC3261], to negotiate
	and establish multimedia sessions.		and establish multimedia sessions.
	In addition to the usual contents of an SDP media description ("m="		In addition to the usual contents of an SDP media description ("m="
	line) specified for UDPTL over the UDP, each SDP media description		line) specified for UDPTL over UDP, each SDP media description for
	for UDPTL over DTLS over the UDP will also contain several SDP		UDPTL over DTLS over UDP will also contain several SDP attributes,
	attributes, as specified in [RFC4145] and [RFC4572].		which were introduced in the context of TCP [RFC4145] and TLS
			[RFC4572], and are re-used in this document.
	The SDP offer and SDP answer MUST conform to the following		The SDP offer and the SDP answer MUST conform to the following
	requirements:		requirements:
	o The endpoint MUST set the "proto" field of the "m=" line to the		o The endpoint MUST set the "proto" field of the "m=" line to the
	token specified in Table 3.		token specified in Table 3.
	o The endpoint MUST use the SDP setup attribute [RFC4145]. The		o In order to negotiate the TLS roles, the endpoint MUST use the SDP
	offerer SHOULD assign the SDP setup attribute with a setup:actpass		setup attribute [RFC4145]. The offerer SHOULD assign the SDP
	value, and MAY assign the SDP setup attribute with a setup:active		setup attribute with a setup:actpass value, and MAY assign the SDP
	value or setup:passive value. The offerer MUST NOT assign the SDP		setup attribute with a setup:active value or setup:passive value.
	setup attribute with a setup:holdconn value. If the offerer		The offerer MUST NOT assign the SDP setup attribute with a
	assigns the SDP setup attribute with a setup:actpass value or		setup:holdconn value. If the offerer assigns the SDP setup
	setup:passive value, it MUST be prepared to receive a DTLS		attribute with a setup:actpass value or setup:passive value, it
	client_hello message before it receives the SDP answer. If the		MUST be prepared to receive a DTLS client_hello message before it
	answerer accepts the media stream, then it MUST assign the SDP		receives the SDP answer. If the answerer accepts the media
	setup attribute with either a setup:active value or setup:passive		stream, then it MUST assign the SDP setup attribute with either a
	value, according to the procedures in [RFC4145]. The answerer		setup:active value or setup:passive value, according to the
	MUST NOT assign an SDP setup attribute with a setup:holdconn		procedures in [RFC4145]. The answerer MUST NOT assign an SDP
	value. Whichever party is active, it MUST initiate a DTLS		setup attribute with a setup:holdconn value. Whichever party is
	handshake by sending a ClientHello over each flow (host/port		active, it MUST initiate a DTLS handshake by sending a ClientHello
	quartet).		over each flow (host/port quartet).
	o If the endpoint supports, and is willing to use, a cipher suite		o If the endpoint supports, and is willing to use, a cipher suite
	with an associated certificate, it MUST include an SDP fingerprint		with an associated certificate, it MUST include an SDP fingerprint
	attribute [RFC4572] in the SDP.		attribute [RFC4572] in the SDP.
	o If a cipher suite with an associated certificate is selected		o If a cipher suite with an associated certificate is selected
	during the DTLS handshake, the certificate received during the		during the DTLS handshake, the certificate received during the
	DTLS handshake MUST match the fingerprint received in the SDP		DTLS handshake MUST match the fingerprint received in the SDP
	fingerprint attribute. If the fingerprint does not match the		fingerprint attribute. If the fingerprint does not match the
	hashed certificate, then the endpoint MUST tear down the media		hashed certificate, then the endpoint MUST tear down the media
	session immediately. Note that it is permissible to wait until		session immediately. Note that it is permissible to wait until
	the other side's fingerprint has been received before establishing		the other side's fingerprint has been received before establishing
	the connection; however, this may have undesirable latency		the connection; however, this may have undesirable latency
	effects.		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		successfully completed (in order to prevent facsimile data from being
	layer "application_data" packets.		transmitted insecurely), the UDPTL packets SHALL be transported in
			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 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.
	skipping to change at page 7, line 30		skipping to change at page 7, line 30
	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.
	5. Security Considerations		5. Security Considerations
			Fax may be used to transmit a wide range of sensitive data, including
			personal, corporate, and governmental information. It is therefore
			critical to be able to protect against threats to the confidentiality
			and integrity of the transmitted data.
			The mechanism in this document provides integrity and confidentiality
			protection for fax by specifying fax transport using UDPTL over DTLS
			[RFC6347].
	DTLS media signaled with SIP requires a mechanism to ensure that the		DTLS media signaled with SIP requires a mechanism to ensure that the
	communicating peers' certificates are correct.		communicating peers' certificates are correct.
	The standard DTLS strategy for authenticating the communicating		The standard DTLS strategy for authenticating the communicating
	parties is to give the server (and optionally the client) a PKIX		parties is to give the server (and optionally the client) a PKIX
	[RFC5280] certificate. The client then verifies the certificate and		[RFC5280] certificate. The client then verifies the certificate and
	checks that the name in the certificate matches the server's domain		checks that the name in the certificate matches the server's domain
	name. This works because there are a relatively small number of		name. This works because there are a relatively small number of
	servers with well-defined names; a situation that does not usually		servers with well-defined names; a situation that does not usually
	occur in the VoIP context.		occur in the VoIP context.
	The design described in this document is intended to leverage the		The design described in this document is intended to leverage the
	authenticity of the signaling channel (while not requiring		authenticity of the signaling channel (while not requiring
	confidentiality). As long as each side of the connection can verify		confidentiality). As long as each side of the connection can verify
	the integrity of the SDP received from the other side, then the DTLS		the integrity of the SDP received from the other side, then the DTLS
	handshake cannot be hijacked via a man-in-the-middle attack. This		handshake cannot be hijacked via a man-in-the-middle attack. This
	integrity protection is easily provided by the caller to the callee		integrity protection is easily provided by the caller to the callee
	(see sample message flow in Annex A.2) via the SIP Identity [RFC4474]		via the SIP Identity [RFC4474] mechanism. Other mechanisms, such as
	mechanism. Other mechanisms, such as the S/MIME mechanism [RFC3261],		the S/MIME mechanism [RFC3261], or perhaps future mechanisms yet to
	or perhaps future mechanisms yet to be specified could also serve		be specified could also serve this purpose.
	this purpose.
	While this mechanism can still be used without such integrity		While this mechanism can still be used without such integrity
	mechanisms, the security provided is limited to defense against		mechanisms, the security provided is limited to defense against
	passive attack by intermediaries. An active attack on the signaling		passive attack by intermediaries. An active attack on the signaling
	plus an active attack on the media plane can allow an attacker to		plus an active attack on the media plane can allow an attacker to
	attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).		attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
	6. IANA Considerations		6. IANA Considerations
	This document updates the "Session Description Protocol (SDP)		This document updates the "Session Description Protocol (SDP)
	Parameters" registry as specified in Section 8.2.2 of [RFC4566].		Parameters" registry as specified in Section 8.2.2 of [RFC4566].
	Specifically, it adds the values in Table 3 to the table for the SDP		Specifically, it adds the values in Table 3 to the table for the SDP
	"proto" field registry.		"proto" field registry.
	+-------+---------------+------------+		+-------+-----------------+------------+
	| Type | SDP Name | Reference |		| Type | SDP Name | Reference |
	+-------+---------------+------------+		+-------+-----------------+------------+
	| proto | UDP/TLS/UDPTL | [RFC-XXXX] |		| proto | "UDP/TLS/UDPTL" | [RFC-XXXX] |
	+-------+---------------+------------+		+-------+-----------------+------------+
	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 and Oscar Ohlsson who provided valuable feedback and input on		Schwarz, Oscar Ohlsson and David Hanes who provided valuable feedback
	the MMUSIC mailing list.		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-02
			o Editorial comments based on review comments by James Rafferty
			(http://www.ietf.org/mail-archive/web/mmusic/current/
			msg12890.html)
			o Editorial comments based on review comments by David Hanes (http:/
			/www.ietf.org/mail-archive/web/mmusic/current/msg12886.html)
			o Editorial comments based on review comments by Oscar Ohlsson
			(http://www.ietf.org/mail-archive/web/mmusic/current/
			msg12882.html)
			o Editorial comments based on review comments by Albrecht Schwartz
			(http://www.ietf.org/mail-archive/web/mmusic/current/
			msg12900.html)
	Changes from draft-ietf-mmusic-udptl-dtls-01		Changes from draft-ietf-mmusic-udptl-dtls-01
	o Usage of the SDP fingerprint attribute depends on whether a cipher		o Usage of the SDP fingerprint attribute depends on whether a cipher
	suite with an associated certificate is used.		suite with an associated certificate is used.
	o Editor's note in section 4.2 removed. Procedure text added.		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
	skipping to change at page 10, line 50		skipping to change at page 11, line 25
	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
	[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. Example		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
	likely, reused for multiple sessions.		likely, reused for multiple sessions.
	The SIP signaling from Alice to her proxy is transported over TLS to		The SIP signaling from Alice to her proxy is transported over TLS to
	ensure an integrity protected channel between Alice and her identity		ensure an integrity protected channel between Alice and her identity
	service. Transport between proxies should also be protected somehow.		service. Alice's identity service asserts identity of Alice and
			protects the SIP message, e.g. using SIP Identity. Transport between
			proxies should also be protected somehow.
	Only one element is shown for Alice's and Bob's proxies for the		Only one element is shown for Alice's and Bob's proxies for the
	purposes of simplification.		purposes of simplification.
	For the sake of brevity and simplicity, only the mandatory SDP T.38		For the sake of brevity and simplicity, only the mandatory SDP T.38
	attributes are shown.		attributes are shown.
	A.2. Basic Message Flow with Identity		A.2. Basic Message Flow
	Figure 1 shows an example message flow of session establishment for		Figure 1 shows an example message flow of session establishment for
	T.38 fax securely transported using UDPTL over DTLS.		T.38 fax securely transported using UDPTL over DTLS.
	In this example flow, Alice acts as the passive endpoint of DTLS		In this example flow, Alice acts as the passive endpoint of the DTLS
	association and Bob acts as the active endpoint of DTLS association.		association and Bob acts as the active endpoint of the DTLS
			association.
	Alice Proxies Bob		Alice Proxies Bob
	| (1) SIP INVITE | |		| (1) SIP INVITE | |
	|----------------------->| |		|----------------------->| |
	| | (2) SIP INVITE |		| | (2) SIP INVITE |
	| |----------------------->|		| |----------------------->|
	| | (3) DTLS ClientHello |		| | (3) DTLS ClientHello |
	|<------------------------------------------------|		|<------------------------------------------------|
	| (4) remaining messages of DTLS handshake |		| (4) remaining messages of DTLS handshake |
	|<----------------------------------------------->|		|<----------------------------------------------->|
	skipping to change at page 11, line 49		skipping to change at page 12, line 26
	| | (5) SIP 200 OK |		| | (5) SIP 200 OK |
	| |<-----------------------|		| |<-----------------------|
	| (6) SIP 200 OK | |		| (6) SIP 200 OK | |
	|<-----------------------| |		|<-----------------------| |
	| (7) SIP ACK | |		| (7) SIP ACK | |
	|------------------------------------------------>|		|------------------------------------------------>|
	| (8) T.38 message using UDPTL over DTLS |		| (8) T.38 message using UDPTL over DTLS |
	|<----------------------------------------------->|		|<----------------------------------------------->|
	| | |		| | |
	Figure 1: Basic message flow with Identity		Figure 1: Basic message flow
	Message (1):		Message (1):
	Figure 2 shows the initial INVITE request sent by Alice to Alice's		Figure 2 shows the initial INVITE request sent by Alice to Alice's
	proxy. The initial INVITE request contains an SDP offer.		proxy. The initial INVITE request contains an SDP offer.
	The "m=" line in the SDP offer indicates T.38 fax using UDPTL over		The "m=" line in the SDP offer indicates T.38 fax using UDPTL over
	DTLS.		DTLS.
	The SDP setup:actpass attribute in the SDP offer indicates that		The SDP setup:actpass attribute in the SDP offer indicates that
	Alice has requested to be either the active or passive endpoint.		Alice has requested to be either the active or passive endpoint.
	The SDP fingerprint attribute in the SDP offer indicates the		The SDP fingerprint attribute in the SDP offer contains the
	certificate fingerprint computed from Alice's self-signed		certificate fingerprint computed from Alice's self-signed
	certificate.		certificate.
	INVITE sip:bob@example.com SIP/2.0		INVITE sip:bob@example.com SIP/2.0
	To: <sip:bob@example.com>		To: <sip:bob@example.com>
	From: "Alice"<sip:alice@example.com>;tag=843c7b0b		From: "Alice"<sip:alice@example.com>;tag=843c7b0b
	Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj		Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
	Contact: <sip:alice@ua1.example.com>		Contact: <sip:alice@ua1.example.com>
	Call-ID: 6076913b1c39c212@REVMTEpG		Call-ID: 6076913b1c39c212@REVMTEpG
	CSeq: 1 INVITE		CSeq: 1 INVITE
	skipping to change at page 13, line 7		skipping to change at page 13, line 35
	a=fingerprint: SHA-1 \		a=fingerprint: SHA-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=T38FaxRateManagement:transferredTCF		a=T38FaxRateManagement:transferredTCF
	Figure 2: Message (1)		Figure 2: Message (1)
	Message (2):		Message (2):
	Figure 3 shows the SIP INVITE request sent by Bob's proxy to Bob.		Figure 3 shows the SIP INVITE request sent by Bob's proxy to Bob.
	The SIP INVITE request contains an Identity header field and an
	Identity-Info header fields inserted by Alice's proxy.
	When received, Bob verifies the identity provided in the SIP		When received, Bob verifies the identity provided in the SIP
	INVITE request.		INVITE request.
	INVITE sip:bob@ua2.example.com SIP/2.0		INVITE sip:bob@ua2.example.com SIP/2.0
	To: <sip:bob@example.com>		To: <sip:bob@example.com>
	From: "Alice"<sip:alice@example.com>;tag=843c7b0b		From: "Alice"<sip:alice@example.com>;tag=843c7b0b
	Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk		Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
	Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj		Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
	Record-Route: <sip:proxy.example.com;lr>		Record-Route: <sip:proxy.example.com;lr>
	Contact: <sip:alice@ua1.example.com>		Contact: <sip:alice@ua1.example.com>
	Call-ID: 6076913b1c39c212@REVMTEpG		Call-ID: 6076913b1c39c212@REVMTEpG
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
	Max-Forwards: 69		Max-Forwards: 69
	Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
	3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
	HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
	Identity-Info: https://example.com/cert
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Length: xxxx		Content-Length: xxxx
	Supported: from-change		Supported: from-change
	v=0		v=0
	o=- 1181923068 1181923196 IN IP4 ua1.example.com		o=- 1181923068 1181923196 IN IP4 ua1.example.com
	s=-		s=-
	c=IN IP4 ua1.example.com		c=IN IP4 ua1.example.com
	t=0 0		t=0 0
	m=image 6056 UDP/TLS/UDPTL t38		m=image 6056 UDP/TLS/UDPTL t38
	skipping to change at page 14, line 14		skipping to change at page 14, line 47
	Message (4):		Message (4):
	Alice and Bob exchange further messages of DTLS handshake		Alice and Bob exchange further messages of DTLS handshake
	(HelloVerifyRequest, ClientHello, ServerHello, Certificate,		(HelloVerifyRequest, ClientHello, ServerHello, Certificate,
	ServerKeyExchange, CertificateRequest, ServerHelloDone,		ServerKeyExchange, CertificateRequest, ServerHelloDone,
	Certificate, ClientKeyExchange, CertificateVerify,		Certificate, ClientKeyExchange, CertificateVerify,
	ChangeCipherSpec, Finished).		ChangeCipherSpec, Finished).
	When Bob receives the certificate of Alice via DTLS, Bob checks		When Bob receives the certificate of Alice via DTLS, Bob checks
	whether the certificate fingerprint calculated from the Alice's		whether the certificate fingerprint calculated from Alice's
	certificate received via DTLS matches the certificate fingerprint		certificate received via DTLS matches the certificate fingerprint
	received in the a=fingerprint SDP attribute of Figure 3. In this		received in the a=fingerprint SDP attribute of Figure 3. In this
	message flow, the check is successful and thus session setup		message flow, the check is successful and thus session setup
	continues.		continues.
	Message (5):		Message (5):
	Figure 4 shows a SIP 200 (OK) response to the initial SIP INVITE		Figure 4 shows a SIP 200 (OK) response to the initial SIP INVITE
	request, sent by Bob to Bob's proxy. The SIP 200 (OK) response		request, sent by Bob to Bob's proxy. The SIP 200 (OK) response
	contains an SDP answer.		contains an SDP answer.
	The "m=" line in the SDP answer indicates T.38 fax using UDPTL		The "m=" line in the SDP answer indicates T.38 fax using UDPTL
	over DTLS.		over DTLS.
	The SDP setup:active attribute in the SDP answer indicates that		The SDP setup:active attribute in the SDP answer indicates that
	Bob has requested to be the active endpoint.		Bob has requested to be the active endpoint.
	The SDP fingerprint attribute in the SDP answer indicates the		The SDP fingerprint attribute in the SDP answer contains the
	certificate fingerprint computed from Bob's self-signed		certificate fingerprint computed from Bob's self-signed
	certificate.		certificate.
	SIP/2.0 200 OK		SIP/2.0 200 OK
	To: <sip:bob@example.com>;tag=6418913922105372816		To: <sip:bob@example.com>;tag=6418913922105372816
	From: "Alice" <sip:alice@example.com>;tag=843c7b0b		From: "Alice" <sip:alice@example.com>;tag=843c7b0b
	Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk		Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
	Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj		Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
	Record-Route: <sip:proxy.example.com;lr>		Record-Route: <sip:proxy.example.com;lr>
	Call-ID: 6076913b1c39c212@REVMTEpG		Call-ID: 6076913b1c39c212@REVMTEpG
	skipping to change at page 15, line 31		skipping to change at page 17, line 5
	Message (6):		Message (6):
	Figure 5 shows a SIP 200 (OK) response to the initial SIP INVITE		Figure 5 shows a SIP 200 (OK) response to the initial SIP INVITE
	request, sent by Alice's proxy to Alice. Alice checks if the		request, sent by Alice's proxy to Alice. Alice checks if the
	certificate fingerprint calculated from the Bob's certificate		certificate fingerprint calculated from the Bob's certificate
	received via DTLS is the same as the certificate fingerprint		received via DTLS is the same as the certificate fingerprint
	received in the a=fingerprint SDP attribute of Figure 5. In this		received in the a=fingerprint SDP attribute of Figure 5. In this
	message flow, the check is successful and thus session setup		message flow, the check is successful and thus session setup
	continues.		continues.
	SIP/2.0 200 OK		SIP/2.0 200 OK
	To: <sip:bob@example.com>;tag=6418913922105372816		To: <sip:bob@example.com>;tag=6418913922105372816
	From: "Alice" <sip:alice@example.com>;tag=843c7b0b		From: "Alice" <sip:alice@example.com>;tag=843c7b0b
	Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj		Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
	Record-Route: <sip:proxy.example.com;lr>		Record-Route: <sip:proxy.example.com;lr>
	Call-ID: 6076913b1c39c212@REVMTEpG		Call-ID: 6076913b1c39c212@REVMTEpG
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Contact: <sip:bob@ua2.example.com>		Contact: <sip:bob@ua2.example.com>
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Length: xxxx		Content-Length: xxxx
	Supported: from-change		Supported: from-change
	v=0		v=0
	o=- 8965454521 2105372818 IN IP4 ua2.example.com		o=- 8965454521 2105372818 IN IP4 ua2.example.com
	s=-		s=-
	c=IN IP4 ua2.example.com		c=IN IP4 ua2.example.com
	t=0 0		t=0 0
	m=image 12000 UDP/TLS/UDPTL t38		m=image 12000 UDP/TLS/UDPTL t38
	a=setup:active		a=setup:active
	a=fingerprint: SHA-1 \		a=fingerprint: SHA-1 \
	FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=T38FaxRateManagement:transferredTCF		a=T38FaxRateManagement:transferredTCF
	Figure 5: Message (6)		Figure 5: Message (6)
	Message (7):		Message (7):
	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
	Figure 6 focuses on T.38 fax securely transported using UDPTL over		Traditionally, most session with non-secure transport of T.38 fax,
	DTLS replacing audio media stream in an existing audio-only session.		transported using UDPTL, are established by modifying an ongoing
			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
			fax securely transported using UDPTL over DTLS.
	In this example flow, Alice acts as the passive endpoint of DTLS		In this example flow, Alice acts as the passive endpoint of the DTLS
	association and Bob acts as the active endpoint of DTLS association.		association and Bob acts as the active endpoint of the DTLS
			association.
	Alice Proxies Bob		Alice Proxies Bob
	| | |		| | |
	| (1) Audio-only session initiation |		| (1) Audio-only session initiation |
	|<-----------------------+----------------------->|		|<-----------------------+----------------------->|
	| | |		| | |
	| (2) SIP re-INVITE | |		| (2) SIP re-INVITE | |
	|------------------------------------------------>|		|------------------------------------------------>|
	| | (3) DTLS ClientHello |		| | (3) DTLS ClientHello |
	|<------------------------------------------------|		|<------------------------------------------------|
	skipping to change at page 17, line 12		skipping to change at page 18, line 40
	Figure 6: Message Flow Of T.38 Fax Replacing Audio Media Stream in An		Figure 6: Message Flow Of T.38 Fax Replacing Audio Media Stream in An
	Existing Audio-Only Session		Existing Audio-Only Session
	Message (1):		Message (1):
	Session establishment of audio-only session. The proxies decide		Session establishment of audio-only session. The proxies decide
	not to record-route.		not to record-route.
	Message (2):		Message (2):
	Alice sends SIP re-INVITE request. SDP offer included in the SIP		Alice sends SIP re-INVITE request. The SDP offer included in the
	re-INVITE request shown in Figure 7.		SIP re-INVITE request is shown in Figure 7.
	The first "m=" line in the SDP offer indicates audio media stream		The first "m=" line in the SDP offer indicates audio media stream
	being removed. The second "m=" line in the SDP offer indicates		being removed. The second "m=" line in the SDP offer indicates
	T.38 fax using UDPTL over DTLS being added.		T.38 fax using UDPTL over DTLS being added.
	The SDP setup:actpass attribute in the SDP offer indicates that		The SDP setup:actpass attribute in the SDP offer indicates that
	Alice has requested to be either the active or passive endpoint.		Alice has requested to be either the active or passive endpoint.
	The SDP fingerprint attribute in the SDP offer indicates the		The SDP fingerprint attribute in the SDP offer contains the
	certificate fingerprint computed from Alice's self-signed		certificate fingerprint computed from Alice's self-signed
	certificate.		certificate.
	v=0		v=0
	o=- 2465353433 3524244442 IN IP4 ua1.example.com		o=- 2465353433 3524244442 IN IP4 ua1.example.com
	s=-		s=-
	c=IN IP4 ua1.example.com		c=IN IP4 ua1.example.com
	t=0 0		t=0 0
	m=audio 0 UDP/TLS/RTP/SAVP 0		m=audio 0 UDP/TLS/RTP/SAVP 0
	m=image 46056 UDP/TLS/UDPTL t38		m=image 46056 UDP/TLS/UDPTL t38
	skipping to change at page 18, line 11		skipping to change at page 19, line 35
	Bob sends a DTLS ClientHello directly to Alice.		Bob sends a DTLS ClientHello directly to Alice.
	Message (4):		Message (4):
	Alice and Bob exchange further messages of DTLS handshake		Alice and Bob exchange further messages of DTLS handshake
	(HelloVerifyRequest, ClientHello, ServerHello, Certificate,		(HelloVerifyRequest, ClientHello, ServerHello, Certificate,
	ServerKeyExchange, CertificateRequest, ServerHelloDone,		ServerKeyExchange, CertificateRequest, ServerHelloDone,
	Certificate, ClientKeyExchange, CertificateVerify,		Certificate, ClientKeyExchange, CertificateVerify,
	ChangeCipherSpec, Finished).		ChangeCipherSpec, Finished).
	When Bob receives Alice's certificate via DTLS, Bob checks whether		When Bob receives the certificate of Alice via DTLS, Bob checks
	the certificate fingerprint calculated from Alice's certificate		whether the certificate fingerprint calculated from Alice's
	received via DTLS matches the certificate fingerprint received in		certificate received via DTLS matches the certificate fingerprint
	the a=fingerprint SDP attribute of Figure 7. In this message		received in the a=fingerprint SDP attribute of Figure 7. In this
	flow, the check is successful and thus session setup continues.		message flow, the check is successful and thus session setup
			continues.
	Message (5):		Message (5):
	Bob sends a SIP 200 (OK) response to the SIP re-INVITE request.		Bob sends a SIP 200 (OK) response to the SIP re-INVITE request.
	The SIP 200 (OK) response contains an SDP answer shown in Figure		The SIP 200 (OK) response contains an SDP answer shown in
	8.		Figure 8.
	The first "m=" line in the SDP offer indicates audio media stream		The first "m=" line in the SDP offer indicates audio media stream
	being removed. The second "m=" line in the SDP answer indicates		being removed. The second "m=" line in the SDP answer indicates
	T.38 fax using UDPTL over DTLS being added.		T.38 fax using UDPTL over DTLS being added.
	The SDP setup:active attribute in the SDP answer indicates that		The SDP setup:active attribute in the SDP answer indicates that
	Bob has requested to be the active endpoint.		Bob has requested to be the active endpoint.
	The SDP fingerprint attribute in the SDP answer indicates the		The SDP fingerprint attribute in the SDP answer contains the
	certificate fingerprint computed from Bob's self-signed		certificate fingerprint computed from Bob's self-signed
	certificate.		certificate.
	v=0		v=0
	o=- 4423478999 5424222292 IN IP4 ua2.example.com		o=- 4423478999 5424222292 IN IP4 ua2.example.com
	s=-		s=-
	c=IN IP4 ua2.example.com		c=IN IP4 ua2.example.com
	t=0 0		t=0 0
	m=audio 0 UDP/TLS/RTP/SAVP 0		m=audio 0 UDP/TLS/RTP/SAVP 0
	m=image 32000 UDP/TLS/UDPTL t38		m=image 32000 UDP/TLS/UDPTL t38
End of changes. 46 change blocks.
	145 lines changed or deleted		171 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/