< draft-kivinen-ipsecme-signature-auth-00.txt		draft-kivinen-ipsecme-signature-auth-01.txt >
	IP Security Maintenance and Extensions T. Kivinen		IP Security Maintenance and Extensions T. Kivinen
	(ipsecme) INSIDE Secure		(ipsecme) INSIDE Secure
	Internet-Draft December 4, 2012		Internet-Draft April 16, 2013
	Updates: RFC 5996 (if approved)		Updates: RFC 5996 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 7, 2013		Expires: October 18, 2013
	Signature Authentication in IKEv2		Signature Authentication in IKEv2
	draft-kivinen-ipsecme-signature-auth-00.txt		draft-kivinen-ipsecme-signature-auth-01.txt
	Abstract		Abstract
	The Internet Key Exchange Version 2 (IKEv2) protocol has limited		The Internet Key Exchange Version 2 (IKEv2) protocol has limited
	support for the Elliptic Curve Digital Signature Algorithm (ECDSA).		support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
	The current support only includes support for three Elliptic Curve		The current version only includes support for three Elliptic Curve
	groups, and there is fixed hash algorithm tied to each curve. This		groups, and there is fixed hash algorithm tied to each curve. This
	document generalizes the IKEv2 signature support so it can support		document generalizes the IKEv2 signature support so it can support
	any signature method supported by the PKIX and also adds signature		any signature method supported by the PKIX and also adds signature
	hash algorithm negotiation. This generic mechanism is not limited to		hash algorithm negotiation. This is generic mechanism, and is not
	ECDSA, but can also be used with other signature algorithms.		limited to ECDSA, but can also be used with other signature
			algorithms.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 7, 2013.		This Internet-Draft will expire on October 18, 2013.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4		3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4
	4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . . 6		4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8		A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 10
			A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 10
			A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 10
			A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 11
			A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 11
			A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 11
			A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 11
			A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 12
			A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 12
			A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 12
			A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 12
			A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 12
			A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 13
			A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 13
			A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 13
			Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	This document adds support for new IKEv2 ([RFC5996]) authentication		This document adds new IKEv2 ([RFC5996]) authentication method to
	method to support all kinds of signature methods. The current		support all kinds of signature methods. The current signature based
	signature based authentication methods in the IKEv2 are per		authentication methods in the IKEv2 are per algorithm, i.e. there is
	algorithm, i.e. there is one for RSA Digital signatures, one for DSS		one for RSA Digital signatures, one for DSS Digital Signatures (using
	Digital Signatures (using SHA-1) and three for different ECDSA curves		SHA-1) and three for different ECDSA curves each tied to exactly one
	each tied to exactly one hash algorithm. This design starts to be		hash algorithm. This design starts to be cumbersome when more ECDSA
	cumbersome when more ECDSA groups are added, as each of them would		groups are added, as each of them would require new authentication
	require new authentication method and as with ECDSA there is no way		method and as with ECDSA there is no way to extract the hash
	to extract the hash algorithm from the signature, each ECDSA		algorithm from the signature, each ECDSA algorithm would need to come
	algorithm would need to come with fixed hash algorithm tied to it.		with fixed hash algorithm tied to it.
	With the SHA-3 definitions coming out, it is seen that it might be		With the SHA-3 definitions coming out, it is seen that it might be
	possible that in the future the signature methods are used with SHA-3		possible that in the future the signature methods are used with SHA-3
	also, not only SHA-2. This means new mechanism for negotiating the		also, not only SHA-2. This means new mechanism for negotiating the
	hash algorithm for the signature algorithms is needed.		hash algorithm for the signature algorithms is needed.
	The RSA Digital Signatures format in the IKEv2 is specified to use		The RSA Digital Signatures format in the IKEv2 is specified to use
	RSASSA-PKCS1-v1_5, but there has been some discussions that newer		RSASSA-PKCS1-v1_5, but there has been some discussions that newer
	padding methods should also be possible (See section 5 of [RFC4055]).		padding methods should be preferred instead of PKCS #1 version 1.5
	The DSS Digital Signatures format in the IKEv2 is specified to always		(See section 5 of [RFC4055]). The DSS Digital Signatures format in
	use SHA-1, which limits the security of that, meaning there is no		the IKEv2 is specified to always use SHA-1, which limits the security
	point of using long keys with it.		of that, meaning there is no point of using long keys with it.
	This documents specifies two things, one is one new authentication		This documents specifies two things, one is one new authentication
	method, which includes the enough information inside the		method, which includes the enough information inside the
	Authentication payload data that the signature hash algorithm can be		Authentication payload data that the signature hash algorithm can be
	extracted from there (see Section 3). The another thing is to add		extracted from there (see Section 3). The another thing is to add
	indication of supported signature hash algorithms by the peer (see		indication of supported signature hash algorithms by the peer (see
	Section 4). This allows peer to know which hash algorithms are		Section 4). This allows peer to know which hash algorithms are
	supported by the other end and use one of them (provided one is		supported by the other end and use one of them (provided one is
	allowed by policy). There is no need to actually negotiate one		allowed by policy). There is no need to actually negotiate one
	common hash algorithm, as different hash algorithms can be used in		common hash algorithm, as different hash algorithms can be used in
	different directions if needed.		different directions if needed.
	The new digital signature method needs to be flexible enough to		The new digital signature method needs to be flexible enough to
	include all current signature methods (ECDSA, ECGDSA, RSASSA-PSS,		include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS,
	ElGamal, etc), and also allow adding new things in the future. For		etc), and also allow adding new things in the future (ECGDSA, ElGamal
	this the signature algorithm is specified by and OID which specifies		etc). For this the signature algorithm is specified in the same way
	both the signature and hash algorithms (i.e. sha1WithRSAEncryption,		as the PKIX ([RFC5280]) specifies the signature of the Certificate,
	dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256		i.e. there is simple ASN.1 object before the actual signature data.
	etc), meaning any signature and hash algorithm specified by an OID		This ASN.1 object contains the OID specifying the algorithm, and
	can be used.		associated parameters to it. In normal case the IKEv2
			implementations supports fixed amount of signature methods, with
			commonly used parameters, so it is acceptable for the implementation
			to just treat this ASN.1 object as binary blob which is compared
			against the known values, or the implementation can parse the ASN.1
			and extract information from there.
	2. Terminology		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].
	3. Authentication Payload		3. Authentication Payload
	This document specifies new "Digital Signature" authentication		This document specifies new "Digital Signature" authentication
	method. This method can be used with any types of signatures. As		method. This method can be used with any types of signatures. As
	the authentication methods are not negotiated in the IKEv2, the peer		the authentication methods are not negotiated in the IKEv2, the peer
	is only allowed to use this authentication method if the		is only allowed to use this authentication method if the
	SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received.		SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received.
	In this newly defined authentication method, the Authentication Data		In this newly defined authentication method, the Authentication Data
	field inside the Authentication Payload does not include only the		field inside the Authentication Payload does not include only the
	signature value, but instead the signature value is prefixed with the		signature value, but instead the signature value is prefixed with the
	algorithm identification OID. This OID identifies both the signature		ASN.1 object containing the algorithm used to generate the signature.
	algorithm and the hash used when calculating the signature. To make		The ASN.1 object contains the algorithm identification OID, and this
	implementations easier, the OID is prefixed by the 8-bit length		OID identifies both the signature algorithm and the hash used when
	field. This length field allows simple implementations to be able to		calculating the signature. In addition to the OID there is optional
	know the length of the OID, so they can use it as binary blob which		parameters which might be needed for algorithms like RSASSA-PSS.
	is compared against the known OIDs, i.e. they do not need to be able
	to parse or generate ASN.1 DER OIDs (Note, that the 2nd byte of the
	ASN.1 DER OID, also includes the length, but adding it outside makes
	things bit easier for implementors).
	The OIDs used here are the same OIDs which are used inside the		To make implementations easier, the ASN.1 object is prefixed by the
	AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]), but		8-bit length field. This length field allows simple implementations
	only the algorithm OID is included, no parameters etc. The EC curve		to be able to know the length of the ASN.1 without the need to parse
	is always known by the peer because it needs to have the certificate		it, so they can use it as binary blob which is compared against the
	or the public key of the other end before it can do signature		known signature algorithm ASN.1 objects, i.e. they do not need to be
	verification and public key specifies the curve.		able to parse or generate ASN.1 objects. See Appendix A for commonly
			used ASN.1 objects.
	XXX While reading RFC4055, it seemed that the OID is not enough to		The ASN.1 used here are the same ASN.1 which is used in the
	specify the hash function used for the RSASSA-PSS, i.e. it seems		AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The
	that we would need to include full AlgorithmIdentifier ASN object,		algorithm OID inside the ASN.1 specifies the signature algorithm and
	as it includes also the parameters, and the hash function is		the hash function, which are needed to signature verification. The
	specified in the parameters. Is my reading of RFC4055 correct?		EC curve is always known by the peer because it needs to have the
	XXX		certificate or the public key of the other end before it can do
			signature verification and public key specifies the curve.
			Currently only the RSASSA-PSS uses the parameters, for all others the
			parameters is either NULL or missing. Note, that for some algorithms
			there is two possible ASN.1 encoding possible, one with parameters
			being NULL and others where the whole parameters is omitted. This is
			because some of those algorithms are specified that way. When
			encoding the ASN.1 implementations should use the preferred way, i.e.
			if the algorithm specification says "preferredPresent" then parameter
			object needs to be there (i.e. it will be NULL if no parameters is
			specified), and if it says "preferredAbsent", then the whole
			parameters object is missing.
	The Authentication payload is defined in IKEv2 as follows:		The Authentication payload is defined in IKEv2 as follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Auth Method | RESERVED |		| Auth Method | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 8 ¶
	The Authentication Data field has bit different format than in		The Authentication Data field has bit different format than in
	other Authentication methods (see below).		other Authentication methods (see below).
	o Authentication Data (variable length) - see Section 2.15 of		o Authentication Data (variable length) - see Section 2.15 of
	RFC5996. For "Digital Signature" format the Authentication data		RFC5996. For "Digital Signature" format the Authentication data
	contains special format as follows:		contains special format as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OID Length | OID (0x06) . OID value len . OID value |		| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ OID value continuing ~		~ AlgorithmIdentifier ASN.1 object continuing ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Signature Value ~		~ Signature Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Authentication Data Format.		Figure 2: Authentication Data Format.
	Where the OID Length is the length of the ASN.1 encoded OID value,		Where the ASN.1 Length is the length of the ASN.1 encoded
	and after that is the actual Signature Algorithm OID followed by		AlgorithmIdentifier object, and after that is the actual
	the actual signature value. There is no padding between OID and		AlgorithmIdentifier ASN.1 object, followed by the actual signature
	signature value. ASN.1 encoded OIDs always start with byte of		value. There is no padding between ASN.1 object and signature
	0x06 followed by the length of the actual OID value (which is		value. For the hash truncation the method of X9.62 ([X9.62]) MUST
	shown in the figure above). For the hash truncation the method of		be used.
	X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for
	X9.62/SEC1 etchere XXX.
	4. Hash Algorithm Notification		4. Hash Algorithm Notification
	The supported hash algorithms that can be used for the signature		The supported hash algorithms that can be used for the signature
	algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS		algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS
	Notification Payload sent inside the IKE_SA_INIT exchange. This		Notification Payload sent inside the IKE_SA_INIT exchange. This
	notification also indicates the support of the new signature		notification also indicates the support of the new signature
	algorithm method, i.e sending this notification tells that new		algorithm method, i.e. sending this notification tells that new
	"Digital Signature" authentication method is supported and that		"Digital Signature" authentication method is supported and that
	following hash functions are supported by sending peer. Both ends		following hash functions are supported by sending peer. Both ends
	sends their list of supported hash-algorithms and when calculating		sends their list of supported hash-algorithms and when calculating
	signature a peer MUST pick one algorithm sent by the other peer.		signature a peer MUST pick one algorithm sent by the other peer.
	Note, that different algorithms can be used in different directions.		Note, that different algorithms can be used in different directions.
	The algorithm OID matching selected hash algorithm (and signature		The algorithm OID matching selected hash algorithm (and signature
	algorithm) used when calculating the signature is sent inside the		algorithm) used when calculating the signature is sent inside the
	Authentication Data field of the Authentication Payload.		Authentication Data field of the Authentication Payload.
	1 2 3		1 2 3
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 30 ¶
	Figure 3: Notify Payload Format.		Figure 3: Notify Payload Format.
	Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from		Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from
	status types>. The Notification Data value contains list of 16-bit		status types>. The Notification Data value contains list of 16-bit
	hash algorithm identifiers from the newly created Hash Algorithm		hash algorithm identifiers from the newly created Hash Algorithm
	Identifiers for the IKEv2 IANA registry.		Identifiers for the IKEv2 IANA registry.
	5. Security Considerations		5. Security Considerations
	XXX The text about the guidance how to select suitable hash		The "Recommendations for Key Management" ([NIST800-57]) table 2
	functions is missing here. XXX		combined with table 3 gives recommendations for how to select
			suitable hash functions for the signature.
	This new digital signature method does not tie the EC curve to the		This new digital signature method does not tie the EC curve to the
	specific hash function, which was done in the old IKEv2 ECDSA		specific hash function, which was done in the old IKEv2 ECDSA
	methods. This means it is possible to use 512-bit EC curve with		methods. This means it is possible to use 512-bit EC curve with
	SHA1, i.e. this allows mixing different security levels. This means		SHA1, i.e. this allows mixing different security levels. This means
	that the security of the authentication method is the security of the		that the security of the authentication method is the security of the
	weakest of components (signature algorithm, hash algorithm, curve).		weakest of components (signature algorithm, hash algorithm, curve).
	This might make the security analysis of the system bit more complex.		This might make the security analysis of the system bit more complex.
	Note, that this kind of mixing of the security can be disallowed by		Note, that this kind of mixing of the security can be disallowed by
	the policy.		the policy.
	The hash algorithm registry does not include MD5 as supported hash		The hash algorithm registry does not include MD5 as supported hash
	algorithm, as it is not considered safe enough for signature use.		algorithm, as it is not considered safe enough for signature use
			([WY05]).
	XXX Need reference for MD5 considered unsafe. XXX
	The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using
	newer padding methods like RSASSA-PSS. This new method allows using
	other padding methods.
	XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security.		The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems
	XXX		([KA08], [ME01]) and does not allow using newer padding methods like
			RSASSA-PSS. This new method allows using other padding methods.
	The current IKEv2 only allows using normal DSA with SHA-1, which		The current IKEv2 only allows using normal DSA with SHA-1, which
	means the security of the regular DSA is limited to the security of		means the security of the regular DSA is limited to the security of
	SHA-1. This new methods allows using longer keys and longer hashes		SHA-1. This new methods allows using longer keys and longer hashes
	with DSA.		with DSA.
	6. IANA Considerations		6. IANA Considerations
	This document creates new IANA registry for IKEv2 Hash Algorithms.		This document creates new IANA registry for IKEv2 Hash Algorithms.
	Changes and additions to this registry is by expert review.		Changes and additions to this registry is by expert review.
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 9 ¶
	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.
	8.2. Informative References		8.2. Informative References
			[KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
			"Variants of Bleichenbacher's Low-Exponent Attack on
			PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109.
			[ME01] Menezes, A., "Evaluation of Security Level of
			Cryptography: RSA-OAEP, RSA-PSS, RSA Signature",
			December 2001.
			[NIST800-57]
			Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
			"Recommendations for Key Management", NIST SP 800-57,
			March 2007.
			[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
			Identifiers for the Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 3279, April 2002.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate		the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,		and Certificate Revocation List (CRL) Profile", RFC 4055,
	June 2005.		June 2005.
	[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.
	Appendix A. Examples		[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
			Polk, "Internet X.509 Public Key Infrastructure:
			Additional Algorithms and Identifiers for DSA and ECDSA",
			RFC 5758, January 2010.
			[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
			Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
			June 2010.
			[WY05] Wang, X. and H. Yu, "How to break MD5 and other hash
			functions", Proceedings of EuroCrypt 2005, Lecture Notes
			in Computer Science Vol. 3494, 2005.
			[X9.62] American National Standards Institute, "Public Key
			Cryptography for the Financial Services Industry: The
			Elliptic Curve Digital Signature Algorithm (ECDSA)",
			ANSI X9.62, November 2005.
			Appendix A. Commonly used ASN.1 objects
			This section lists commonly used ASN.1 objects in binary form. This
			section is not-normative, and these values should only be used as
			examples, i.e. if this and the actual specification of the algorithm
			ASN.1 object is different the actual format specified in the actual
			specification needs to be used. These values are taken form the New
			ASN.1 Modules for the Public Key Infrastructure Using X.509
			([RFC5912]).
			A.1. PKCS#1 1.5 RSA Encryption
			These algorithm identifiers here include several different ASN.1
			objects with different hash algorithms. In this document we only
			include the commonly used ones i.e. the one using SHA-1, or SHA-2 as
			hash function. Some of those other algorithms (MD2, MD5) specified
			for this are not safe enough to be used as signature hash algorithm,
			and some are omitted as there is no hash algorithm specified in the
			our IANA registry for them. Note, that there is no parameters in any
			of these, but all specified here needs to have NULL parameters
			present in the ASN.1.
			See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and
			Additional Algorithms and Identifiers for RSA Cryptography for PKIX
			Profile ([RFC4055]) for more information.
			A.1.1. sha1WithRSAEncryption
			sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
			us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
			Parameters are required, and they must be NULL.
			XXX binary object missing
			A.1.2. sha256WithRSAEncryption
			sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
			Parameters are required, and they must be NULL.
			XXX binary object missing
			A.1.3. sha384WithRSAEncryption
			sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
			Parameters are required, and they must be NULL.
			XXX binary object missing
			A.1.4. sha512WithRSAEncryption
			sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
			Parameters are required, and they must be NULL.
			XXX binary object missing
			A.2. DSA
			With different DSA algorithms the parameters are always omitted.
			Again we omit dsa-with-sha224 as there is no hash algorithm in our
			IANA registry for it.
			See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX
			Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]
			for more information.
			A.2.1. dsa-with-sha1
			dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
			x9-57(10040) x9algorithm(4) 3 }
			Parameters are absent.
			XXX binary object missing
			A.2.2. dsa-with-sha256
			dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
			country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
			id-dsa-with-sha2(3) 2 }
			Parameters are absent.
			XXX binary object missing
			A.3. ECDSA
			With different ECDSA algorithms the parameters are always omitted.
			Again we omit ecdsa-with-sha224 as there is no hash algorithm in our
			IANA registry for it.
			See Elliptic Curve Cryptography Subject Public Key Information
			([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279])
			and PKIX Additional Algorithms and Identifiers for DSA and ECDSA
			([RFC5758] for more information.
			A.3.1. ecdsa-with-sha1
			ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
			ansi-X9-62(10045) signatures(4) 1 }
			Parameters are absent.
			XXX binary object missing
			A.3.2. ecdsa-with-sha256
			ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
			us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
			Parameters are absent.
			XXX binary object missing
			A.3.3. ecdsa-with-sha384
			ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
			us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
			Parameters are absent.
			XXX binary object missing
			A.3.4. ecdsa-with-sha512
			ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
			us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
			Parameters are absent.
			XXX binary object missing
			A.4. RSASSA-PSS
			With the RSASSA-PSS the algorithm object identifier is always id-
			RSASSA-PSS, but the hash function is taken from the parameters, and
			it is required. See [RFC4055] for more information.
			A.4.1. RSASSA-PSS with empty parameters
			id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
			Parameters are empty, but the ASN.1 part of the sequence must be
			there. This means default parameters are used (same as the next
			example).
			XXX binary object missing
			A.4.2. RSASSA-PSS with default parameters
			id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
			Here the parameters are present, and contains the default parameters,
			i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1.
			XXX binary object missing
			Appendix B. Examples
	Author's Address		Author's Address
	Tero Kivinen		Tero Kivinen
	INSIDE Secure		INSIDE Secure
	Eerikinkatu 28		Eerikinkatu 28
	HELSINKI FI-00180		HELSINKI FI-00180
	FI		FI
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
End of changes. 23 change blocks.
	85 lines changed or deleted		309 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/