< draft-kivinen-ipsecme-oob-pubkey-01.txt		draft-kivinen-ipsecme-oob-pubkey-02.txt >
	IP Security Maintenance and Extensions T. Kivinen		IP Security Maintenance and Extensions T. Kivinen
	(ipsecme) AuthenTec		(ipsecme) AuthenTec
	Internet-Draft P. Wouters		Internet-Draft P. Wouters
	Intended status: Informational Red Hat		Updates: RFC 5996 (if approved) Red Hat
	Expires: April 19, 2013 H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Nokia Siemens Networks		Expires: April 25, 2013 Nokia Siemens Networks
	October 16, 2012		October 22, 2012
	More Raw Public Keys for IKEv2		More Raw Public Keys for IKEv2
	draft-kivinen-ipsecme-oob-pubkey-01.txt		draft-kivinen-ipsecme-oob-pubkey-02.txt
	Abstract		Abstract
	The Internet Key Exchange Version 2 (IKEv2) protocol currently only		The Internet Key Exchange Version 2 (IKEv2) protocol currently only
	supports raw RSA keys. In some environments it is useful to make use		supports raw RSA keys. In some environments it is useful to make use
	of other types of public keys, such as those based on Elliptic Curve		of other types of public keys, such as those based on Elliptic Curve
	Cryptography. This documents adds support for other types of raw		Cryptography. This documents adds support for other types of raw
	public keys to IKEv2.		public keys to IKEv2.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 April 19, 2013.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4		3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Secure DNS allows public keys to be associated with domain names for		Secure DNS allows public keys to be associated with domain names for
	usage with security protocols like Internet Key Exchange Version 2		usage with security protocols like Internet Key Exchange Version 2
	(IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on		(IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on
	extensions in those protocols to be specified.		extensions in those protocols to be specified.
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	This document is similar than the TLS Out-of-Band Public Key		This document is similar than the TLS Out-of-Band Public Key
	Validation specification, and applies the concept to IKEv2 to support		Validation specification, and applies the concept to IKEv2 to support
	all public key formats defined by PKIX. This approach also allows		all public key formats defined by PKIX. This approach also allows
	future public key extensions to be supported without the need to		future public key extensions to be supported without the need to
	introduce further enhancements to IKEv2.		introduce further enhancements to IKEv2.
	To support new types of public keys in IKEv2 the following changes		To support new types of public keys in IKEv2 the following changes
	are needed:		are needed:
	o A new Certificate Encoding format needs to be defined for carrying		o A new Certificate Encoding format needs to be defined for carrying
	the SubjectPublicKeyInfo structure. Section 2 specifies this new		the SubjectPublicKeyInfo structure. Section 3 specifies this new
	encoding format.		encoding format.
	o A new Certificate Encoding type needs to be allocated from the		o A new Certificate Encoding type needs to be allocated from the
	IANA registry. Section 5 contains this request to IANA.		IANA registry. Section 6 contains this request to IANA.
			2. Terminology
	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].
	2. Certificate Encoding Payload		3. Certificate Encoding Payload
	Section 3.6 of RFC 5996 defines the Certificate payload format as		Section 3.6 of RFC 5996 defines the Certificate payload format as
	shown in Figure 1.		shown in Figure 1.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cert Encoding | |		| Cert Encoding | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	~ Certificate Data ~		~ Certificate Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Certificate Payload Format		Figure 1: Certificate Payload Format.
	o Certificate Encoding (1 octet) - This field indicates the type of		o Certificate Encoding (1 octet) - This field indicates the type of
	certificate or certificate-related information contained in the		certificate or certificate-related information contained in the
	Certificate Data field.		Certificate Data field.
	Certificate Encoding Value		Certificate Encoding Value
	----------------------------------------------------		----------------------------------------------------
	Raw Public Key TBD		Raw Public Key TBD
	o Certificate Data (variable length) - Actual encoding of the		o Certificate Data (variable length) - Actual encoding of the
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	Certificate Encoding field.		Certificate Encoding field.
	When the certificate encoding type 'Raw Public Key' is used then the		When the certificate encoding type 'Raw Public Key' is used then the
	Certificate Data only contains the SubjectPublicKeyInfo part of the		Certificate Data only contains the SubjectPublicKeyInfo part of the
	PKIX certificate.		PKIX certificate.
	In the case of the Certificate Request payload the Certification		In the case of the Certificate Request payload the Certification
	Authority field MUST be empty if the "Raw Public Key" certificate		Authority field MUST be empty if the "Raw Public Key" certificate
	encoding is used.		encoding is used.
	3. Old Raw RSA Key Certificate Type		4. Old Raw RSA Key Certificate Type
	After this there are two ways of sending Raw RSA public keys in the		After this there are two ways of sending Raw RSA public keys in the
	IKEv2: The already existing mechanism (Raw RSA Key, encoding value		IKEv2: The already existing mechanism (Raw RSA Key, encoding value
	11), and the new format defined here. The IKEv2 protocol already		11), and the new format defined here. The IKEv2 protocol already
	supports a method to indicate what certificate encoding formats are		supports a method to indicate what certificate encoding formats are
	supported, i.e. a peer can send one or multiple Certificate Request		supported, i.e. a peer can send one or multiple Certificate Request
	payload with the certificate encoding types it supports. From this		payload with the certificate encoding types it supports. From this
	list the recipient can see what formats are supported and select one		list the recipient can see what formats are supported and select one
	which is used to send Certificate back.		which is used to send Certificate back.
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	the Certificate Request payloads, it is RECOMMENDED for		the Certificate Request payloads, it is RECOMMENDED for
	implementations to prefer new format defined in this document, so the		implementations to prefer new format defined in this document, so the
	old Raw RSA public key format could possibly be phased out in the		old Raw RSA public key format could possibly be phased out in the
	future.		future.
	To better support minimal implementations, it would be best to limit		To better support minimal implementations, it would be best to limit
	the code complexity of those versions, and such implementations might		the code complexity of those versions, and such implementations might
	choose to implement only the new format, which supports all types of		choose to implement only the new format, which supports all types of
	raw public keys.		raw public keys.
	4. Security Considerations		5. Security Considerations
	An IKEv2 deployment using raw public keys needs to utilize an out-of-		An IKEv2 deployment using raw public keys needs to utilize an out-of-
	band public key validation procedure to be confident in the		band public key validation procedure to be confident in the
	authenticity of the keys being used. One such mechanism is to use a		authenticity of the keys being used. One such mechanism is to use a
	configuration mechanism for provisioning raw public keys into the		configuration mechanism for provisioning raw public keys into the
	IKEv2 software. A suitable deployment is likely to be found with		IKEv2 software. A suitable deployment is likely to be found with
	smart objects. Yet another approach is to rely on secure DNS to		smart objects. Yet another approach is to rely on secure DNS to
	associate public keys to be associated with domain names using the		associate public keys to be associated with domain names using the
	IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-		IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-
	Based Authentication of Named Entities (DANE) [RFC6394].		Based Authentication of Named Entities (DANE) [RFC6394].
	This document does not change the assumptions made by the IKEv2		This document does not change the assumptions made by the IKEv2
	specifications since "Raw RSA Key" support is already available in		specifications since "Raw RSA Key" support is already available in
	IKEv2. This document only generalizes the raw public key support.		IKEv2. This document only generalizes the raw public key support.
	5. IANA Considerations		6. IANA Considerations
	This document allocates a new value from the IKEv2 Certificate		This document allocates a new value from the IKEv2 Certificate
	Encodings registry:		Encodings registry:
	TBD Raw Public Key		TBD Raw Public Key
	6. Acknowledgements		7. Acknowledgements
	This document copies parts from the similar TLS document		This document copies parts from the similar TLS document
	([I-D.ietf-tls-oob-pubkey]).		([I-D.ietf-tls-oob-pubkey]).
	7. References		8. References
	7.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.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] 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.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 5996, September 2010.		RFC 5996, September 2010.
	7.2. Informative References		8.2. Informative References
	[I-D.ietf-tls-oob-pubkey]		[I-D.ietf-tls-oob-pubkey]
	Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.		Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
	Tschofenig, "Out-of-Band Public Key Validation for		Tschofenig, "Out-of-Band Public Key Validation for
	Transport Layer Security", draft-ietf-tls-oob-pubkey-04		Transport Layer Security", draft-ietf-tls-oob-pubkey-04
	(work in progress), July 2012.		(work in progress), July 2012.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
End of changes. 14 change blocks.
	25 lines changed or deleted		28 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/