draft-kivinen-ipsecme-signature-auth-07.txt   rfc7427.txt 
IP Security Maintenance and Extensions T. Kivinen Internet Engineering Task Force (IETF) T. Kivinen
(ipsecme) INSIDE Secure Request for Comments: 7427 INSIDE Secure
Internet-Draft J. Snyder Updates: 7296 J. Snyder
Updates: RFC 5996 (if approved) Opus One Category: Standards Track Opus One
Intended status: Standards Track July 21, 2014 ISSN: 2070-1721 January 2015
Expires: January 22, 2015
Signature Authentication in IKEv2 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
draft-kivinen-ipsecme-signature-auth-07.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 a fixed hash algorithm tied to each group. This groups, and there is a fixed hash algorithm tied to each group. This
document generalizes IKEv2 signature support to allow any signature document generalizes IKEv2 signature support to allow any signature
method supported by the PKIX and also adds signature hash algorithm method supported by PKIX and also adds signature hash algorithm
negotiation. This is a generic mechanism, and is not limited to negotiation. This is a generic mechanism and is not limited to
ECDSA, but can also be used with other signature algorithms. ECDSA; it can also be used with other signature algorithms.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 22, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7427.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Payload . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 7 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8 5. Selecting the Public Key Algorithm . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Commonly Used ASN.1 Objects . . . . . . . . . . . . 12
Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 12 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 13 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 15
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 15 A.4.1. RSASSA-PSS with Empty Parameters . . . . . . . . . . 15
A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 15 A.4.2. RSASSA-PSS with Default Parameters . . . . . . . . . 16
A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 16 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 17
A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . 17
Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 17 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document adds a new IKEv2 ([RFC5996]) authentication method to This document adds a new IKEv2 [RFC7296] authentication method to
support signature methods in a more general way. The current support signature methods in a more general way. The current
signature-based authentication methods in IKEv2 are per-algorithm, signature-based authentication methods in IKEv2 are per algorithm,
i.e. there is one for RSA digital signatures, one for DSS digital i.e., there is one for RSA digital signatures, one for DSS digital
signatures (using SHA-1) and three for different ECDSA curves, each signatures (using SHA-1), and three for different ECDSA curves, each
tied to exactly one hash algorithm. This design is cumbersome when tied to exactly one hash algorithm. This design is cumbersome when
more signature algorithms, hash algorithms and elliptic curves need more signature algorithms, hash algorithms, and elliptic curves need
to be supported: to be supported:
o In IKEv2, authentication using RSA digital signatures calls for o In IKEv2, authentication using RSA digital signatures calls for
padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA_PSS padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS
padding method is now recommended. (See section 5 of "Additional padding method is now recommended. (See Section 5 of "Additional
Algorithms and Identifiers for RSA Cryptography for use in PKIX Algorithms and Identifiers for RSA Cryptography for use in PKIX
Profile" [RFC4055]). Profile" [RFC4055].)
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 o With ECDSA and the Digital Signature Standard (DSS), there is no
supported with ECDSA or DSA, new authentication methods would be way to extract the hash algorithm from the signature. Thus, for
needed. Support for new hash functions is particularly needed for each new hash function to be supported with ECDSA or DSA, new
DSS because the current restriction to SHA-1 limits its security, authentication methods would be needed. Support for new hash
meaning there is no point of using long keys with SHA-1. functions is particularly needed for DSS, because the current
restriction to SHA-1 limits its security, 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. The combination of new ECDSA groups and hash functions new group. The combination of new ECDSA groups and hash functions
will cause the number of required authentication methods to become 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 might be possible that a signature With the selection of SHA-3, it might be possible that a signature
method can be used with either SHA-3 or SHA-2. This means that a new method can be used with either SHA-3 or SHA-2. This means that a new
mechanism for negotiating the hash algorithm for a signature mechanism for negotiating the hash algorithm for a signature
algorithm is needed. algorithm is needed.
This document specifies two things: This document specifies two things:
1. A new authentication method which includes enough information 1. A new authentication method that includes enough information
inside the Authentication payload data so that the signature hash inside the Authentication payload data so the signature hash
algorithm can be extracted (see Section 3). algorithm can be extracted (see Section 3).
2. A method to indicate supported signature hash algorithms (see 2. A method to indicate supported signature hash algorithms (see
Section 4). This allows the peer to know which hash algorithms Section 4). This allows the peer to know which hash algorithms
are supported by the other end and use one of them (provided one are supported by the other end and use one of them (provided one
is allowed by policy). There is no requirement to actually is allowed by policy). There is no requirement to actually
negotiate one common hash algorithm, as different hash algorithms negotiate one common hash algorithm, as different hash algorithms
can be used in different directions if needed. can be used in different directions if needed.
The new digital signature method is flexible enough to include all The new digital signature method is flexible enough to include all
current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.), and current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add
add new methods (ECGDSA, ElGamal, etc.) in the future. To support new methods (ECGDSA, ElGamal, etc.) in the future. To support this
this flexibility, the signature algorithm is specified in the same flexibility, the signature algorithm is specified in the same way
way that PKIX ([RFC5280]) specifies the signature of the Digital that PKIX [RFC5280] specifies the signature of the Digital
Certificate, by placing a simple ASN.1 object before the actual Certificate, by placing a simple ASN.1 object before the actual
signature data. This ASN.1 object contains an OID specifying the signature data. This ASN.1 object contains an OID specifying the
algorithm and associated parameters. When an IKEv2 implementation algorithm and associated parameters. When an IKEv2 implementation
supports a fixed set of signature methods with commonly used supports a fixed set of signature methods with commonly used
parameters, it is acceptable for the implementation to treat the parameters, it is acceptable for the implementation to treat the
ASN.1 object as a binary blob which can be compared against the fixed ASN.1 object as a binary blob that can be compared against the fixed
set of known values. IKEv2 implementations can also parse the ASN.1 set of known values. IKEv2 implementations can also parse the ASN.1
and extract the signature algorithm and associated parameters. 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 a new "Digital Signature" authentication This document specifies a new "Digital Signature" authentication
method. This method can be used with any type of signature. As the method. This method can be used with any type of signature. As the
authentication methods are not negotiated in IKEv2, the peer is only authentication methods are not negotiated in IKEv2, the peer is only
allowed to use this authentication method if the Notify payload of allowed to use this authentication method if the Notify payload of
type SIGNATURE_HASH_ALGORITHMS has been sent and received by each type SIGNATURE_HASH_ALGORITHMS has been sent and received by each
peer. peer.
In this authentication method, the Authentication Data field inside In this authentication method, the Authentication Data field inside
the Authentication Payload does not just include the signature value, the Authentication payload does not just include the signature value,
as do other existing IKEv2 Authentication Payloads. Instead, the as do other existing IKEv2 Authentication payloads. Instead, the
signature value is prefixed with an ASN.1 object indicating the signature value is prefixed with an ASN.1 object indicating the
algorithm used to generate the signature. The ASN.1 object contains algorithm used to generate the signature. The ASN.1 object contains
the algorithm identification OID, which identifies both the signature the algorithm identification OID, which identifies both the signature
algorithm and the hash used when calculating the signature. In algorithm and the hash used when calculating the signature. In
addition to the OID, the ASN.1 object can contain optional parameters 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 that might be needed for algorithms such as RSASSA-PSS (see
of [RFC3447]). 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 know the length of the ASN.1 object without the need to parse it, to know the length of the ASN.1 object without the need to parse it,
so they can use it as a binary blob to be compared against known so they can use it as a binary blob to be compared against known
signature algorithm ASN.1 objects. Thus, simple implementations may signature algorithm ASN.1 objects. Thus, simple implementations may
not need to be able to parse or generate ASN.1 objects. See not need to be able to parse or generate ASN.1 objects. See
Appendix A for commonly used ASN.1 objects. Appendix A for commonly used ASN.1 objects.
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier
of PKIX (Section 4.1.1.2 of [RFC5280]), encoded using distinguished of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using
encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the distinguished encoding rules (DER) [CCITT.X690.2002]. The algorithm
ASN.1 specifies the signature algorithm and the hash function, both OID inside the ASN.1 specifies the signature algorithm and the hash
of which are needed for signature verification. function, both of which are needed for signature verification.
Currently, only the RSASSA-PSS signature algorithm uses the optional Currently, only the RSASSA-PSS signature algorithm uses the optional
parameters. For other signature algorithms, the parameters are parameters. For other signature algorithms, the parameters are
either NULL or missing. Note, that for some algorithms there are two either NULL or missing. Note that for some algorithms there are two
possible ASN.1 encodings, one with optional parameters included but possible ASN.1 encodings, one with optional parameters included but
set to NULL and the other where the optional parameters are omitted. set to NULL and the other where the optional parameters are omitted.
These dual encodings exist because of the way those algorithms are These dual encodings exist because of the way those algorithms are
specified. When encoding the ASN.1, implementations SHOULD use the specified. When encoding the ASN.1, implementations SHOULD use the
preferred format called for by the algorithm specification. If the preferred format called for by the algorithm specification. If the
algorithm specification says "preferredPresent" then the parameters algorithm specification says "preferredPresent", then the parameters
object needs to be present, although it will be NULL if no parameters object needs to be present, although it will be NULL if no parameters
are specified. If the algorithm specification says are specified. If the algorithm specification says
"preferredAbsent", then the entire optional parameters object is "preferredAbsent", then the entire optional parameters object is
missing. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Authentication Data ~ ~ Authentication Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 14
Computed as specified in Section 2.15 of RFC5996 using a Computed as specified in Section 2.15 of [RFC7296] using a private
private key associated with the public key sent in the key associated with the public key sent in the Certificate payload
Certificate payload, and using one of the hash algorithms and using one of the hash algorithms sent by the other end in the
sent by the other end in the Notify payload of type Notify payload of type SIGNATURE_HASH_ALGORITHMS. If both ends
SIGNATURE_HASH_ALGORITHMS. If both ends send and receive send and receive SIGNATURE_HASH_ALGORITHMS Notify payloads, and
SIGNATURE_HASH_ALGORITHMS Notify payloads and signature signature authentication is to be used, then the authentication
authentication is to be used, then the authentication method specified in this Authentication payload MUST be used. The
method specified in this Authentication payload MUST be format of the Authentication Data field is different from other
used. The format of the Authentication Data field is Authentication methods and is specified below.
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 [RFC7296]. For "Digital Signature" format, the Authentication
is formatted as follows: Data 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
* ASN.1 Length (1 octet) - This field contains the length of the * ASN.1 Length (1 octet) - This field contains the length of the
ASN.1 encoded AlgorithmIdentifier object. ASN.1-encoded AlgorithmIdentifier object.
* Algorithm Identifier (variable length) - This field contains * Algorithm Identifier (variable length) - This field contains
the AlgorithmIdentifier ASN.1 object. the AlgorithmIdentifier ASN.1 object.
* Signature Value (variable length) - This field contains the * Signature Value (variable length) - This field contains the
actual signature value. 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]) There is no padding between the ASN.1 object and the signature
MUST be used. 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 indicated with a Notify payload of type algorithms are indicated with a Notify payload of type
SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange. SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
This notification also implicitly indicates support of the new This notification also implicitly indicates support of the new
"Digital Signature" algorithm method, as well as the list of hash "Digital Signature" algorithm method, as well as the list of hash
functions supported by the sending peer. functions supported by the sending peer.
Both ends send their list of supported hash algorithms. When Both ends send their list of supported hash algorithms. When
calculating the digital signature, a peer MUST pick one algorithm calculating the digital signature, a peer MUST pick one algorithm
sent by the other peer. Note that different algorithms can be used sent by the other peer. Note that different algorithms can be used
in different directions. The algorithm OID indicating the selected in different directions. The algorithm OID indicating the selected
hash algorithm (and signature algorithm) used when calculating the hash algorithm (and signature algorithm) used when calculating the
signature is sent inside the Authentication Data field of the signature is sent inside the Authentication Data field of the
Authentication payload (with Auth Method of "Digital Signature" as Authentication payload (with Auth Method of "Digital Signature" as
defined above). 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
The Notify payload format is defined in RFC5996 section 3.10. When a The Notify payload format is defined in Section 3.10 of [RFC7296].
Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the When a Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the
Protocol ID field is set to 0, the SPI Size is set to 0, and the Protocol ID field is set to 0, the SPI Size is set to 0, and the
Notify Message Type is set to <TBD from status types>. Notify Message Type is set to 16431.
The Notification Data field contains the list of 16-bit hash The Notification Data field contains the list of 16-bit hash
algorithm identifiers from the Hash Algorithm Identifiers for the algorithm identifiers from the Hash Algorithm Identifiers of IANA's
IKEv2 IANA registry. There is no padding between the hash algorithm "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. There
identifiers. is no padding between the hash algorithm identifiers.
5. Selecting the Public Key Algorithm 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. This raises the the public/private key pair types they have. This raises the
question of how the responder selects a public / private key pair question of how the responder selects a public/private key pair type
type that the initiator supports. This information can be found by that the initiator supports. This information can be found by
several methods. several methods.
One method to signal the key the initiator wants the responder to use One method to signal the key the initiator wants the responder to use
is to indicate that in the IDr payload of the IKE_AUTH request sent is to indicate that in the IDr (Identification - Responder) payload
by the initiator. In this case, the initiator indicates that it of the IKE_AUTH request sent by the initiator. In this case, the
wants the responder to use a particular public / private key pair by initiator indicates that it wants the responder to use a particular
sending an IDr payload which indicates that information. In this public/private key pair by sending an IDr payload that indicates that
case, the responder has different identities configured, with each of information. In this case, the responder has different identities
those identities associated to a public / private key or key type. configured, with each of those identities associated to a public/
private key or key type.
Another method to ascertain the key the initiator wants the responder Another method to ascertain the key the initiator wants the responder
to use is through a Certificate Request payload sent by the to use is through a Certificate Request payload sent by the
initiator. For example, the initiator could indicate in the initiator. For example, the initiator could indicate in the
Certificate Request payload that it trusts a CA signed by an ECDSA Certificate Request payload that it trusts a certificate authority
key. This indication implies that the initiator can process ECDSA certificate signed by an ECDSA key. This indication implies that the
signatures, which means that the responder can safely use ECDSA keys initiator can process ECDSA signatures, which means that the
when authenticating. responder can safely use ECDSA keys when authenticating.
A third method is for the responder to check the key type used by the A third method is for the responder to check the key type used by the
initiator, and use same key type that the initiator used. This initiator and use the same key type that the initiator used. This
method does not work if the initiator is using shared secret or EAP method does not work if the initiator is using shared secret or
authentication (i.e., is not using public keys). If the initiator is Extensible Authentication Protocol (EAP) authentication (i.e., is not
using public key authentication, this method is the best way for the using public keys). If the initiator is using public key
responder to ascertain the type of key the initiator supports. authentication, this method is the best way for the responder to
ascertain the type of key the initiator supports.
If the initiator uses a public key type that the responder does not If the initiator uses a public key type that the responder does not
support, the responder replies with a Notify message with error type support, the responder replies with a Notify message with error type
AUTHENTICATION_FAILED. If the initiator has multiple different keys, AUTHENTICATION_FAILED. If the initiator has multiple different keys,
it may try a different key (and perhaps a different key type) until it may try a different key (and perhaps a different key type) until
it finds a key that the other end accepts. The initiator can also it finds a key that the other end accepts. The initiator can also
use the Certificate Request payload sent by the responder to help use the Certificate Request payload sent by the responder to help
decide which public key should be tried. In normal cases, when the decide which public key should be tried. In normal cases, when the
initiator has multiple public keys, out-of-band configuration is used initiator has multiple public keys, out-of-band configuration is used
to select a public key for each connection. to select a public key for each connection.
6. Security Considerations 6. Security Considerations
The "Recommendations for Key Management" ([NIST800-57]) table 2 Tables 2 and 3 of the "Recommendations for Key Management"
combined with table 3 gives recommendations for how to select [NIST800-57] give recommendations for how to select suitable hash
suitable hash functions for the signature. functions for the signature.
This new digital signature method does not tie the Elliptic Curve to This new digital signature method does not tie the Elliptic Curve to
a 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 mix different security levels. methods. This means it is possible to mix different security levels.
For example, it is possible to use 512-bit Elliptic Curve with SHA1. For example, it is possible to use a 512-bit Elliptic Curve with
This means that the security of the authentication method is the SHA1. This means that the security of the authentication method is
security of the weakest component (signature algorithm, hash the security of the weakest component (signature algorithm, hash
algorithm, or curve). This complicates the security analysis of the algorithm, or curve). This complicates the security analysis of the
system. system.
IKEv2 peers have a series of policy databases (see [RFC4301] section IKEv2 peers have a series of policy databases (see Section 4.4 of
4.4 "Major IPsec Databases") that define which security algorithms [RFC4301]) that define which security algorithms and methods should
and methods should be used during establishment of security be used during establishment of security associations. To help end
associations. To help end-users select the desired security levels users select the desired security levels for communications protected
for communications protected by IPsec, implementers may wish to by IPsec, implementers may wish to provide a mechanism in the IKE
provide a mechanism in the IKE policy databases to limit the mixing policy databases to limit the mixing of security levels or to
of security levels or to restrict combinations of protocols. restrict combinations of protocols.
Security downgrade attacks, where more secure methods are deleted or Security downgrade attacks, where more secure methods are deleted or
modified from a payload by a Man-in-the-Middle to force lower levels modified from a payload by a man-in-the-middle to force lower levels
of security, are not a significant concern in IKEv2 Authentication of security, are not a significant concern in IKEv2 Authentication
Payloads as discussed in this RFC. This is because a modified AUTH payloads, as discussed in this RFC. This is because a modified AUTH
payload will be detected when the peer computes a signature over the payload will be detected when the peer computes a signature over the
IKE messages. IKE messages.
One specific class of downgrade attacks requires selection of One specific class of downgrade attacks requires selection of
catastrophically weak ciphers. In this type of attack, the Man-in- catastrophically weak ciphers. In this type of attack, the man-in-
the-Middle attacker is able to "break" the cryptography in real time. the-middle attacker is able to "break" the cryptography in real time.
This type of downgrade attack should be blocked by policy regarding This type of downgrade attack should be blocked by policy regarding
cipher algorithm selection, as discussed above. cipher algorithm selection, as discussed above.
The hash algorithm registry does not include MD5 as a 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 protocol uses RSASSA-PKCS1-v1_5, which has known The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known
security vulnerabilities ([KA08], [ME01]) and does not allow using security vulnerabilities [KA08] [ME01] and does not allow using newer
newer padding methods such as RSASSA-PSS. The new method described padding methods such as RSASSA-PSS. The new method described in this
in this RFC allows using other padding methods. RFC allows the use of other padding methods.
The current IKEv2 protocol only allows use of normal DSA with SHA-1, The current IKEv2 protocol only allows use of normal DSA with SHA-1,
which means the security of the authentication is limited to the which means the security of the authentication is limited to the
security of SHA-1. This new method allows using longer keys and security of SHA-1. This new method allows using longer keys and
longer hashes with DSA. longer hashes with DSA.
7. IANA Considerations 7. IANA Considerations
This document creates a new IANA registry for IKEv2 Hash Algorithms. This document creates a new IANA registry for IKEv2 Hash Algorithms.
Changes and additions to this registry are by Expert Review
Changes and additions to this registry are by expert review. [RFC5226].
The initial values of this registry are: 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 in 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 Unassigned. Values 1024-65535 are reserved for
private use among mutually consenting parties. Private Use among mutually consenting parties.
This specification also adds one new "IKEv2 Notify Message Types -
Status Types" value for SIGNATURE_HASH_ALGORITHMS, and adds one new
"IKEv2 Authentication Method" value for "Digital Signature".
8. Acknowledgements
Most of this work was based on the work done in the IPsecME design This specification also adds a new value for
team for the ECDSA. The design team members were: Dan Harkins, SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types
Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. - Status Types" registry and adds a new value for Digital Signature
(14) to the "IKEv2 Authentication Method" registry.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
"Internet Key Exchange Protocol Version 2 (IKEv2)", Kivinen, "Internet Key Exchange Protocol Version 2
RFC 5996, September 2010. (IKEv2)", RFC 7296, October 2014,
<http://www.rfc-editor.org/info/rfc7296>.
9.2. Informative References 8.2. Informative References
[CCITT.X690.2002] [CCITT.X690.2002]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
"Variants of Bleichenbacher's Low-Exponent Attack on "Variants of Bleichenbacher's Low-Exponent Attack on
PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008,
pp.97-109, 2008.
[ME01] Menezes, A., "Evaluation of Security Level of [ME01] Menezes, A., "Evaluation of Security Level of
Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December
December 2001. 2001.
[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, "Recommendation for Key Management - Part 1: General
March 2007. (Revised)", NIST Special Publication 800-57, 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,
<http://www.rfc-editor.org/info/rfc3279>.
[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,
<http://www.rfc-editor.org/info/rfc3447>.
[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, <http://www.rfc-editor.org/info/rfc4055>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs)", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[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,
<http://www.rfc-editor.org/info/rfc5480>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure: Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA", Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, January 2010. RFC 5758, January 2010,
<http://www.rfc-editor.org/info/rfc5758>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010. June 2010, <http://www.rfc-editor.org/info/rfc5912>.
[WY05] Wang, X. and H. Yu, "How to break MD5 and other hash [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash
functions", Proceedings of EuroCrypt 2005, Lecture Notes functions", Proceedings of EuroCrypt 2005, Lecture Notes
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
ANSI X9.62, November 2005. 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. If the ASN.1 object listed in Appendix A and the ASN.1 examples. If the ASN.1 object listed in Appendix A and the ASN.1
object specified by the algorithm differ, then the algorithm object specified by the algorithm differ, then the algorithm
specification must be used. These values are taken from "New ASN.1 specification must be used. These values are taken from "New ASN.1
Modules for the Public Key Infrastructure Using X.509 (PKIX)" 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
The algorithm identifiers here include several different ASN.1 The algorithm identifiers here include several different ASN.1
objects with different hash algorithms. This document only includes objects with different hash algorithms. This document only includes
the commonly used ones, i.e. the ones using SHA-1 or SHA-2 as hash the commonly used ones, i.e., the ones using SHA-1 or SHA-2 as the
function. Some other algorithms (such as MD2 and MD5) are not safe hash function. Some other algorithms (such as MD2 and MD5) are not
enough to be used as signature hash algorithms, and are omitted. The safe enough to be used as signature hash algorithms and are omitted.
IANA registry does not have code points for these other algorithms The IANA registry does not have code points for these other
with RSA Encryption. Note that there are no optional parameters in algorithms with RSA Encryption. Note that there are no optional
any of these algorithm identifiers, but all included here need NULL parameters in any of these algorithm identifiers, but all included
optional parameters present in the ASN.1. here need NULL 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 use "Additional Algorithms and Identifiers for RSA Cryptography for use
in PKIX Profile" ([RFC4055]) for more information. in the Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) 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 13, line 42 skipping to change at page 13, line 28
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 DSA algorithms, optional parameters are always omitted. Only With DSA algorithms, optional parameters are always omitted. Only
algorithm combinations for DSA listed in the IANA registry are algorithm combinations for DSA that are listed in the IANA registry
included. are included.
See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "PKIX
"PKIX Additional Algorithms and Identifiers for DSA and ECDSA" Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758]
([RFC5758] for more information. 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
0000: 3009 0607 2a86 48ce 3804 03 0000: 3009 0607 2a86 48ce 3804 03
A.2.2. dsa-with-sha256 A.2.2. dsa-with-sha256
dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
skipping to change at page 14, line 25 skipping to change at page 14, line 20
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 ECDSA algorithms, the optional parameters are always omitted. With ECDSA algorithms, the optional parameters are always omitted.
Only algorithm combinations for ECDSA listed in the IANA registry are Only algorithm combinations for the ECDSA listed in the IANA registry
included. are included.
See "Elliptic Curve Cryptography Subject Public Key Information" See "Elliptic Curve Cryptography Subject Public Key Information"
([RFC5480]), "Algorithms and Identifiers for PKIX Profile" [RFC5480], "Algorithms and Identifiers for PKIX Profile" [RFC3279],
([RFC3279]) and "PKIX Additional Algorithms and Identifiers for DSA and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA"
and ECDSA" ([RFC5758] for more information. [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 15, line 33 skipping to change at page 15, line 29
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 RSASSA-PSS, the algorithm object identifier must always be id- With RSASSA-PSS, the algorithm object identifier must always be
RSASSA-PSS, and the hash function and padding parameters are conveyed id-RSASSA-PSS, and the hash function and padding parameters are
in the parameters (which are not optional in this case). See conveyed in the parameters (which are not optional in this case).
[RFC4055] for more information. See Additional RSA Algorithms and Identifiers [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
present. This means default parameters are used. present. This means default parameters are used.
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 contain the default parameters, Here the parameters are present and contain the default parameters,
i.e. hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1,
of 20, trailerField of 1. saltLength of 20, and 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 id-sha1 (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
skipping to change at page 16, line 43 skipping to change at page 17, line 9
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 contain hashAlgorithm of SHA- Here the parameters are present and contain hashAlgorithm of SHA-256,
256, maskGenAlgorithm of SHA-256, saltLength of 32, trailerField of maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.
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 id-sha256 (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
skipping to change at page 17, line 37 skipping to change at page 17, line 44
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 0e00 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. the value depends on Where the NN will be the next payload type (i.e., the value depends
the next payload after this Authentication payload), the LL will be on the next payload after this Authentication payload), the LL will
the length of this payload, and after the sha1WithRSAEncryption ASN.1 be the length of this payload, and after the sha1WithRSAEncryption
block (15 bytes) there will be the actual signature, which is omitted ASN.1 block (15 bytes) there will be the actual signature, which is
here. omitted here.
Note to the RFC editor / IANA, replace the XX above with the newly Acknowledgements
allocated authentication method type for Digital Signature, and
remove this note. Most of this work was based on the work done in the IPsecME design
team for the ECDSA. The design team members were: Dan Harkins,
Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
INSIDE Secure INSIDE Secure
Eerikinkatu 28 Eerikinkatu 28
HELSINKI FI-00180 Helsinki FI-00180
FI Finland
Email: kivinen@iki.fi EMail: kivinen@iki.fi
Joel Snyder Joel Snyder
Opus One Opus One
1404 East Lind Road 1404 East Lind Road
Tucson, AZ 85719 Tucson, AZ 85719
Phone: +1 520 324 0494 Phone: +1 520 324 0494
Email: jms@opus1.com EMail: jms@opus1.com
 End of changes. 90 change blocks. 
237 lines changed or deleted 252 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/