idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5996, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5996, updated by this document, for RFC5378 checks: 2008-08-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 4, 2012) is 4162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5480' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Maintenance and Extensions T. Kivinen 3 (ipsecme) INSIDE Secure 4 Internet-Draft December 4, 2012 5 Updates: RFC 5996 (if approved) 6 Intended status: Standards Track 7 Expires: June 7, 2013 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-00.txt 12 Abstract 14 The Internet Key Exchange Version 2 (IKEv2) protocol has limited 15 support for the Elliptic Curve Digital Signature Algorithm (ECDSA). 16 The current support only includes support for three Elliptic Curve 17 groups, and there is fixed hash algorithm tied to each curve. This 18 document generalizes the IKEv2 signature support so it can support 19 any signature method supported by the PKIX and also adds signature 20 hash algorithm negotiation. This generic mechanism is not limited to 21 ECDSA, but can also be used with other signature algorithms. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 7, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 60 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document adds support for new IKEv2 ([RFC5996]) authentication 73 method to support all kinds of signature methods. The current 74 signature based authentication methods in the IKEv2 are per 75 algorithm, i.e. there is one for RSA Digital signatures, one for DSS 76 Digital Signatures (using SHA-1) and three for different ECDSA curves 77 each tied to exactly one hash algorithm. This design starts to be 78 cumbersome when more ECDSA groups are added, as each of them would 79 require new authentication method and as with ECDSA there is no way 80 to extract the hash algorithm from the signature, each ECDSA 81 algorithm would need to come with fixed hash algorithm tied to it. 83 With the SHA-3 definitions coming out, it is seen that it might be 84 possible that in the future the signature methods are used with SHA-3 85 also, not only SHA-2. This means new mechanism for negotiating the 86 hash algorithm for the signature algorithms is needed. 88 The RSA Digital Signatures format in the IKEv2 is specified to use 89 RSASSA-PKCS1-v1_5, but there has been some discussions that newer 90 padding methods should also be possible (See section 5 of [RFC4055]). 91 The DSS Digital Signatures format in the IKEv2 is specified to always 92 use SHA-1, which limits the security of that, meaning there is no 93 point of using long keys with it. 95 This documents specifies two things, one is one new authentication 96 method, which includes the enough information inside the 97 Authentication payload data that the signature hash algorithm can be 98 extracted from there (see Section 3). The another thing is to add 99 indication of supported signature hash algorithms by the peer (see 100 Section 4). This allows peer to know which hash algorithms are 101 supported by the other end and use one of them (provided one is 102 allowed by policy). There is no need to actually negotiate one 103 common hash algorithm, as different hash algorithms can be used in 104 different directions if needed. 106 The new digital signature method needs to be flexible enough to 107 include all current signature methods (ECDSA, ECGDSA, RSASSA-PSS, 108 ElGamal, etc), and also allow adding new things in the future. For 109 this the signature algorithm is specified by and OID which specifies 110 both the signature and hash algorithms (i.e. sha1WithRSAEncryption, 111 dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256 112 etc), meaning any signature and hash algorithm specified by an OID 113 can be used. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Authentication Payload 123 This document specifies new "Digital Signature" authentication 124 method. This method can be used with any types of signatures. As 125 the authentication methods are not negotiated in the IKEv2, the peer 126 is only allowed to use this authentication method if the 127 SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. 129 In this newly defined authentication method, the Authentication Data 130 field inside the Authentication Payload does not include only the 131 signature value, but instead the signature value is prefixed with the 132 algorithm identification OID. This OID identifies both the signature 133 algorithm and the hash used when calculating the signature. To make 134 implementations easier, the OID is prefixed by the 8-bit length 135 field. This length field allows simple implementations to be able to 136 know the length of the OID, so they can use it as binary blob which 137 is compared against the known OIDs, i.e. they do not need to be able 138 to parse or generate ASN.1 DER OIDs (Note, that the 2nd byte of the 139 ASN.1 DER OID, also includes the length, but adding it outside makes 140 things bit easier for implementors). 142 The OIDs used here are the same OIDs which are used inside the 143 AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]), but 144 only the algorithm OID is included, no parameters etc. The EC curve 145 is always known by the peer because it needs to have the certificate 146 or the public key of the other end before it can do signature 147 verification and public key specifies the curve. 149 XXX While reading RFC4055, it seemed that the OID is not enough to 150 specify the hash function used for the RSASSA-PSS, i.e. it seems 151 that we would need to include full AlgorithmIdentifier ASN object, 152 as it includes also the parameters, and the hash function is 153 specified in the parameters. Is my reading of RFC4055 correct? 154 XXX 156 The Authentication payload is defined in IKEv2 as follows: 158 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Next Payload |C| RESERVED | Payload Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Auth Method | RESERVED | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 ~ Authentication Data ~ 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: Authentication Payload Format. 172 o Auth Method (1 octet) - Specifies the method of authentication 173 used. 175 Mechanism Value 176 ----------------------------------------------------------------- 177 Digital Signature 178 Computed as specified in Section 2.15 of RFC5996 using a 179 private key associated with the public key sent in certificate 180 payload, and using one of the hash algorithms sent by the other 181 end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both 182 ends send and receive SIGNATURE_HASH_ALGORITHMS and signature 183 authentication is to be used, then this method MUST be used. 184 The Authentication Data field has bit different format than in 185 other Authentication methods (see below). 187 o Authentication Data (variable length) - see Section 2.15 of 188 RFC5996. For "Digital Signature" format the Authentication data 189 contains special format as follows: 191 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | OID Length | OID (0x06) . OID value len . OID value | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 ~ OID value continuing ~ 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 ~ Signature Value ~ 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Authentication Data Format. 207 Where the OID Length is the length of the ASN.1 encoded OID value, 208 and after that is the actual Signature Algorithm OID followed by 209 the actual signature value. There is no padding between OID and 210 signature value. ASN.1 encoded OIDs always start with byte of 211 0x06 followed by the length of the actual OID value (which is 212 shown in the figure above). For the hash truncation the method of 213 X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for 214 X9.62/SEC1 etchere XXX. 216 4. Hash Algorithm Notification 218 The supported hash algorithms that can be used for the signature 219 algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS 220 Notification Payload sent inside the IKE_SA_INIT exchange. This 221 notification also indicates the support of the new signature 222 algorithm method, i.e sending this notification tells that new 223 "Digital Signature" authentication method is supported and that 224 following hash functions are supported by sending peer. Both ends 225 sends their list of supported hash-algorithms and when calculating 226 signature a peer MUST pick one algorithm sent by the other peer. 227 Note, that different algorithms can be used in different directions. 228 The algorithm OID matching selected hash algorithm (and signature 229 algorithm) used when calculating the signature is sent inside the 230 Authentication Data field of the Authentication Payload. 232 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Next Payload |C| RESERVED | Payload Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Protocol ID | SPI Size | Notify Message Type | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 ~ Security Parameter Index (SPI) ~ 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 ~ Notification Data ~ 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3: Notify Payload Format. 250 Protocol ID is 0, SPI Size 0, and Notify Message Type . The Notification Data value contains list of 16-bit 252 hash algorithm identifiers from the newly created Hash Algorithm 253 Identifiers for the IKEv2 IANA registry. 255 5. Security Considerations 257 XXX The text about the guidance how to select suitable hash 258 functions is missing here. XXX 260 This new digital signature method does not tie the EC curve to the 261 specific hash function, which was done in the old IKEv2 ECDSA 262 methods. This means it is possible to use 512-bit EC curve with 263 SHA1, i.e. this allows mixing different security levels. This means 264 that the security of the authentication method is the security of the 265 weakest of components (signature algorithm, hash algorithm, curve). 266 This might make the security analysis of the system bit more complex. 267 Note, that this kind of mixing of the security can be disallowed by 268 the policy. 270 The hash algorithm registry does not include MD5 as supported hash 271 algorithm, as it is not considered safe enough for signature use. 273 XXX Need reference for MD5 considered unsafe. XXX 275 The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using 276 newer padding methods like RSASSA-PSS. This new method allows using 277 other padding methods. 279 XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. 280 XXX 282 The current IKEv2 only allows using normal DSA with SHA-1, which 283 means the security of the regular DSA is limited to the security of 284 SHA-1. This new methods allows using longer keys and longer hashes 285 with DSA. 287 6. IANA Considerations 289 This document creates new IANA registry for IKEv2 Hash Algorithms. 290 Changes and additions to this registry is by expert review. 292 The initial values of this registry is: 294 Hash Algorithm Value 295 -------------- ----- 296 RESERVED 0 297 SHA1 1 298 SHA2-256 2 299 SHA2-384 3 300 SHA2-512 4 301 MD5 is not included to the hash algorithm list as it is not 302 considered safe enough for signature hash uses. 304 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 305 private use among mutually consenting parties. 307 7. Acknowledgements 309 Most of this work was based on the work done in the IPsecME design 310 team for the ECDSA. The design team members were: Dan Harking, 311 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 321 Housley, R., and W. Polk, "Internet X.509 Public Key 322 Infrastructure Certificate and Certificate Revocation List 323 (CRL) Profile", RFC 5280, May 2008. 325 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 326 "Internet Key Exchange Protocol Version 2 (IKEv2)", 327 RFC 5996, September 2010. 329 8.2. Informative References 331 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 332 Algorithms and Identifiers for RSA Cryptography for use in 333 the Internet X.509 Public Key Infrastructure Certificate 334 and Certificate Revocation List (CRL) Profile", RFC 4055, 335 June 2005. 337 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 338 "Elliptic Curve Cryptography Subject Public Key 339 Information", RFC 5480, March 2009. 341 Appendix A. Examples 342 Author's Address 344 Tero Kivinen 345 INSIDE Secure 346 Eerikinkatu 28 347 HELSINKI FI-00180 348 FI 350 Email: kivinen@iki.fi