< draft-ietf-tls-oob-pubkey-08.txt		draft-ietf-tls-oob-pubkey-09.txt >
	TLS P. Wouters, Ed.		TLS P. Wouters, Ed.
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Standards Track H. Tschofenig, Ed.		Intended status: Standards Track H. Tschofenig, Ed.
	Expires: January 17, 2014 Nokia Siemens Networks		Expires: January 31, 2014 Nokia Siemens Networks
	J. Gilmore		J. Gilmore
	S. Weiler		S. Weiler
	SPARTA, Inc.		SPARTA, Inc.
	T. Kivinen		T. Kivinen
	AuthenTec		AuthenTec
	July 16, 2013		July 30, 2013
	Out-of-Band Public Key Validation for Transport Layer Security (TLS)		Out-of-Band Public Key Validation for Transport Layer Security (TLS)
	draft-ietf-tls-oob-pubkey-08.txt		draft-ietf-tls-oob-pubkey-09.txt
	Abstract		Abstract
	This document specifies a new certificate type and two TLS		This document specifies a new certificate type and two TLS
	extensions, one for the client and one for the server, for exchanging		extensions, one for the client and one for the server, for exchanging
	raw public keys in Transport Layer Security (TLS) and Datagram		raw public keys in Transport Layer Security (TLS) and Datagram
	Transport Layer Security (DTLS) for use with out-of-band public key		Transport Layer Security (DTLS) for use with out-of-band public key
	validation.		validation.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 17, 2014.		This Internet-Draft will expire on January 31, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 21 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. New TLS Extension . . . . . . . . . . . . . . . . . . . . . . 3		3. New TLS Extension . . . . . . . . . . . . . . . . . . . . . . 3
	4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7		4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7
	4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7		4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7
	4.4. Other Handshake Messages . . . . . . . . . . . . . . . . 7		4.4. Other Handshake Messages . . . . . . . . . . . . . . . . 8
	4.5. Client authentication . . . . . . . . . . . . . . . . . . 8		4.5. Client authentication . . . . . . . . . . . . . . . . . . 8
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13		Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Traditionally, TLS client and server public keys are obtained in PKIX		Traditionally, TLS client and server public keys are obtained in PKIX
	containers in-band using the TLS handshake and validated using trust		containers in-band using the TLS handshake and validated using trust
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	algorithm AlgorithmIdentifier,		algorithm AlgorithmIdentifier,
	subjectPublicKey BIT STRING }		subjectPublicKey BIT STRING }
	AlgorithmIdentifier ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	algorithm OBJECT IDENTIFIER,		algorithm OBJECT IDENTIFIER,
	parameters ANY DEFINED BY algorithm OPTIONAL }		parameters ANY DEFINED BY algorithm OPTIONAL }
	Figure 2: SubjectPublicKeyInfo ASN.1 Structure.		Figure 2: SubjectPublicKeyInfo ASN.1 Structure.
	The algorithm identifiers are Object Identifiers (OIDs). RFC 3279		The algorithm identifiers are Object Identifiers (OIDs). RFC 3279
	[RFC3279] and [RFC5480] define the following OIDs shown in Figure 3.		[RFC3279] and [RFC5480], for example, define the following OIDs shown
			in Figure 3. Note that this list is not exhaustive and more OIDs may
			be defined in future RFCs. RFC 5480 also defines a number of OIDs.
	Key Type | Document | OID		Key Type | Document | OID
	-----------------------+----------------------------+-------------------		-----------------------+----------------------------+-------------------
	RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1		RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1
	.......................|............................|...................		.......................|............................|...................
	Digital Signature | |		Digital Signature | |
	Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1		Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1
	.......................|............................|...................		.......................|............................|...................
	Elliptic Curve | |		Elliptic Curve | |
	Digital Signature | |		Digital Signature | |
	Algorithm (ECDSA) | Section 2.3.5 of RFC 5480 | 1.2.840.10045.2.1		Algorithm (ECDSA) | Section 2 of RFC 5480 | 1.2.840.10045.2.1
	-----------------------+----------------------------+-------------------		-----------------------+----------------------------+-------------------
	Figure 3: Example Algorithm Object Identifiers.		Figure 3: Example Algorithm Object Identifiers.
	The message exchange in Figure 4 shows the 'client_certificate_type'		The message exchange in Figure 4 shows the 'client_certificate_type'
	and 'server_certificate_type' extensions added to the client and		and 'server_certificate_type' extensions added to the client and
	server hello messages.		server hello messages.
	client_hello,		client_hello,
	client_certificate_type		client_certificate_type
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 12 ¶
	procedures for associating the public key with the possession of a		procedures for associating the public key with the possession of a
	private key also follows standard procedures.		private key also follows standard procedures.
	The main security challenge is, however, how to associate the public		The main security challenge is, however, how to associate the public
	key with a specific entity. Without a secure binding between		key with a specific entity. Without a secure binding between
	identity and key the protocol will be vulnerable to masquerade and		identity and key the protocol will be vulnerable to masquerade and
	man-in-the-middle attacks. This document assumes that such binding		man-in-the-middle attacks. This document assumes that such binding
	can be made out-of-band and we list a few examples in Section 1.		can be made out-of-band and we list a few examples in Section 1.
	DANE [RFC6698] offers one such approach. In order to address these		DANE [RFC6698] offers one such approach. In order to address these
	vulnerabilities, specifications that make use of the extension MUST		vulnerabilities, specifications that make use of the extension MUST
	specify how the identity and public key are bound. If public keys		specify how the identity and public key are bound. In addition to
	are obtained using DANE, these public keys are authenticated via		ensuring the binding is done out-of-band an implementation also needs
	DNSSEC. Pre-configured keys is another out of band method for		to check the status of that binding.
	authenticating raw public keys. While pre-configured keys are not
	suitable for a generic Web-based e-commerce environment such keys are		If public keys are obtained using DANE, these public keys are
	a reasonable approach for many smart object deployments where there		authenticated via DNSSEC. Pre-configured keys is another out of band
	is a close relationship between the software running on the device		method for authenticating raw public keys. While pre-configured keys
	and the server-side communication endpoint. Regardless of the chosen		are not suitable for a generic Web-based e-commerce environment such
	mechanism for out-of-band public key validation an assessment of the		keys are a reasonable approach for many smart object deployments
	most suitable approach has to be made prior to the start of a		where there is a close relationship between the software running on
	deployment to ensure the security of the system.		the device and the server-side communication endpoint. Regardless of
			the chosen mechanism for out-of-band public key validation an
			assessment of the most suitable approach has to be made prior to the
			start of a deployment to ensure the security of the system.
	7. IANA Considerations		7. IANA Considerations
	IANA is asked to register a new value in the "TLS Certificate Types"		IANA is asked to register a new value in the "TLS Certificate Types"
	registry of Transport Layer Security (TLS) Extensions		registry of Transport Layer Security (TLS) Extensions
	[TLS-Certificate-Types-Registry], as follows:		[TLS-Certificate-Types-Registry], as follows:
	Value: 2		Value: 2
	Description: Raw Public Key		Description: Raw Public Key
	Reference: [[THIS RFC]]		Reference: [[THIS RFC]]
	skipping to change at page 11, line 47 ¶		skipping to change at page 12, line 18 ¶
	substantially shaped the document and we would like to thank the		substantially shaped the document and we would like to thank the
	meeting participants for their input. The support for hashes of		meeting participants for their input. The support for hashes of
	public keys has been moved to [I-D.ietf-tls-cached-info] after the		public keys has been moved to [I-D.ietf-tls-cached-info] after the
	discussions at the IETF#82 meeting.		discussions at the IETF#82 meeting.
	We would like to thank the following persons for their review		We would like to thank the following persons for their review
	comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann,		comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann,
	Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba,		Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba,
	Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John		Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John
	Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn		Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn
	Gillmor, Peter Sylvester, and James Manger. Nikos Mavrogiannopoulos		Gillmor, Peter Sylvester, Hauke Mehrtens, and James Manger. Nikos
	contributed the design for re-using the certificate type registry.		Mavrogiannopoulos contributed the design for re-using the certificate
			type registry. Barry Leiba contributed guidance for the IANA
	Barry Leiba contributed guidance for the IANA consideration text.		consideration text. Stefan Jucker, Kovatsch Matthias, and Klaus
	Stefan Jucker, Kovatsch Matthias, and Klaus Hartke provided		Hartke provided implementation feedback regarding the
	implementation feedback regarding the SubjectPublicKeyInfo structure.		SubjectPublicKeyInfo structure.
	We would like to thank our TLS working group chairs, Eric Rescorla		We would like to thank our TLS working group chairs, Eric Rescorla
	and Joe Salowey, for their guidance and support. Finally, we would		and Joe Salowey, for their guidance and support. Finally, we would
	like to thank Sean Turner, who is the responsible security area		like to thank Sean Turner, who is the responsible security area
	director for this work for his review comments and suggestions.		director for this work for his review comments and suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
End of changes. 10 change blocks.
	25 lines changed or deleted		30 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/