idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-07.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 (July 21, 2014) is 3567 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 July 21, 2014 7 Expires: January 22, 2015 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-07.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 January 22, 2015. 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 . . . . . . . . . . . . . . . . . . 11 68 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 12 69 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12 70 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12 71 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 13 72 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . 14 77 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14 79 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14 80 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15 81 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . 16 85 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16 86 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 17 87 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 In IKEv2, authentication using RSA digital signatures calls for 102 padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA_PSS 103 padding method is now recommended. (See section 5 of "Additional 104 Algorithms and Identifiers for RSA Cryptography for use in PKIX 105 Profile" [RFC4055]). 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. 373 IKEv2 peers have a series of policy databases (see [RFC4301] section 374 4.4 "Major IPsec Databases") that define which security algorithms 375 and methods should be used during establishment of security 376 associations. To help end-users select the desired security levels 377 for communications protected by IPsec, implementers may wish to 378 provide a mechanism in the IKE policy databases to limit the mixing 379 of security levels or to restrict combinations of protocols. 381 Security downgrade attacks, where more secure methods are deleted or 382 modified from a payload by a Man-in-the-Middle to force lower levels 383 of security, are not a significant concern in IKEv2 Authentication 384 Payloads as discussed in this RFC. This is because a modified AUTH 385 payload will be detected when the peer computes a signature over the 386 IKE messages. 388 One specific class of downgrade attacks requires selection of 389 catastrophically weak ciphers. In this type of attack, the Man-in- 390 the-Middle attacker is able to "break" the cryptography in real time. 391 This type of downgrade attack should be blocked by policy regarding 392 cipher algorithm selection, as discussed above. 394 The hash algorithm registry does not include MD5 as a supported hash 395 algorithm, as it is not considered safe enough for signature use 396 ([WY05]). 398 The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known 399 security vulnerabilities ([KA08], [ME01]) and does not allow using 400 newer padding methods such as RSASSA-PSS. The new method described 401 in this RFC allows using other padding methods. 403 The current IKEv2 protocol only allows use of normal DSA with SHA-1, 404 which means the security of the authentication is limited to the 405 security of SHA-1. This new method allows using longer keys and 406 longer hashes with DSA. 408 7. IANA Considerations 410 This document creates a new IANA registry for IKEv2 Hash Algorithms. 412 Changes and additions to this registry are by expert review. 414 The initial values of this registry are: 416 Hash Algorithm Value 417 -------------- ----- 418 RESERVED 0 419 SHA1 1 420 SHA2-256 2 421 SHA2-384 3 422 SHA2-512 4 424 MD5 is not included in the hash algorithm list as it is not 425 considered safe enough for signature hash uses. 427 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 428 private use among mutually consenting parties. 430 This specification also adds one new "IKEv2 Notify Message Types - 431 Status Types" value for SIGNATURE_HASH_ALGORITHMS, and adds one new 432 "IKEv2 Authentication Method" value for "Digital Signature". 434 8. Acknowledgements 436 Most of this work was based on the work done in the IPsecME design 437 team for the ECDSA. The design team members were: Dan Harkins, 438 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 440 9. References 442 9.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 448 Housley, R., and W. Polk, "Internet X.509 Public Key 449 Infrastructure Certificate and Certificate Revocation List 450 (CRL) Profile", RFC 5280, May 2008. 452 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 453 "Internet Key Exchange Protocol Version 2 (IKEv2)", 454 RFC 5996, September 2010. 456 9.2. Informative References 458 [CCITT.X690.2002] 459 International Telephone and Telegraph Consultative 460 Committee, "ASN.1 encoding rules: Specification of basic 461 encoding Rules (BER), Canonical encoding rules (CER) and 462 Distinguished encoding rules (DER)", CCITT Recommendation 463 X.690, July 2002. 465 [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, 466 "Variants of Bleichenbacher's Low-Exponent Attack on 467 PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. 469 [ME01] Menezes, A., "Evaluation of Security Level of 470 Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", 471 December 2001. 473 [NIST800-57] 474 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 475 "Recommendations for Key Management", NIST SP 800-57, 476 March 2007. 478 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 479 Identifiers for the Internet X.509 Public Key 480 Infrastructure Certificate and Certificate Revocation List 481 (CRL) Profile", RFC 3279, April 2002. 483 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 484 Standards (PKCS) #1: RSA Cryptography Specifications 485 Version 2.1", RFC 3447, February 2003. 487 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 488 Algorithms and Identifiers for RSA Cryptography for use in 489 the Internet X.509 Public Key Infrastructure Certificate 490 and Certificate Revocation List (CRL) Profile", RFC 4055, 491 June 2005. 493 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 494 Internet Protocol", RFC 4301, December 2005. 496 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 497 "Elliptic Curve Cryptography Subject Public Key 498 Information", RFC 5480, March 2009. 500 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 501 Polk, "Internet X.509 Public Key Infrastructure: 502 Additional Algorithms and Identifiers for DSA and ECDSA", 503 RFC 5758, January 2010. 505 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 506 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 507 June 2010. 509 [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash 510 functions", Proceedings of EuroCrypt 2005, Lecture Notes 511 in Computer Science Vol. 3494, 2005. 513 [X9.62] American National Standards Institute, "Public Key 514 Cryptography for the Financial Services Industry: The 515 Elliptic Curve Digital Signature Algorithm (ECDSA)", 516 ANSI X9.62, November 2005. 518 Appendix A. Commonly used ASN.1 objects 520 This section lists commonly used ASN.1 objects in binary form. This 521 section is not normative, and these values should only be used as 522 examples. If the ASN.1 object listed in Appendix A and the ASN.1 523 object specified by the algorithm differ, then the algorithm 524 specification must be used. These values are taken from "New ASN.1 525 Modules for the Public Key Infrastructure Using X.509 (PKIX)" 526 ([RFC5912]). 528 A.1. PKCS#1 1.5 RSA Encryption 530 The algorithm identifiers here include several different ASN.1 531 objects with different hash algorithms. This document only includes 532 the commonly used ones, i.e. the ones using SHA-1 or SHA-2 as hash 533 function. Some other algorithms (such as MD2 and MD5) are not safe 534 enough to be used as signature hash algorithms, and are omitted. The 535 IANA registry does not have code points for these other algorithms 536 with RSA Encryption. Note that there are no optional parameters in 537 any of these algorithm identifiers, but all included here need NULL 538 optional parameters present in the ASN.1. 540 See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and 541 "Additional Algorithms and Identifiers for RSA Cryptography for use 542 in PKIX Profile" ([RFC4055]) for more information. 544 A.1.1. sha1WithRSAEncryption 546 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 547 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 549 Parameters are required, and they must be NULL. 551 Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 552 Length = 15 553 0000: 300d 0609 2a86 4886 f70d 0101 0505 00 555 A.1.2. sha256WithRSAEncryption 557 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 559 Parameters are required, and they must be NULL. 561 Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 562 Length = 15 563 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00 565 A.1.3. sha384WithRSAEncryption 567 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 569 Parameters are required, and they must be NULL. 571 Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 572 Length = 15 573 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00 575 A.1.4. sha512WithRSAEncryption 577 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 579 Parameters are required, and they must be NULL. 581 Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 582 Length = 15 583 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00 585 A.2. DSA 587 With DSA algorithms, optional parameters are always omitted. Only 588 algorithm combinations for DSA listed in the IANA registry are 589 included. 591 See "Algorithms and Identifiers for PKIX Profile" ([RFC3279]) and 592 "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" 593 ([RFC5758] for more information. 595 A.2.1. dsa-with-sha1 597 dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 598 x9-57(10040) x9algorithm(4) 3 } 599 Parameters are absent. 601 Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 602 Length = 11 603 0000: 3009 0607 2a86 48ce 3804 03 605 A.2.2. dsa-with-sha256 607 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 608 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 609 id-dsa-with-sha2(3) 2 } 611 Parameters are absent. 613 Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 614 Length = 13 615 0000: 300b 0609 6086 4801 6503 0403 02 617 A.3. ECDSA 619 With ECDSA algorithms, the optional parameters are always omitted. 620 Only algorithm combinations for ECDSA listed in the IANA registry are 621 included. 623 See "Elliptic Curve Cryptography Subject Public Key Information" 624 ([RFC5480]), "Algorithms and Identifiers for PKIX Profile" 625 ([RFC3279]) and "PKIX Additional Algorithms and Identifiers for DSA 626 and ECDSA" ([RFC5758] for more information. 628 A.3.1. ecdsa-with-sha1 630 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 631 ansi-X9-62(10045) signatures(4) 1 } 633 Parameters are absent. 635 Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 636 Length = 11 637 0000: 3009 0607 2a86 48ce 3d04 01 639 A.3.2. ecdsa-with-sha256 641 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 642 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 644 Parameters are absent. 646 Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 647 Length = 12 648 0000: 300a 0608 2a86 48ce 3d04 0302 650 A.3.3. ecdsa-with-sha384 652 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 653 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 655 Parameters are absent. 657 Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 658 Length = 12 659 0000: 300a 0608 2a86 48ce 3d04 0303 661 A.3.4. ecdsa-with-sha512 663 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 664 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 666 Parameters are absent. 668 Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 669 Length = 12 670 0000: 300a 0608 2a86 48ce 3d04 0304 672 A.4. RSASSA-PSS 674 With RSASSA-PSS, the algorithm object identifier must always be id- 675 RSASSA-PSS, and the hash function and padding parameters are conveyed 676 in the parameters (which are not optional in this case). See 677 [RFC4055] for more information. 679 A.4.1. RSASSA-PSS with empty parameters 681 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 683 Parameters are empty, but the ASN.1 part of the sequence must be 684 present. This means default parameters are used. 686 0000 : SEQUENCE 687 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 688 000d : SEQUENCE 690 Length = 15 691 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 693 A.4.2. RSASSA-PSS with default parameters 695 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 697 Here the parameters are present, and contain the default parameters, 698 i.e. hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength 699 of 20, trailerField of 1. 701 0000 : SEQUENCE 702 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 703 000d : SEQUENCE 704 000f : CONTEXT 0 705 0011 : SEQUENCE 706 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 707 001a : NULL 708 001c : CONTEXT 1 709 001e : SEQUENCE 710 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 711 002b : SEQUENCE 712 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 713 0034 : NULL 714 0036 : CONTEXT 2 715 0038 : INTEGER 0x14 (5 bits) 716 003b : CONTEXT 3 717 003d : INTEGER 0x1 (1 bits) 719 Name = RSASSA-PSS with default parameters, 720 oid = 1.2.840.113549.1.1.10 721 Length = 64 722 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 723 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 724 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 725 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 727 A.4.3. RSASSA-PSS with SHA-256 729 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 731 Here the parameters are present, and contain hashAlgorithm of SHA- 732 256, maskGenAlgorithm of SHA-256, saltLength of 32, trailerField of 733 1. 735 0000 : SEQUENCE 736 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 737 000d : SEQUENCE 738 000f : CONTEXT 0 739 0011 : SEQUENCE 740 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 741 001e : NULL 742 0020 : CONTEXT 1 743 0022 : SEQUENCE 744 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 745 002f : SEQUENCE 746 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 747 003c : NULL 748 003e : CONTEXT 2 749 0040 : INTEGER 0x20 (6 bits) 750 0043 : CONTEXT 3 751 0045 : INTEGER 0x1 (1 bits) 753 Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 754 Length = 72 755 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 756 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 757 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 758 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 759 0040: 0201 20a3 0302 0101 761 Appendix B. IKEv2 Payload Example 763 B.1. sha1WithRSAEncryption 765 The IKEv2 AUTH payload would start like this: 767 00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648 768 00000010: 86f7 0d01 0105 0500 .... 770 Where the NN will be the next payload type (i.e. the value depends on 771 the next payload after this Authentication payload), the LL will be 772 the length of this payload, and after the sha1WithRSAEncryption ASN.1 773 block (15 bytes) there will be the actual signature, which is omitted 774 here. 776 Note to the RFC editor / IANA, replace the XX above with the newly 777 allocated authentication method type for Digital Signature, and 778 remove this note. 780 Authors' Addresses 782 Tero Kivinen 783 INSIDE Secure 784 Eerikinkatu 28 785 HELSINKI FI-00180 786 FI 788 Email: kivinen@iki.fi 790 Joel Snyder 791 Opus One 792 1404 East Lind Road 793 Tucson, AZ 85719 795 Phone: +1 520 324 0494 796 Email: jms@opus1.com