idnits 2.17.1 draft-ietf-lamps-cms-aes-gmac-alg-04.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 (8 March 2021) is 1144 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 8 March 2021 5 Expires: 9 September 2021 7 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) 8 draft-ietf-lamps-cms-aes-gmac-alg-04 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 9 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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 When IV lengths other than 96 bits are used, the GHASH function is 235 used to process the provided IV, which introduces a potential of IV 236 collisions. However, IV collisions are not a concern with CMS 237 AuthenticatedData because a fresh content-authentication key is 238 usually generated for each message. 240 The probability of a successful forgery is close to 2^(-t), where t 241 is the number of bits in the authentication tag length (MACLength*8). 242 This nearly ideal authentication protection is achieved for CMS 243 AuthenticatedData when a fresh content-authentication key is 244 generated for each message. However, the strength of GMAC degrades 245 slightly as a function of the length of the message being 246 authenticated [F2005][MV2005]. Implementations SHOULD use 16-octet 247 authentication tags for messages over 2^64 octets. 249 Implementations must randomly generate message-authentication keys. 250 The use of inadequate pseudo-random number generators (PRNGs) to 251 generate keys can result in little or no security. An attacker may 252 find it much easier to reproduce the PRNG environment that produced 253 the keys, searching the resulting small set of possibilities, rather 254 than brute force searching the whole key space. The generation of 255 quality random numbers is difficult. [RFC4086] offers important 256 guidance in this area. 258 Implementers should be aware that cryptographic algorithms become 259 weaker with time. As new cryptanalysis techniques are developed and 260 computing performance improves, the work factor to break a particular 261 cryptographic algorithm will reduce. Therefore, cryptographic 262 algorithm implementations should be modular allowing new algorithms 263 to be readily inserted. That is, implementers should be prepared to 264 regularly update the set of algorithms in their implementations. 265 More information is available in BCP 201 [RFC7696]. 267 8. Acknowledgements 269 Many thanks to Quynh Dang, Roman Danyliw, Tim Hollebeek, Ben Kaduk, 270 Mike Ounsworth, and Magnus Westerlund for their careful review and 271 thoughtful improvements. 273 9. References 275 9.1. Normative References 277 [AES] National Institute of Standards and Technology (NIST), 278 "Advanced Encryption Standard (AES)", FIPS 279 Publication 197, November 2001. 281 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 282 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 283 Special Publication 800-38D, November 2007. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 291 RFC 5652, DOI 10.17487/RFC5652, September 2009, 292 . 294 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 295 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 296 DOI 10.17487/RFC5912, June 2010, 297 . 299 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 300 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 301 May 2017, . 303 9.2. Informative References 305 [F2005] Ferguson, N., "Authentication weaknesses in GCM", 20 May 306 2005, . Comments to the NIST Modes of Operation 309 process. 311 [MV2005] McGrew, D. and J. Viega, "GCM Update", 31 May 2005, 312 . 314 Comments to the NIST Modes of Operation process. 316 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 317 "Randomness Requirements for Security", BCP 106, RFC 4086, 318 DOI 10.17487/RFC4086, June 2005, 319 . 321 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 322 Encryption in the Cryptographic Message Syntax (CMS)", 323 RFC 5084, DOI 10.17487/RFC5084, November 2007, 324 . 326 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 327 Agility and Selecting Mandatory-to-Implement Algorithms", 328 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 329 . 331 Author's Address 332 Russ Housley 333 Vigil Security, LLC 334 516 Dranesville Road 335 Herndon, VA, 20170 336 United States of America 338 Email: housley@vigilsec.com