< draft-kivinen-ipsecme-oob-pubkey-00.txt		draft-kivinen-ipsecme-oob-pubkey-01.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		Intended status: Informational Red Hat
	Expires: September 6, 2012 H. Tschofenig		Expires: April 19, 2013 H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	March 5, 2012		October 16, 2012
	More Raw Public Keys for IKEv2		More Raw Public Keys for IKEv2
	draft-kivinen-ipsecme-oob-pubkey-00.txt		draft-kivinen-ipsecme-oob-pubkey-01.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 September 6, 2012.		This Internet-Draft will expire on April 19, 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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3		2. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3
	3. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4		3. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6
			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.
	IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a		IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a
	DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other		DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	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		3. 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 mechanisms, and the new format defined		IKEv2: The already existing mechanism (Raw RSA Key, encoding value
	here. The IKEv2 protocol already supports a method to indicate which		11), and the new format defined here. The IKEv2 protocol already
	certificate encoding formats are supported, i.e. a peer can send one		supports a method to indicate what certificate encoding formats are
	or multiple Certificate Request payload with the certificate encoding		supported, i.e. a peer can send one or multiple Certificate Request
	types it supports. From this list the recipient can see which		payload with the certificate encoding types it supports. From this
	formats are supported and select one which is used to send		list the recipient can see what formats are supported and select one
	Certificate back.		which is used to send Certificate back.
	If the peer has raw non-RSA public key, it has no other option than		If the peer has non-RSA raw public key, it has no other option than
	to use the new format. If it has raw RSA public key, it can either		to use the new format. If it has RSA raw public key, it can either
	use the old format or the new format, and it SHOULD indicate support		use the old format or the new format, and it SHOULD indicate support
	for both by sending both certificate encoding types inside		for both by sending both certificate encoding types inside
	Certificate Request payloads.		Certificate Request payloads.
	If a peer receives both old and new certificate endocing formats in		If a peer receives both old and new certificate encoding formats in
	the Certificate Request payloads, it is RECOMMENDED for new		the Certificate Request payloads, it is RECOMMENDED for
	implementations to prefer this new format defined in this document,		implementations to prefer new format defined in this document, so the
	so the old Raw RSA public key format could possibly be phased out in		old Raw RSA public key format could possibly be phased out in the
	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 in such implementations it		the code complexity of those versions, and such implementations might
	might be better to implement only the new format as it supports all		choose to implement only the new format, which supports all types of
	types of raw public keys.		raw public keys.
	4. Security Considerations		4. 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. More		associate public keys to be associated with domain names using the
	information can be found in DNS-Based Authentication of Named		IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-
	Entitites (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		5. 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:
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	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		7.2. Informative References
	[I-D.ietf-tls-oob-pubkey]		[I-D.ietf-tls-oob-pubkey]
	Tschofenig, H., Gilmore, J., Wouters, P., Weiler, S., and		Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
	T. Kivinen, "TLS Out-of-Band Public Key Validation",		Tschofenig, "Out-of-Band Public Key Validation for
	draft-ietf-tls-oob-pubkey-01 (work in progress),		Transport Layer Security", draft-ietf-tls-oob-pubkey-04
	January 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.
			[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
			Material in DNS", RFC 4025, March 2005.
			[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
			the Elliptic Curve Digital Signature Algorithm (ECDSA)",
			RFC 4754, January 2007.
	[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based		[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
	Authentication of Named Entities (DANE)", RFC 6394,		Authentication of Named Entities (DANE)", RFC 6394,
	October 2011.		October 2011.
	[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for		[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
	Obtaining Digital Signatures and Public-Key		Obtaining Digital Signatures and Public-Key
	Cryptosystems", February 1978.		Cryptosystems", February 1978.
			Appendix A. Examples
			This appendix provides examples of the actual packets sent on the
			wire. This uses the 256-bit ECDSA private/public key pair defined in
			the section 8.1. of the IKEv2 ECDSA document [RFC4754].
			The public key is as followed:
			o Algorithm : id-ecPublicKey (1.2.840.10045.2.1)
			o Fixed curve: secp256r1 (1.2.840.10045.3.1.7)
			o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707
			9716cbbf 917dd72e 97566ea1 c066957c
			o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f
			dbe71e36 99d91339 afbb903e e17255dc
			The SubjectPublicKeyInfo ASN.1 object is as follows:
			0000 : SEQUENCE
			0002 : SEQUENCE
			0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1)
			000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7)
			0017 : BIT STRING (66 bytes)
			00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a
			00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066
			00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911
			00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172
			00000040: 55dc
			The first byte (00) of the bit string indicates that there is no
			"number of unused bits", and the second byte (04) indicates
			uncompressed form. Those two octets are followed by the values of X
			and Y.
			The final encoded SubjectPublicKeyInfo object is as follows:
			00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a
			00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b
			00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91
			00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f
			00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699
			00000050: d913 39af bb90 3ee1 7255 dc
			This will result the final IKEv2 Certificate Payload to be:
			00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d
			00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004
			00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707
			00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c
			00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f
			00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc
			Where the NN will be the next payload type (i.e. that value depends
			on what is the next payload after this certificate payload).
			Note to the RFC editor / IANA, replace the XX above with the newly
			allocated Raw Public Key number, and remove this note.
	Authors' Addresses		Authors' Addresses
	Tero Kivinen		Tero Kivinen
	AuthenTec		AuthenTec
	Eerikinkatu 28		Eerikinkatu 28
	HELSINKI FI-00180		HELSINKI FI-00180
	FI		FI
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
End of changes. 14 change blocks.
	29 lines changed or deleted		95 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/