< draft-kivinen-ipsecme-oob-pubkey-03.txt		draft-kivinen-ipsecme-oob-pubkey-04.txt >
	IP Security Maintenance and Extensions T. Kivinen		IP Security Maintenance and Extensions T. Kivinen
	(ipsecme) AuthenTec		(ipsecme) INSIDE Secure
	Internet-Draft P. Wouters		Internet-Draft P. Wouters
	Updates: RFC 5996 (if approved) Red Hat		Updates: RFC 5996 (if approved) Red Hat
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: June 2, 2013 Nokia Siemens Networks		Expires: January 31, 2014 Nokia Siemens Networks
	November 29, 2012		July 30, 2013
	More Raw Public Keys for IKEv2		More Raw Public Keys for IKEv2
	draft-kivinen-ipsecme-oob-pubkey-03.txt		draft-kivinen-ipsecme-oob-pubkey-04.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 and obsoletes the old raw RSA key format.		public keys to IKEv2 and obsoletes the old raw RSA key format.
	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 June 2, 2013.		This Internet-Draft will expire on January 31, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3		3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3
	4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4		4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
	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
	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.
			Note, that we do follow public key processing rules of the section
			1.2 of the Additional Algorithms and Identifiers for RSA Cryptography
			for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part
			of the certificate, but sent here. This means RSASSA-PSS and RSASSA-
			PSS-params inside the SubjectPublicKeyInfo needs to be followed.
	4. Old Raw RSA Key Certificate Type		4. Old Raw RSA Key Certificate Type
	After this there would be two ways of sending Raw RSA public keys in		After this there would be two ways of sending Raw RSA public keys in
	the IKEv2: The original IKEv2 mechanism (Raw RSA Key, encoding value		the IKEv2: The original IKEv2 mechanism (Raw RSA Key, encoding value
	11), and the new format defined here. The old Raw RSA Key encoding		11), and the new format defined here. The old Raw RSA Key encoding
	has not been widely used. The IKEv2 protocol already supports a		has not been widely used. The IKEv2 protocol already supports a
	method to indicate what certificate encoding formats are supported,		method to indicate what certificate encoding formats are supported,
	i.e. a peer can send one or multiple Certificate Request payload with		i.e. a peer can send one or multiple Certificate Request payload with
	the certificate encoding types it supports. From this list the		the certificate encoding types it supports. From this list the
	recipient can see what formats are supported and select one which is		recipient can see what formats are supported and select one which is
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 32 ¶
	[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.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-tls-oob-pubkey]		[I-D.ietf-tls-oob-pubkey]
	Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and		Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	T. Kivinen, "Out-of-Band Public Key Validation for		T. Kivinen, "Out-of-Band Public Key Validation for
	Transport Layer Security (TLS)",		Transport Layer Security (TLS)",
	draft-ietf-tls-oob-pubkey-06 (work in progress),		draft-ietf-tls-oob-pubkey-08 (work in progress),
	October 2012.		July 2013.
	[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		[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
	Material in DNS", RFC 4025, March 2005.		Material in DNS", RFC 4025, March 2005.
			[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
			Algorithms and Identifiers for RSA Cryptography for use in
			the Internet X.509 Public Key Infrastructure Certificate
			and Certificate Revocation List (CRL) Profile", RFC 4055,
			June 2005.
	[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using		[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
	the Elliptic Curve Digital Signature Algorithm (ECDSA)",		the Elliptic Curve Digital Signature Algorithm (ECDSA)",
	RFC 4754, January 2007.		RFC 4754, January 2007.
	[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
	"Elliptic Curve Cryptography Subject Public Key		"Elliptic Curve Cryptography Subject Public Key
	Information", RFC 5480, March 2009.		Information", RFC 5480, March 2009.
	[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,
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 30 ¶
	Where the NN will be the next payload type (i.e. that value depends		Where the NN will be the next payload type (i.e. that value depends
	on what is the next payload after this certificate payload).		on what is the next payload after this certificate payload).
	Note to the RFC editor / IANA, replace the XX above with the newly		Note to the RFC editor / IANA, replace the XX above with the newly
	allocated Raw Public Key number, and remove this note.		allocated Raw Public Key number, and remove this note.
	Authors' Addresses		Authors' Addresses
	Tero Kivinen		Tero Kivinen
	AuthenTec		INSIDE Secure
	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
End of changes. 10 change blocks.
	10 lines changed or deleted		22 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/