idnits 2.17.1 draft-housley-lamps-crmf-update-algs-01.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 (31 October 2020) is 1265 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 118, but not defined == Missing Reference: 'PKCS11' is mentioned on line 112, but not defined == Unused Reference: 'AES' is defined on line 147, but no explicit reference was found in the text -- 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 (~~), 4 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) 31 October 2020 5 Intended status: Standards Track 6 Expires: 4 May 2021 8 Algorithm Requirements Update to the Internet X.509 Public Key 9 Infrastructure Certificate Request Message Format (CRMF) 10 draft-housley-lamps-crmf-update-algs-01 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 4 May 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. One-Way Function . . . . . . . . . . . . . . . . . . . . 2 56 3.2. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 This document updates the cryptographic algorithm requirements for 65 the Password-Based Message Authentication Code (MAC) in the Internet 66 X.509 Public Key Infrastructure Certificate Request Message Format 67 (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were 68 appropriate in 2005; however, these algorithms are no longer 69 considered the best choices. This update specifies algorithms that 70 are more appropriate today. 72 2. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described in 77 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 78 capitals, as shown here. 80 3. Password-Based Message Authentication Code 82 Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies 83 on a one-way function to compute a symmetric key from the password 84 and a MAC algorithm. This section specifies algorithm requirements 85 for the one-way function and the MAC algorithm. 87 3.1. One-Way Function 89 Change the paragraph describing the "owf" as follows: 91 OLD: 93 owf identifies the algorithm and associated parameters used to 94 compute the key used in the MAC process. All implementations MUST 95 support SHA-1. 97 NEW: 99 owf identifies the algorithm and associated parameters used to 100 compute the key used in the MAC process. All implementations MUST 101 support SHA-256 [SHS]. 103 3.2. MAC Algorithm 105 Change the paragraph describing the "mac" as follows: 107 OLD: 109 mac identifies the algorithm and associated parameters of the MAC 110 function to be used. All implementations MUST support HMAC-SHA1 111 [HMAC]. All implementations SHOULD support DES-MAC and Triple- 112 DES-MAC [PKCS11]. 114 NEW: 116 mac identifies the algorithm and associated parameters of the MAC 117 function to be used. All implementations MUST support HMAC-SHA256 118 [HMAC]. All implementations SHOULD support AES-GMAC [GMAC] with a 119 128 bit key. 121 {{{ Note: Has an OID already been assigned for AES-GMAC? If not, we 122 will need to do that too. }}} 124 4. IANA Considerations 126 This document makes no requests of the IANA. 128 5. Security Considerations 130 Cryptographic algorithms age; they become weaker with time. As new 131 cryptanalysis techniques are developed and computing capabilities 132 improve, the work required to break a particular cryptographic 133 algorithm will reduce, making an attack on the algorithm more 134 feasible for more attackers. While it is unknown how cryptoanalytic 135 attacks will evolve, it is certain that they will get better. It is 136 unknown how much better they will become or when the advances will 137 happen. For this reason, the algorithm requirements for CRMF are 138 updated by this specification. 140 When a Password-Based MAC is used, implementations must protect the 141 password and the MAC key. Compromise of either the password or the 142 MAC key may result in the ability of an attacker to undermine 143 authentication. 145 6. Normative References 147 [AES] National Institute of Standards and Technology (NIST), 148 "Advanced Encryption Standard (AES)", FIPS 149 Publication 197, November 2001. 151 [GMAC] M., D., "Recommendation for Block Cipher Modes of 152 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 153 Special Publication 800-38D, November 2007. 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, 157 DOI 10.17487/RFC2119, March 1997, 158 . 160 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 161 Certificate Request Message Format (CRMF)", RFC 4211, 162 DOI 10.17487/RFC4211, September 2005, 163 . 165 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 166 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 167 May 2017, . 169 [SHS] National Institute of Standards and Technology (NIST), 170 "Secure Hash Standard", FIPS Publication 180-4, August 171 2015. 173 Author's Address 175 Russ Housley 176 Vigil Security, LLC 177 516 Dranesville Road 178 Herndon, VA, 20170 179 United States of America 181 Email: housley@vigilsec.com