draft-ietf-tls-extractor-00.txt		draft-ietf-tls-extractor-01.txt
	Network Working Group E. Rescorla		Network Working Group E. Rescorla
	Internet-Draft Network Resonance		Internet-Draft Network Resonance
	Intended status: Standards Track December 19, 2007		Intended status: Standards Track February 20, 2008
	Expires: June 21, 2008		Expires: August 23, 2008
	Keying Material Extractors for Transport Layer Security (TLS)		Keying Material Extractors for Transport Layer Security (TLS)
	draft-ietf-tls-extractor-00.txt		draft-ietf-tls-extractor-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 June 21, 2008.		This Internet-Draft will expire on August 23, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	A number of protocols wish to leverage Transport Layer Security (TLS)		A number of protocols wish to leverage Transport Layer Security (TLS)
	to perform key establishment but then use some of the keying material		to perform key establishment but then use some of the keying material
	for their own purposes. This document describes a general mechanism		for their own purposes. This document describes a general mechanism
	for allowing that.		for allowing that.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used In This Document . . . . . . . . . . . . . . . 3		2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
	3. Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3		3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3
	4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 3		4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informational References . . . . . . . . . . . . . . . . . 5		8.2. Informational References . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Intellectual Property and Copyright Statements . . . . . . . . . . 6		Intellectual Property and Copyright Statements . . . . . . . . . . 7
	1. Introduction		1. Introduction
	A number of protocols wish to leverage Transport Layer Security (TLS)		A number of protocols wish to leverage Transport Layer Security (TLS)
	[4] or Datagram TLS (DTLS) [5] to perform key establishment but then		[RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key
	use some of the keying material for their own purposes. A typical		establishment but then use some of the keying material for their own
	example is DTLS-SRTP [6], which uses DTLS to perform a key exchange		purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp],
	and negotiate the SRTP [3] protection suite and then uses the DTLS		which uses DTLS to perform a key exchange and negotiate the SRTP
	master_secret to generate the SRTP keys.		[RFC3711] protection suite and then uses the DTLS master_secret to
			generate the SRTP keys.
	These applications imply a need to be able to extract Exported Keying		These applications imply a need to be able to extract keying material
	Material (EKM) from TLS/DTLS. This mechanism has the following		(later called Exported Keying Material or EKM) from TLS/DTLS, and
	requirements:		securely agree on the upper-layer context where the keying material
			will be used. The mechanism for extracting the keying material has
			the following requirements:
	o Both client and server need to be able to extract the same EKM		o Both client and server need to be able to extract the same EKM
	value.		value.
	o EKM values should be indistinguishable from random by attackers		o EKM values should be indistinguishable from random by attackers
	who don't know the master_secret.		who don't know the master_secret.
	o It should be possible to extract multiple EKM values from the same		o It should be possible to extract 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 fill these		The mechanism described in this document is intended to fill these
	requirements.		requirements.
	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 [1].		document are to be interpreted as described in [RFC2119].
	3. Signalling Extractors		3. Binding to Application Contexts
	Other protocols which wish to use extractors SHOULD have some way for		In addition to extracting keying material, an application using the
	the peers to signal that an extractor will be used. An example is a		keying material has to securely establish the upper-layer layer
	TLS extension, as used in DTLS-SRTP.		context where the keying material will be used. The details of this
			context depend on the application, but it could include things such
			as algorithms and parameters that will be used with the keys,
			identifier(s) for the endpoint(s) who will use the keys,
			identifier(s) for the session(s) where the keys will be used, and the
			lifetime(s) for the context and/or keys. At minimum, there should be
			some mechanism for signalling that an extractor will be used.
			This specification does not mandate a single mechanism for agreeing
			on such context; instead, there are several possibilities that can be
			used (and can complement each other). For example:
			o One important part of the context -- which application will use
			the extracted keys -- is given by the disambiguating label string
			(see Section 4).
			o Information about the upper-layer context can be included in the
			optional data after the extractor label (see Section 4).
			o Information about the upper-layer context can be exchanged in TLS
			extensions included in the ClientHello and ServerHello messages.
			This approach is used in [DTLS-SRTP]. The handshake messages are
			protected by the Finished messages, so once the handshake
			completes, the peers will have the same view of the information.
			Extensions also allow a limited form of negotiation: for example,
			the TLS client could propose several alternatives for some context
			parameters, and TLS server could select one of them.
			o The upper-layer protocol can include its own handshake which can
			be protected using the keys extracted from TLS.
			It is important to note that just embedding TLS messages in the
			upper-layer protocol may not automatically secure all the important
			context information, since the upper-layer messages are not covered
			by TLS Finished messages.
	4. Extractor Definition		4. Extractor Definition
	An extractor takes as input two values:		An extractor takes as input three values:
	o A disambiguating label string		o A disambiguating label string
			o A per-association context value provided by the extractor using
			application
	o A length value		o A length value
	It then computes:		It then computes:
	PRF(master_secret, label,		PRF(master_secret, label,
	SecurityParameters.client_random +		SecurityParameters.client_random +
	SecurityParameters.server_random)[length]		SecurityParameters.server_random +
			context_value_length + context_value
			)[length]
	The output is a pseudorandom bit string of length bytes generated		The output is a pseudorandom bit string of length bytes generated
	from the master_secret.		from the master_secret.
	Label values MUST be registered via Specification Required as		Label values beginning with "EXPERIMENTAL" MAY be used for private
	described by RFC 2434 [2]. Note that extractor labels have the		use without registration. All other label values MUST be registered
	potential to collide with existing PRF labels. In order to prevent		via Specification Required as described by RFC 2434 [RFC2434]. Note
	this, labels SHOULD begin with "EXTRACTOR". This is not a MUST		that extractor labels have the potential to collide with existing PRF
	because there are existing uses which have labels which do not begin		labels. In order to prevent this, labels SHOULD begin with
	with this prefix.		"EXTRACTOR". This is not a MUST because there are existing uses
			which have labels which do not begin with this prefix.
			The context value allows the application using the extractor to mix
			its own data with the TLS PRF for the extractor output. The context
			value length is encoded as an unsigned 16-bit quantity (uint16)
			representing the length of the context value.
	5. Security Considerations		5. Security Considerations
	Because an extractor produces the same value if applied twice with		Because an extractor produces the same value if applied twice with
	the same label to the same master_secret, it is critical that two EKM		the same label to the same master_secret, it is critical that two EKM
	values generated with the same label be used for two different		values generated with the same label be used for two different
	purposes--hence the requirement for IANA registration. However,		purposes--hence the requirement for IANA registration. However,
	because extractors depend on the TLS PRF, it is not a threat to the		because extractors depend on the TLS PRF, it is not a threat to the
	use of an EKM value generated from one label to reveal an EKM value		use of an EKM value generated from one label to reveal an EKM value
	generated from another label.		generated from another label.
	skipping to change at page 5, line 8		skipping to change at page 6, line 8
	Future values are allocated via RFC2434 Specification Required		Future values are allocated via RFC2434 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.		IANA section and Section 3.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	RFC 3711, March 2004.
	[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		8.2. Informational References
	Protocol Version 1.1", RFC 4346, April 2006.
	[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
	8.2. Informational References		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
			Norrman, "The Secure Real-time Transport Protocol (SRTP)",
			RFC 3711, March 2004.
	[6] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security		[I-D.ietf-avt-dtls-srtp]
	(DTLS) Extension to Establish Keys for Secure Real-time		McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work in		Security (DTLS) Extension to Establish Keys for Secure
	progress), November 2007.		Real-time Transport Protocol (SRTP)",
			draft-ietf-avt-dtls-srtp-01 (work in progress),
			November 2007.
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
	Network Resonance		Network Resonance
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
	USA		USA
	Email: ekr@networkresonance.com		Email: ekr@networkresonance.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 23 change blocks.
	53 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/