From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7427.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc7427.txt (limited to 'doc/rfc/rfc7427.txt') diff --git a/doc/rfc/rfc7427.txt b/doc/rfc/rfc7427.txt new file mode 100644 index 0000000..d8ecb5b --- /dev/null +++ b/doc/rfc/rfc7427.txt @@ -0,0 +1,1011 @@ + + + + + + +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. + + + +Kivinen & Snyder Standards Track [Page 1] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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: + + + + + + +Kivinen & Snyder Standards Track [Page 2] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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 + + + +Kivinen & Snyder Standards Track [Page 3] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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 + + + +Kivinen & Snyder Standards Track [Page 4] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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: + + + +Kivinen & Snyder Standards Track [Page 5] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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). + + + + +Kivinen & Snyder Standards Track [Page 6] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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 + + + +Kivinen & Snyder Standards Track [Page 7] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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 + + + +Kivinen & Snyder Standards Track [Page 8] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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. + + + + + +Kivinen & Snyder Standards Track [Page 9] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + 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, + . + + [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, + . + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", RFC 7296, October 2014, + . + +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. + + + + + +Kivinen & Snyder Standards Track [Page 10] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + + [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, . + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs)", BCP 26, RFC 5226, + May 2008, . + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, March 2009, + . + + [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, + . + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, + June 2010, . + + [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. + + + +Kivinen & Snyder Standards Track [Page 11] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + +Kivinen & Snyder Standards Track [Page 12] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + + + + + + + + + +Kivinen & Snyder Standards Track [Page 13] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + + + + + +Kivinen & Snyder Standards Track [Page 14] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + + + + + + +Kivinen & Snyder Standards Track [Page 15] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + + + + + + + + + + + + + + + + +Kivinen & Snyder Standards Track [Page 16] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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. + + + + +Kivinen & Snyder Standards Track [Page 17] + +RFC 7427 Signature Authentication in IKEv2 January 2015 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kivinen & Snyder Standards Track [Page 18] + -- cgit v1.2.3