--- 1/draft-kivinen-ipsecme-signature-auth-04.txt 2014-03-28 07:14:40.474798692 -0700 +++ 2/draft-kivinen-ipsecme-signature-auth-05.txt 2014-03-28 07:14:40.510799567 -0700 @@ -1,20 +1,20 @@ IP Security Maintenance and Extensions T. Kivinen (ipsecme) INSIDE Secure -Internet-Draft December 9, 2013 +Internet-Draft March 28, 2014 Updates: RFC 5996 (if approved) Intended status: Standards Track -Expires: June 12, 2014 +Expires: September 29, 2014 Signature Authentication in IKEv2 - draft-kivinen-ipsecme-signature-auth-04.txt + draft-kivinen-ipsecme-signature-auth-05.txt Abstract The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is fixed hash algorithm tied to each curve. This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is generic mechanism, and is not @@ -29,25 +29,25 @@ 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 June 12, 2014. + This Internet-Draft will expire on September 29, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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 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 @@ -76,58 +76,69 @@ A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15 - Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 + A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 15 + Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16 + B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document adds new IKEv2 ([RFC5996]) authentication method to support all kinds of signature methods. The current signature based authentication methods in the IKEv2 are per algorithm, i.e. there is one for RSA Digital signatures, one for DSS Digital Signatures (using SHA-1) and three for different ECDSA curves each tied to exactly one - hash algorithm. This design starts to be cumbersome when more ECDSA - groups are added, as each of them would require new authentication - method and as with ECDSA there is no way to extract the hash - algorithm from the signature, each ECDSA algorithm would need to come - with fixed hash algorithm tied to it. + hash algorithm. This design starts to be cumbersome when more + signature algorithms, hash algorithms and elliptic curves are to be + supported: - With the SHA-3 definitions coming out, it is seen that it might be - possible that in the future the signature methods are used with SHA-3 - also, not only SHA-2. This means new mechanism for negotiating the - hash algorithm for the signature algorithms is needed. + o The RSA Digital Signatures format in the IKEv2 is specified to use + RSASSA-PKCS1-v1_5 padding, but Additional RSA Algorithms and + Identifiers for X.509 document recommends the use of the newer + RSASSA_PSS (See section 5 of [RFC4055]) instead. + o 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 it. + o The tying of ECDSA authentication methods to particular elliptic + curve groups requires definition of additional methods for each + new group. By combination of new ECDSA groups with various hash + functions the number of required authentication methods may grow + unmanageable. Furthermore, the restriction of ECDSA + authentication to a specific group is inconsistent with the + approach taken with DSS. - The RSA Digital Signatures format in the IKEv2 is specified to use - RSASSA-PKCS1-v1_5, but there has been some discussions that newer - padding methods should be preferred instead of PKCS #1 version 1.5 - (See section 5 of [RFC4055]). The DSS Digital Signatures format in - the IKEv2 is specified to always use SHA-1, which limits the security - of that, meaning there is no point of using long keys with it. + With the selection of SHA-3, it is seen that it might be possible + that in the future the signature methods are used with SHA-3 also, + not only SHA-2. This means new mechanism for negotiating the hash + algorithm for the signature algorithms is needed. This documents specifies two things, one is one new authentication - method, which includes the enough information inside the - Authentication payload data that the signature hash algorithm can be - extracted from there (see Section 3). The another thing is to add - indication of supported signature hash algorithms by the peer (see - Section 4). This allows peer to know which hash algorithms are - supported by the other end and use one of them (provided one is - allowed by policy). There is no need to actually negotiate one - common hash algorithm, as different hash algorithms can be used in - different directions if needed. + method, which includes enough information inside the Authentication + payload data that the signature hash algorithm can be extracted from + there (see Section 3). The another thing is to add indication of + supported signature hash algorithms by the peer (see Section 4). + This allows peer to know which hash algorithms are supported by the + other end and use one of them (provided one is allowed by policy). + There is no need to actually negotiate one common hash algorithm, as + different hash algorithms can be used in different directions if + needed. The new digital signature method needs to be flexible enough to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc), and also allow adding new things in the future (ECGDSA, ElGamal etc). For this the signature algorithm is specified in the same way as the PKIX ([RFC5280]) specifies the signature of the Certificate, i.e. there is simple ASN.1 object before the actual signature data. This ASN.1 object contains the OID specifying the algorithm, and associated parameters to it. In normal case the IKEv2 implementations supports fixed amount of signature methods, with @@ -160,21 +171,21 @@ parameters which might be needed for algorithms like RSASSA-PSS. To make implementations easier, the ASN.1 object is prefixed by the 8-bit length field. This length field allows simple implementations to be able to know the length of the ASN.1 without the need to parse it, so they can use it as binary blob which is compared against the known signature algorithm ASN.1 objects, i.e. they do not need to be able to parse or generate ASN.1 objects. See Appendix A for commonly used ASN.1 objects. - The ASN.1 used here are the same ASN.1 which is used in the + The ASN.1 used here is the same ASN.1 which is used in the AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the ASN.1 specifies the signature algorithm and the hash function, which are needed for signature verification. The EC curve is always known by the peer because it needs to have the certificate or the public key of the other end before it can do signature verification and public key specifies the curve. Currently only the RSASSA-PSS uses the parameters, for all others the parameters is either NULL or missing. Note, that for some algorithms @@ -484,56 +495,52 @@ 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 = 17 - 0000: 300f 300d 0609 2a86 4886 f70d 0101 0505 - 0010: 00 + 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 = 17 - 0000: 300f 300d 0609 2a86 4886 f70d 0101 0b05 - 0010: 00 + 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 = 17 - 0000: 300f 300d 0609 2a86 4886 f70d 0101 0c05 - 0010: 00 + 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 = 17 - 0000: 300f 300d 0609 2a86 4886 f70d 0101 0d05 - 0010: 00 + Length = 15 + 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00 A.2. DSA With different DSA algorithms the parameters are always omitted. Again we omit dsa-with-sha224 as there is no hash algorithm in our IANA registry for it. See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758] for more information. @@ -535,151 +542,199 @@ IANA registry for it. 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 = 13 - 0000: 300b 3009 0607 2a86 48ce 3804 03 + 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 = 15 - 0000: 300d 300b 0609 6086 4801 6503 0403 02 + Length = 13 + 0000: 300b 0609 6086 4801 6503 0403 02 A.3. ECDSA With different ECDSA algorithms the parameters are always omitted. Again we omit ecdsa-with-sha224 as there is no hash algorithm in our IANA registry for it. 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 = 13 - 0000: 300b 3009 0607 2a86 48ce 3d04 01 + 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 = 14 - 0000: 300c 300a 0608 2a86 48ce 3d04 0302 + 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 = 14 - 0000: 300c 300a 0608 2a86 48ce 3d04 0303 + 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 = 14 - 0000: 300c 300a 0608 2a86 48ce 3d04 0304 + Length = 12 + 0000: 300a 0608 2a86 48ce 3d04 0304 A.4. RSASSA-PSS With the RSASSA-PSS the algorithm object identifier is always id- RSASSA-PSS, but the hash function is taken from the parameters, and it is required. See [RFC4055] for more information. 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). - Name = RSASSA-PSS with empty parameters, oid = 1.2.840.113549.1.1.10 - Length = 17 - 0000: 300f 300d 0609 2a86 4886 f70d 0101 0a30 - 0010: 00 + 0000 : SEQUENCE + 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) + 000d : SEQUENCE + + Length = 15 + 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 A.4.2. RSASSA-PSS with default parameters id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } Here the parameters are present, and contains the default parameters, i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1. 0000 : SEQUENCE - 0002 : SEQUENCE - 0004 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) - 000f : SEQUENCE - 0011 : CONTEXT 0 + 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) + 000d : SEQUENCE + 000f : CONTEXT 0 + 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 - 001e : OBJECT IDENTIFIER id-mgf1 ( 1.2.840.113549.1.1.8) - 0029 : SEQUENCE - 002b : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) - 0032 : NULL - 0034 : CONTEXT 2 (1 bytes) - 0036 : INTEGER 20 (0x14) - 0037 : CONTEXT 3 (1 bytes) - 0039 : INTEGER 01 (0x01) + 001e : SEQUENCE + 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 + 002b : SEQUENCE + 002d : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) + 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 = 58 - 0000: 3038 3036 0609 2a86 4886 f70d 0101 0a30 - 0010: 29a0 0906 052b 0e03 021a 0500 a116 0609 - 0020: 2a86 4886 f70d 0101 0830 0906 052b 0e03 - 0030: 021a 0500 8201 1483 0101 + 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 -Appendix B. Examples +A.4.3. RSASSA-PSS with SHA-256 - XXX Examples missing + id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } - XXX Most likely include examples for sha1WithRSAEncryption and dsa- - with-sha256 or something like that. I do not think we need all - possible signature examples. + Here the parameters are present, and contains the SHA-256 for both + the hash and mgf, 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 Sha-256 (2.16.840.1.101.3.4.2.1) + 001e : NULL + 0020 : CONTEXT 1 + 0022 : SEQUENCE + 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 + 002f : SEQUENCE + 0031 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1) + 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 XX00 0000 0f30 0d06 092a 8648 + 00000010: 86f7 0d01 0105 0500 .... + + Where the NN will be the next payload type (i.e. that value depends + on what is the next payload after this Authentication payload), the + LL will be the length of this payload, and after the + sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual + signature, which is omitted here. + + Note to the RFC editor / IANA, replace the XX above with the newly + allocated authentication method type for Digital Signature, and + remove this note. Author's Address Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FI Email: kivinen@iki.fi