draft-kivinen-ipsecme-signature-auth-05.txt		draft-kivinen-ipsecme-signature-auth-06.txt
	IP Security Maintenance and Extensions T. Kivinen		IP Security Maintenance and Extensions T. Kivinen
	(ipsecme) INSIDE Secure		(ipsecme) INSIDE Secure
	Internet-Draft March 28, 2014		Internet-Draft J. Snyder
	Updates: RFC 5996 (if approved)		Updates: RFC 5996 (if approved) Opus One
	Intended status: Standards Track		Intended status: Standards Track May 7, 2014
	Expires: September 29, 2014		Expires: November 8, 2014
	Signature Authentication in IKEv2		Signature Authentication in IKEv2
	draft-kivinen-ipsecme-signature-auth-05.txt		draft-kivinen-ipsecme-signature-auth-06.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 version 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 a fixed hash algorithm tied to each group. This
	document generalizes the IKEv2 signature support so it can support		document generalizes IKEv2 signature support to allow any signature
	any signature method supported by the PKIX and also adds signature		method supported by the PKIX and also adds signature hash algorithm
	hash algorithm negotiation. This is generic mechanism, and is not		negotiation. This is a generic mechanism, and is not limited to
	limited to ECDSA, but can also be used with other signature		ECDSA, but can also be used with other signature algorithms.
	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 September 29, 2014.		This Internet-Draft will expire on November 8, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16		skipping to change at page 2, line 15
	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 . . . . . . . . . . . . . . . . . 7
	5. Selecting Public Key Algorithm . . . . . . . . . . . . . . . . 7		5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11		Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11
	A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 11		A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
	A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 11		A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
	A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12		A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
	A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12		A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12
	A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 12		A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
	A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12		A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
	A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13		A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13
	A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13		A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13		A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
	A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13		A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
	A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14		A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14
	A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14		A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14
	A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14		A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 15
	A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14		A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 15
	A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15		A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15
	A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 15		A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16
	Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16		Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16
	B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 16		B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document adds new IKEv2 ([RFC5996]) authentication method to		This document adds a new IKEv2 ([RFC5996]) authentication method to
	support all kinds of signature methods. The current signature based		support signature methods in a more general way. The current
	authentication methods in the IKEv2 are per algorithm, i.e. there is		signature-based authentication methods in IKEv2 are per-algorithm,
	one for RSA Digital signatures, one for DSS Digital Signatures (using		i.e. there is one for RSA digital signatures, one for DSS digital
	SHA-1) and three for different ECDSA curves each tied to exactly one		signatures (using SHA-1) and three for different ECDSA curves, each
	hash algorithm. This design starts to be cumbersome when more		tied to exactly one hash algorithm. This design is cumbersome when
	signature algorithms, hash algorithms and elliptic curves are to be		more signature algorithms, hash algorithms and elliptic curves need
	supported:		to be supported:
	o The RSA Digital Signatures format in the IKEv2 is specified to use		o The RSA digital signature format in IKEv2 is specified to use
	RSASSA-PKCS1-v1_5 padding, but Additional RSA Algorithms and		RSASSA-PKCS1-v1_5 padding, but "Additional Algorithms and
	Identifiers for X.509 document recommends the use of the newer		Identifiers for RSA Cryptography for use in PKIX Profile"
	RSASSA_PSS (See section 5 of [RFC4055]) instead.		([RFC4055])) recommends the use of the newer RSASSA_PSS (See
			section 5 of [RFC4055]) instead.
	o With ECDSA and DSS there is no way to extract the hash algorithm		o With ECDSA and DSS there is no way to extract the hash algorithm
	from the signature, thus, for each new hash function to be		from the signature. Thus, for each new hash function to be
	supported with ECDSA or DSA new authentication methods would be		supported with ECDSA or DSA, new authentication methods would be
	needed. Support for new hash functions is particularly needed for		needed. Support for new hash functions is particularly needed for
	DSS because the current restriction to SHA-1 limits its security,		DSS because the current restriction to SHA-1 limits its security,
	meaning there is no point of using long keys with it.		meaning there is no point of using long keys with SHA-1.
	o The tying of ECDSA authentication methods to particular elliptic		o The tying of ECDSA authentication methods to particular elliptic
	curve groups requires definition of additional methods for each		curve groups requires definition of additional methods for each
	new group. By combination of new ECDSA groups with various hash		new group. The combination of new ECDSA groups and hash functions
	functions the number of required authentication methods may grow		will cause the number of required authentication methods to become
	unmanageable. Furthermore, the restriction of ECDSA		unmanageable. Furthermore, the restriction of ECDSA
	authentication to a specific group is inconsistent with the		authentication to a specific group is inconsistent with the
	approach taken with DSS.		approach taken with DSS.
	With the selection of SHA-3, it is seen that it might be possible		With the selection of SHA-3, it might be possible that a signature
	that in the future the signature methods are used with SHA-3 also,		method can be used with either SHA-3 or SHA-2. This means that a new
	not only SHA-2. This means new mechanism for negotiating the hash		mechanism for negotiating the hash algorithm for a signature
	algorithm for the signature algorithms is needed.		algorithm is needed.
	This documents specifies two things, one is one new authentication		This document specifies two things:
	method, which includes enough information inside the Authentication
	payload data that the signature hash algorithm can be extracted from
	there (see Section 3). The another thing is to add indication of
	supported signature hash algorithms by the peer (see Section 4).
	This allows peer to know which hash algorithms are supported by the
	other end and use one of them (provided one is allowed by policy).
	There is no need to actually negotiate one common hash algorithm, as
	different hash algorithms can be used in different directions if
	needed.
	The new digital signature method needs to be flexible enough to		1. A new authentication method which includes enough information
	include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS,		inside the Authentication payload data so that the signature hash
	etc), and also allow adding new things in the future (ECGDSA, ElGamal		algorithm can be extracted (see Section 3).
	etc). For this the signature algorithm is specified in the same way		2. A method to indicate supported signature hash algorithms (see
	as the PKIX ([RFC5280]) specifies the signature of the Certificate,		Section 4). This allows the peer to know which hash algorithms
	i.e. there is simple ASN.1 object before the actual signature data.		are supported by the other end and use one of them (provided one
	This ASN.1 object contains the OID specifying the algorithm, and		is allowed by policy). There is no requirement to actually
	associated parameters to it. In normal case the IKEv2		negotiate one common hash algorithm, as different hash algorithms
	implementations supports fixed amount of signature methods, with		can be used in different directions if needed.
	commonly used parameters, so it is acceptable for the implementation
	to just treat this ASN.1 object as binary blob which is compared		The new digital signature method is flexible enough to include all
	against the known values, or the implementation can parse the ASN.1		current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.), and
	and extract information from there.		add new methods (ECGDSA, ElGamal, etc.) in the future. To support
			this flexibility, the signature algorithm is specified in the same
			way that PKIX ([RFC5280]) specifies the signature of the Digital
			Certificate, by placing a simple ASN.1 object before the actual
			signature data. This ASN.1 object contains an OID specifying the
			algorithm and associated parameters. When an IKEv2 implementation
			supports a fixed set of signature methods with commonly used
			parameters, it is acceptable for the implementation to treat the
			ASN.1 object as a binary blob which can be compared against the fixed
			set of known values. IKEv2 implementations can also parse the ASN.1
			and extract the signature algorithm and associated parameters.
	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 a new "Digital Signature" authentication
	method. This method can be used with any types of signatures. As		method. This method can be used with any type of signature. As the
	the authentication methods are not negotiated in the IKEv2, the peer		authentication methods are not negotiated in IKEv2, the peer is only
	is only allowed to use this authentication method if the		allowed to use this authentication method if the Notify payload of
	SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received.		type SIGNATURE_HASH_ALGORITHMS has been sent and received by each
			peer.
	In this newly defined authentication method, the Authentication Data		In this authentication method, the Authentication Data field inside
	field inside the Authentication Payload does not include only the		the Authentication Payload does not just include the signature value,
	signature value, but instead the signature value is prefixed with the		as do other existing IKEv2 Authentication Payloads. Instead, the
	ASN.1 object containing the algorithm used to generate the signature.		signature value is prefixed with an ASN.1 object indicating the
	The ASN.1 object contains the algorithm identification OID, and this		algorithm used to generate the signature. The ASN.1 object contains
	OID identifies both the signature algorithm and the hash used when		the algorithm identification OID, which identifies both the signature
	calculating the signature. In addition to the OID there is optional		algorithm and the hash used when calculating the signature. In
	parameters which might be needed for algorithms like RSASSA-PSS.		addition to the OID, the ASN.1 object can contain optional parameters
			which might be needed for algorithms such as RSASSA-PSS (Section 8.1
			of [RFC3447]).
	To make implementations easier, the ASN.1 object is prefixed by the		To make implementations easier, the ASN.1 object is prefixed by the
	8-bit length field. This length field allows simple implementations		8-bit length field. This length field allows simple implementations
	to be able to know the length of the ASN.1 without the need to parse		to know the length of the ASN.1 object without the need to parse it,
	it, so they can use it as binary blob which is compared against the		so they can use it as a binary blob to be compared against known
	known signature algorithm ASN.1 objects, i.e. they do not need to be		signature algorithm ASN.1 objects. Thus, simple implementations may
	able to parse or generate ASN.1 objects. See Appendix A for commonly		not need to be able to parse or generate ASN.1 objects. See
	used ASN.1 objects.		Appendix A for commonly used ASN.1 objects.
	The ASN.1 used here is the same ASN.1 which is used in the		The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier
	AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280])		of PKIX (Section 4.1.1.2 of [RFC5280]), encoded using distinguished
	encoded using distinguished encoding rules (DER) [CCITT.X690.2002].		encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the
	The algorithm OID inside the ASN.1 specifies the signature algorithm		ASN.1 specifies the signature algorithm and the hash function, both
	and the hash function, which are needed for signature verification.		of which are needed for signature verification.
	The EC curve is always known by the peer because it needs to have the
	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		Currently, only the RSASSA-PSS signature algorithm uses the optional
	parameters is either NULL or missing. Note, that for some algorithms		parameters. For other signature algorithms, the parameters are
	there is two possible ASN.1 encoding possible, one with parameters		either NULL or missing. Note, that for some algorithms there are two
	being NULL and others where the whole parameters is omitted. This is		possible ASN.1 encodings, one with optional parameters included but
	because some of those algorithms are specified that way. When		set to NULL and the other where the optional parameters are omitted.
	encoding the ASN.1 implementations should use the preferred way, i.e.		These dual encodings exist because of the way those algorithms are
	if the algorithm specification says "preferredPresent" then parameter		specified. When encoding the ASN.1, implementations SHOULD use the
	object needs to be there (i.e. it will be NULL if no parameters is		preferred format called for by the algorithm specification. If the
	specified), and if it says "preferredAbsent", then the whole		algorithm specification says "preferredPresent" then the parameters
	parameters object is missing.		object needs to be present, although it will be NULL if no parameters
			are specified. If the algorithm specification says
			"preferredAbsent", then the entire optional 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 42		skipping to change at page 6, line 8
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Authentication Payload Format.		Figure 1: Authentication Payload Format.
	o Auth Method (1 octet) - Specifies the method of authentication		o Auth Method (1 octet) - Specifies the method of authentication
	used.		used.
	Mechanism Value		Mechanism Value
	-----------------------------------------------------------------		-----------------------------------------------------------------
	Digital Signature <TBD>		Digital Signature <TBD>
	Computed as specified in Section 2.15 of RFC5996 using a		Computed as specified in Section 2.15 of RFC5996 using a
	private key associated with the public key sent in certificate		private key associated with the public key sent in the
	payload, and using one of the hash algorithms sent by the other		Certificate payload, and using one of the hash algorithms
	end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both		sent by the other end in the Notify payload of type
	ends send and receive SIGNATURE_HASH_ALGORITHMS and signature		SIGNATURE_HASH_ALGORITHMS. If both ends send and receive
	authentication is to be used, then this method MUST be used.		SIGNATURE_HASH_ALGORITHMS Notify payloads and signature
	The Authentication Data field has bit different format than in		authentication is to be used, then the authentication
	other Authentication methods (see below).		method specified in this Authentication payload MUST be
			used. The format of the Authentication Data field is
			different from other Authentication methods and is
			specified 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:		is formatted 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ASN.1 Length | AlgorithmIdentifier ASN.1 object |		| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ AlgorithmIdentifier ASN.1 object continuing ~		~ AlgorithmIdentifier ASN.1 object continuing ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Signature Value ~		~ Signature Value ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Authentication Data Format.		Figure 2: Authentication Data Format.
	Where the ASN.1 Length is the length of the ASN.1 encoded		* ASN.1 Length (1 octet) - This field contains the length of the
	AlgorithmIdentifier object, and after that is the actual		ASN.1 encoded AlgorithmIdentifier object.
	AlgorithmIdentifier ASN.1 object, followed by the actual signature		* Algorithm Identifier (variable length) - This field contains
	value. There is no padding between ASN.1 object and signature		the AlgorithmIdentifier ASN.1 object.
	value. For the hash truncation the method of X9.62 ([X9.62]) MUST		* Signature Value (variable length) - This field contains the
	be used.		actual signature value.
			There is no padding between ASN.1 object and signature value. For
			hash truncation, the method specified in ANSI X9.62:2005 ([X9.62])
			MUST be used.
	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 indicated with a Notify payload of type
	Notification Payload sent inside the IKE_SA_INIT exchange. This		SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
	notification also indicates the support of the new signature
	algorithm method, i.e. sending this notification tells that new		This notification also implicitly indicates support of the new
	"Digital Signature" authentication method is supported and that		"Digital Signature" algorithm method, as well as the list of hash
	following hash functions are supported by sending peer. Both ends		functions supported by the sending peer.
	sends their list of supported hash-algorithms and when calculating
	signature a peer MUST pick one algorithm sent by the other peer.		Both ends send their list of supported hash algorithms. When
	Note, that different algorithms can be used in different directions.		calculating the digital signature, a peer MUST pick one algorithm
	The algorithm OID matching selected hash algorithm (and signature		sent by the other peer. Note that different algorithms can be used
	algorithm) used when calculating the signature is sent inside the		in different directions. The algorithm OID indicating the selected
	Authentication Data field of the Authentication Payload.		hash algorithm (and signature algorithm) used when calculating the
			signature is sent inside the Authentication Data field of the
			Authentication payload (with Auth Method of "Digital Signature" as
			defined above).
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol ID | SPI Size | Notify Message Type |		| Protocol ID | SPI Size | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Security Parameter Index (SPI) ~		~ Security Parameter Index (SPI) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Notification Data ~		~ Notification Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Notify Payload Format.		Figure 3: Notify Payload Format.
	Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from		The Notify payload format is defined in RFC5996 section 3.10. When a
	status types>. The Notification Data value contains list of 16-bit		Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the
	hash algorithm identifiers from the newly created Hash Algorithm		Protocol ID field is set to 0, the SPI Size is set to 0, and the
	Identifiers for the IKEv2 IANA registry.		Notify Message Type is set to <TBD from status types>.
	5. Selecting Public Key Algorithm		The Notification Data field contains the list of 16-bit hash
			algorithm identifiers from the Hash Algorithm Identifiers for the
			IKEv2 IANA registry. There is no padding between the hash algorithm
			identifiers.
			5. Selecting the Public Key Algorithm
	This specification does not provide a way for the peers to indicate		This specification does not provide a way for the peers to indicate
	the public / private key pair types they have. I.e. how can the		the public / private key pair types they have. This raises the
	responder select public / private key pair type that the initiator		question of how the responder selects a public / private key pair
	supports. There is already several ways this information can be		type that the initiator supports. This information can be found by
	found in common cases.		several methods.
	One of the ways to find out which key the initiator wants the		One method to signal the key the initiator wants the responder to use
	responder to use is to indicate that in the IDr payload of the		is to indicate that in the IDr payload of the IKE_AUTH request sent
	IKE_AUTH request of the initiator. I.e initiator indicates that it		by the initiator. In this case, the initiator indicates that it
	wants the responder to use certain public / private key pair by		wants the responder to use a particular public / private key pair by
	sending IDr which indicates that information. This means the		sending an IDr payload which indicates that information. In this
	responder needs to have different identities configured and each of		case, the responder has different identities configured, with each of
	those identities needs to be tied up to certain public / private key		those identities associated to a public / private key or key type.
	(or key type).
	Another way to get this information is from the Certificate Request		Another method to ascertain the key the initiator wants the responder
	payload sent by the initiator. For example if the initiator		to use is through a Certificate Request payload sent by the
	indicates in his Certificate Request payload that it trust CA which		initiator. For example, the initiator could indicate in the
	is signed by the ECDSA key, that will also indicate it can be process		Certificate Request payload that it trusts a CA signed by an ECDSA
	ECDSA signatures, thus responder can safely use ECDSA keys when		key. This indication implies that the initiator can process ECDSA
	authenticating himself.		signatures, which means that the responder can safely use ECDSA keys
			when authenticating.
	Responder can also check the key type used by the initiator, and use		A third method is for the responder to check the key type used by the
	same key type than the initiator used. This does not work in case		initiator, and use same key type that the initiator used. This
	the initiator is using shared secret or EAP authentication, as in		method does not work if the initiator is using shared secret or EAP
	that case it is not using public key. If initiator is using public		authentication (i.e., is not using public keys). If the initiator is
	key authentication himself this is most likely the best way for the		using public key authentication, this method is the best way for the
	responder to find the type the initiator supports.		responder to ascertain the type of key the initiator supports.
	In case the initiator uses a public key type that the responder will		If the initiator uses a public key type that the responder does not
	not support, the responder will reply with AUTHENTICATION_FAILED		support, the responder replies with a Notify message with error type
	error. If initiator has multiple different keys it can try different		AUTHENTICATION_FAILED. If the initiator has multiple different keys,
	key (and perhaps different key type) until it finds key that the		it may try a different key (and perhaps a different key type) until
	other end accepts. Initiator can also use the Certificate Request		it finds a key that the other end accepts. The initiator can also
	payload sent by the responder to help deciding which public key		use the Certificate Request payload sent by the responder to help
	should be tried. In normal case if initiator has multiple public		decide which public key should be tried. In normal cases, when the
	keys, there is configuration that will select one of those for each		initiator has multiple public keys, out-of-band configuration is used
	connection, so the proper key is know by configuration.		to select a public key for each connection.
	6. Security Considerations		6. Security Considerations
	The "Recommendations for Key Management" ([NIST800-57]) table 2		The "Recommendations for Key Management" ([NIST800-57]) table 2
	combined with table 3 gives recommendations for how to select		combined with table 3 gives recommendations for how to select
	suitable hash functions for the signature.		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 Elliptic Curve to
	specific hash function, which was done in the old IKEv2 ECDSA		a 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 mix different security levels.
	SHA1, i.e. this allows mixing different security levels. This means		For example, it is possible to use 512-bit Elliptic Curve with SHA1.
	that the security of the authentication method is the security of the		This means that the security of the authentication method is the
	weakest of components (signature algorithm, hash algorithm, curve).		security of the weakest component (signature algorithm, hash
	This might make the security analysis of the system bit more complex.		algorithm, or curve). This complicates the security analysis of the
	Note, that this kind of mixing of the security can be disallowed by		system. Note that this kind of mixing of security levels can be
	the policy.		disallowed by policy.
	The hash algorithm registry does not include MD5 as supported hash		The hash algorithm registry does not include MD5 as a 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]).		([WY05]).
	The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems		The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known
	([KA08], [ME01]) and does not allow using newer padding methods like		security vulnerabilities ([KA08], [ME01]) and does not allow using
	RSASSA-PSS. This new method allows using other padding methods.		newer padding methods such as RSASSA-PSS. The new method described
			in this RFC allows using other padding methods.
	The current IKEv2 only allows using normal DSA with SHA-1, which		The current IKEv2 protocol only allows use of normal DSA with SHA-1,
	means the security of the regular DSA is limited to the security of		which means the security of the authentication is limited to the
	SHA-1. This new methods allows using longer keys and longer hashes		security of SHA-1. This new method allows using longer keys and
	with DSA.		longer hashes with DSA.
	7. IANA Considerations		7. IANA Considerations
	This document creates new IANA registry for IKEv2 Hash Algorithms.		This document creates a new IANA registry for IKEv2 Hash Algorithms.
	Changes and additions to this registry is by expert review.		Changes and additions to this registry are by expert review.
	The initial values of this registry is:		The initial values of this registry are:
	Hash Algorithm Value		Hash Algorithm Value
	-------------- -----		-------------- -----
	RESERVED 0		RESERVED 0
	SHA1 1		SHA1 1
	SHA2-256 2		SHA2-256 2
	SHA2-384 3		SHA2-384 3
	SHA2-512 4		SHA2-512 4
	MD5 is not included to the hash algorithm list as it is not		MD5 is not included in the hash algorithm list as it is not
	considered safe enough for signature hash uses.		considered safe enough for signature hash uses.
	Values 5-1023 are reserved to IANA. Values 1024-65535 are for		Values 5-1023 are reserved to IANA. Values 1024-65535 are for
	private use among mutually consenting parties.		private use among mutually consenting parties.
	This specification also allocates one new IKEv2 Notify Message Types		This specification also adds one new "IKEv2 Notify Message Types -
	- Status Types value for the SIGNATURE_HASH_ALGORITHMS, and adds new		Status Types" value for SIGNATURE_HASH_ALGORITHMS, and adds one new
	value "Digital Signature" to the IKEv2 Authentication Method		"IKEv2 Authentication Method" value for "Digital Signature".
	registry.
	8. Acknowledgements		8. Acknowledgements
	Most of this work was based on the work done in the IPsecME design		Most of this work was based on the work done in the IPsecME design
	team for the ECDSA. The design team members were: Dan Harking,		team for the ECDSA. The design team members were: Dan Harkins,
	Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.		Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
	9. References		9. References
	9.1. Normative References		9.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.,
	skipping to change at page 10, line 33		skipping to change at page 11, line 10
	[NIST800-57]		[NIST800-57]
	Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,		Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
	"Recommendations for Key Management", NIST SP 800-57,		"Recommendations for Key Management", NIST SP 800-57,
	March 2007.		March 2007.
	[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and		[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
	Identifiers for the Internet X.509 Public Key		Identifiers for the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 3279, April 2002.		(CRL) Profile", RFC 3279, April 2002.
			[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
			Standards (PKCS) #1: RSA Cryptography Specifications
			Version 2.1", RFC 3447, February 2003.
	[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.
	skipping to change at page 11, line 17		skipping to change at page 11, line 45
	in Computer Science Vol. 3494, 2005.		in Computer Science Vol. 3494, 2005.
	[X9.62] American National Standards Institute, "Public Key		[X9.62] American National Standards Institute, "Public Key
	Cryptography for the Financial Services Industry: The		Cryptography for the Financial Services Industry: The
	Elliptic Curve Digital Signature Algorithm (ECDSA)",		Elliptic Curve Digital Signature Algorithm (ECDSA)",
	ANSI X9.62, November 2005.		ANSI X9.62, November 2005.
	Appendix A. Commonly used ASN.1 objects		Appendix A. Commonly used ASN.1 objects
	This section lists commonly used ASN.1 objects in binary form. This		This section lists commonly used ASN.1 objects in binary form. This
	section is not-normative, and these values should only be used as		section is not normative, and these values should only be used as
	examples, i.e. if this and the actual specification of the algorithm		examples. If the ASN.1 object listed in Appendix A and the ASN.1
	ASN.1 object is different the actual format specified in the actual		object specified by the algorithm differ, then the algorithm
	specification needs to be used. These values are taken from the New		specification must be used. These values are taken from "New ASN.1
	ASN.1 Modules for the Public Key Infrastructure Using X.509		Modules for the Public Key Infrastructure Using X.509 (PKIX)"
	([RFC5912]).		([RFC5912]).
	A.1. PKCS#1 1.5 RSA Encryption		A.1. PKCS#1 1.5 RSA Encryption
	These algorithm identifiers here include several different ASN.1		The algorithm identifiers here include several different ASN.1
	objects with different hash algorithms. In this document we only		objects with different hash algorithms. This document only includes
	include the commonly used ones i.e. the one using SHA-1, or SHA-2 as		the commonly used ones, i.e. the ones using SHA-1 or SHA-2 as hash
	hash function. Some of those other algorithms (MD2, MD5) specified		function. Some other algorithms (such as MD2 and MD5) are not safe
	for this are not safe enough to be used as signature hash algorithm,		enough to be used as signature hash algorithms, and are omitted. The
	and some are omitted as there is no hash algorithm specified in the		IANA registry does not have code points for these other algorithms
	our IANA registry for them. Note, that there is no parameters in any		with RSA Encryption. Note that there are no optional parameters in
	of these, but all specified here needs to have NULL parameters		any of these algorithm identifiers, but all included here need NULL
	present in the ASN.1.		optional parameters present in the ASN.1.
	See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and		See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and
	Additional Algorithms and Identifiers for RSA Cryptography for PKIX		"Additional Algorithms and Identifiers for RSA Cryptography for use
	Profile ([RFC4055]) for more information.		in PKIX Profile" ([RFC4055]) for more information.
	A.1.1. sha1WithRSAEncryption		A.1.1. sha1WithRSAEncryption
	sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)		sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }		us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5		Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
	Length = 15		Length = 15
	skipping to change at page 12, line 37		skipping to change at page 13, line 17
	sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }		sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
	Parameters are required, and they must be NULL.		Parameters are required, and they must be NULL.
	Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13		Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
	Length = 15		Length = 15
	0000: 300d 0609 2a86 4886 f70d 0101 0d05 00		0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
	A.2. DSA		A.2. DSA
	With different DSA algorithms the parameters are always omitted.		With DSA algorithms, optional parameters are always omitted. Only
	Again we omit dsa-with-sha224 as there is no hash algorithm in our		algorithm combinations for DSA listed in the IANA registry are
	IANA registry for it.		included.
	See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX		See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and
	Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758]		"PKIX Additional Algorithms and Identifiers for DSA and ECDSA"
	for more information.		([RFC5758] for more information.
	A.2.1. dsa-with-sha1		A.2.1. dsa-with-sha1
	dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	x9-57(10040) x9algorithm(4) 3 }		x9-57(10040) x9algorithm(4) 3 }
	Parameters are absent.		Parameters are absent.
	Name = dsa-with-sha1, oid = 1.2.840.10040.4.3		Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
	Length = 11		Length = 11
	skipping to change at page 13, line 23		skipping to change at page 13, line 50
	id-dsa-with-sha2(3) 2 }		id-dsa-with-sha2(3) 2 }
	Parameters are absent.		Parameters are absent.
	Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2		Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
	Length = 13		Length = 13
	0000: 300b 0609 6086 4801 6503 0403 02		0000: 300b 0609 6086 4801 6503 0403 02
	A.3. ECDSA		A.3. ECDSA
	With different ECDSA algorithms the parameters are always omitted.		With ECDSA algorithms, the optional parameters are always omitted.
	Again we omit ecdsa-with-sha224 as there is no hash algorithm in our		Only algorithm combinations for ECDSA listed in the IANA registry are
	IANA registry for it.		included.
	See Elliptic Curve Cryptography Subject Public Key Information		See "Elliptic Curve Cryptography Subject Public Key Information"
	([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279])		([RFC5480]), "Algorithms and Identifiers for PKIX Profile"
	and PKIX Additional Algorithms and Identifiers for DSA and ECDSA		([RFC3279]) and "PKIX Additional Algorithms and Identifiers for DSA
	([RFC5758] for more information.		and ECDSA" ([RFC5758] for more information.
	A.3.1. ecdsa-with-sha1		A.3.1. ecdsa-with-sha1
	ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	ansi-X9-62(10045) signatures(4) 1 }		ansi-X9-62(10045) signatures(4) 1 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1		Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
	Length = 11		Length = 11
	skipping to change at page 14, line 29		skipping to change at page 15, line 7
	us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }		us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
	Parameters are absent.		Parameters are absent.
	Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4		Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
	Length = 12		Length = 12
	0000: 300a 0608 2a86 48ce 3d04 0304		0000: 300a 0608 2a86 48ce 3d04 0304
	A.4. RSASSA-PSS		A.4. RSASSA-PSS
	With the RSASSA-PSS the algorithm object identifier is always id-		With RSASSA-PSS, the algorithm object identifier is always id-RSASSA-
	RSASSA-PSS, but the hash function is taken from the parameters, and		PSS, but the hash function is taken from the optional parameters, and
	it is required. See [RFC4055] for more information.		is required. See [RFC4055] for more information.
	A.4.1. RSASSA-PSS with empty parameters		A.4.1. RSASSA-PSS with empty parameters
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	Parameters are empty, but the ASN.1 part of the sequence must be		Parameters are empty, but the ASN.1 part of the sequence must be
	there. This means default parameters are used (same as the next		there. This means default parameters are used (same as the next
	example).		example).
	0000 : SEQUENCE		0000 : SEQUENCE
	0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)		0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
	000d : SEQUENCE		000d : SEQUENCE
	Length = 15		Length = 15
	0000: 300d 0609 2a86 4886 f70d 0101 0a30 00		0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
	A.4.2. RSASSA-PSS with default parameters		A.4.2. RSASSA-PSS with default parameters
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	Here the parameters are present, and contains the default parameters,		Here the parameters are present, and contain the default parameters,
	i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1.		i.e. hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength
			of 20, trailerField of 1.
	0000 : SEQUENCE		0000 : SEQUENCE
	0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)		0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
	000d : SEQUENCE		000d : SEQUENCE
	000f : CONTEXT 0		000f : CONTEXT 0
	0011 : SEQUENCE		0011 : SEQUENCE
	0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)		0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
	001a : NULL		001a : NULL
	001c : CONTEXT 1		001c : CONTEXT 1
	001e : SEQUENCE		001e : SEQUENCE
	0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8		0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
	002b : SEQUENCE		002b : SEQUENCE
	002d : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26)		002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
	0034 : NULL		0034 : NULL
	0036 : CONTEXT 2		0036 : CONTEXT 2
	0038 : INTEGER 0x14 (5 bits)		0038 : INTEGER 0x14 (5 bits)
	003b : CONTEXT 3		003b : CONTEXT 3
	003d : INTEGER 0x1 (1 bits)		003d : INTEGER 0x1 (1 bits)
	Name = RSASSA-PSS with default parameters,		Name = RSASSA-PSS with default parameters,
	oid = 1.2.840.113549.1.1.10		oid = 1.2.840.113549.1.1.10
	Length = 64		Length = 64
	0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0		0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
	0010: 0b30 0906 052b 0e03 021a 0500 a118 3016		0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
	0020: 0609 2a86 4886 f70d 0101 0830 0906 052b		0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
	0030: 0e03 021a 0500 a203 0201 14a3 0302 0101		0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
	A.4.3. RSASSA-PSS with SHA-256		A.4.3. RSASSA-PSS with SHA-256
	skipping to change at page 15, line 42		skipping to change at page 16, line 16
	Length = 64		Length = 64
	0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0		0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
	0010: 0b30 0906 052b 0e03 021a 0500 a118 3016		0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
	0020: 0609 2a86 4886 f70d 0101 0830 0906 052b		0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
	0030: 0e03 021a 0500 a203 0201 14a3 0302 0101		0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
	A.4.3. RSASSA-PSS with SHA-256		A.4.3. RSASSA-PSS with SHA-256
	id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }		id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
	Here the parameters are present, and contains the SHA-256 for both		Here the parameters are present, and contain hashAlgorithm of SHA-
	the hash and mgf, saltlength of 32, and trailerfield of 1.		256, maskGenAlgorithm of SHA-256, saltLength of 32, trailerField of
			1.
	0000 : SEQUENCE		0000 : SEQUENCE
	0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)		0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
	000d : SEQUENCE		000d : SEQUENCE
	000f : CONTEXT 0		000f : CONTEXT 0
	0011 : SEQUENCE		0011 : SEQUENCE
	0013 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1)		0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
	001e : NULL		001e : NULL
	0020 : CONTEXT 1		0020 : CONTEXT 1
	0022 : SEQUENCE		0022 : SEQUENCE
	0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8		0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
	002f : SEQUENCE		002f : SEQUENCE
	0031 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1)		0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
	003c : NULL		003c : NULL
	003e : CONTEXT 2		003e : CONTEXT 2
	0040 : INTEGER 0x20 (6 bits)		0040 : INTEGER 0x20 (6 bits)
	0043 : CONTEXT 3		0043 : CONTEXT 3
	0045 : INTEGER 0x1 (1 bits)		0045 : INTEGER 0x1 (1 bits)
	Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10		Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
	Length = 72		Length = 72
	0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0		0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
	0010: 0f30 0d06 0960 8648 0165 0304 0201 0500		0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
	skipping to change at page 16, line 32		skipping to change at page 17, line 4
	Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10		Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
	Length = 72		Length = 72
	0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0		0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
	0010: 0f30 0d06 0960 8648 0165 0304 0201 0500		0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
	0020: a11c 301a 0609 2a86 4886 f70d 0101 0830		0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
	0030: 0d06 0960 8648 0165 0304 0201 0500 a203		0030: 0d06 0960 8648 0165 0304 0201 0500 a203
	0040: 0201 20a3 0302 0101		0040: 0201 20a3 0302 0101
	Appendix B. IKEv2 Payload Example		Appendix B. IKEv2 Payload Example
	B.1. sha1WithRSAEncryption		B.1. sha1WithRSAEncryption
	The IKEv2 AUTH payload would start like this:		The IKEv2 AUTH payload would start like this:
	00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648		00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648
	00000010: 86f7 0d01 0105 0500 ....		00000010: 86f7 0d01 0105 0500 ....
	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. the value depends on
	on what is the next payload after this Authentication payload), the		the next payload after this Authentication payload), the LL will be
	LL will be the length of this payload, and after the		the length of this payload, and after the sha1WithRSAEncryption ASN.1
	sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual		block (15 bytes) there will be the actual signature, which is omitted
	signature, which is omitted here.		here.
	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 authentication method type for Digital Signature, and		allocated authentication method type for Digital Signature, and
	remove this note.		remove this note.
	Author's Address		Authors' Addresses
	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
			Joel Snyder
			Opus One
			1404 East Lind Road
			Tucson, AZ 85719
			Phone: +1 520 324 0494
			Email: jms@opus1.com
End of changes. 66 change blocks.
	249 lines changed or deleted		272 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/