< draft-wouters-tls-oob-pubkey-01.txt		draft-wouters-tls-oob-pubkey-02.txt >
	IETF P. Wouters		IETF P. Wouters
	Internet-Draft Xelerance		Internet-Draft Xelerance
	Intended status: Standards Track J. Gilmore		Intended status: Standards Track J. Gilmore
	Expires: May 3, 2012		Expires: May 20, 2012
	S. Weiler		S. Weiler
	SPARTA, Inc.		SPARTA, Inc.
	T. Kivinen		T. Kivinen
	AuthenTec		AuthenTec
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	October 31, 2011		November 17, 2011
	TLS out-of-band public key validation		TLS out-of-band public key validation
	draft-wouters-tls-oob-pubkey-01		draft-wouters-tls-oob-pubkey-02
	Abstract		Abstract
	This document specifies a new TLS certificate type for exchanging raw		This document specifies a new TLS certificate type for exchanging raw
	public keys or their fingerprints in Transport Layer Security (TLS)		public keys in Transport Layer Security (TLS) and Datagram Transport
	and Datagram Transport Layer Security (DTLS) for use with out-of-band		Layer Security (DTLS) for use with out-of-band authentication.
	authentication. Currently, TLS authentication can only occur via		Currently, TLS authentication can only occur via PKIX or OpenPGP
	PKIX or OpenPGP certificates. By specifying a minimum resource for		certificates. By specifying a minimum resource for raw public key
	raw public key exchange, implementations can use alternative		exchange, implementations can use alternative authentication methods.
	authentication methods.
	One such method is using DANE Resource Records secured by DNSSEC,		One such method is using DANE Resource Records secured by DNSSEC,
	Another use case is to provide authentication functionality when used		Another use case is to provide authentication functionality when used
	with devices in a constrained environment that use whitelists and		with devices in a constrained environment that use whitelists and
	blacklists, as is the case with sensors and other embedded devices		blacklists, as is the case with sensors and other embedded devices
	that are constrained by memory, computational, and communication		that are constrained by memory, computational, and communication
	limitations where the usage of PKIX is not feasible.		limitations where the usage of PKIX is not feasible.
	The new certificate type specified can also be used to reduce the		The new certificate type specified can also be used to reduce the
	latency of a TLS client that is already in possession of a validated		latency of a TLS client that is already in possession of a validated
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 8 ¶
	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 May 3, 2012.		This Internet-Draft will expire on May 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Changes to the Handshake Message Contents . . . . . . . . . . 5		2. Changes to the Handshake Message Contents . . . . . . . . . . . 5
	2.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Certificate Request . . . . . . . . . . . . . . . . . . . 8		2.3. Certificate Request . . . . . . . . . . . . . . . . . . . . 7
	2.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 8		2.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 8
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	1.1. Motivation		1.1. Motivation
	Traditionally, TLS server public keys are obtained in PKIX containers		Traditionally, TLS server public keys are obtained in PKIX containers
	in-band using the TLS connection and validated using trust anchors		in-band using the TLS connection and validated using trust anchors
	based on a [PKIX] certification authority (CA). This method can add		based on a [PKIX] certification authority (CA). This method can add
	a complicated trust relationship that is difficult to validate.		a complicated trust relationship that is difficult to validate.
	Examples of such complexity can be seen in [Defeating-SSL].		Examples of such complexity can be seen in [Defeating-SSL].
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 6 ¶
	certificate chains could contain contradicting or additional		certificate chains could contain contradicting or additional
	information that the TLS client cannot validate or trust, such as an		information that the TLS client cannot validate or trust, such as an
	expiry date that conflicts with information obtained from DNS or		expiry date that conflicts with information obtained from DNS or
	LDAP. This document specifies a method to suppress sending this		LDAP. This document specifies a method to suppress sending this
	additional information.		additional information.
	Some small embedded devices use the UDP based [CoAP], a specialized		Some small embedded devices use the UDP based [CoAP], a specialized
	constrained networks and nodes for machine-to-machine applications.		constrained networks and nodes for machine-to-machine applications.
	These devices interact with a Web server to upload data such as		These devices interact with a Web server to upload data such as
	temperature sensor readings at a regular intervals. [CoAP] can		temperature sensor readings at a regular intervals. Constrained
	utilize DTLS for its communication security. As part of the		Application Protocol (CoAP) [CoAP] can utilize DTLS for its
	provisioning procedure, the embeded device is configured with the		communication security. As part of the provisioning procedure, the
	address and public key of a dedicated CoAP server to upload sensor		embeded device is configured with the address and public key of a
	data. Receiving [PKIX] information from a webserver would be an		dedicated CoAP server to upload sensor data. Receiving PKIX
	unneccesarry burden on a sensor networking deployment environment		information [PKIX] from a webserver would be an unneccesarry burden
	that requires pre-configured client-server public keys. These		on a sensor networking deployment environment that requires pre-
	devices often also lack a real-time clock to perform any PKIX epixry		configured client-server public keys. These devices often also lack
	checks.		a real-time clock to perform any PKIX epixry checks.
	1.2. Applicability		1.2. Applicability
	The Transport Layer Security (TLS) Protocol Version 1.2 is specified		The Transport Layer Security (TLS) Protocol Version 1.2 is specified
	in [RFC5246] and provides a framework for extensions to TLS as well		in [RFC5246] and provides a framework for extensions to TLS as well
	as considerations for designing such extensions. [RFC6066] defines		as considerations for designing such extensions. [RFC6066] defines
	several new TLS extensions. This document extends the specifications		several new TLS extensions. This document extends the specifications
	of those RFCs with one new TLS Certificate Type to facilitate		of those RFCs with one new TLS Certificate Type to facilitate
	suppressing unneeded [PKIX] information from being sent during the		suppressing unneeded [PKIX] information from being sent during the
	TLS handshake when this information is not required to authenticate		TLS handshake when this information is not required to authenticate
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 8 ¶
	CertificateTypeExtension structure is being used both by the client		CertificateTypeExtension structure is being used both by the client
	and the server, even though the structure is only specified once in		and the server, even though the structure is only specified once in
	this document.		this document.
	The [RFC6091] defined CertificateTypeExtension is extended as		The [RFC6091] defined CertificateTypeExtension is extended as
	follows:		follows:
	enum { client, server } ClientOrServerExtension;		enum { client, server } ClientOrServerExtension;
	enum { X.509(0), OpenPGP(1),		enum { X.509(0), OpenPGP(1),
	RawPublicKey([TBD]), RawPublicKeySHA256([TBD]),		RawPublicKey([TBD]),
	(255) } CertificateType;		(255) } CertificateType;
	struct {		struct {
	select(ClientOrServerExtension)		select(ClientOrServerExtension)
	case client:		case client:
	CertificateType certificate_types<1..2^8-1>;		CertificateType certificate_types<1..2^8-1>;
	case server:		case server:
	CertificateType certificate_type;		CertificateType certificate_type;
	}		}
	} CertificateTypeExtension;		} CertificateTypeExtension;
	No new cipher suites are required to use raw public keys or		No new cipher suites are required to use raw public keys. All
	fingerprints of raw public keys. All existing cipher suites that		existing cipher suites that support a key exchange method compatible
	support a key exchange method compatible with the defined extension		with the defined extension can be used.
	can be used.
	2.2. Server Hello		2.2. Server Hello
	If the server receives a client hello that contains the "cert_type"		If the server receives a client hello that contains the "cert_type"
	extension and chooses a cipher suite then two outcomes are possible.		extension and chooses a cipher suite then two outcomes are possible.
	The server MUST either select a certificate type from the		The server MUST either select a certificate type from the
	certificate_types field in the extended client hello or terminate the		certificate_types field in the extended client hello or terminate the
	session with a fatal alert of type "unsupported_certificate".		session with a fatal alert of type "unsupported_certificate".
	The certificate type selected by the server is encoded in a		The certificate type selected by the server is encoded in a
	CertificateTypeExtension structure, which is included in the extended		CertificateTypeExtension structure, which is included in the extended
	server hello message using an extension of type "cert_type". Servers		server hello message using an extension of type "cert_type". Servers
	that only support X.509 certificates MAY omit including the		that only support X.509 certificates MAY omit including the
	"cert_type" extension in the extended server hello.		"cert_type" extension in the extended server hello.
	If the negotiated certificate type is RawPublicKey the TLS server		If the negotiated certificate type is RawPublicKey the TLS server
	MUST send a CertificateTypeExtension structure with a [PKIX]		MUST send a CertificateTypeExtension structure with a PKIX [PKIX]
	certificate containing ONLY the SubjectPublicKeyInfo. The public key		certificate containing ONLY the SubjectPublicKeyInfo. The public key
	MUST match the selected key exchange algorithm.		MUST match the selected key exchange algorithm.
	If the negotiated certificate type is RawPublicKeySHA256 the TLS
	server MUST send a CertificateTypeExtension structure with a [PKIX]
	certificate containing ONLY the SHA256 of the SubjectPublicKeyInfo.
	The public key used to create the hash MUST match the selected key
	exchange algorithm.
	2.3. Certificate Request		2.3. Certificate Request
	The semantics of this message remain the same as in the TLS		The semantics of this message remain the same as in the TLS
	specification. However, if this message is sent, and the negotiated		specification. However, if this message is sent, and the negotiated
	certificate type is RawPublicKey or RawPublicKeySHA256, the		certificate type is RawPublicKey, the "certificate_authorities" list
	"certificate_authorities" list MUST be empty.		MUST be empty.
	2.4. Other Handshake Messages		2.4. Other Handshake Messages
	All the other handshake messages are identical to the TLS		All the other handshake messages are identical to the TLS
	specification.		specification.
	3. Security Considerations		3. Security Considerations
	The TLS cert_type extension defined here lets a TLS client attempt to		The TLS cert_type extension defined here lets a TLS client attempt to
	supress the sending of server certificate as well as the		supress the sending of server certificate as well as the
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 28 ¶
	were obtained out-of-band extension), the authentication must also be		were obtained out-of-band extension), the authentication must also be
	out-of-band.		out-of-band.
	Depending on exactly how the public keys were obtained, it may be		Depending on exactly how the public keys were obtained, it may be
	appropriate to use authentication mechanisms tied to the public key		appropriate to use authentication mechanisms tied to the public key
	transport. For example, if public keys were obtained using [DANE] it		transport. For example, if public keys were obtained using [DANE] it
	is appropriate to use DNSSEC to authenticate the public keys.		is appropriate to use DNSSEC to authenticate the public keys.
	4. IANA Considerations		4. IANA Considerations
	We request that IANA assign a TLS cert_type value for RawPublicKey		We request that IANA assign a TLS cert_type value for RawPublicKey.
	and RawPublicKeySHA256
	5. Contributors		5. Contributors
	The following individuals made important contributions to this		The following individuals made important contributions to this
	document: Paul Hoffman.		document: Paul Hoffman.
	6. Acknowledgements		6. Acknowledgements
	This document is based on material from RFC 6066 for which the author		This document is based on material from RFC 6066 for which the author
	is Donald Eastlake 3rd. Contributions to that document also include		is Donald Eastlake 3rd. Contributions to that document also include
	Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian		Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian
	Farrel.		Farrel.
	The second version of this document was made after feedback from the		The second version of this document was made after feedback from the
	TLS working group at IETF-81		TLS working group at IETF#81. The support for hashes of public keys
			has been removed after the discussions at the IETF#82 meeting.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[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.
End of changes. 15 change blocks.
	54 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/