idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-06.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 (May 7, 2014) is 3639 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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 J. Snyder 5 Updates: RFC 5996 (if approved) Opus One 6 Intended status: Standards Track May 7, 2014 7 Expires: November 8, 2014 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-06.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 version only includes support for three Elliptic Curve 17 groups, and there is a fixed hash algorithm tied to each group. This 18 document generalizes IKEv2 signature support to allow any signature 19 method supported by the PKIX and also adds signature hash algorithm 20 negotiation. This is a generic mechanism, and 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 November 8, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . 7 61 5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11 69 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12 70 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12 71 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12 72 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12 73 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13 74 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13 76 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13 77 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14 79 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14 80 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14 81 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14 82 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 15 83 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 15 84 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15 85 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16 86 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16 87 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 This document adds a new IKEv2 ([RFC5996]) authentication method to 93 support signature methods in a more general way. The current 94 signature-based authentication methods in IKEv2 are per-algorithm, 95 i.e. there is one for RSA digital signatures, one for DSS digital 96 signatures (using SHA-1) and three for different ECDSA curves, each 97 tied to exactly one hash algorithm. This design is cumbersome when 98 more signature algorithms, hash algorithms and elliptic curves need 99 to be supported: 101 o The RSA digital signature format in IKEv2 is specified to use 102 RSASSA-PKCS1-v1_5 padding, but "Additional Algorithms and 103 Identifiers for RSA Cryptography for use in PKIX Profile" 104 ([RFC4055])) recommends the use of the newer RSASSA_PSS (See 105 section 5 of [RFC4055]) instead. 106 o With ECDSA and DSS there is no way to extract the hash algorithm 107 from the signature. Thus, for each new hash function to be 108 supported with ECDSA or DSA, new authentication methods would be 109 needed. Support for new hash functions is particularly needed for 110 DSS because the current restriction to SHA-1 limits its security, 111 meaning there is no point of using long keys with SHA-1. 112 o The tying of ECDSA authentication methods to particular elliptic 113 curve groups requires definition of additional methods for each 114 new group. The combination of new ECDSA groups and hash functions 115 will cause the number of required authentication methods to become 116 unmanageable. Furthermore, the restriction of ECDSA 117 authentication to a specific group is inconsistent with the 118 approach taken with DSS. 120 With the selection of SHA-3, it might be possible that a signature 121 method can be used with either SHA-3 or SHA-2. This means that a new 122 mechanism for negotiating the hash algorithm for a signature 123 algorithm is needed. 125 This document specifies two things: 127 1. A new authentication method which includes enough information 128 inside the Authentication payload data so that the signature hash 129 algorithm can be extracted (see Section 3). 130 2. A method to indicate supported signature hash algorithms (see 131 Section 4). This allows the peer to know which hash algorithms 132 are supported by the other end and use one of them (provided one 133 is allowed by policy). There is no requirement to actually 134 negotiate one common hash algorithm, as different hash algorithms 135 can be used in different directions if needed. 137 The new digital signature method is flexible enough to include all 138 current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.), and 139 add new methods (ECGDSA, ElGamal, etc.) in the future. To support 140 this flexibility, the signature algorithm is specified in the same 141 way that PKIX ([RFC5280]) specifies the signature of the Digital 142 Certificate, by placing a simple ASN.1 object before the actual 143 signature data. This ASN.1 object contains an OID specifying the 144 algorithm and associated parameters. When an IKEv2 implementation 145 supports a fixed set of signature methods with commonly used 146 parameters, it is acceptable for the implementation to treat the 147 ASN.1 object as a binary blob which can be compared against the fixed 148 set of known values. IKEv2 implementations can also parse the ASN.1 149 and extract the signature algorithm and associated parameters. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 3. Authentication Payload 159 This document specifies a new "Digital Signature" authentication 160 method. This method can be used with any type of signature. As the 161 authentication methods are not negotiated in IKEv2, the peer is only 162 allowed to use this authentication method if the Notify payload of 163 type SIGNATURE_HASH_ALGORITHMS has been sent and received by each 164 peer. 166 In this authentication method, the Authentication Data field inside 167 the Authentication Payload does not just include the signature value, 168 as do other existing IKEv2 Authentication Payloads. Instead, the 169 signature value is prefixed with an ASN.1 object indicating the 170 algorithm used to generate the signature. The ASN.1 object contains 171 the algorithm identification OID, which identifies both the signature 172 algorithm and the hash used when calculating the signature. In 173 addition to the OID, the ASN.1 object can contain optional parameters 174 which might be needed for algorithms such as RSASSA-PSS (Section 8.1 175 of [RFC3447]). 177 To make implementations easier, the ASN.1 object is prefixed by the 178 8-bit length field. This length field allows simple implementations 179 to know the length of the ASN.1 object without the need to parse it, 180 so they can use it as a binary blob to be compared against known 181 signature algorithm ASN.1 objects. Thus, simple implementations may 182 not need to be able to parse or generate ASN.1 objects. See 183 Appendix A for commonly used ASN.1 objects. 185 The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier 186 of PKIX (Section 4.1.1.2 of [RFC5280]), encoded using distinguished 187 encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the 188 ASN.1 specifies the signature algorithm and the hash function, both 189 of which are needed for signature verification. 191 Currently, only the RSASSA-PSS signature algorithm uses the optional 192 parameters. For other signature algorithms, the parameters are 193 either NULL or missing. Note, that for some algorithms there are two 194 possible ASN.1 encodings, one with optional parameters included but 195 set to NULL and the other where the optional parameters are omitted. 196 These dual encodings exist because of the way those algorithms are 197 specified. When encoding the ASN.1, implementations SHOULD use the 198 preferred format called for by the algorithm specification. If the 199 algorithm specification says "preferredPresent" then the parameters 200 object needs to be present, although it will be NULL if no parameters 201 are specified. If the algorithm specification says 202 "preferredAbsent", then the entire optional parameters object is 203 missing. 205 The Authentication payload is defined in IKEv2 as follows: 207 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Next Payload |C| RESERVED | Payload Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Auth Method | RESERVED | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 ~ Authentication Data ~ 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: Authentication Payload Format. 221 o Auth Method (1 octet) - Specifies the method of authentication 222 used. 224 Mechanism Value 225 ----------------------------------------------------------------- 226 Digital Signature 228 Computed as specified in Section 2.15 of RFC5996 using a 229 private key associated with the public key sent in the 230 Certificate payload, and using one of the hash algorithms 231 sent by the other end in the Notify payload of type 232 SIGNATURE_HASH_ALGORITHMS. If both ends send and receive 233 SIGNATURE_HASH_ALGORITHMS Notify payloads and signature 234 authentication is to be used, then the authentication 235 method specified in this Authentication payload MUST be 236 used. The format of the Authentication Data field is 237 different from other Authentication methods and is 238 specified below. 240 o Authentication Data (variable length) - see Section 2.15 of 241 RFC5996. For "Digital Signature" format, the Authentication data 242 is formatted as follows: 244 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | ASN.1 Length | AlgorithmIdentifier ASN.1 object | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ AlgorithmIdentifier ASN.1 object continuing ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 ~ Signature Value ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 2: Authentication Data Format. 260 * ASN.1 Length (1 octet) - This field contains the length of the 261 ASN.1 encoded AlgorithmIdentifier object. 262 * Algorithm Identifier (variable length) - This field contains 263 the AlgorithmIdentifier ASN.1 object. 264 * Signature Value (variable length) - This field contains the 265 actual signature value. 266 There is no padding between ASN.1 object and signature value. For 267 hash truncation, the method specified in ANSI X9.62:2005 ([X9.62]) 268 MUST be used. 270 4. Hash Algorithm Notification 272 The supported hash algorithms that can be used for the signature 273 algorithms are indicated with a Notify payload of type 274 SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange. 276 This notification also implicitly indicates support of the new 277 "Digital Signature" algorithm method, as well as the list of hash 278 functions supported by the sending peer. 280 Both ends send their list of supported hash algorithms. When 281 calculating the digital signature, a peer MUST pick one algorithm 282 sent by the other peer. Note that different algorithms can be used 283 in different directions. The algorithm OID indicating the selected 284 hash algorithm (and signature algorithm) used when calculating the 285 signature is sent inside the Authentication Data field of the 286 Authentication payload (with Auth Method of "Digital Signature" as 287 defined above). 289 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Next Payload |C| RESERVED | Payload Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Protocol ID | SPI Size | Notify Message Type | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 ~ Security Parameter Index (SPI) ~ 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 ~ Notification Data ~ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Notify Payload Format. 307 The Notify payload format is defined in RFC5996 section 3.10. When a 308 Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the 309 Protocol ID field is set to 0, the SPI Size is set to 0, and the 310 Notify Message Type is set to . 312 The Notification Data field contains the list of 16-bit hash 313 algorithm identifiers from the Hash Algorithm Identifiers for the 314 IKEv2 IANA registry. There is no padding between the hash algorithm 315 identifiers. 317 5. Selecting the Public Key Algorithm 319 This specification does not provide a way for the peers to indicate 320 the public / private key pair types they have. This raises the 321 question of how the responder selects a public / private key pair 322 type that the initiator supports. This information can be found by 323 several methods. 325 One method to signal the key the initiator wants the responder to use 326 is to indicate that in the IDr payload of the IKE_AUTH request sent 327 by the initiator. In this case, the initiator indicates that it 328 wants the responder to use a particular public / private key pair by 329 sending an IDr payload which indicates that information. In this 330 case, the responder has different identities configured, with each of 331 those identities associated to a public / private key or key type. 333 Another method to ascertain the key the initiator wants the responder 334 to use is through a Certificate Request payload sent by the 335 initiator. For example, the initiator could indicate in the 336 Certificate Request payload that it trusts a CA signed by an ECDSA 337 key. This indication implies that the initiator can process ECDSA 338 signatures, which means that the responder can safely use ECDSA keys 339 when authenticating. 341 A third method is for the responder to check the key type used by the 342 initiator, and use same key type that the initiator used. This 343 method does not work if the initiator is using shared secret or EAP 344 authentication (i.e., is not using public keys). If the initiator is 345 using public key authentication, this method is the best way for the 346 responder to ascertain the type of key the initiator supports. 348 If the initiator uses a public key type that the responder does not 349 support, the responder replies with a Notify message with error type 350 AUTHENTICATION_FAILED. If the initiator has multiple different keys, 351 it may try a different key (and perhaps a different key type) until 352 it finds a key that the other end accepts. The initiator can also 353 use the Certificate Request payload sent by the responder to help 354 decide which public key should be tried. In normal cases, when the 355 initiator has multiple public keys, out-of-band configuration is used 356 to select a public key for each connection. 358 6. Security Considerations 360 The "Recommendations for Key Management" ([NIST800-57]) table 2 361 combined with table 3 gives recommendations for how to select 362 suitable hash functions for the signature. 364 This new digital signature method does not tie the Elliptic Curve to 365 a specific hash function, which was done in the old IKEv2 ECDSA 366 methods. This means it is possible to mix different security levels. 367 For example, it is possible to use 512-bit Elliptic Curve with SHA1. 368 This means that the security of the authentication method is the 369 security of the weakest component (signature algorithm, hash 370 algorithm, or curve). This complicates the security analysis of the 371 system. Note that this kind of mixing of security levels can be 372 disallowed by policy. 374 The hash algorithm registry does not include MD5 as a supported hash 375 algorithm, as it is not considered safe enough for signature use 376 ([WY05]). 378 The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known 379 security vulnerabilities ([KA08], [ME01]) and does not allow using 380 newer padding methods such as RSASSA-PSS. The new method described 381 in this RFC allows using other padding methods. 383 The current IKEv2 protocol only allows use of normal DSA with SHA-1, 384 which means the security of the authentication is limited to the 385 security of SHA-1. This new method allows using longer keys and 386 longer hashes with DSA. 388 7. IANA Considerations 390 This document creates a new IANA registry for IKEv2 Hash Algorithms. 391 Changes and additions to this registry are by expert review. 393 The initial values of this registry are: 395 Hash Algorithm Value 396 -------------- ----- 397 RESERVED 0 398 SHA1 1 399 SHA2-256 2 400 SHA2-384 3 401 SHA2-512 4 403 MD5 is not included in the hash algorithm list as it is not 404 considered safe enough for signature hash uses. 406 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 407 private use among mutually consenting parties. 409 This specification also adds one new "IKEv2 Notify Message Types - 410 Status Types" value for SIGNATURE_HASH_ALGORITHMS, and adds one new 411 "IKEv2 Authentication Method" value for "Digital Signature". 413 8. Acknowledgements 415 Most of this work was based on the work done in the IPsecME design 416 team for the ECDSA. The design team members were: Dan Harkins, 417 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 419 9. References 421 9.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 427 Housley, R., and W. Polk, "Internet X.509 Public Key 428 Infrastructure Certificate and Certificate Revocation List 429 (CRL) Profile", RFC 5280, May 2008. 431 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 432 "Internet Key Exchange Protocol Version 2 (IKEv2)", 433 RFC 5996, September 2010. 435 9.2. Informative References 437 [CCITT.X690.2002] 438 International Telephone and Telegraph Consultative 439 Committee, "ASN.1 encoding rules: Specification of basic 440 encoding Rules (BER), Canonical encoding rules (CER) and 441 Distinguished encoding rules (DER)", CCITT Recommendation 442 X.690, July 2002. 444 [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, 445 "Variants of Bleichenbacher's Low-Exponent Attack on 446 PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. 448 [ME01] Menezes, A., "Evaluation of Security Level of 449 Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", 450 December 2001. 452 [NIST800-57] 453 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 454 "Recommendations for Key Management", NIST SP 800-57, 455 March 2007. 457 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 458 Identifiers for the Internet X.509 Public Key 459 Infrastructure Certificate and Certificate Revocation List 460 (CRL) Profile", RFC 3279, April 2002. 462 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 463 Standards (PKCS) #1: RSA Cryptography Specifications 464 Version 2.1", RFC 3447, February 2003. 466 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 467 Algorithms and Identifiers for RSA Cryptography for use in 468 the Internet X.509 Public Key Infrastructure Certificate 469 and Certificate Revocation List (CRL) Profile", RFC 4055, 470 June 2005. 472 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 473 "Elliptic Curve Cryptography Subject Public Key 474 Information", RFC 5480, March 2009. 476 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 477 Polk, "Internet X.509 Public Key Infrastructure: 478 Additional Algorithms and Identifiers for DSA and ECDSA", 479 RFC 5758, January 2010. 481 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 482 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 483 June 2010. 485 [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash 486 functions", Proceedings of EuroCrypt 2005, Lecture Notes 487 in Computer Science Vol. 3494, 2005. 489 [X9.62] American National Standards Institute, "Public Key 490 Cryptography for the Financial Services Industry: The 491 Elliptic Curve Digital Signature Algorithm (ECDSA)", 492 ANSI X9.62, November 2005. 494 Appendix A. Commonly used ASN.1 objects 496 This section lists commonly used ASN.1 objects in binary form. This 497 section is not normative, and these values should only be used as 498 examples. If the ASN.1 object listed in Appendix A and the ASN.1 499 object specified by the algorithm differ, then the algorithm 500 specification must be used. These values are taken from "New ASN.1 501 Modules for the Public Key Infrastructure Using X.509 (PKIX)" 502 ([RFC5912]). 504 A.1. PKCS#1 1.5 RSA Encryption 506 The algorithm identifiers here include several different ASN.1 507 objects with different hash algorithms. This document only includes 508 the commonly used ones, i.e. the ones using SHA-1 or SHA-2 as hash 509 function. Some other algorithms (such as MD2 and MD5) are not safe 510 enough to be used as signature hash algorithms, and are omitted. The 511 IANA registry does not have code points for these other algorithms 512 with RSA Encryption. Note that there are no optional parameters in 513 any of these algorithm identifiers, but all included here need NULL 514 optional parameters present in the ASN.1. 516 See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and 517 "Additional Algorithms and Identifiers for RSA Cryptography for use 518 in PKIX Profile" ([RFC4055]) for more information. 520 A.1.1. sha1WithRSAEncryption 522 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 523 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 525 Parameters are required, and they must be NULL. 527 Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 528 Length = 15 529 0000: 300d 0609 2a86 4886 f70d 0101 0505 00 531 A.1.2. sha256WithRSAEncryption 533 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 535 Parameters are required, and they must be NULL. 537 Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 538 Length = 15 539 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00 541 A.1.3. sha384WithRSAEncryption 543 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 545 Parameters are required, and they must be NULL. 547 Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 548 Length = 15 549 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00 551 A.1.4. sha512WithRSAEncryption 553 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 555 Parameters are required, and they must be NULL. 557 Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 558 Length = 15 559 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00 561 A.2. DSA 563 With DSA algorithms, optional parameters are always omitted. Only 564 algorithm combinations for DSA listed in the IANA registry are 565 included. 567 See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and 568 "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" 569 ([RFC5758] for more information. 571 A.2.1. dsa-with-sha1 573 dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 574 x9-57(10040) x9algorithm(4) 3 } 576 Parameters are absent. 578 Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 579 Length = 11 580 0000: 3009 0607 2a86 48ce 3804 03 582 A.2.2. dsa-with-sha256 584 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 585 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 586 id-dsa-with-sha2(3) 2 } 588 Parameters are absent. 590 Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 591 Length = 13 592 0000: 300b 0609 6086 4801 6503 0403 02 594 A.3. ECDSA 596 With ECDSA algorithms, the optional parameters are always omitted. 597 Only algorithm combinations for ECDSA listed in the IANA registry are 598 included. 600 See "Elliptic Curve Cryptography Subject Public Key Information" 601 ([RFC5480]), "Algorithms and Identifiers for PKIX Profile" 602 ([RFC3279]) and "PKIX Additional Algorithms and Identifiers for DSA 603 and ECDSA" ([RFC5758] for more information. 605 A.3.1. ecdsa-with-sha1 607 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 608 ansi-X9-62(10045) signatures(4) 1 } 610 Parameters are absent. 612 Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 613 Length = 11 614 0000: 3009 0607 2a86 48ce 3d04 01 616 A.3.2. ecdsa-with-sha256 618 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 619 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 621 Parameters are absent. 623 Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 624 Length = 12 625 0000: 300a 0608 2a86 48ce 3d04 0302 627 A.3.3. ecdsa-with-sha384 629 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 630 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 632 Parameters are absent. 634 Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 635 Length = 12 636 0000: 300a 0608 2a86 48ce 3d04 0303 638 A.3.4. ecdsa-with-sha512 640 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 641 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 643 Parameters are absent. 645 Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 646 Length = 12 647 0000: 300a 0608 2a86 48ce 3d04 0304 649 A.4. RSASSA-PSS 651 With RSASSA-PSS, the algorithm object identifier is always id-RSASSA- 652 PSS, but the hash function is taken from the optional parameters, and 653 is required. See [RFC4055] for more information. 655 A.4.1. RSASSA-PSS with empty parameters 657 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 659 Parameters are empty, but the ASN.1 part of the sequence must be 660 there. This means default parameters are used (same as the next 661 example). 663 0000 : SEQUENCE 664 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 665 000d : SEQUENCE 667 Length = 15 668 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 670 A.4.2. RSASSA-PSS with default parameters 672 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 674 Here the parameters are present, and contain the default parameters, 675 i.e. hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength 676 of 20, trailerField of 1. 678 0000 : SEQUENCE 679 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 680 000d : SEQUENCE 681 000f : CONTEXT 0 682 0011 : SEQUENCE 683 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 684 001a : NULL 685 001c : CONTEXT 1 686 001e : SEQUENCE 687 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 688 002b : SEQUENCE 689 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 690 0034 : NULL 691 0036 : CONTEXT 2 692 0038 : INTEGER 0x14 (5 bits) 693 003b : CONTEXT 3 694 003d : INTEGER 0x1 (1 bits) 695 Name = RSASSA-PSS with default parameters, 696 oid = 1.2.840.113549.1.1.10 697 Length = 64 698 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 699 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 700 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 701 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 703 A.4.3. RSASSA-PSS with SHA-256 705 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 707 Here the parameters are present, and contain hashAlgorithm of SHA- 708 256, maskGenAlgorithm of SHA-256, saltLength of 32, trailerField of 709 1. 711 0000 : SEQUENCE 712 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 713 000d : SEQUENCE 714 000f : CONTEXT 0 715 0011 : SEQUENCE 716 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 717 001e : NULL 718 0020 : CONTEXT 1 719 0022 : SEQUENCE 720 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 721 002f : SEQUENCE 722 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 723 003c : NULL 724 003e : CONTEXT 2 725 0040 : INTEGER 0x20 (6 bits) 726 0043 : CONTEXT 3 727 0045 : INTEGER 0x1 (1 bits) 729 Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 730 Length = 72 731 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 732 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 733 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 734 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 735 0040: 0201 20a3 0302 0101 737 Appendix B. IKEv2 Payload Example 738 B.1. sha1WithRSAEncryption 740 The IKEv2 AUTH payload would start like this: 742 00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648 743 00000010: 86f7 0d01 0105 0500 .... 745 Where the NN will be the next payload type (i.e. the value depends on 746 the next payload after this Authentication payload), the LL will be 747 the length of this payload, and after the sha1WithRSAEncryption ASN.1 748 block (15 bytes) there will be the actual signature, which is omitted 749 here. 751 Note to the RFC editor / IANA, replace the XX above with the newly 752 allocated authentication method type for Digital Signature, and 753 remove this note. 755 Authors' Addresses 757 Tero Kivinen 758 INSIDE Secure 759 Eerikinkatu 28 760 HELSINKI FI-00180 761 FI 763 Email: kivinen@iki.fi 765 Joel Snyder 766 Opus One 767 1404 East Lind Road 768 Tucson, AZ 85719 770 Phone: +1 520 324 0494 771 Email: jms@opus1.com