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