idnits 2.17.1 draft-kivinen-ipsecme-signature-auth-05.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 (March 28, 2014) is 3676 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) Summary: 1 error (**), 0 flaws (~~), 2 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 March 28, 2014 5 Updates: RFC 5996 (if approved) 6 Intended status: Standards Track 7 Expires: September 29, 2014 9 Signature Authentication in IKEv2 10 draft-kivinen-ipsecme-signature-auth-05.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 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 is generic mechanism, and is not 21 limited to ECDSA, but can also be used with other signature 22 algorithms. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 29, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 61 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6 62 5. Selecting Public Key Algorithm . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11 70 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 11 71 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 11 72 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12 73 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12 74 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 12 75 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 12 77 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13 78 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 13 80 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 13 81 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14 82 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14 83 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 14 84 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 14 85 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15 86 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 15 87 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16 88 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 16 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 This document adds new IKEv2 ([RFC5996]) authentication method to 94 support all kinds of signature methods. The current signature based 95 authentication methods in the IKEv2 are per algorithm, i.e. there is 96 one for RSA Digital signatures, one for DSS Digital Signatures (using 97 SHA-1) and three for different ECDSA curves each tied to exactly one 98 hash algorithm. This design starts to be cumbersome when more 99 signature algorithms, hash algorithms and elliptic curves are to be 100 supported: 102 o The RSA Digital Signatures format in the IKEv2 is specified to use 103 RSASSA-PKCS1-v1_5 padding, but Additional RSA Algorithms and 104 Identifiers for X.509 document recommends the use of the newer 105 RSASSA_PSS (See 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 it. 112 o The tying of ECDSA authentication methods to particular elliptic 113 curve groups requires definition of additional methods for each 114 new group. By combination of new ECDSA groups with various hash 115 functions the number of required authentication methods may grow 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 is seen that it might be possible 121 that in the future the signature methods are used with SHA-3 also, 122 not only SHA-2. This means new mechanism for negotiating the hash 123 algorithm for the signature algorithms is needed. 125 This documents specifies two things, one is one new authentication 126 method, which includes enough information inside the Authentication 127 payload data that the signature hash algorithm can be extracted from 128 there (see Section 3). The another thing is to add indication of 129 supported signature hash algorithms by the peer (see Section 4). 130 This allows peer to know which hash algorithms are supported by the 131 other end and use one of them (provided one is allowed by policy). 132 There is no need to actually negotiate one common hash algorithm, as 133 different hash algorithms can be used in different directions if 134 needed. 136 The new digital signature method needs to be flexible enough to 137 include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, 138 etc), and also allow adding new things in the future (ECGDSA, ElGamal 139 etc). For this the signature algorithm is specified in the same way 140 as the PKIX ([RFC5280]) specifies the signature of the Certificate, 141 i.e. there is simple ASN.1 object before the actual signature data. 142 This ASN.1 object contains the OID specifying the algorithm, and 143 associated parameters to it. In normal case the IKEv2 144 implementations supports fixed amount of signature methods, with 145 commonly used parameters, so it is acceptable for the implementation 146 to just treat this ASN.1 object as binary blob which is compared 147 against the known values, or the implementation can parse the ASN.1 148 and extract information from there. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 3. Authentication Payload 158 This document specifies new "Digital Signature" authentication 159 method. This method can be used with any types of signatures. As 160 the authentication methods are not negotiated in the IKEv2, the peer 161 is only allowed to use this authentication method if the 162 SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. 164 In this newly defined authentication method, the Authentication Data 165 field inside the Authentication Payload does not include only the 166 signature value, but instead the signature value is prefixed with the 167 ASN.1 object containing the algorithm used to generate the signature. 168 The ASN.1 object contains the algorithm identification OID, and this 169 OID identifies both the signature algorithm and the hash used when 170 calculating the signature. In addition to the OID there is optional 171 parameters which might be needed for algorithms like RSASSA-PSS. 173 To make implementations easier, the ASN.1 object is prefixed by the 174 8-bit length field. This length field allows simple implementations 175 to be able to know the length of the ASN.1 without the need to parse 176 it, so they can use it as binary blob which is compared against the 177 known signature algorithm ASN.1 objects, i.e. they do not need to be 178 able to parse or generate ASN.1 objects. See Appendix A for commonly 179 used ASN.1 objects. 181 The ASN.1 used here is the same ASN.1 which is used in the 182 AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) 183 encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. 184 The algorithm OID inside the ASN.1 specifies the signature algorithm 185 and the hash function, which are needed for signature verification. 186 The EC curve is always known by the peer because it needs to have the 187 certificate or the public key of the other end before it can do 188 signature verification and public key specifies the curve. 190 Currently only the RSASSA-PSS uses the parameters, for all others the 191 parameters is either NULL or missing. Note, that for some algorithms 192 there is two possible ASN.1 encoding possible, one with parameters 193 being NULL and others where the whole parameters is omitted. This is 194 because some of those algorithms are specified that way. When 195 encoding the ASN.1 implementations should use the preferred way, i.e. 196 if the algorithm specification says "preferredPresent" then parameter 197 object needs to be there (i.e. it will be NULL if no parameters is 198 specified), and if it says "preferredAbsent", then the whole 199 parameters object is missing. 201 The Authentication payload is defined in IKEv2 as follows: 203 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Next Payload |C| RESERVED | Payload Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Auth Method | RESERVED | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 ~ Authentication Data ~ 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: Authentication Payload Format. 217 o Auth Method (1 octet) - Specifies the method of authentication 218 used. 220 Mechanism Value 221 ----------------------------------------------------------------- 222 Digital Signature 223 Computed as specified in Section 2.15 of RFC5996 using a 224 private key associated with the public key sent in certificate 225 payload, and using one of the hash algorithms sent by the other 226 end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both 227 ends send and receive SIGNATURE_HASH_ALGORITHMS and signature 228 authentication is to be used, then this method MUST be used. 229 The Authentication Data field has bit different format than in 230 other Authentication methods (see below). 232 o Authentication Data (variable length) - see Section 2.15 of 233 RFC5996. For "Digital Signature" format the Authentication data 234 contains special format as follows: 236 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | ASN.1 Length | AlgorithmIdentifier ASN.1 object | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 ~ AlgorithmIdentifier ASN.1 object continuing ~ 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 ~ Signature Value ~ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2: Authentication Data Format. 252 Where the ASN.1 Length is the length of the ASN.1 encoded 253 AlgorithmIdentifier object, and after that is the actual 254 AlgorithmIdentifier ASN.1 object, followed by the actual signature 255 value. There is no padding between ASN.1 object and signature 256 value. For the hash truncation the method of X9.62 ([X9.62]) MUST 257 be used. 259 4. Hash Algorithm Notification 261 The supported hash algorithms that can be used for the signature 262 algorithms are now indicated with new SIGNATURE_HASH_ALGORITHMS 263 Notification Payload sent inside the IKE_SA_INIT exchange. This 264 notification also indicates the support of the new signature 265 algorithm method, i.e. sending this notification tells that new 266 "Digital Signature" authentication method is supported and that 267 following hash functions are supported by sending peer. Both ends 268 sends their list of supported hash-algorithms and when calculating 269 signature a peer MUST pick one algorithm sent by the other peer. 270 Note, that different algorithms can be used in different directions. 271 The algorithm OID matching selected hash algorithm (and signature 272 algorithm) used when calculating the signature is sent inside the 273 Authentication Data field of the Authentication Payload. 275 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Next Payload |C| RESERVED | Payload Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Protocol ID | SPI Size | Notify Message Type | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 ~ Security Parameter Index (SPI) ~ 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 ~ Notification Data ~ 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 3: Notify Payload Format. 293 Protocol ID is 0, SPI Size 0, and Notify Message Type . The Notification Data value contains list of 16-bit 295 hash algorithm identifiers from the newly created Hash Algorithm 296 Identifiers for the IKEv2 IANA registry. 298 5. Selecting Public Key Algorithm 300 This specification does not provide a way for the peers to indicate 301 the public / private key pair types they have. I.e. how can the 302 responder select public / private key pair type that the initiator 303 supports. There is already several ways this information can be 304 found in common cases. 306 One of the ways to find out which key the initiator wants the 307 responder to use is to indicate that in the IDr payload of the 308 IKE_AUTH request of the initiator. I.e initiator indicates that it 309 wants the responder to use certain public / private key pair by 310 sending IDr which indicates that information. This means the 311 responder needs to have different identities configured and each of 312 those identities needs to be tied up to certain public / private key 313 (or key type). 315 Another way to get this information is from the Certificate Request 316 payload sent by the initiator. For example if the initiator 317 indicates in his Certificate Request payload that it trust CA which 318 is signed by the ECDSA key, that will also indicate it can be process 319 ECDSA signatures, thus responder can safely use ECDSA keys when 320 authenticating himself. 322 Responder can also check the key type used by the initiator, and use 323 same key type than the initiator used. This does not work in case 324 the initiator is using shared secret or EAP authentication, as in 325 that case it is not using public key. If initiator is using public 326 key authentication himself this is most likely the best way for the 327 responder to find the type the initiator supports. 329 In case the initiator uses a public key type that the responder will 330 not support, the responder will reply with AUTHENTICATION_FAILED 331 error. If initiator has multiple different keys it can try different 332 key (and perhaps different key type) until it finds key that the 333 other end accepts. Initiator can also use the Certificate Request 334 payload sent by the responder to help deciding which public key 335 should be tried. In normal case if initiator has multiple public 336 keys, there is configuration that will select one of those for each 337 connection, so the proper key is know by configuration. 339 6. Security Considerations 341 The "Recommendations for Key Management" ([NIST800-57]) table 2 342 combined with table 3 gives recommendations for how to select 343 suitable hash functions for the signature. 345 This new digital signature method does not tie the EC curve to the 346 specific hash function, which was done in the old IKEv2 ECDSA 347 methods. This means it is possible to use 512-bit EC curve with 348 SHA1, i.e. this allows mixing different security levels. This means 349 that the security of the authentication method is the security of the 350 weakest of components (signature algorithm, hash algorithm, curve). 351 This might make the security analysis of the system bit more complex. 352 Note, that this kind of mixing of the security can be disallowed by 353 the policy. 355 The hash algorithm registry does not include MD5 as supported hash 356 algorithm, as it is not considered safe enough for signature use 357 ([WY05]). 359 The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems 360 ([KA08], [ME01]) and does not allow using newer padding methods like 361 RSASSA-PSS. This new method allows using other padding methods. 363 The current IKEv2 only allows using normal DSA with SHA-1, which 364 means the security of the regular DSA is limited to the security of 365 SHA-1. This new methods allows using longer keys and longer hashes 366 with DSA. 368 7. IANA Considerations 370 This document creates new IANA registry for IKEv2 Hash Algorithms. 371 Changes and additions to this registry is by expert review. 373 The initial values of this registry is: 375 Hash Algorithm Value 376 -------------- ----- 377 RESERVED 0 378 SHA1 1 379 SHA2-256 2 380 SHA2-384 3 381 SHA2-512 4 383 MD5 is not included to the hash algorithm list as it is not 384 considered safe enough for signature hash uses. 386 Values 5-1023 are reserved to IANA. Values 1024-65535 are for 387 private use among mutually consenting parties. 389 This specification also allocates one new IKEv2 Notify Message Types 390 - Status Types value for the SIGNATURE_HASH_ALGORITHMS, and adds new 391 value "Digital Signature" to the IKEv2 Authentication Method 392 registry. 394 8. Acknowledgements 396 Most of this work was based on the work done in the IPsecME design 397 team for the ECDSA. The design team members were: Dan Harking, 398 Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir. 400 9. References 402 9.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 408 Housley, R., and W. Polk, "Internet X.509 Public Key 409 Infrastructure Certificate and Certificate Revocation List 410 (CRL) Profile", RFC 5280, May 2008. 412 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 413 "Internet Key Exchange Protocol Version 2 (IKEv2)", 414 RFC 5996, September 2010. 416 9.2. Informative References 418 [CCITT.X690.2002] 419 International Telephone and Telegraph Consultative 420 Committee, "ASN.1 encoding rules: Specification of basic 421 encoding Rules (BER), Canonical encoding rules (CER) and 422 Distinguished encoding rules (DER)", CCITT Recommendation 423 X.690, July 2002. 425 [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, 426 "Variants of Bleichenbacher's Low-Exponent Attack on 427 PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. 429 [ME01] Menezes, A., "Evaluation of Security Level of 430 Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", 431 December 2001. 433 [NIST800-57] 434 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 435 "Recommendations for Key Management", NIST SP 800-57, 436 March 2007. 438 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 439 Identifiers for the Internet X.509 Public Key 440 Infrastructure Certificate and Certificate Revocation List 441 (CRL) Profile", RFC 3279, April 2002. 443 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 444 Algorithms and Identifiers for RSA Cryptography for use in 445 the Internet X.509 Public Key Infrastructure Certificate 446 and Certificate Revocation List (CRL) Profile", RFC 4055, 447 June 2005. 449 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 450 "Elliptic Curve Cryptography Subject Public Key 451 Information", RFC 5480, March 2009. 453 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 454 Polk, "Internet X.509 Public Key Infrastructure: 455 Additional Algorithms and Identifiers for DSA and ECDSA", 456 RFC 5758, January 2010. 458 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 459 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 460 June 2010. 462 [WY05] Wang, X. and H. Yu, "How to break MD5 and other hash 463 functions", Proceedings of EuroCrypt 2005, Lecture Notes 464 in Computer Science Vol. 3494, 2005. 466 [X9.62] American National Standards Institute, "Public Key 467 Cryptography for the Financial Services Industry: The 468 Elliptic Curve Digital Signature Algorithm (ECDSA)", 469 ANSI X9.62, November 2005. 471 Appendix A. Commonly used ASN.1 objects 473 This section lists commonly used ASN.1 objects in binary form. This 474 section is not-normative, and these values should only be used as 475 examples, i.e. if this and the actual specification of the algorithm 476 ASN.1 object is different the actual format specified in the actual 477 specification needs to be used. These values are taken from the New 478 ASN.1 Modules for the Public Key Infrastructure Using X.509 479 ([RFC5912]). 481 A.1. PKCS#1 1.5 RSA Encryption 483 These algorithm identifiers here include several different ASN.1 484 objects with different hash algorithms. In this document we only 485 include the commonly used ones i.e. the one using SHA-1, or SHA-2 as 486 hash function. Some of those other algorithms (MD2, MD5) specified 487 for this are not safe enough to be used as signature hash algorithm, 488 and some are omitted as there is no hash algorithm specified in the 489 our IANA registry for them. Note, that there is no parameters in any 490 of these, but all specified here needs to have NULL parameters 491 present in the ASN.1. 493 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and 494 Additional Algorithms and Identifiers for RSA Cryptography for PKIX 495 Profile ([RFC4055]) for more information. 497 A.1.1. sha1WithRSAEncryption 499 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 500 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 502 Parameters are required, and they must be NULL. 504 Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 505 Length = 15 506 0000: 300d 0609 2a86 4886 f70d 0101 0505 00 508 A.1.2. sha256WithRSAEncryption 510 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 512 Parameters are required, and they must be NULL. 514 Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 515 Length = 15 516 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00 518 A.1.3. sha384WithRSAEncryption 520 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 522 Parameters are required, and they must be NULL. 524 Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 525 Length = 15 526 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00 528 A.1.4. sha512WithRSAEncryption 530 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 532 Parameters are required, and they must be NULL. 534 Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 535 Length = 15 536 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00 538 A.2. DSA 540 With different DSA algorithms the parameters are always omitted. 541 Again we omit dsa-with-sha224 as there is no hash algorithm in our 542 IANA registry for it. 544 See Algorithms and Identifiers for PKIX Profile ([RFC3279]) and PKIX 545 Additional Algorithms and Identifiers for DSA and ECDSA ([RFC5758] 546 for more information. 548 A.2.1. dsa-with-sha1 550 dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 551 x9-57(10040) x9algorithm(4) 3 } 553 Parameters are absent. 555 Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 556 Length = 11 557 0000: 3009 0607 2a86 48ce 3804 03 559 A.2.2. dsa-with-sha256 561 dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 562 country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 563 id-dsa-with-sha2(3) 2 } 565 Parameters are absent. 567 Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 568 Length = 13 569 0000: 300b 0609 6086 4801 6503 0403 02 571 A.3. ECDSA 573 With different ECDSA algorithms the parameters are always omitted. 574 Again we omit ecdsa-with-sha224 as there is no hash algorithm in our 575 IANA registry for it. 577 See Elliptic Curve Cryptography Subject Public Key Information 578 ([RFC5480]), Algorithms and Identifiers for PKIX Profile ([RFC3279]) 579 and PKIX Additional Algorithms and Identifiers for DSA and ECDSA 580 ([RFC5758] for more information. 582 A.3.1. ecdsa-with-sha1 584 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 585 ansi-X9-62(10045) signatures(4) 1 } 587 Parameters are absent. 589 Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 590 Length = 11 591 0000: 3009 0607 2a86 48ce 3d04 01 593 A.3.2. ecdsa-with-sha256 595 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 596 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } 598 Parameters are absent. 600 Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 601 Length = 12 602 0000: 300a 0608 2a86 48ce 3d04 0302 604 A.3.3. ecdsa-with-sha384 606 ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 607 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } 609 Parameters are absent. 611 Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 612 Length = 12 613 0000: 300a 0608 2a86 48ce 3d04 0303 615 A.3.4. ecdsa-with-sha512 617 ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 618 us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } 620 Parameters are absent. 622 Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 623 Length = 12 624 0000: 300a 0608 2a86 48ce 3d04 0304 626 A.4. RSASSA-PSS 628 With the RSASSA-PSS the algorithm object identifier is always id- 629 RSASSA-PSS, but the hash function is taken from the parameters, and 630 it is required. See [RFC4055] for more information. 632 A.4.1. RSASSA-PSS with empty parameters 634 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 636 Parameters are empty, but the ASN.1 part of the sequence must be 637 there. This means default parameters are used (same as the next 638 example). 640 0000 : SEQUENCE 641 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 642 000d : SEQUENCE 644 Length = 15 645 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 647 A.4.2. RSASSA-PSS with default parameters 649 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 651 Here the parameters are present, and contains the default parameters, 652 i.e. SHA-1, mgf1SHA1, saltlength of 20, trailerfield of 1. 654 0000 : SEQUENCE 655 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 656 000d : SEQUENCE 657 000f : CONTEXT 0 658 0011 : SEQUENCE 659 0013 : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) 660 001a : NULL 661 001c : CONTEXT 1 662 001e : SEQUENCE 663 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 664 002b : SEQUENCE 665 002d : OBJECT IDENTIFIER Sha-1 (1.3.14.3.2.26) 666 0034 : NULL 667 0036 : CONTEXT 2 668 0038 : INTEGER 0x14 (5 bits) 669 003b : CONTEXT 3 670 003d : INTEGER 0x1 (1 bits) 672 Name = RSASSA-PSS with default parameters, 673 oid = 1.2.840.113549.1.1.10 674 Length = 64 675 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 676 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 677 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 678 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 680 A.4.3. RSASSA-PSS with SHA-256 682 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 684 Here the parameters are present, and contains the SHA-256 for both 685 the hash and mgf, saltlength of 32, and trailerfield of 1. 687 0000 : SEQUENCE 688 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 689 000d : SEQUENCE 690 000f : CONTEXT 0 691 0011 : SEQUENCE 692 0013 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1) 693 001e : NULL 694 0020 : CONTEXT 1 695 0022 : SEQUENCE 696 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 697 002f : SEQUENCE 698 0031 : OBJECT IDENTIFIER Sha-256 (2.16.840.1.101.3.4.2.1) 699 003c : NULL 700 003e : CONTEXT 2 701 0040 : INTEGER 0x20 (6 bits) 702 0043 : CONTEXT 3 703 0045 : INTEGER 0x1 (1 bits) 705 Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 706 Length = 72 707 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 708 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 709 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 710 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 711 0040: 0201 20a3 0302 0101 713 Appendix B. IKEv2 Payload Example 715 B.1. sha1WithRSAEncryption 717 The IKEv2 AUTH payload would start like this: 719 00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648 720 00000010: 86f7 0d01 0105 0500 .... 722 Where the NN will be the next payload type (i.e. that value depends 723 on what is the next payload after this Authentication payload), the 724 LL will be the length of this payload, and after the 725 sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual 726 signature, which is omitted here. 728 Note to the RFC editor / IANA, replace the XX above with the newly 729 allocated authentication method type for Digital Signature, and 730 remove this note. 732 Author's Address 734 Tero Kivinen 735 INSIDE Secure 736 Eerikinkatu 28 737 HELSINKI FI-00180 738 FI 740 Email: kivinen@iki.fi