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/