draft-ietf-perc-dtls-tunnel-01.txt		draft-ietf-perc-dtls-tunnel-02.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track P. Ellenbogen		Intended status: Standards Track P. Ellenbogen
	Expires: October 30, 2017 Princeton University		Expires: May 3, 2018 Princeton University
	N. Ohlmeier		N. Ohlmeier
	Mozilla		Mozilla
	April 28, 2017		October 30, 2017
	DTLS Tunnel between a Media Distributor and Key Distributor to		DTLS Tunnel between a Media Distributor and Key Distributor to
	Facilitate Key Exchange		Facilitate Key Exchange
	draft-ietf-perc-dtls-tunnel-01		draft-ietf-perc-dtls-tunnel-02
	Abstract		Abstract
	This document defines a DTLS tunneling protocol for use in multimedia		This document defines a DTLS tunneling protocol for use in multimedia
	conferences that enables a Media Distributor to facilitate key		conferences that enables a Media Distributor to facilitate key
	exchange between an endpoint in a conference and the Key Distributor.		exchange between an endpoint in a conference and the Key Distributor.
	The protocol is designed to ensure that the keying material used for		The protocol is designed to ensure that the keying material used for
	hop-by-hop encryption and authentication is accessible to the media		hop-by-hop encryption and authentication is accessible to the media
	distributor, while the keying material used for end-to-end encryption		distributor, while the keying material used for end-to-end encryption
	and authentication is inaccessible to the media distributor.		and authentication is inaccessible to the media distributor.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 October 30, 2017.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 22 ¶		skipping to change at page 2, line 22 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used In This Document . . . . . . . . . . . . . . 3		2. Conventions Used In This Document . . . . . . . . . . . . . . 3
	3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3		3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3
	4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4		4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4
	5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6		5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6
	5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6		5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6
	5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6		5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6
	5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7		5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7
	5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8		5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8
	5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10		5.5. Versioning Considerations . . . . . . . . . . . . . . . . 9
	6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10		6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10		6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10
	7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13		7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 16		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 41 ¶
	When processing an incoming endpoint association, the key distributor		When processing an incoming endpoint association, the key distributor
	MUST extract the "tls_id" value transmitted in the "ClientHello"		MUST extract the "tls_id" value transmitted in the "ClientHello"
	message and match that against "tls-id" value the endpoint		message and match that against "tls-id" value the endpoint
	transmitted via SDP. If the values in SDP and the "ClientHello" do		transmitted via SDP. If the values in SDP and the "ClientHello" do
	not match, the DTLS association MUST be rejected.		not match, the DTLS association MUST be rejected.
	The process through which the "tls-id" in SDP is conveyed to the key		The process through which the "tls-id" in SDP is conveyed to the key
	distributor is outside the scope of this document.		distributor is outside the scope of this document.
	Editor's Note: The above can be removed if we agree that the media
	distributor will always forward SDP to the key distributor. That
	said, should the media server take on this function or should some
	other call control function do this? The former assumes the media
	distributor always has the SDP.
	The key distributor MUST correlate the certificate fingerprint and		The key distributor MUST correlate the certificate fingerprint and
	"tls_id" received from endpoint's "ClientHello" message with the		"tls_id" received from endpoint's "ClientHello" message with the
	corresponding values received from the SDP transmitted by the		corresponding values received from the SDP transmitted by the
	endpoint. It is through this correlation that the key distributor		endpoint. It is through this correlation that the key distributor
	can be sure to deliver the correct conference key to the endpoint.		can be sure to deliver the correct conference key to the endpoint.
	When sending the "ServerHello" message, the key distributor MUST		When sending the "ServerHello" message, the key distributor MUST
	insert its own "tls_id" value in the "sdp_tls_id" extension. This		insert its own "tls_id" value in the "sdp_tls_id" extension. This
	value MUST also be conveyed back to the client via SDP as a "tls-id"		value MUST also be conveyed back to the client via SDP as a "tls-id"
	attribute.		attribute.
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	10. Acknowledgments		10. Acknowledgments
	The author would like to thank David Benham and Cullen Jennings for		The author would like to thank David Benham and Cullen Jennings for
	reviewing this document and providing constructive comments.		reviewing this document and providing constructive comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-mmusic-dtls-sdp]		[I-D.ietf-mmusic-dtls-sdp]
	Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer		Holmberg, C. and R. Shpount, "Session Description Protocol
	Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-24 (work		(SDP) Offer/Answer Considerations for Datagram Transport
	in progress), April 2017.		Layer Security (DTLS) and Transport Layer Security (TLS)",
			draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
			2017.
	[I-D.thomson-mmusic-sdp-uks]		[I-D.thomson-mmusic-sdp-uks]
	Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on		Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
	uses of Transport Layer Security with the Session		uses of Transport Layer Security with the Session
	Description Protocol (SDP)", draft-thomson-mmusic-sdp-		Description Protocol (SDP)", draft-thomson-mmusic-sdp-
	uks-00 (work in progress), April 2017.		uks-00 (work in progress), April 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,		with Session Description Protocol (SDP)", RFC 3264,
	DOI 10.17487/RFC3264, June 2002,		DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc3264>.		editor.org/info/rfc3264>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <https://www.rfc-editor.org/info/rfc3550>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<http://www.rfc-editor.org/info/rfc3711>.		<https://www.rfc-editor.org/info/rfc3711>.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,		DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc4122>.		editor.org/info/rfc4122>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5246>.		editor.org/info/rfc5246>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,		Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5764>.		editor.org/info/rfc5764>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-perc-double]		[I-D.ietf-perc-double]
	Jennings, C., Jones, P., and A. Roach, "SRTP Double		Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
	Encryption Procedures", draft-ietf-perc-double-03 (work in		Double Encryption Procedures", draft-ietf-perc-double-07
	progress), March 2017.		(work in progress), September 2017.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, DOI 10.17487/RFC4566,		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	July 2006, <http://www.rfc-editor.org/info/rfc4566>.		July 2006, <https://www.rfc-editor.org/info/rfc4566>.
	Authors' Addresses		Authors' Addresses
	Paul E. Jones		Paul E. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, North Carolina 27709		Research Triangle Park, North Carolina 27709
	USA		USA
	Phone: +1 919 476 2048		Phone: +1 919 476 2048
End of changes. 17 change blocks.
	31 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/