idnits 2.17.1 draft-ietf-lamps-crmf-update-algs-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 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 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 (30 March 2021) is 1115 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') ** Downref: Normative reference to an Informational RFC: RFC 8018 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-05) exists of draft-ietf-lamps-cms-aes-gmac-alg-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 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) 30 March 2021 5 Intended status: Standards Track 6 Expires: 1 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-05 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 1 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 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Password-Based Message Authentication Code . . . . . . . . . 3 56 4.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 3 57 4.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 4 58 4.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 4 59 4.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This document updates the cryptographic algorithm requirements for 71 the Password-Based Message Authentication Code (MAC) in the Internet 72 X.509 Public Key Infrastructure Certificate Request Message Format 73 (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were 74 appropriate in 2005; however, these algorithms are no longer 75 considered the best choices: 77 * HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much 78 stronger alternatives [RFC6194]. 80 * DES-MAC [PKCS11] provides 56 bits of security, which is no longer 81 considered secure [WITHDRAW]. 83 * Triple-DES-MAC [PKCS11] provides 112 bits of security, which is 84 now deprecated [TRANSIT]. 86 This update specifies algorithms that are more appropriate today. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 3. Signature Key POP 98 Section 4.1 of [RFC4211] specifies the Proof-of-Possession (POP) 99 processing. This section is updated to explicitly allow the use of 100 the PBMAC1 algorithm presented in Section 7.1 of [RFC8018]. 102 OLD: 104 algId identifies the algorithm used to compute the MAC value. All 105 implementations MUST support id-PasswordBasedMAC. The details on 106 this algorithm are presented in section 4.4 108 NEW: 110 algId identifies the algorithm used to compute the MAC value. All 111 implementations MUST support id-PasswordBasedMAC as presented in 112 Section 4.4 of [RFC4211]. Implementations MAY also support PBMAC1 113 presented in Section 7.1 of [RFC8018]. 115 4. Password-Based Message Authentication Code 117 Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies 118 on a one-way function to compute a symmetric key from the password 119 and a MAC algorithm. This section specifies algorithm requirements 120 for the one-way function and the MAC algorithm. 122 4.1. Introduction Paragraph 124 Add guidance about limiting the use of the password. 126 OLD: 128 This MAC algorithm was designed to take a shared secret (a 129 password) and use it to compute a check value over a piece of 130 information. The assumption is that, without the password, the 131 correct check value cannot be computed. The algorithm computes 132 the one-way function multiple times in order to slow down any 133 dictionary attacks against the password value. 135 NEW: 137 This MAC algorithm was designed to take a shared secret (a 138 password) and use it to compute a check value over a piece of 139 information. The assumption is that, without the password, the 140 correct check value cannot be computed. The algorithm computes 141 the one-way function multiple times in order to slow down any 142 dictionary attacks against the password value. The password used 143 to compute this MAC SHOULD NOT be used for any other purpose. 145 4.2. One-Way Function 147 Change the paragraph describing the "owf" as follows: 149 OLD: 151 owf identifies the algorithm and associated parameters used to 152 compute the key used in the MAC process. All implementations MUST 153 support SHA-1. 155 NEW: 157 owf identifies the algorithm and associated parameters used to 158 compute the key used in the MAC process. All implementations MUST 159 support SHA-256 [SHS]. 161 4.3. Iteration Count 163 Update the guidance on appropriate iteration count values. 165 OLD: 167 iterationCount identifies the number of times the hash is applied 168 during the key computation process. The iterationCount MUST be a 169 minimum of 100. Many people suggest using values as high as 1000 170 iterations as the minimum value. The trade off here is between 171 protection of the password from attacks and the time spent by the 172 server processing all of the different iterations in deriving 173 passwords. Hashing is generally considered a cheap operation but 174 this may not be true with all hash functions in the future. 176 NEW: 178 iterationCount identifies the number of times the hash is applied 179 during the key computation process. The iterationCount MUST be a 180 minimum of 100; however, the iterationCount SHOULD be as large as 181 server performance will allow, typically at least 10,000 [DIGALM]. 182 There is a trade off between protection of the password from 183 attacks and the time spent by the server processing the 184 iterations. As part of that tradeoff, an iteration count smaller 185 than 10,000 can be used when automated generation produces shared 186 secrets with high entropy. 188 4.4. MAC Algorithm 190 Change the paragraph describing the "mac" as follows: 192 OLD: 194 mac identifies the algorithm and associated parameters of the MAC 195 function to be used. All implementations MUST support HMAC-SHA1 196 [HMAC]. All implementations SHOULD support DES-MAC and Triple- 197 DES-MAC [PKCS11]. 199 NEW: 201 mac identifies the algorithm and associated parameters of the MAC 202 function to be used. All implementations MUST support HMAC-SHA256 203 [HMAC]. All implementations SHOULD support AES-GMAC AES [GMAC] 204 with a 128 bit key. 206 For convenience, the identifiers for these two algorithms are 207 repeated here. 209 The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]: 211 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 212 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 214 When this algorithm identifier is used, the parameters SHOULD be 215 present. When present, the parameters MUST contain a type of NULL. 217 The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key 218 is defined in [I-D.ietf-lamps-cms-aes-gmac-alg]: 220 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 221 country(16) us(840) organization(1) gov(101) csor(3) 222 nistAlgorithm(4) aes(1) 9 } 224 When this algorithm identifier is used, the parameters MUST be 225 present, and the parameters MUST contain the GMACParameters structure 226 as follows: 228 GMACParameters ::= SEQUENCE { 229 nonce OCTET STRING, 230 length MACLength DEFAULT 12 } 232 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 234 The GMACParameters nonce parameter is the GMAC initialization vector. 235 The nonce may have any number of bits between 8 and (2^64)-1, but it 236 MUST be a multiple of 8 bits. Within the scope of any GMAC key, the 237 nonce value MUST be unique. A nonce value of 12 octets can be 238 processed more efficiently, so that length for the nonce value is 239 RECOMMENDED. 241 The GMACParameters length parameter field tells the size of the 242 message authentication code in octets. GMAC supports lengths between 243 12 and 16 octets, inclusive. However, for use with CRMF, the maximum 244 length of 16 octets MUST be used. 246 5. IANA Considerations 248 This document makes no requests of the IANA. 250 6. Security Considerations 252 The security of the password-based MAC relies on the number of times 253 the hash function is applied as well as the entropy of the shared 254 secret (the password). Hardware support for hash calculation is 255 available at very low cost [PHS], which reduces the protection 256 provided by a high iterationCount value. Therefore, the entropy of 257 the password is crucial for the security of the password-based MAC 258 function. In 2010, researchers showed that about half of the real- 259 world passwords can be broken with less than 150 million trials, 260 indicating a median entropy of only 27 bits [DMR]. Higher entropy 261 can be achieved by using randomly generated strings. For example, 262 assuming an alphabet of 60 characters a randomly chosen password with 263 10 characters offers 59 bits a entropy, and 20 characters offers 118 264 bits of entropy. Using a one-time password also increases the 265 security of the MAC, assuming that the integrity-protected 266 transaction will complete before the attacker is able to learn the 267 password with an offline attack. 269 Please see [RFC8018] for security considerations related to PBMAC1. 271 Please see [HMAC] and [SHS] for security considerations related to 272 HMAC-SHA256. 274 Please see [AES] and [GMAC] for security considerations related to 275 AES-GMAC. 277 Cryptographic algorithms age; they become weaker with time. As new 278 cryptanalysis techniques are developed and computing capabilities 279 improve, the work required to break a particular cryptographic 280 algorithm will reduce, making an attack on the algorithm more 281 feasible for more attackers. While it is unknown how cryptoanalytic 282 attacks will evolve, it is certain that they will get better. It is 283 unknown how much better they will become or when the advances will 284 happen. For this reason, the algorithm requirements for CRMF are 285 updated by this specification. 287 When a Password-Based MAC is used, implementations must protect the 288 password and the MAC key. Compromise of either the password or the 289 MAC key may result in the ability of an attacker to undermine 290 authentication. 292 7. Acknowledgements 294 Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman 295 Danyliw, Tomas Gustavsson, Jonathan Hammell, Tim Hollebeek, Lijun 296 Liao, Mike Ounsworth, Tim Polk, Ines Robles, Mike StJohns, and Sean 297 Turner for their careful review and improvements. 299 8. References 301 8.1. Normative References 303 [AES] National Institute of Standards and Technology, "Advanced 304 encryption standard (AES)", DOI 10.6028/nist.fips.197, 305 November 2001, . 307 [GMAC] National Institute of Standards and Technology, 308 "Recommendation for block cipher modes of operation: 309 Galois Counter Mode (GCM) and GMAC", 310 DOI 10.6028/nist.sp.800-38d, 2007, 311 . 313 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 314 Hashing for Message Authentication", RFC 2104, 315 DOI 10.17487/RFC2104, February 1997, 316 . 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, 320 DOI 10.17487/RFC2119, March 1997, 321 . 323 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 324 Certificate Request Message Format (CRMF)", RFC 4211, 325 DOI 10.17487/RFC4211, September 2005, 326 . 328 [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: 329 Password-Based Cryptography Specification Version 2.1", 330 RFC 8018, DOI 10.17487/RFC8018, January 2017, 331 . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 [SHS] National Institute of Standards and Technology, "Secure 338 Hash Standard", DOI 10.6028/nist.fips.180-4, July 2015, 339 . 341 8.2. Informative References 343 [DIGALM] National Institute of Standards and Technology, "Digital 344 identity guidelines: authentication and lifecycle 345 management", DOI 10.6028/nist.sp.800-63b, June 2017, 346 . 348 [DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password 349 Strength: An Empirical Analysis", 350 DOI 10.1109/INFCOM.2010.5461951, March 2010, 351 . 353 [I-D.ietf-lamps-cms-aes-gmac-alg] 354 Housley, R., "Using the AES-GMAC Algorithm with the 355 Cryptographic Message Syntax (CMS)", Work in Progress, 356 Internet-Draft, draft-ietf-lamps-cms-aes-gmac-alg-02, 30 357 December 2020, . 360 [PHS] Pathirana, A., Halgamuge, M., and A. Syed, "Energy 361 efficient bitcoin mining to maximize the mining profit: 362 Using data from 119 bitcoin mining hardware setups", 363 International Conference on Advances in Business 364 Management and Information Technology, pp 1-14, November 365 2019. 367 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 368 PKCS #11 v2.11: Cryptographic Token Interface Standard", 369 June 2001. 371 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 372 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 373 RFC 4231, DOI 10.17487/RFC4231, December 2005, 374 . 376 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 377 Considerations for the SHA-0 and SHA-1 Message-Digest 378 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 379 . 381 [TRANSIT] National Institute of Standards and Technology, 382 "Transitioning the use of cryptographic algorithms and key 383 lengths", NIST SP 800-131Ar2, March 2019. 385 [WITHDRAW] National Institute of Standards and Technology, "NIST 386 Withdraws Outdated Data Encryption Standard", 2 June 2005. 388 Author's Address 390 Russ Housley 391 Vigil Security, LLC 392 516 Dranesville Road 393 Herndon, VA, 20170 394 United States of America 396 Email: housley@vigilsec.com