IKEv2 signature auth: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
One IKEv2 authentication method that carries the signature algorithm with the signature, so new hashes and curves need no new codes.
Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, <https://www.rfc-editor.org/info/rfc7427>.
@misc{rfc7427,
series = {Request for Comments},
number = 7427,
howpublished = {RFC 7427},
publisher = {RFC Editor},
doi = {10.17487/RFC7427},
url = {https://www.rfc-editor.org/info/rfc7427},
author = {T. Kivinen and J. Snyder},
title = {{Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)}},
pagetotal = 18,
year = 2015,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) T. Kivinen Request for Comments: 7427 INSIDE Secure Updates: 7296 J. Snyder Category: Standards Track Opus One ISSN: 2070-1721 January 2015 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) 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 a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7427. Copyright Notice Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Payload . . . . . . . . . . . . . . . . . . . 4 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6 5. Selecting the Public Key Algorithm . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Commonly Used ASN.1 Objects . . . . . . . . . . . . 12 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 15 A.4.1. RSASSA-PSS with Empty Parameters . . . . . . . . . . 15 A.4.2. RSASSA-PSS with Default Parameters . . . . . . . . . 16 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 17 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . 17 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction This document adds a new IKEv2 [RFC7296] 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 In IKEv2, authentication using RSA digital signatures calls for padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS padding method is now recommended. (See Section 5 of "Additional Algorithms and Identifiers for RSA Cryptography for use in PKIX Profile" [RFC4055].) o With ECDSA and the Digital Signature Standard (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 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 SHA-1. o The tying of ECDSA authentication methods to particular elliptic curve groups requires definition of additional methods for each 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 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 document specifies two things: 1. A new authentication method that includes enough information inside the Authentication payload data so 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 that 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 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 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 that might be needed for algorithms such as RSASSA-PSS (see 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 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 used in the AlgorithmIdentifier of PKIX (see 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Authentication Payload Format o Auth Method (1 octet) - Specifies the method of authentication used. Mechanism Value ----------------------------------------------------------------- Digital Signature 14 Computed as specified in Section 2.15 of [RFC7296] using a 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 [RFC7296]. 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 * 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 the ASN.1 object and the 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 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 The Notify payload format is defined in Section 3.10 of [RFC7296]. 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 16431. The Notification Data field contains the list of 16-bit hash algorithm identifiers from the Hash Algorithm Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" 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. 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 method to signal the key the initiator wants the responder to use is to indicate that in the IDr (Identification - Responder) 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 that 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 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 certificate authority certificate 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. A third method is for the responder to check the key type used by the initiator and use the same key type that the initiator used. This method does not work if the initiator is using shared secret or Extensible Authentication Protocol (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. 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 Tables 2 and 3 of the "Recommendations for Key Management" [NIST800-57] give recommendations for how to select suitable hash functions for the signature. 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 a 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. IKEv2 peers have a series of policy databases (see Section 4.4 of [RFC4301]) that define which security algorithms and methods should be used during establishment of security associations. To help end users select the desired security levels for communications protected by IPsec, implementers may wish to provide a mechanism in the IKE policy databases to limit the mixing of security levels or to restrict combinations of protocols. Security downgrade attacks, where more secure methods are deleted or modified from a payload by a man-in-the-middle to force lower levels of security, are not a significant concern in IKEv2 Authentication payloads, as discussed in this RFC. This is because a modified AUTH payload will be detected when the peer computes a signature over the IKE messages. One specific class of downgrade attacks requires selection of catastrophically weak ciphers. In this type of attack, the man-in- the-middle attacker is able to "break" the cryptography in real time. This type of downgrade attack should be blocked by policy regarding cipher algorithm selection, as discussed above. 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 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 the use of other padding methods. 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 a new IANA registry for IKEv2 Hash Algorithms. Changes and additions to this registry are by Expert Review [RFC5226]. 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 in the hash algorithm list, as it is not considered safe enough for signature hash uses. Values 5-1023 are Unassigned. Values 1024-65535 are reserved for Private Use among mutually consenting parties. This specification also adds a new value for SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types - Status Types" registry and adds a new value for Digital Signature (14) to the "IKEv2 Authentication Method" registry. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>. 8.2. Informative References [CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002. [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, "Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008, pp.97-109, 2008. [ME01] Menezes, A., "Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December 2001. [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 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, <http://www.rfc-editor.org/info/rfc3279>. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>. [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, <http://www.rfc-editor.org/info/rfc4055>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs)", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>. [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010, <http://www.rfc-editor.org/info/rfc5758>. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010, <http://www.rfc-editor.org/info/rfc5912>. [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash functions", Proceedings of EuroCrypt 2005, Lecture Notes 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. 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 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 the 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 use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) 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 0000: 300d 0609 2a86 4886 f70d 0101 0505 00 A.1.2. sha256WithRSAEncryption sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } Parameters are required, and they must be NULL. Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00 A.1.3. sha384WithRSAEncryption sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } Parameters are required, and they must be NULL. Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00 A.1.4. sha512WithRSAEncryption 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 DSA algorithms, optional parameters are always omitted. Only algorithm combinations for DSA that are 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. 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 0000: 3009 0607 2a86 48ce 3804 03 A.2.2. dsa-with-sha256 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 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 ECDSA algorithms, the optional parameters are always omitted. Only algorithm combinations for the 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. 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 0000: 3009 0607 2a86 48ce 3d04 01 A.3.2. ecdsa-with-sha256 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } Parameters are absent. Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0302 A.3.3. ecdsa-with-sha384 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } Parameters are absent. Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0303 A.3.4. ecdsa-with-sha512 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 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 RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the parameters (which are not optional in this case). See Additional RSA Algorithms and Identifiers [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 present. This means default parameters are used. 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 contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and 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 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 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 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } Here the parameters are present and contain hashAlgorithm of SHA-256, maskGenAlgorithm of SHA-256, saltLength of 32, and 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 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 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 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 0e00 0000 0f30 0d06 092a 8648 00000010: 86f7 0d01 0105 0500 .... 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. 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 Harkins, Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. Authors' Addresses Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland EMail: kivinen@iki.fi Joel Snyder Opus One 1404 East Lind Road Tucson, AZ 85719 Phone: +1 520 324 0494 EMail: jms@opus1.com
ISO Plain Language
On this page
§1Why a New Authentication Method
The RFC adds a new IKEv2 authentication method to support signature methods in a more general way. The current signature-based authentication methods in IKEv2 are per algorithm: 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.
Three problems follow from that. In IKEv2, authentication using RSA digital signatures calls for padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS padding method is now recommended. With ECDSA and the Digital Signature Standard, there is no way to extract the hash algorithm from the signature, so 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, and there is no point in using long keys with SHA-1. And tying ECDSA authentication methods to particular elliptic curve groups requires an additional method for each new group, so the combination of new groups and hash functions would make the number of required methods unmanageable. The restriction of ECDSA authentication to a specific group is also inconsistent with the approach taken with DSS.
With the selection of SHA-3, it might be possible for a signature method to be used with either SHA-3 or SHA-2, which means that a new mechanism for negotiating the hash algorithm for a signature algorithm is needed.
The RFC therefore specifies two things. First, a new authentication method that includes enough information inside the Authentication payload data so that the signature hash algorithm can be extracted. Second, a method to indicate supported signature hash algorithms, which allows the peer to know which hash algorithms the other end supports and use one of them, provided one is allowed by policy. There is no requirement to 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 the current signature methods and to add new ones in future. To support that flexibility, the signature algorithm is specified in the same way that PKIX specifies the signature of a digital certificate, by placing a simple ASN.1 object before the actual signature data. This object contains an object identifier specifying the algorithm and any associated parameters. When an IKEv2 implementation supports a fixed set of signature methods with commonly used parameters, it is acceptable to treat the ASN.1 object as a binary blob that can be compared against the fixed set of known values; implementations can also parse the ASN.1 and extract the signature algorithm and its parameters.
IKEv2 lets two peers prove who they are with a digital signature, and the signature is computed over a hash of the exchange, so the hash algorithm has to be known to both ends. The old design solved that with a separate authentication method for every combination: one for RSA, one for DSA, and three for particular elliptic curves.
That does not scale. Every new curve and hash function would need a method of its own, and with ECDSA and DSA there is no way to work out from the signature alone which hash was used. The DSA method is the worst affected, because it is pinned to SHA-1, so a long key buys nothing.
This RFC replaces the collection with one method. The signature names the algorithm and the hash used, and a separate message lists the hashes each end will accept.
| Aspect | The existing IKEv2 methods | The new Digital Signature method |
|---|---|---|
| How many methods are needed | One per signature algorithm, and one per curve and hash combination | One, whatever the signature algorithm and the hash |
| How the hash algorithm is chosen | Fixed by the method that was chosen | Picked from the list the peer sent, and named inside the signature |
| What can be combined | Each method is tied to one curve and one hash | Any curve with any hash, which means the weakest part sets the security level |
| Padding methods for RSA | RSASSA-PKCS1-v1_5 only | Whatever the algorithm identifier allows, including RSASSA-PSS |
§3The Authentication Payload
The RFC specifies a new Digital Signature authentication method that can be used with any type of signature. Because authentication methods are not negotiated in IKEv2, the peer is only allowed to use this method if the Notify payload of type SIGNATURE_HASH_ALGORITHMS has been sent and received by each peer.
In this method, the Authentication Data field inside the Authentication payload does not just include the signature value, as in the 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 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used when calculating the signature, and it can contain optional parameters that might be needed for algorithms such as RSASSA-PSS.
To make implementations easier, the ASN.1 object is prefixed by an 8-bit length field, so a simple implementation can know the length of the object without parsing it and use it as a binary blob compared against known signature algorithm objects. The ASN.1 used is the same as that in the AlgorithmIdentifier of PKIX, encoded using distinguished encoding rules. The algorithm OID inside specifies the signature algorithm and the hash function, both of which are needed for signature verification.
Currently only the RSASSA-PSS signature algorithm uses the optional parameters; for other signature algorithms the parameters are either NULL or missing. Some algorithms have two possible encodings, one with the optional parameters included but set to NULL and one where they are omitted. When encoding the ASN.1, implementations SHOULD use the preferred format called for by the algorithm specification: if the specification says preferredPresent then the parameters object needs to be present, although it will be NULL if no parameters are specified, and if it says preferredAbsent then the entire optional parameters object is missing.
The Authentication payload is the one defined in IKEv2: a Next Payload field, a critical bit with reserved space, a payload length, an Auth Method octet and reserved space, and the Authentication Data. The Auth Method octet specifies the method of authentication used, and Digital Signature has the value 14. It is computed as specified in Section 2.15 of RFC 7296 using a 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 those Notify payloads, and signature authentication is to be used, then the authentication method specified in this payload MUST be used.
The Authentication Data for this format holds three fields: an ASN.1 Length of one octet containing the length of the ASN.1-encoded AlgorithmIdentifier object, the Algorithm Identifier itself, which is of variable length, and the Signature Value, also of variable length. There is no padding between the ASN.1 object and the signature value, and for hash truncation the method specified in ANSI X9.62 MUST be used.
The Authentication payload is where a peer puts the proof of its identity. In the new method, that field holds two things instead of one: a short description of the algorithm used, and the signature itself.
The description is an object identifier, the same kind of label that a certificate carries to say how it was signed. Here it names both the signature algorithm and the hash function, because the receiver needs both to check the signature.
Before the description comes a single byte giving its length. That lets a simple implementation skip the description without parsing it and compare it against a list of values it knows, so an implementation need not understand the encoding at all if it only supports a fixed set of algorithms.
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+§4Telling the Peer Which Hashes Are Supported
The supported hash algorithms that can be used for the signature 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. Different algorithms can be used in different directions. The algorithm OID indicating the selected hash algorithm, and the signature algorithm, used when calculating the signature is sent inside the Authentication Data field of the Authentication payload.
The Notify payload format is the one defined in Section 3.10 of RFC 7296. 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 16431. The Notification Data field contains the list of 16-bit hash algorithm identifiers from the Hash Algorithm Identifiers of the IANA IKEv2 Parameters registry, with no padding between them.
The list of acceptable hash functions travels in a message that is sent in the first exchange of the connection, before anything is authenticated. Each end sends its own list, and the presence of the message also tells the peer that the new authentication method is understood.
There is no need for the two lists to match. When a peer signs, it picks one hash from the list the other end sent, and the one it picked is named inside the signature. The two directions of the connection may use different hashes.
- 0RESERVED — Reserved by the registry.
- 1SHA1 — The SHA-1 hash function.
- 2SHA2-256 — The 256-bit SHA-2 hash function.
- 3SHA2-384 — The 384-bit SHA-2 hash function.
- 4SHA2-512 — The 512-bit SHA-2 hash function.
§5Choosing the Public Key Algorithm
The specification does not provide a way for the peers to indicate the public and private key pair types they have, which raises the question of how the responder selects a key pair type that the initiator supports. This information can be found by several methods.
One method is to indicate the key the initiator wants the responder to use 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 key pair by sending an IDr payload that carries that information, and the responder has different identities configured, each associated with a key or key type.
Another method is a Certificate Request payload sent by the initiator. For example, the initiator could indicate in the Certificate Request payload that it trusts a certificate authority certificate signed by an ECDSA key, which implies that the initiator can process ECDSA signatures, so the responder can safely use ECDSA keys when authenticating.
A third method is for the responder to check the key type used by the initiator and use the same key type that the initiator used. This method does not work if the initiator is using shared secret or Extensible Authentication Protocol authentication, that is, if it is not using public keys. If the initiator is using public key authentication, this is the best way for the responder to ascertain the type of key the initiator supports.
If the initiator uses a public key type that the responder does not 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 one 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, where the initiator has multiple public keys, out-of-band configuration is used to select a public key for each connection.
The new method says which signature algorithm is in use, but it does not say which key the peer should use to sign. That question has to be answered separately, and the RFC lists three ways it can be settled.
The initiator can name the key it wants the responder to use, in the identity payload of its request. The initiator can say which kinds of certificate it trusts, and the responder infers from that which kind of key it may use. Or the responder can simply match whatever the initiator used, which works whenever the initiator used a public key at all.
If the responder cannot match, it refuses the authentication, and an initiator with several keys can try another one.
§6Security Considerations
Tables 2 and 3 of the Recommendations for Key Management give recommendations for how to select suitable hash functions for the signature.
The new digital signature method does not tie the elliptic curve to a specific hash function, which is what the old IKEv2 ECDSA methods did. This means it is possible to mix different security levels, for example to use a 512-bit elliptic curve with SHA-1, so the security of the authentication method is the security of its weakest component, whether that is the signature algorithm, the hash algorithm or the curve. This complicates the security analysis of the system.
IKEv2 peers have a series of policy databases, described in Section 4.4 of RFC 4301, that define which security algorithms and methods should be used when security associations are established. To help end users select the desired security levels for communications protected by IPsec, implementers may wish to provide a mechanism in the IKE policy databases to limit the mixing of security levels or to restrict combinations of protocols.
Security downgrade attacks, where more secure methods are deleted or modified from a payload by a man in the middle to force lower levels of security, are not a significant concern in IKEv2 Authentication payloads, because a modified AUTH payload will be detected when the peer computes a signature over the IKE messages. One specific class of downgrade attacks requires the selection of catastrophically weak ciphers, in which the attacker is able to break the cryptography in real time; this should be blocked by policy regarding cipher algorithm selection.
The hash algorithm registry does not include MD5, as it is not considered safe enough for signature use. The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known security vulnerabilities and does not allow newer padding methods such as RSASSA-PSS; the new method described in the RFC allows the use of other padding methods. The current IKEv2 protocol also only allows normal DSA with SHA-1, which limits the security of the authentication to the security of SHA-1, and the new method allows using longer keys and longer hashes with DSA.
The flexibility that the new method brings has a price. Because the curve and the hash are no longer tied together, an implementation could combine a strong curve with a weak hash, and the result would be as weak as its weakest part. The RFC therefore suggests that the policy databases of an IKE implementation should be able to restrict which combinations are allowed, so that an operator can set a floor on the security level.
Downgrade attacks are not a concern here, because the signature is computed over the whole exchange, so any change to a payload is detected when the signature is checked. The exception is the case where the attacker can break the cryptography outright, which has to be prevented by the cipher policy.
§7IANA Considerations
The RFC creates a new IANA registry for IKEv2 hash algorithms, with changes and additions by Expert Review. The initial values of the registry are RESERVED with value 0, SHA1 with value 1, SHA2-256 with value 2, SHA2-384 with value 3 and SHA2-512 with value 4. MD5 is not included, as it is not considered safe enough for signature hash uses. Values 5 to 1023 are unassigned, and values 1024 to 65535 are reserved for private use among mutually consenting parties.
The specification also adds a new value for SIGNATURE_HASH_ALGORITHMS, 16431, to the IKEv2 Notify Message Types - Status Types registry, and a new value for Digital Signature, 14, to the IKEv2 Authentication Method registry.
The document starts two new registries. One lists the hash functions that may be used for signatures, with numbers for SHA-1 and the three SHA-2 sizes, and a block of numbers reserved for private use. The other records the new authentication method and the new notification type.