draft-ietf-tls-extractor-05.txt		draft-ietf-tls-extractor-06.txt
	Network Working Group E. Rescorla		Network Working Group E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft Network Resonance
	Intended status: Standards Track March 07, 2009		Intended status: Standards Track July 12, 2009
	Expires: September 8, 2009		Expires: January 13, 2010
	Keying Material Exporters for Transport Layer Security (TLS)		Keying Material Exporters for Transport Layer Security (TLS)
	draft-ietf-tls-extractor-05.txt		draft-ietf-tls-extractor-06.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 September 8, 2009.		This Internet-Draft will expire on January 13, 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 2, line 24		skipping to change at page 2, line 24
	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. Binding to Application Contexts . . . . . . . . . . . . . . . . 3		3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3
	4. Exporter Definition . . . . . . . . . . . . . . . . . . . . . . 4		4. Exporter Definition . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	8.2. Informational References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Note: The mechanism described in this document was previously known		Note: The mechanism described in this document was previously known
	as "TLS Extractors" but was changed to avoid a name conflict with		as "TLS Extractors" but was changed to avoid a name conflict with
	the use of the term "Extractor" in the cryptographic community.		the use of the term "Extractor" in the cryptographic community.
	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],		purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], a
	which uses DTLS to perform a key exchange and negotiate the SRTP		key management scheme for SRTP which uses DTLS to perform a key
	[RFC3711] protection suite and then uses the DTLS master_secret to		exchange and negotiate the SRTP [RFC3711] protection suite and then
	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, and
	securely agree on the upper-layer context where the keying material		securely agree on the upper-layer context where the keying material
	will be used. The mechanism for exporting the keying material has		will be used. The mechanism for exporting the keying material has
	the following requirements:		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 by attackers
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Binding to Application Contexts		3. Binding to Application Contexts
	In addition to exporting keying material, an application using the		In addition to using an exporter to obtain keying material, an
	keying material has to securely establish the upper-layer context		application using the keying material has to securely establish the
	where the keying material will be used. The details of this context		upper-layer context where the keying material will be used. The
	depend on the application, but it could include things such as		details of this context depend on the application, but it could
	algorithms and parameters that will be used with the keys,		include things such as algorithms and parameters that will be used
	identifier(s) for the endpoint(s) who will use the keys,		with the keys, identifier(s) for the endpoint(s) who will use the
	identifier(s) for the session(s) where the keys will be used, and the		keys, identifier(s) for the session(s) where the keys will be used,
	lifetime(s) for the context and/or keys. At minimum, there should be		and the lifetime(s) for the context and/or keys. At a minimum, there
	some mechanism for signalling that an exporter will be used.		should be some mechanism for signalling that an exporter will be
			used.
	This specification does not mandate a single mechanism for agreeing		This specification does not mandate a single mechanism for agreeing
	on such context; instead, there are several possibilities that can be		on such context; instead, there are several possibilities that can be
	used (and can complement each other). For example:		used (and can complement each other). For example:
	o One important part of the context -- which application will use		o One important part of the context -- which application will use
	the exported keys -- is given by the disambiguating label string		the exported keys -- is given by the disambiguating label string
	(see Section 4).		(see Section 4).
	o Information about the upper-layer context can be included in the		o Information about the upper-layer context can be included in the
	optional data after the exporter label (see Section 4).		optional data after the exporter label (see Section 4).
	o Information about the upper-layer context can be exchanged in TLS		o Information about the upper-layer context can be exchanged in TLS
	extensions included in the ClientHello and ServerHello messages.		extensions included in the ClientHello and ServerHello messages.
	This approach is used in [DTLS-SRTP]. The handshake messages are		This approach is used in [I-D.ietf-avt-dtls-srtp]. The handshake
	protected by the Finished messages, so once the handshake		messages are protected by the Finished messages, so once the
	completes, the peers will have the same view of the information.		handshake completes, the peers will have the same view of the
	Extensions also allow a limited form of negotiation: for example,		information. Extensions also allow a limited form of negotiation:
	the TLS client could propose several alternatives for some context		for example, the TLS client could propose several alternatives for
	parameters, and the TLS server could select one of them.		some context parameters, and the TLS server could select one of
			them.
	o The upper-layer protocol can include its own handshake which can		o The upper-layer protocol can include its own handshake which can
	be protected using the keys exported from TLS.		be protected using the keys exported by TLS.
	It is important to note that just embedding TLS messages in the		It is important to note that just embedding TLS messages in the
	upper-layer protocol may not automatically secure all the important		upper-layer protocol may not automatically secure all the important
	context information, since the upper-layer messages are not covered		context information, since the upper-layer messages are not covered
	by TLS Finished messages.		by TLS Finished messages.
	4. Exporter Definition		4. Exporter Definition
	The output of the exporter is intended to be used in a single scope,		The output of the exporter is intended to be used in a single scope,
	which is associated with the TLS session, the label, and the context		which is associated with the TLS session, the label, and the context
	value.		value.
	o A disambiguating label string		The exporter takes three input values
	o A per-association context value provided by the application using
	the exporter		o a disambiguating label string,
	o A length value		o a per-association context value provided by the application using
			the exporter, and
			o a length value.
	It then computes:		It then computes:
	PRF(SecurityParameters.master_secret, label,		PRF(SecurityParameters.master_secret, label,
	SecurityParameters.client_random +		SecurityParameters.client_random +
	SecurityParameters.server_random +		SecurityParameters.server_random +
	context_value_length + context_value		context_value_length + context_value
	)[length]		)[length]
	Where PRF is the TLS PRF in use for the session. The output is a		Where PRF is the TLS PRF in use for the session. The output is a
	skipping to change at page 5, line 19		skipping to change at page 5, line 24
	Labels here have the same definition as in TLS, i.e., an ASCII string		Labels here have the same definition as in TLS, i.e., an ASCII string
	with no terminating NULL. Label values beginning with "EXPERIMENTAL"		with no terminating NULL. Label values beginning with "EXPERIMENTAL"
	MAY be used for private use without registration. All other label		MAY be used for private use without registration. All other label
	values MUST be registered via Specification Required as described by		values MUST be registered via Specification Required as described by
	RFC 5226 [RFC5226]. Note that exporter labels have the potential to		RFC 5226 [RFC5226]. Note that exporter labels have the potential to
	collide with existing PRF labels. In order to prevent this, labels		collide with existing PRF labels. In order to prevent this, labels
	SHOULD begin with "EXPORTER". This is not a MUST because there are		SHOULD begin with "EXPORTER". This is not a MUST because there are
	existing uses which have labels which do not begin with this prefix.		existing uses which have labels which do not begin with this prefix.
	opaque context<0..2^16-1>;
	The context value allows the application using the exporter to mix		The context value allows the application using the exporter to mix
	its own data with the TLS PRF for the exporter output. One example		its own data with the TLS PRF for the exporter output. One example
	of where this might be useful is an authentication setting where the		of where this might be useful is an authentication setting where the
	client credentials are valid for more than one identity; the context		client credentials are valid for more than one identity; the context
	value could then be used to mix the expected identity into the keying		value could then be used to mix the expected identity into the keying
	material, thus preventing substitution attacks. The context value		material, thus preventing substitution attacks. The context value
	length is encoded as an unsigned 16-bit quantity (uint16)		length is encoded as an unsigned 16-bit quantity (uint16)
	representing the length of the context value. The context MAY be		representing the length of the context value. The context MAY be
	zero length.		zero length. Because the context value is mixed with the
			master_secret via the PRF, it is safe to mix confidential information
			into the extractor provided that the master_secret will not be known
			to the attacker.
	5. Security Considerations		5. Security Considerations
	The prime security requirement for exporter outputs is that they be		The prime security requirement for exporter outputs is that they be
	independent. More formally, after a particular TLS session, if an		independent. More formally, after a particular TLS session, if an
	adversary is allowed to choose multiple (label, context value) pairs		adversary is allowed to choose multiple (label, context value) pairs
	and is given the output of the PRF for those values, the attacker is		and is given the output of the PRF for those values, the attacker is
	still unable to distinguish between the output of the PRF for a		still unable to distinguish between the output of the PRF for a
	(label, context value) pair (different from the ones that it		(label, context value) pair (different from the ones that it
	submitted) and a random value of the same length. In particular,		submitted) and a random value of the same length. In particular,
	there may be settings, such as the one described in Section 4, where		there may be settings, such as the one described in Section 4, where
	the attacker can control the context value; such an attacker MUST not		the attacker can control the context value; such an attacker MUST NOT
	be able to predict the output of the exporter. Similarly, an		be able to predict the output of the exporter. Similarly, an
	attacker who does not know the master secret should not be able to		attacker who does not know the master secret should not be able to
	distinguish valid exporter outputs from random values. The current		distinguish valid exporter outputs from random values. The current
	set of TLS PRFs is believed to meet this objective, provided the		set of TLS PRFs is believed to meet this objective, provided the
	master secret is randomly generated.		master secret is randomly generated.
	Because an exporter produces the same value if applied twice with the		Because an exporter produces the same value if applied twice with the
	same label to the same master_secret, it is critical that two EKM		same label to the same master_secret, it is critical that two EKM
	values generated with the same label not be used for two different		values generated with the same label not be used for two different
	purposes--hence the requirement for IANA registration. However,		purposes--hence the requirement for IANA registration. However,
	because exporters depend on the TLS PRF, it is not a threat to the		because exporters 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.
			With certain TLS cipher suites, the TLS master secret is not
			necessarily unique to a single TLS session. In particular, with RSA
			key exchange, a malicious party acting as TLS server in one session
			and TLS client in another session can cause those two sessions to
			have the same TLS master secret (though the sessions must be
			established simultaneously to get adequate control of the Random
			values). Applications using the EKM need to consider this in how
			they use the EKM; in some cases, requiring the use of other cipher
			suites (such as those using Diffie-Hellman key exchange) may be
			advisable.
			Designing a secure mechanism that uses extractors is not necessarily
			straightforward. This document only provides the extractor
			mechanism, but the problem of agreeing on the surrounding context and
			the meaning of the information passed to and from the extractor
			remains. Any new uses of the extractor mechanism should be subject
			to careful review.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to create (has created) a TLS Exporter Label		IANA is requested to create (has created) a TLS Exporter Label
	registry for this purpose. The initial contents of the registry are		registry for this purpose. The initial contents of the registry are
	given below:		given below:
	Value Reference		Value Reference Note
	----- ------------		----------------------------- --------- ----
	client finished [RFC5246]		client finished [RFC5246] (1)
	server finished [RFC5246]		server finished [RFC5246] (1)
	master secret [RFC5246]		master secret [RFC5246] (1)
	key expansion [RFC5246]		key expansion [RFC5246] (1)
	client EAP encryption [RFC2716]		client EAP encryption [RFC5216]
	ttls keying material [RFC5281]		ttls keying material [RFC5281]
	ttls challenge [RFC5281]		ttls challenge [RFC5281]
			Note(1): These entries are reserved and MUST NOT be used for the
			purpose described in RFC XXXX, in order to avoid confusion with
			similar, but distinct use in RFC 5246.
			[ RFC Editor: Please replace 'XXXX' above by the RFC number assigned
			to this document and delete this remark. ]
	Future values are allocated via RFC5226 Specification Required		Future values are allocated via RFC5226 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
	skipping to change at page 7, line 8		skipping to change at page 7, line 35
	[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,
	May 2008.		May 2008.
	[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, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication		8.2. Informative References
	Protocol Tunneled Transport Layer Security Authenticated
	Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
	8.2. Informational References		[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
			Authentication Protocol", RFC 5216, March 2008.
	[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, March 2004.		RFC 3711, March 2004.
	[RFC4347] 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.
	[I-D.ietf-avt-dtls-srtp]		[I-D.ietf-avt-dtls-srtp]
	McGrew, D. and E. Rescorla, "Datagram Transport Layer		McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for Secure		Security (DTLS) Extension to Establish Keys for Secure
	Real-time Transport Protocol (SRTP)",		Real-time Transport Protocol (SRTP)",
	draft-ietf-avt-dtls-srtp-07 (work in progress),		draft-ietf-avt-dtls-srtp-07 (work in progress),
	February 2009.		February 2009.
			[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
			Protocol Tunneled Transport Layer Security Authenticated
			Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
	Author's Address		Author's Address
	Eric Rescorla		Eric Rescorla
	RTFM, Inc.		Network Resonance
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
	USA		USA
	Email: ekr@rtfm.com		Email: ekr@networkresonance.com
End of changes. 20 change blocks.
	50 lines changed or deleted		83 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/