idnits 2.17.1 draft-ietf-lamps-cms-aes-gmac-alg-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 April 2021) is 1120 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. 'GCM' ** Downref: Normative reference to an Informational RFC: RFC 5912 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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 Intended status: Standards Track 2 April 2021 5 Expires: 4 October 2021 7 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) 8 draft-ietf-lamps-cms-aes-gmac-alg-05 10 Abstract 12 This document specifies the conventions for using the AES-GMAC 13 Message Authentication Code algorithms with the Cryptographic Message 14 Syntax (CMS) as specified in RFC 5652. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 4 October 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Message Authentication Code Algorithms . . . . . . . . . . . 2 52 3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Implementation Considerations . . . . . . . . . . . . . . . . 3 54 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 9.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 This document specifies the conventions for using the AES-GMAC 66 [AES][GCM] Message Authentication Code (MAC) algorithm with the 67 Cryptographic Message Syntax (CMS) [RFC5652]. 69 2. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 73 "OPTIONAL" in this document are to be interpreted as described in 74 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 75 capitals, as shown here. 77 3. Message Authentication Code Algorithms 79 This section specifies the conventions employed by CMS [RFC5652] 80 implementations that support the AES-GMAC [AES][GCM] Message 81 Authentication Code (MAC) algorithm. 83 MAC algorithm identifiers are located in the AuthenticatedData 84 macAlgorithm field. 86 MAC values are located in the AuthenticatedData mac field. 88 3.1. AES-GMAC 90 The AES-GMAC [AES][GCM] Message Authentication Code (MAC) algorithm 91 uses one of the following algorithm identifiers in the 92 AuthenticatedData macAlgorithm field; the choice depends on the size 93 of the AES key, which is either 128 bits, 192 bits, or 256 bits: 95 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 96 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 98 id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 } 100 id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 } 102 id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 } 104 For all three of these algorithm identifier values, the 105 AlgorithmIdentifier parameters field MUST be present, and the 106 parameters MUST contain GMACParameters: 108 GMACParameters ::= SEQUENCE { 109 nonce OCTET STRING, -- recommended size is 12 octets 110 length MACLength DEFAULT 12 } 112 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 114 The GMACParameters nonce field is the GMAC initialization vector. 115 The nonce may have any number of bits between 8 and (2^64)-1, but it 116 MUST be a multiple of 8 bits. Within the scope of any content- 117 authentication key, the nonce value MUST be unique. A nonce value of 118 12 octets can be processed more efficiently, so that length for the 119 nonce value is RECOMMENDED. 121 The GMACParameters length field tells the size of the message 122 authentication code. It MUST match the size in octets of the value 123 in the AuthenticatedData mac field. A length of 12 octets is 124 RECOMMENDED. 126 4. Implementation Considerations 128 An implementation of the Advanced Encryption Standard (AES) Galois/ 129 Counter Mode (GCM) authenticated encryption algorithm is specified in 130 [GCM]. An implementation of AES-GCM can be used to compute the GMAC 131 message authentication code by providing the content-authentication 132 key as the AES key, the nonce as the initialization vector, a zero- 133 length plaintext content, and the content to be authenticated as the 134 additional authenticated data (AAD). The result of the AES-GCM 135 invocation is the AES-GMAC authentication code, which is called the 136 authentication tag in some implementations. In AES-GCM, the 137 encryption step is skipped when no input plaintext is provided, and 138 therefore, no ciphertext is produced. 140 The DEFAULT and RECOMMENDED values in GMACParameters were selected to 141 align with the parameters defined for AES-GCM in Section 3.2 of 142 [RFC5084]. 144 5. ASN.1 Module 146 The following ASN.1 module uses the definition for MAC-ALGORITHM from 147 [RFC5912]. 149 CryptographicMessageSyntaxGMACAlgorithms 150 { iso(1) member-body(2) us(840) rsadsi(113549) 151 pkcs(1) pkcs-9(9) smime(16) modules(0) 152 id-mod-aes-gmac-alg-2020(TBD) } 154 DEFINITIONS IMPLICIT TAGS ::= 155 BEGIN 157 -- EXPORTS All 159 IMPORTS 160 AlgorithmIdentifier{}, MAC-ALGORITHM 161 FROM AlgorithmInformation-2009 -- from [RFC5912] 162 { iso(1) identified-organization(3) dod(6) internet(1) 163 security(5) mechanisms(5) pkix(7) id-mod(0) 164 id-mod-algorithmInformation-02(58)} ; 166 -- Object Identifiers 168 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 169 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 171 id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 } 173 id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 } 175 id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 } 177 -- GMAC Parameters 179 GMACParameters ::= SEQUENCE { 180 nonce OCTET STRING, -- recommended size is 12 octets 181 length MACLength DEFAULT 12 } 183 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 185 -- Algorithm Identifiers 187 maca-aes128-GMAC MAC-ALGORITHM ::= { 188 IDENTIFIER id-aes128-GMAC 189 PARAMS TYPE GMACParameters ARE required 190 IS-KEYED-MAC TRUE } 192 maca-aes192-GMAC MAC-ALGORITHM ::= { 193 IDENTIFIER id-aes192-GMAC 194 PARAMS TYPE GMACParameters ARE required 195 IS-KEYED-MAC TRUE } 197 maca-aes256-GMAC MAC-ALGORITHM ::= { 198 IDENTIFIER id-aes256-GMAC 199 PARAMS TYPE GMACParameters ARE required 200 IS-KEYED-MAC TRUE } 202 END -- of CryptographicMessageSyntaxGMACAlgorithms 204 6. IANA Considerations 206 IANA is asked to register object identifiers for one module 207 identifier in the "SMI Security for S/MIME Module Identifier 208 (1.2.840.113549.1.9.16.0)" registry for id-mod-aes-gmac-alg-2020. 210 7. Security Considerations 212 The CMS provides a method for authenticating data. This document 213 identifies the conventions for using the AES-GMAC algorithm with the 214 CMS. 216 The key management technique employed to distribute message- 217 authentication keys must itself provide authentication, otherwise the 218 content is delivered with integrity from an unknown source. 220 When more than two parties share the same message-authentication key, 221 data origin authentication is not provided. Any party that knows the 222 message-authentication key can compute a valid MAC, therefore the 223 content could originate from any one of the parties. 225 Within the scope of any content-authentication key, the AES-GMAC 226 nonce value MUST be unique. Use of a nonce value more than once 227 allows an attacker to generate valid AES-GMAC authentication codes 228 for arbitrary messages, resulting in the loss of authentication as 229 described in Appendix A of [GCM]. 231 Within the scope of any content-authentication key, the 232 authentication tag length (MACLength) MUST be fixed. 234 If AES-GMAC is used as a building block in another algorithm (e.g., 235 as a pseudo-random function), AES-GMAC MUST be used only one time by 236 that algorithm. For instance, AES-GMAC MUST NOT be used as the 237 pseudo-random function for PBKDF2. 239 When IV lengths other than 96 bits are used, the GHASH function is 240 used to process the provided IV, which introduces a potential of IV 241 collisions. However, IV collisions are not a concern with CMS 242 AuthenticatedData because a fresh content-authentication key is 243 usually generated for each message. 245 The probability of a successful forgery is close to 2^(-t), where t 246 is the number of bits in the authentication tag length (MACLength*8). 247 This nearly ideal authentication protection is achieved for CMS 248 AuthenticatedData when a fresh content-authentication key is 249 generated for each message. However, the strength of GMAC degrades 250 slightly as a function of the length of the message being 251 authenticated [F2005][MV2005]. Implementations SHOULD use 16-octet 252 authentication tags for messages over 2^64 octets. 254 Implementations must randomly generate message-authentication keys. 255 The use of inadequate pseudo-random number generators (PRNGs) to 256 generate keys can result in little or no security. An attacker may 257 find it much easier to reproduce the PRNG environment that produced 258 the keys, searching the resulting small set of possibilities, rather 259 than brute force searching the whole key space. The generation of 260 quality random numbers is difficult. [RFC4086] offers important 261 guidance in this area. 263 Implementers should be aware that cryptographic algorithms become 264 weaker with time. As new cryptanalysis techniques are developed and 265 computing performance improves, the work factor to break a particular 266 cryptographic algorithm will reduce. Therefore, cryptographic 267 algorithm implementations should be modular allowing new algorithms 268 to be readily inserted. That is, implementers should be prepared to 269 regularly update the set of algorithms in their implementations. 270 More information is available in BCP 201 [RFC7696]. 272 8. Acknowledgements 274 Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman 275 Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus 276 Westerlund for their careful review and thoughtful improvements. 278 9. References 280 9.1. Normative References 282 [AES] National Institute of Standards and Technology (NIST), 283 "Advanced Encryption Standard (AES)", FIPS 284 Publication 197, November 2001. 286 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 287 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 288 Special Publication 800-38D, November 2007. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 296 RFC 5652, DOI 10.17487/RFC5652, September 2009, 297 . 299 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 300 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 301 DOI 10.17487/RFC5912, June 2010, 302 . 304 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 305 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 306 May 2017, . 308 9.2. Informative References 310 [F2005] Ferguson, N., "Authentication weaknesses in GCM", 20 May 311 2005, . Comments to the NIST Modes of Operation 314 process. 316 [MV2005] McGrew, D. and J. Viega, "GCM Update", 31 May 2005, 317 . 319 Comments to the NIST Modes of Operation process. 321 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 322 "Randomness Requirements for Security", BCP 106, RFC 4086, 323 DOI 10.17487/RFC4086, June 2005, 324 . 326 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 327 Encryption in the Cryptographic Message Syntax (CMS)", 328 RFC 5084, DOI 10.17487/RFC5084, November 2007, 329 . 331 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 332 Agility and Selecting Mandatory-to-Implement Algorithms", 333 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 334 . 336 Author's Address 338 Russ Housley 339 Vigil Security, LLC 340 516 Dranesville Road 341 Herndon, VA, 20170 342 United States of America 344 Email: housley@vigilsec.com