idnits 2.17.1 draft-ietf-lamps-crmf-update-algs-02.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 (21 December 2020) is 1215 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) == Missing Reference: 'HMAC' is mentioned on line 172, but not defined == Missing Reference: 'PKCS11' is mentioned on line 166, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 0 errors (**), 0 flaws (~~), 3 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) 21 December 2020 5 Intended status: Standards Track 6 Expires: 24 June 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-02 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 24 June 2021. 36 Copyright Notice 38 Copyright (c) 2020 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. Password-Based Message Authentication Code . . . . . . . . . 2 55 3.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 2 56 3.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 3 57 3.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 3 58 3.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This document updates the cryptographic algorithm requirements for 70 the Password-Based Message Authentication Code (MAC) in the Internet 71 X.509 Public Key Infrastructure Certificate Request Message Format 72 (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were 73 appropriate in 2005; however, these algorithms are no longer 74 considered the best choices. This update specifies algorithms that 75 are more appropriate today. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 3. Password-Based Message Authentication Code 87 Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies 88 on a one-way function to compute a symmetric key from the password 89 and a MAC algorithm. This section specifies algorithm requirements 90 for the one-way function and the MAC algorithm. 92 3.1. Introduction Paragraph 94 Add guidance about limiting the use of the password. 96 OLD: 98 This MAC algorithm was designed to take a shared secret (a 99 password) and use it to compute a check value over a piece of 100 information. The assumption is that, without the password, the 101 correct check value cannot be computed. The algorithm computes 102 the one-way function multiple times in order to slow down any 103 dictionary attacks against the password value. 105 NEW: 107 This MAC algorithm was designed to take a shared secret (a 108 password) and use it to compute a check value over a piece of 109 information. The assumption is that, without the password, the 110 correct check value cannot be computed. The algorithm computes 111 the one-way function multiple times in order to slow down any 112 dictionary attacks against the password value. The password used 113 to compute this MAC SHOULD NOT be used for any other purpose. 115 3.2. One-Way Function 117 Change the paragraph describing the "owf" as follows: 119 OLD: 121 owf identifies the algorithm and associated parameters used to 122 compute the key used in the MAC process. All implementations MUST 123 support SHA-1. 125 NEW: 127 owf identifies the algorithm and associated parameters used to 128 compute the key used in the MAC process. All implementations MUST 129 support SHA-256 [SHS]. 131 3.3. Iteration Count 133 Update the guidance on appropriate iteration count values. 135 OLD: 137 iterationCount identifies the number of times the hash is applied 138 during the key computation process. The iterationCount MUST be a 139 minimum of 100. Many people suggest using values as high as 1000 140 iterations as the minimum value. The trade off here is between 141 protection of the password from attacks and the time spent by the 142 server processing all of the different iterations in deriving 143 passwords. Hashing is generally considered a cheap operation but 144 this may not be true with all hash functions in the future. 146 NEW: 148 iterationCount identifies the number of times the hash is applied 149 during the key computation process. The iterationCount MUST be a 150 minimum of 100; however, the iterationCount SHOULD be as large as 151 server performance will allow, typically at least 10,000 152 [NISTSP800-63B]. There is a trade off between protection of the 153 password from attacks and the time spent by the server processing 154 the iterations. A lower iteration count can be used, if automated 155 generation produces shared secrets with high entropy. 157 3.4. MAC Algorithm 159 Change the paragraph describing the "mac" as follows: 161 OLD: 163 mac identifies the algorithm and associated parameters of the MAC 164 function to be used. All implementations MUST support HMAC-SHA1 165 [HMAC]. All implementations SHOULD support DES-MAC and Triple- 166 DES-MAC [PKCS11]. 168 NEW: 170 mac identifies the algorithm and associated parameters of the MAC 171 function to be used. All implementations MUST support HMAC-SHA256 172 [HMAC]. All implementations SHOULD support AES-GMAC AES [GMAC] 173 with a 128 bit key. 175 For convenience, the identifiers for these two algorithms are 176 repeated here. 178 The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]: 180 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 181 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 183 When this The algorithm identifier is used, the parameters SHOULD be 184 present. When present, the parameters MUST contain a type of NULL. 186 The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key 187 is defined in [I-D.housley-lamps-cms-aes-mac-alg]: 189 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 190 country(16) us(840) organization(1) gov(101) csor(3) 191 nistAlgorithm(4) aes(1) 9 } 193 When this algorithm identifier is used, the parameters MUST be 194 present, and the parameters MUST contain the GMACParameters structure 195 as follows: 197 GMACParameters ::= SEQUENCE { 198 nonce OCTET STRING, -- recommended size is 12 octets 199 length MACLength DEFAULT 12 } 201 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 203 The GMACParameters nonce parameter is the GMAC initialization vector. 204 The nonce may have any number of bits between 8 and 2^64, but it MUST 205 be a multiple of 8 bits. Within the scope of any GMAC key, the nonce 206 value MUST be unique. A nonce value of 12 octets can be processed 207 more efficiently, so that length for the nonce value is RECOMMENDED. 209 The GMACParameters length parameter field tells the size of the 210 message authentication code in octets. The length may have a value 211 between 12 and 16, inclusive. A length of 12 octets is RECOMMENDED. 213 4. IANA Considerations 215 This document makes no requests of the IANA. 217 5. Security Considerations 219 The security of the password-based MAC relies on the number of times 220 the hash function is applied as well as the entropy of the shared 221 secret (the password). Hardware support for hash calculation is 222 available at very low cost [PHS], which reduces the protection 223 provided by a high iterationCount value. Therefore, the entropy of 224 the password is crucial for the security of password-based MAC 225 function. In 2010, researchers showed that about half of the real- 226 world passwords can be broken with less than 150 million trials, 227 indicating a median entropy of only 27 bits [DMR]. Higher entropy 228 can be achieved by using randomly generated strings. For example, 229 assuming an alphabet of 60 characters a randomly chosen password with 230 10 characters offers 59 bits a entropy, and 20 characters offers 118 231 bits of entropy. Using a one-time password also increases the 232 security of the MAC, assuming that the integrity-protected 233 transaction will complete before the attacker is able to learn the 234 password with an offline attack. 236 Cryptographic algorithms age; they become weaker with time. As new 237 cryptanalysis techniques are developed and computing capabilities 238 improve, the work required to break a particular cryptographic 239 algorithm will reduce, making an attack on the algorithm more 240 feasible for more attackers. While it is unknown how cryptoanalytic 241 attacks will evolve, it is certain that they will get better. It is 242 unknown how much better they will become or when the advances will 243 happen. For this reason, the algorithm requirements for CRMF are 244 updated by this specification. 246 When a Password-Based MAC is used, implementations must protect the 247 password and the MAC key. Compromise of either the password or the 248 MAC key may result in the ability of an attacker to undermine 249 authentication. 251 6. Acknowledgements 253 Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Tomas 254 Gustavsson, Jonathan Hammell, Lijun Liao, Tim Polk, Mike StJohns, and 255 Sean Turner for their careful review and improvements. 257 7. References 259 7.1. Normative References 261 [AES] "Advanced encryption standard (AES)", National Institute 262 of Standards and Technology report, 263 DOI 10.6028/nist.fips.197, November 2001, 264 . 266 [GMAC] Dworkin, M., "Recommendation for block cipher modes of 267 operation :: GaloisCounter Mode (GCM) and GMAC", National 268 Institute of Standards and Technology report, 269 DOI 10.6028/nist.sp.800-38d, 2007, 270 . 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 278 Certificate Request Message Format (CRMF)", RFC 4211, 279 DOI 10.17487/RFC4211, September 2005, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 287 Standards and Technology report, 288 DOI 10.6028/nist.fips.180-4, July 2015, 289 . 291 7.2. Informative References 293 [DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password 294 Strength: An Empirical Analysis", 2010 Proceedings 295 IEEE INFOCOM, DOI 10.1109/infcom.2010.5461951, March 2010, 296 . 298 [I-D.housley-lamps-cms-aes-mac-alg] 299 Housley, R., "Using the AES-GMAC Algorithm with the 300 Cryptographic Message Syntax (CMS)", Work in Progress, 301 Internet-Draft, draft-housley-lamps-cms-aes-mac-alg-00, 9 302 November 2020, . 305 [NISTSP800-63B] 306 Grassi, P., Fenton, J., Newton, E., Perlner, R., 307 Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., 308 Danker, J., Choong, Y., Greene, K., and M. Theofanos, 309 "Digital identity guidelines: authentication and lifecycle 310 management", National Institute of Standards and 311 Technology report, DOI 10.6028/nist.sp.800-63b, June 2017, 312 . 314 [PHS] Pathirana, A., Halgamuge, M., and A. Syed, "Energy 315 efficient bitcoin mining to maximize the mining profit: 316 Using data from 119 bitcoin mining hardware setups", 317 International Conference on Advances in Business 318 Management and Information Technology, pp 1-14, November 319 2019. 321 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 322 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 323 RFC 4231, DOI 10.17487/RFC4231, December 2005, 324 . 326 Author's Address 328 Russ Housley 329 Vigil Security, LLC 330 516 Dranesville Road 331 Herndon, VA, 20170 332 United States of America 333 Email: housley@vigilsec.com