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/ |