idnits 2.17.1 draft-ietf-lamps-crmf-update-algs-00.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 (10 December 2020) is 1225 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 168, but not defined == Missing Reference: 'PKCS11' is mentioned on line 162, 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) 10 December 2020 5 Intended status: Standards Track 6 Expires: 13 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-00 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 13 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This document updates the cryptographic algorithm requirements for 69 the Password-Based Message Authentication Code (MAC) in the Internet 70 X.509 Public Key Infrastructure Certificate Request Message Format 71 (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were 72 appropriate in 2005; however, these algorithms are no longer 73 considered the best choices. This update specifies algorithms that 74 are more appropriate today. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in 81 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 3. Password-Based Message Authentication Code 86 Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies 87 on a one-way function to compute a symmetric key from the password 88 and a MAC algorithm. This section specifies algorithm requirements 89 for the one-way function and the MAC algorithm. 91 3.1. Introduction Paragraph 93 Add guidance about limiting the use of the password. 95 OLD: 97 This MAC algorithm was designed to take a shared secret (a 98 password) and use it to compute a check value over a piece of 99 information. The assumption is that, without the password, the 100 correct check value cannot be computed. The algorithm computes 101 the one-way function multiple times in order to slow down any 102 dictionary attacks against the password value. 104 NEW: 106 This MAC algorithm was designed to take a shared secret (a 107 password) and use it to compute a check value over a piece of 108 information. The assumption is that, without the password, the 109 correct check value cannot be computed. The algorithm computes 110 the one-way function multiple times in order to slow down any 111 dictionary attacks against the password value. The password used 112 to compute this MAC SHOULD NOT be used for any other purpose. 114 3.2. One-Way Function 116 Change the paragraph describing the "owf" as follows: 118 OLD: 120 owf identifies the algorithm and associated parameters used to 121 compute the key used in the MAC process. All implementations MUST 122 support SHA-1. 124 NEW: 126 owf identifies the algorithm and associated parameters used to 127 compute the key used in the MAC process. All implementations MUST 128 support SHA-256 [SHS]. 130 3.3. Iteration Count 132 Update the guidance on appropriate iteration count values. 134 OLD: 136 iterationCount identifies the number of times the hash is applied 137 during the key computation process. The iterationCount MUST be a 138 minimum of 100. Many people suggest using values as high as 1000 139 iterations as the minimum value. The trade off here is between 140 protection of the password from attacks and the time spent by the 141 server processing all of the different iterations in deriving 142 passwords. Hashing is generally considered a cheap operation but 143 this may not be true with all hash functions in the future. 145 NEW: 147 iterationCount identifies the number of times the hash is applied 148 during the key computation process. The iterationCount MUST be a 149 least 10,000 [NISTSP800-63B]. There is a trade off between 150 protection of the password from attacks and the time spent by the 151 server processing the iterations. 153 3.4. MAC Algorithm 155 Change the paragraph describing the "mac" as follows: 157 OLD: 159 mac identifies the algorithm and associated parameters of the MAC 160 function to be used. All implementations MUST support HMAC-SHA1 161 [HMAC]. All implementations SHOULD support DES-MAC and Triple- 162 DES-MAC [PKCS11]. 164 NEW: 166 mac identifies the algorithm and associated parameters of the MAC 167 function to be used. All implementations MUST support HMAC-SHA256 168 [HMAC]. All implementations SHOULD support AES-GMAC AES [GMAC] 169 with a 128 bit key. 171 For convenience, the identifiers for these two algorithms are 172 repeated here. 174 The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]: 176 id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 177 us(840) rsadsi(113549) digestAlgorithm(2) 9 } 179 When this The algorithm identifier is used, the parameters SHOULD be 180 present. When present, the parameters MUST contain a type of NULL. 182 The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key 183 is defined in [I-D.housley-lamps-cms-aes-mac-alg]: 185 id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 186 country(16) us(840) organization(1) gov(101) csor(3) 187 nistAlgorithm(4) aes(1) 9 } 189 When this The algorithm identifier is used, the parameters MUST be 190 present, and the parameters MUST contain the GMACParameters structure 191 as follows: 193 GMACParameters ::= SEQUENCE { 194 nonce OCTET STRING, -- recommended size is 12 octets 195 length MACLength DEFAULT 12 } 197 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 199 The GMACParameters nonce parameter is the GMAC initialization vector. 200 The nonce may have any number of bits between 8 and 2^64, but it MUST 201 be a multiple of 8 bits. Within the scope of any GMAC key, the nonce 202 value MUST be unique. A nonce value of 12 octets can be processed 203 more efficiently, so that length for the nonce value is RECOMMENDED. 205 The GMACParameters length parameter field tells the size of the 206 message authentication code in octets. The length may have a value 207 between 12 and 16, inclusive. A length of 12 octets is RECOMMENDED. 209 4. IANA Considerations 211 This document makes no requests of the IANA. 213 5. Security Considerations 215 The security of the password-based MAC relies on the number of times 216 the hash function is applied as well as the entropy of the shared 217 secret (the password). Hardware support for hash calculation is 218 available at very low cost [CHIP], which reduces the protection 219 provided by a high iterationCount value. Therefore, the entropy of 220 the used shared secret (the password) is crucial for the security of 221 password-based MAC function. High entropy can be achieved by using 222 randomly generated strings. For example, assuming an alphabet of 60 223 characters a randomly chosen password with 10 characters offers 59 224 bits a entropy, and 20 characters offers 118 bits of entropy. Using 225 a one-time password also increases the security of the MAC, assuming 226 that the integrity-protected transaction will complete before the 227 attacker is able to learn the password with an offline attack. 229 Cryptographic algorithms age; they become weaker with time. As new 230 cryptanalysis techniques are developed and computing capabilities 231 improve, the work required to break a particular cryptographic 232 algorithm will reduce, making an attack on the algorithm more 233 feasible for more attackers. While it is unknown how cryptoanalytic 234 attacks will evolve, it is certain that they will get better. It is 235 unknown how much better they will become or when the advances will 236 happen. For this reason, the algorithm requirements for CRMF are 237 updated by this specification. 239 When a Password-Based MAC is used, implementations must protect the 240 password and the MAC key. Compromise of either the password or the 241 MAC key may result in the ability of an attacker to undermine 242 authentication. 244 6. References 246 6.1. Normative References 248 [AES] "Advanced encryption standard (AES)", National Institute 249 of Standards and Technology report, 250 DOI 10.6028/nist.fips.197, November 2001, 251 . 253 [GMAC] Dworkin, M., "Recommendation for block cipher modes of 254 operation :: GaloisCounter Mode (GCM) and GMAC", National 255 Institute of Standards and Technology report, 256 DOI 10.6028/nist.sp.800-38d, 2007, 257 . 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 265 Certificate Request Message Format (CRMF)", RFC 4211, 266 DOI 10.17487/RFC4211, September 2005, 267 . 269 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 270 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 271 May 2017, . 273 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 274 Standards and Technology report, 275 DOI 10.6028/nist.fips.180-4, July 2015, 276 . 278 6.2. Informative References 280 [CHIP] Pham, H., Tran, T., Phan, T., Duong Le, V., Lam, D., and 281 Y. Nakashima, "Double SHA-256 Hardware Architecture With 282 Compact Message Expander for Bitcoin Mining", IEEE 283 Access Vol. 8, pp. 139634-139646, 284 DOI 10.1109/access.2020.3012581, 2020, 285 . 287 [I-D.housley-lamps-cms-aes-mac-alg] 288 Housley, R., "Using the AES-GMAC Algorithm with the 289 Cryptographic Message Syntax (CMS)", Work in Progress, 290 Internet-Draft, draft-housley-lamps-cms-aes-mac-alg-00, 9 291 November 2020, . 294 [NISTSP800-63B] 295 Grassi, P., Fenton, J., Newton, E., Perlner, R., 296 Regenscheid, A., Burr, W., Richer, J., Lefkovitz, N., 297 Danker, J., Choong, Y., Greene, K., and M. Theofanos, 298 "Digital identity guidelines: authentication and lifecycle 299 management", National Institute of Standards and 300 Technology report, DOI 10.6028/nist.sp.800-63b, June 2017, 301 . 303 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 304 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 305 RFC 4231, DOI 10.17487/RFC4231, December 2005, 306 . 308 Author's Address 310 Russ Housley 311 Vigil Security, LLC 312 516 Dranesville Road 313 Herndon, VA, 20170 314 United States of America 316 Email: housley@vigilsec.com