--- 1/draft-kivinen-ipsecme-signature-auth-06.txt 2014-07-21 09:14:32.641491053 -0700 +++ 2/draft-kivinen-ipsecme-signature-auth-07.txt 2014-07-21 09:14:32.677491951 -0700 @@ -1,20 +1,20 @@ IP Security Maintenance and Extensions T. Kivinen (ipsecme) INSIDE Secure Internet-Draft J. Snyder Updates: RFC 5996 (if approved) Opus One -Intended status: Standards Track May 7, 2014 -Expires: November 8, 2014 +Intended status: Standards Track July 21, 2014 +Expires: January 22, 2015 Signature Authentication in IKEv2 - draft-kivinen-ipsecme-signature-auth-06.txt + draft-kivinen-ipsecme-signature-auth-07.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 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 @@ -28,21 +28,21 @@ 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 November 8, 2014. + This Internet-Draft will expire on January 22, 2015. 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 @@ -57,59 +57,59 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 7 5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 + 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 . . . . . . . . . . . . . . . 12 + A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 13 + 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 . . . . . . . . . . . . . . . . . . . 13 - A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 14 - A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 15 + A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 16 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16 - Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16 + Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 17 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction 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 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 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 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 @@ -361,22 +361,42 @@ 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 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. + system. + + IKEv2 peers have a series of policy databases (see [RFC4301] section + 4.4 "Major IPsec Databases") 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 using other padding methods. @@ -462,20 +483,23 @@ [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. + [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 @@ -641,31 +664,31 @@ 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 is always id-RSASSA- - PSS, but the hash function is taken from the optional parameters, and - is required. See [RFC4055] for more information. + 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 + [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). + 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