idnits 2.17.1 draft-housley-lamps-cms-aes-mac-alg-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 : ---------------------------------------------------------------------------- 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 (9 November 2020) is 1261 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' Summary: 0 errors (**), 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 9 November 2020 5 Expires: 13 May 2021 7 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) 8 draft-housley-lamps-cms-aes-mac-alg-00 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 13 May 2021. 33 Copyright Notice 35 Copyright (c) 2020 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 59 8.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 This document specifies the conventions for using the AES-GMAC 65 [AES][GCM] Message Authentication Code (MAC) algorithm with the 66 Cryptographic Message Syntax (CMS) [RFC5652]. 68 2. Terminology 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 72 "OPTIONAL" in this document are to be interpreted as described in 73 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 74 capitals, as shown here. 76 3. Message Authentication Code Algorithms 78 This section specifies the conventions employed by CMS [RFC5652] 79 implementations that support the AES-GMAC [AES][GCM] Message 80 Authentication Code (MAC) algorithm. 82 MAC algorithm identifiers are located in the AuthenticatedData 83 macAlgorithm field. 85 MAC values are located in the AuthenticatedData mac field. 87 3.1. AES-GMAC 89 The AES-GMAC [AES][GCM] Message Authentication Code (MAC) algorithm 90 uses one of the following algorithm identifiers; the choice depends 91 on the size of the AES key, which is either 128 bits, 192 bits, or 92 256 bits: 94 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 95 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 97 id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 } 99 id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 } 101 id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 } 103 For all three of these algorithm identifier values, the 104 AlgorithmIdentifier parameters field MUST be present, and the 105 parameters MUST contain GMACParameters: 107 GMACParameters ::= SEQUENCE { 108 nonce OCTET STRING, -- recommended size is 12 octets 109 length MACLength DEFAULT 12 } 111 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 113 The GMACParameters nonce parameter is the GMAC initialization vector. 114 The nonce may have any number of bits between 8 and 2^64, but it MUST 115 be a multiple of 8 bits. Within the scope of any content- 116 authentication key, the nonce value MUST be unique. A nonce value of 117 12 octets can be processed more efficiently, so that length for the 118 nonce value is RECOMMENDED. 120 The GMACParameters length parameter field tells the size of the 121 message authentication code. It MUST match the size in octets of the 122 value in the AuthenticatedData mac field. A length of 12 octets is 123 RECOMMENDED. 125 4. Implementation Considerations 127 An implementation of the Advanced Encryption Standard (AES) Galois/ 128 Counter Mode (GCM) authenticated encryption algorithm is specified in 129 [GCM]. An implementation of AES-GCM can be used to compute the GMAC 130 message authentication code by providing the content-authentication 131 key as the AES key, the nonce as the initialization vector, a zero- 132 length plaintext content, and the content to be authenticated as the 133 additional authenticated data (AAD). The result of the AES-GCM 134 invocation the AES-GMAC authentication code, which is called the 135 authentication tag in some implementations. In AES-GCM, the 136 encryption step is skipped when a zero-length input plaintext is 137 provided; therefore, any value returned for ciphertext is ignored. 139 5. ASN.1 Module 141 The following ASN.1 module uses the definition for MAC-ALGORITHM from 142 [RFC5912]. 144 CryptographicMessageSyntaxGMACAlgorithms 145 { iso(1) member-body(2) us(840) rsadsi(113549) 146 pkcs(1) pkcs-9(9) smime(16) modules(0) 147 id-mod-aes-gmac-alg-2020(TBD) } 149 DEFINITIONS IMPLICIT TAGS ::= 150 BEGIN 152 -- EXPORTS All 154 IMPORTS 155 AlgorithmIdentifier{}, MAC-ALGORITHM 156 FROM AlgorithmInformation-2009 -- from [RFC5912] 157 { iso(1) identified-organization(3) dod(6) internet(1) 158 security(5) mechanisms(5) pkix(7) id-mod(0) 159 id-mod-algorithmInformation-02(58)} ; 161 -- Object Identifiers 163 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 164 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 166 id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 } 168 id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 } 170 id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 } 172 -- GMAC Parameters 174 GMACParameters ::= SEQUENCE { 175 nonce OCTET STRING, -- recommended size is 12 octets 176 length MACLength DEFAULT 12 } 178 MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16) 180 -- Algorithm Identifiers 182 maca-aes128-GMAC MAC-ALGORITHM ::= { 183 IDENTIFIER id-aes128-GMAC 184 PARAMS TYPE GMACParameters ARE required 185 IS-KEYED-MAC TRUE } 187 maca-aes192-GMAC MAC-ALGORITHM ::= { 188 IDENTIFIER id-aes192-GMAC 189 PARAMS TYPE GMACParameters ARE required 190 IS-KEYED-MAC TRUE } 192 maca-aes256-GMAC MAC-ALGORITHM ::= { 193 IDENTIFIER id-aes256-GMAC 194 PARAMS TYPE GMACParameters ARE required 195 IS-KEYED-MAC TRUE } 197 END -- of CryptographicMessageSyntaxGMACAlgorithms 199 6. IANA Considerations 201 IANA is asked to register object identifiers for one module 202 identifier in the "SMI Security for S/MIME Module Identifier 203 (1.2.840.113549.1.9.16.0)" registry for id-mod-aes-gmac-alg-2020. 205 7. Security Considerations 207 The CMS provides a method for authenticating data. This document 208 identifies the conventions for using the AES-GMAC algorithm with the 209 CMS. 211 The key management technique employed to distribute message- 212 authentication keys must itself provide authentication, otherwise the 213 content is delivered with integrity from an unknown source. 215 When more than two parties share the same message-authentication key, 216 data origin authentication is not provided. Any party that knows the 217 message-authentication key can compute a valid MAC, therefore the 218 content could originate from any one of the parties. 220 Implementations must randomly generate message-authentication keys. 221 The use of inadequate pseudo-random number generators (PRNGs) to 222 generate keys can result in little or no security. An attacker may 223 find it much easier to reproduce the PRNG environment that produced 224 the keys, searching the resulting small set of possibilities, rather 225 than brute force searching the whole key space. The generation of 226 quality random numbers is difficult. [RFC4086] offers important 227 guidance in this area. 229 Implementers should be aware that cryptographic algorithms become 230 weaker with time. As new cryptanalysis techniques are developed and 231 computing performance improves, the work factor to break a particular 232 cryptographic algorithm will reduce. Therefore, cryptographic 233 algorithm implementations should be modular allowing new algorithms 234 to be readily inserted. That is, implementers should be prepared to 235 regularly update the set of algorithms in their implementations. 237 8. References 239 8.1. Normative References 241 [AES] National Institute of Standards and Technology (NIST), 242 "Advanced Encryption Standard (AES)", FIPS 243 Publication 197, November 2001. 245 [GCM] M., D., "Recommendation for Block Cipher Modes of 246 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 247 Special Publication 800-38D, November 2007. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 255 RFC 5652, DOI 10.17487/RFC5652, September 2009, 256 . 258 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 259 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 260 May 2017, . 262 8.2. Informative References 264 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 265 "Randomness Requirements for Security", BCP 106, RFC 4086, 266 DOI 10.17487/RFC4086, June 2005, 267 . 269 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 270 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 271 DOI 10.17487/RFC5912, June 2010, 272 . 274 Author's Address 275 Russ Housley 276 Vigil Security, LLC 277 516 Dranesville Road 278 Herndon, VA, 20170 279 United States of America 281 Email: housley@vigilsec.com