idnits 2.17.1 draft-ietf-lamps-crmf-update-algs-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 draft header indicates that this document updates RFC4211, but the abstract doesn't seem to directly say this. It does mention RFC4211 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4211, updated by this document, for RFC5378 checks: 2000-11-29) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 April 2021) is 1106 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMAC' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') == Outdated reference: A later version (-05) exists of draft-ietf-lamps-cms-aes-gmac-alg-02 ** Downref: Normative reference to an Informational RFC: RFC 8018 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Updates: 4211 (if approved) 8 April 2021 5 Intended status: Standards Track 6 Expires: 10 October 2021 8 Algorithm Requirements Update to the Internet X.509 Public Key 9 Infrastructure Certificate Request Message Format (CRMF) 10 draft-ietf-lamps-crmf-update-algs-07 12 Abstract 14 This document updates the cryptographic algorithm requirements for 15 the Password-Based Message Authentication Code in the Internet X.509 16 Public Key Infrastructure Certificate Request Message Format (CRMF) 17 specified in RFC 4211. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 10 October 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Password-Based Message Authentication Code . . . . . . . . . 3 68 4.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 3 69 4.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 4 70 4.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 4 71 4.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 This document updates the cryptographic algorithm requirements for 83 the Password-Based Message Authentication Code (MAC) in the Internet 84 X.509 Public Key Infrastructure Certificate Request Message Format 85 (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were 86 appropriate in 2005; however, these algorithms are no longer 87 considered the best choices: 89 * HMAC-SHA1 [HMAC][SHS] is not broken yet, but there are much 90 stronger alternatives [RFC6194]. 92 * DES-MAC [PKCS11] provides 56 bits of security, which is no longer 93 considered secure [WITHDRAW]. 95 * Triple-DES-MAC [PKCS11] provides 112 bits of security, which is 96 now deprecated [TRANSIT]. 98 This update specifies algorithms that are more appropriate today. 100 CRMF is defined using Abstract Syntax Notation One (ASN.1) [X680]. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 3. Signature Key POP 112 Section 4.1 of [RFC4211] specifies the Proof-of-Possession (POP) 113 processing. This section is updated to explicitly allow the use of 114 the PBMAC1 algorithm presented in Section 7.1 of [RFC8018]. 116 OLD: 118 algId identifies the algorithm used to compute the MAC value. All 119 implementations MUST support id-PasswordBasedMAC. The details on 120 this algorithm are presented in section 4.4 122 NEW: 124 algId identifies the algorithm used to compute the MAC value. All 125 implementations MUST support id-PasswordBasedMAC as presented in 126 Section 4.4 of [RFC4211]. Implementations MAY also support PBMAC1 127 as presented in Section 7.1 of [RFC8018]. 129 4. Password-Based Message Authentication Code 131 Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies 132 on a one-way function to compute a symmetric key from the password 133 and a MAC algorithm. This section specifies algorithm requirements 134 for the one-way function and the MAC algorithm. 136 4.1. Introduction Paragraph 138 Add guidance about limiting the use of the password. 140 OLD: 142 This MAC algorithm was designed to take a shared secret (a 143 password) and use it to compute a check value over a piece of 144 information. The assumption is that, without the password, the 145 correct check value cannot be computed. The algorithm computes 146 the one-way function multiple times in order to slow down any 147 dictionary attacks against the password value. 149 NEW: 151 This MAC algorithm was designed to take a shared secret (a 152 password) and use it to compute a check value over a piece of 153 information. The assumption is that, without the password, the 154 correct check value cannot be computed. The algorithm computes 155 the one-way function multiple times in order to slow down any 156 dictionary attacks against the password value. The password used 157 to compute this MAC SHOULD NOT be used for any other purpose. 159 4.2. One-Way Function 161 Change the paragraph describing the "owf" as follows: 163 OLD: 165 owf identifies the algorithm and associated parameters used to 166 compute the key used in the MAC process. All implementations MUST 167 support SHA-1. 169 NEW: 171 owf identifies the algorithm and associated parameters used to 172 compute the key used in the MAC process. All implementations MUST 173 support SHA-256 [SHS]. 175 4.3. Iteration Count 177 Update the guidance on appropriate iteration count values. 179 OLD: 181 iterationCount identifies the number of times the hash is applied 182 during the key computation process. The iterationCount MUST be a 183 minimum of 100. Many people suggest using values as high as 1000 184 iterations as the minimum value. The trade off here is between 185 protection of the password from attacks and the time spent by the 186 server processing all of the different iterations in deriving 187 passwords. Hashing is generally considered a cheap operation but 188 this may not be true with all hash functions in the future. 190 NEW: 192 iterationCount identifies the number of times the hash is applied 193 during the key computation process. The iterationCount MUST be a 194 minimum of 100; however, the iterationCount SHOULD be as large as 195 server performance will allow, typically at least 10,000 [DIGALM]. 196 There is a trade off between protection of the password from 197 attacks and the time spent by the server processing the 198 iterations. As part of that tradeoff, an iteration count smaller 199 than 10,000 can be used when automated generation produces shared 200 secrets with high entropy. 202 4.4. MAC Algorithm 204 Change the paragraph describing the "mac" as follows: 206 OLD: 208 mac identifies the algorithm and associated parameters of the MAC 209 function to be used. All implementations MUST support HMAC-SHA1 210 [HMAC]. All implementations SHOULD support DES-MAC and Triple- 211 DES-MAC [PKCS11]. 213 NEW: 215 mac identifies the algorithm and associated parameters of the MAC 216 function to be used. All implementations MUST support HMAC-SHA256 217 [HMAC]. All implementations SHOULD support AES-GMAC [AES][GMAC] 218 with a 128-bit key. 220 For convenience, the identifiers for these two algorithms are 221 repeated here. 223 The ASN.1 algorithm identifier for HMAC-SHA256 is defined in 224 [RFC4231]: 226 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 227 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 229 When this object identifier is used in the ASN.1 algorithm 230 identifier, the parameters SHOULD be present. When present, the 231 parameters MUST contain a type of NULL as specified in [RFC4231]. 233 The ASN.1 algorithm identifier for AES-GMAC [AES][GMAC] with a 234 128-bit key is defined in [I-D.ietf-lamps-cms-aes-gmac-alg]: 236 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 237 country(16) us(840) organization(1) gov(101) csor(3) 238 nistAlgorithm(4) aes(1) 9 } 240 When this object identifier is used in the ASN.1 algorithm 241 identifier, the parameters MUST be present, and the parameters MUST 242 contain the GMACParameters structure as follows: 244 GMACParameters ::= SEQUENCE { 245 nonce OCTET STRING, 246 length MACLength DEFAULT 12 } 248 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 250 The GMACParameters nonce parameter is the GMAC initialization vector. 251 The nonce may have any number of bits between 8 and (2^64)-1, but it 252 MUST be a multiple of 8 bits. Within the scope of any GMAC key, the 253 nonce value MUST be unique. A nonce value of 12 octets can be 254 processed more efficiently, so that length for the nonce value is 255 RECOMMENDED. 257 The GMACParameters length parameter field tells the size of the 258 message authentication code in octets. GMAC supports lengths between 259 12 and 16 octets, inclusive. However, for use with CRMF, the maximum 260 length of 16 octets MUST be used. 262 5. IANA Considerations 264 This document makes no requests of the IANA. 266 6. Security Considerations 268 The security of the password-based MAC relies on the number of times 269 the hash function is applied as well as the entropy of the shared 270 secret (the password). Hardware support for hash calculation is 271 available at very low cost [PHS], which reduces the protection 272 provided by a high iterationCount value. Therefore, the entropy of 273 the password is crucial for the security of the password-based MAC 274 function. In 2010, researchers showed that about half of the real- 275 world passwords in a leaked corpus can be broken with less than 150 276 million trials, indicating a median entropy of only 27 bits [DMR]. 277 Higher entropy can be achieved by using randomly generated strings. 278 For example, assuming an alphabet of 60 characters a randomly chosen 279 password with 10 characters offers 59 bits of entropy, and 20 280 characters offers 118 bits of entropy. Using a one-time password 281 also increases the security of the MAC, assuming that the integrity- 282 protected transaction will complete before the attacker is able to 283 learn the password with an offline attack. 285 Please see [RFC8018] for security considerations related to PBMAC1. 287 Please see [HMAC] and [SHS] for security considerations related to 288 HMAC-SHA256. 290 Please see [AES] and [GMAC] for security considerations related to 291 AES-GMAC. 293 Cryptographic algorithms age; they become weaker with time. As new 294 cryptanalysis techniques are developed and computing capabilities 295 improve, the work required to break a particular cryptographic 296 algorithm will reduce, making an attack on the algorithm more 297 feasible for more attackers. While it is unknown how cryptoanalytic 298 attacks will evolve, it is certain that they will get better. It is 299 unknown how much better they will become or when the advances will 300 happen. For this reason, the algorithm requirements for CRMF are 301 updated by this specification. 303 When a Password-Based MAC is used, implementations must protect the 304 password and the MAC key. Compromise of either the password or the 305 MAC key may result in the ability of an attacker to undermine 306 authentication. 308 7. Acknowledgements 310 Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman 311 Danyliw, Lars Eggert, Tomas Gustavsson, Jonathan Hammell, Tim 312 Hollebeek, Ben Kaduk, Erik Kline, Lijun Liao, Mike Ounsworth, 313 Francesca Palombini, Tim Polk, Ines Robles, Mike StJohns, and Sean 314 Turner for their careful review and improvements. 316 8. References 318 8.1. Normative References 320 [AES] National Institute of Standards and Technology, "Advanced 321 encryption standard (AES)", DOI 10.6028/nist.fips.197, 322 November 2001, . 324 [GMAC] National Institute of Standards and Technology, 325 "Recommendation for block cipher modes of operation: 326 Galois Counter Mode (GCM) and GMAC", 327 DOI 10.6028/nist.sp.800-38d, 2007, 328 . 330 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 331 Hashing for Message Authentication", RFC 2104, 332 DOI 10.17487/RFC2104, February 1997, 333 . 335 [I-D.ietf-lamps-cms-aes-gmac-alg] 336 Housley, R., "Using the AES-GMAC Algorithm with the 337 Cryptographic Message Syntax (CMS)", Work in Progress, 338 Internet-Draft, draft-ietf-lamps-cms-aes-gmac-alg-02, 30 339 December 2020, . 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 348 Certificate Request Message Format (CRMF)", RFC 4211, 349 DOI 10.17487/RFC4211, September 2005, 350 . 352 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 353 Password-Based Cryptography Specification Version 2.1", 354 RFC 8018, DOI 10.17487/RFC8018, January 2017, 355 . 357 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 358 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 359 May 2017, . 361 [SHS] National Institute of Standards and Technology, "Secure 362 Hash Standard", DOI 10.6028/nist.fips.180-4, July 2015, 363 . 365 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 366 One (ASN.1): Specification of basic notation", 367 Recommendation X.680, 2015. 369 8.2. Informative References 371 [DIGALM] National Institute of Standards and Technology, "Digital 372 identity guidelines: authentication and lifecycle 373 management", DOI 10.6028/nist.sp.800-63b, June 2017, 374 . 376 [DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password 377 Strength: An Empirical Analysis", 378 DOI 10.1109/INFCOM.2010.5461951, March 2010, 379 . 381 [PHS] Pathirana, A., Halgamuge, M., and A. Syed, "Energy 382 efficient bitcoin mining to maximize the mining profit: 383 Using data from 119 bitcoin mining hardware setups", 384 International Conference on Advances in Business 385 Management and Information Technology, pp 1-14, November 386 2019. 388 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 389 PKCS #11 v2.11: Cryptographic Token Interface Standard", 390 June 2001. 392 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 393 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 394 RFC 4231, DOI 10.17487/RFC4231, December 2005, 395 . 397 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 398 Considerations for the SHA-0 and SHA-1 Message-Digest 399 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 400 . 402 [TRANSIT] National Institute of Standards and Technology, 403 "Transitioning the use of cryptographic algorithms and key 404 lengths", NIST SP 800-131Ar2, March 2019. 406 [WITHDRAW] National Institute of Standards and Technology, "NIST 407 Withdraws Outdated Data Encryption Standard", 2 June 2005. 409 Author's Address 411 Russ Housley 412 Vigil Security, LLC 413 516 Dranesville Road 414 Herndon, VA, 20170 415 United States of America 417 Email: housley@vigilsec.com