draft-ietf-tls-extractor-06.txt		draft-ietf-tls-extractor-07.txt
	Network Working Group E. Rescorla		Network Working Group E. Rescorla
	Internet-Draft Network Resonance		Internet-Draft Network Resonance
	Intended status: Standards Track July 12, 2009		Intended status: Standards Track September 07, 2009
	Expires: January 13, 2010		Expires: March 11, 2010
	Keying Material Exporters for Transport Layer Security (TLS)		Keying Material Exporters for Transport Layer Security (TLS)
	draft-ietf-tls-extractor-06.txt		draft-ietf-tls-extractor-07.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 13, 2010.		This Internet-Draft will expire on March 11, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 20		skipping to change at page 3, line 20
	A number of protocols wish to leverage Transport Layer Security (TLS)		A number of protocols wish to leverage Transport Layer Security (TLS)
	[RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key		[RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key
	establishment but then use some of the keying material for their own		establishment but then use some of the keying material for their own
	purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], a		purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], a
	key management scheme for SRTP which uses DTLS to perform a key		key management scheme for SRTP which uses DTLS to perform a key
	exchange and negotiate the SRTP [RFC3711] protection suite and then		exchange and negotiate the SRTP [RFC3711] protection suite and then
	uses the DTLS master_secret to generate the SRTP keys.		uses the DTLS master_secret to generate the SRTP keys.
	These applications imply a need to be able to export keying material		These applications imply a need to be able to export keying material
	(later called Exported Keying Material or EKM) from TLS/DTLS, and		(later called Exported Keying Material or EKM) from TLS/DTLS to an
	securely agree on the upper-layer context where the keying material		application or protocol residing at an upper-layer, and securely
	will be used. The mechanism for exporting the keying material has		agree on the upper-layer context where the keying material will be
	the following requirements:		used. The mechanism for exporting the keying material has the
			following requirements:
	o Both client and server need to be able to export the same EKM		o Both client and server need to be able to export the same EKM
	value.		value.
	o EKM values should be indistinguishable from random by attackers		o EKM values should be indistinguishable from random data by
	who don't know the master_secret.		attackers who don't know the master_secret.
	o It should be possible to export multiple EKM values from the same		o It should be possible to export multiple EKM values from the same
	TLS/DTLS association.		TLS/DTLS association.
	o Knowing one EKM value should not reveal any information about the		o Knowing one EKM value should not reveal any information about the
	master_secret or about other EKM values.		master_secret or about other EKM values.
	The mechanism described in this document is intended to fulfill these		The mechanism described in this document is intended to fulfill these
	requirements.		requirements. This mechanism is compatible with all versions of TLS.
	2. Conventions Used In This Document		2. Conventions Used In This Document
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Binding to Application Contexts		3. Binding to Application Contexts
	In addition to using an exporter to obtain keying material, an		In addition to using an exporter to obtain keying material, an
	skipping to change at page 7, line 18		skipping to change at page 7, line 18
	Future values are allocated via RFC 5226 Specification Required		Future values are allocated via RFC 5226 Specification Required
	policy. The label is a string consisting of printable ASCII		policy. The label is a string consisting of printable ASCII
	characters. IANA MUST also verify that one label is not a prefix of		characters. IANA MUST also verify that one label is not a prefix of
	any other label. For example, labels "key" or "master secretary" are		any other label. For example, labels "key" or "master secretary" are
	forbidden.		forbidden.
	7. Acknowledgments		7. Acknowledgments
	Thanks to Pasi Eronen for valuable comments and the contents of the		Thanks to Pasi Eronen for valuable comments and the contents of the
	IANA section and Section 3. Thanks to David McGrew for helpful		IANA section and Section 3. Thanks to David McGrew for helpful
	discussion of the security considerations and Alfred Hoenes for		discussion of the security considerations and to Vijay Gurbani and
	editorial comments.		Alfred Hoenes for editorial comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
End of changes. 7 change blocks.
	13 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/