rfc9044.original   rfc9044.txt 
Network Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9044 Vigil Security
Intended status: Standards Track 2 April 2021 Category: Standards Track June 2021
Expires: 4 October 2021 ISSN: 2070-1721
Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-aes-gmac-alg-05
Abstract Abstract
This document specifies the conventions for using the AES-GMAC This document specifies the conventions for using the AES-GMAC
Message Authentication Code algorithms with the Cryptographic Message Message Authentication Code algorithm with the Cryptographic Message
Syntax (CMS) as specified in RFC 5652. Syntax (CMS) as specified in RFC 5652.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 October 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9044.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology
3. Message Authentication Code Algorithms . . . . . . . . . . . 2 3. Message Authentication Code Algorithms
3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. AES-GMAC
4. Implementation Considerations . . . . . . . . . . . . . . . . 3 4. Implementation Considerations
5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4 5. ASN.1 Module
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address
1. Introduction 1. Introduction
This document specifies the conventions for using the AES-GMAC This document specifies the conventions for using the AES-GMAC [AES]
[AES][GCM] Message Authentication Code (MAC) algorithm with the [GCM] Message Authentication Code (MAC) algorithm with the
Cryptographic Message Syntax (CMS) [RFC5652]. Cryptographic Message Syntax (CMS) [RFC5652].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Message Authentication Code Algorithms 3. Message Authentication Code Algorithms
This section specifies the conventions employed by CMS [RFC5652] This section specifies the conventions employed by CMS [RFC5652]
implementations that support the AES-GMAC [AES][GCM] Message implementations that support the AES-GMAC [AES] [GCM] Message
Authentication Code (MAC) algorithm. Authentication Code (MAC) algorithm.
MAC algorithm identifiers are located in the AuthenticatedData MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field. macAlgorithm field.
MAC values are located in the AuthenticatedData mac field. MAC values are located in the AuthenticatedData mac field.
3.1. AES-GMAC 3.1. AES-GMAC
The AES-GMAC [AES][GCM] Message Authentication Code (MAC) algorithm The AES-GMAC [AES] [GCM] Message Authentication Code (MAC) algorithm
uses one of the following algorithm identifiers in the uses one of the following algorithm identifiers in the
AuthenticatedData macAlgorithm field; the choice depends on the size AuthenticatedData macAlgorithm field; the choice depends on the size
of the AES key, which is either 128 bits, 192 bits, or 256 bits: of the AES key, which is either 128 bits, 192 bits, or 256 bits:
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }
id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 } id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 }
id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 } id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 }
skipping to change at page 3, line 46 skipping to change at line 133
4. Implementation Considerations 4. Implementation Considerations
An implementation of the Advanced Encryption Standard (AES) Galois/ An implementation of the Advanced Encryption Standard (AES) Galois/
Counter Mode (GCM) authenticated encryption algorithm is specified in Counter Mode (GCM) authenticated encryption algorithm is specified in
[GCM]. An implementation of AES-GCM can be used to compute the GMAC [GCM]. An implementation of AES-GCM can be used to compute the GMAC
message authentication code by providing the content-authentication message authentication code by providing the content-authentication
key as the AES key, the nonce as the initialization vector, a zero- key as the AES key, the nonce as the initialization vector, a zero-
length plaintext content, and the content to be authenticated as the length plaintext content, and the content to be authenticated as the
additional authenticated data (AAD). The result of the AES-GCM additional authenticated data (AAD). The result of the AES-GCM
invocation is the AES-GMAC authentication code, which is called the invocation is the AES-GMAC authentication code, which is called the
authentication tag in some implementations. In AES-GCM, the "authentication tag" in some implementations. In AES-GCM, the
encryption step is skipped when no input plaintext is provided, and encryption step is skipped when no input plaintext is provided;
therefore, no ciphertext is produced. therefore, no ciphertext is produced.
The DEFAULT and RECOMMENDED values in GMACParameters were selected to The DEFAULT and RECOMMENDED values in GMACParameters were selected to
align with the parameters defined for AES-GCM in Section 3.2 of align with the parameters defined for AES-GCM in Section 3.2 of
[RFC5084]. [RFC5084].
5. ASN.1 Module 5. ASN.1 Module
The following ASN.1 module uses the definition for MAC-ALGORITHM from The following ASN.1 module uses the definition for MAC-ALGORITHM from
[RFC5912]. [RFC5912].
CryptographicMessageSyntaxGMACAlgorithms CryptographicMessageSyntaxGMACAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-aes-gmac-alg-2020(TBD) } id-mod-aes-gmac-alg-2020(72) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
AlgorithmIdentifier{}, MAC-ALGORITHM AlgorithmIdentifier{}, MAC-ALGORITHM
FROM AlgorithmInformation-2009 -- from [RFC5912] FROM AlgorithmInformation-2009 -- from [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
skipping to change at page 5, line 19 skipping to change at line 203
maca-aes256-GMAC MAC-ALGORITHM ::= { maca-aes256-GMAC MAC-ALGORITHM ::= {
IDENTIFIER id-aes256-GMAC IDENTIFIER id-aes256-GMAC
PARAMS TYPE GMACParameters ARE required PARAMS TYPE GMACParameters ARE required
IS-KEYED-MAC TRUE } IS-KEYED-MAC TRUE }
END -- of CryptographicMessageSyntaxGMACAlgorithms END -- of CryptographicMessageSyntaxGMACAlgorithms
6. IANA Considerations 6. IANA Considerations
IANA is asked to register object identifiers for one module IANA has registered the object identifier shown in Table 1 in the
identifier in the "SMI Security for S/MIME Module Identifier "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
(1.2.840.113549.1.9.16.0)" registry for id-mod-aes-gmac-alg-2020. registry.
+=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| 72 | id-mod-aes-gmac-alg-2020 | RFC 9044 |
+---------+--------------------------+------------+
Table 1
7. Security Considerations 7. Security Considerations
The CMS provides a method for authenticating data. This document The CMS provides a method for authenticating data. This document
identifies the conventions for using the AES-GMAC algorithm with the identifies the conventions for using the AES-GMAC algorithm with the
CMS. CMS.
The key management technique employed to distribute message- The key management technique employed to distribute message-
authentication keys must itself provide authentication, otherwise the authentication keys must itself provide authentication; otherwise,
content is delivered with integrity from an unknown source. the content is delivered with integrity from an unknown source.
When more than two parties share the same message-authentication key, When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the message-authentication key can compute a valid MAC; therefore, the
content could originate from any one of the parties. content could originate from any one of the parties.
Within the scope of any content-authentication key, the AES-GMAC Within the scope of any content-authentication key, the AES-GMAC
nonce value MUST be unique. Use of a nonce value more than once nonce value MUST be unique. Use of a nonce value more than once
allows an attacker to generate valid AES-GMAC authentication codes allows an attacker to generate valid AES-GMAC authentication codes
for arbitrary messages, resulting in the loss of authentication as for arbitrary messages, resulting in the loss of authentication as
described in Appendix A of [GCM]. described in Appendix A of [GCM].
Within the scope of any content-authentication key, the Within the scope of any content-authentication key, the
authentication tag length (MACLength) MUST be fixed. authentication tag length (MACLength) MUST be fixed.
If AES-GMAC is used as a building block in another algorithm (e.g., If AES-GMAC is used as a building block in another algorithm (e.g.,
as a pseudo-random function), AES-GMAC MUST be used only one time by as a pseudorandom function), AES-GMAC MUST be used only one time by
that algorithm. For instance, AES-GMAC MUST NOT be used as the that algorithm. For instance, AES-GMAC MUST NOT be used as the
pseudo-random function for PBKDF2. pseudorandom function for PBKDF2.
When IV lengths other than 96 bits are used, the GHASH function is When initialization vector (IV) lengths other than 96 bits are used,
used to process the provided IV, which introduces a potential of IV the GHASH function is used to process the provided IV, which
collisions. However, IV collisions are not a concern with CMS introduces a potential for IV collisions. However, IV collisions are
AuthenticatedData because a fresh content-authentication key is not a concern with CMS AuthenticatedData because a fresh content-
usually generated for each message. authentication key is usually generated for each message.
The probability of a successful forgery is close to 2^(-t), where t The probability of a successful forgery is close to 2^(-t), where t
is the number of bits in the authentication tag length (MACLength*8). is the number of bits in the authentication tag length (MACLength*8).
This nearly ideal authentication protection is achieved for CMS This nearly ideal authentication protection is achieved for CMS
AuthenticatedData when a fresh content-authentication key is AuthenticatedData when a fresh content-authentication key is
generated for each message. However, the strength of GMAC degrades generated for each message. However, the strength of GMAC degrades
slightly as a function of the length of the message being slightly as a function of the length of the message being
authenticated [F2005][MV2005]. Implementations SHOULD use 16-octet authenticated [F2005] [MV2005]. Implementations SHOULD use 16-octet
authentication tags for messages over 2^64 octets. authentication tags for messages over 2^64 octets.
Implementations must randomly generate message-authentication keys. Implementations must randomly generate message-authentication keys.
The use of inadequate pseudo-random number generators (PRNGs) to The use of inadequate pseudorandom number generators (PRNGs) to
generate keys can result in little or no security. An attacker may generate keys can result in little or no security. An attacker may
find it much easier to reproduce the PRNG environment that produced find it much easier to reproduce the PRNG environment that produced
the keys, searching the resulting small set of possibilities, rather the keys, searching the resulting small set of possibilities, rather
than brute force searching the whole key space. The generation of than brute-force searching the whole key space. The generation of
quality random numbers is difficult. [RFC4086] offers important quality random numbers is difficult. [RFC4086] offers important
guidance in this area. guidance in this area.
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptanalysis techniques are developed and weaker with time. As new cryptanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms algorithm implementations should be modular, allowing new algorithms
to be readily inserted. That is, implementers should be prepared to to be readily inserted. That is, implementers should be prepared to
regularly update the set of algorithms in their implementations. regularly update the set of algorithms in their implementations.
More information is available in BCP 201 [RFC7696]. More information is available in BCP 201 [RFC7696].
8. Acknowledgements 8. References
Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus
Westerlund for their careful review and thoughtful improvements.
9. References
9.1. Normative References 8.1. Normative References
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology, "Advanced
"Advanced Encryption Standard (AES)", FIPS Encryption Standard (AES)", FIPS PUB 197,
Publication 197, November 2001. DOI 10.6028/NIST.FIPS.197, November 2001,
<https://doi.org/10.6028/NIST.FIPS.197>.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007. Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 8.2. Informative References
[F2005] Ferguson, N., "Authentication weaknesses in GCM", 20 May [F2005] Ferguson, N., "Authentication weaknesses in GCM", May
2005, <https://csrc.nist.gov/csrc/media/projects/block- 2005, <https://csrc.nist.gov/csrc/media/projects/block-
cipher-techniques/documents/bcm/comments/cwc-gcm/ cipher-techniques/documents/bcm/comments/cwc-gcm/
ferguson2.pdf>. Comments to the NIST Modes of Operation ferguson2.pdf>.
process.
[MV2005] McGrew, D. and J. Viega, "GCM Update", 31 May 2005, [MV2005] McGrew, D. and J. Viega, "GCM Update", May 2005,
<https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher- <https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-
Techniques/documents/BCM/Comments/CWC-GCM/gcm-update.pdf>. Techniques/documents/BCM/Comments/CWC-GCM/gcm-update.pdf>.
Comments to the NIST Modes of Operation process.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007, RFC 5084, DOI 10.17487/RFC5084, November 2007,
<https://www.rfc-editor.org/info/rfc5084>. <https://www.rfc-editor.org/info/rfc5084>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
Acknowledgements
Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus
Westerlund for their careful review and thoughtful improvements.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA, 20170 Herndon, VA 20170
United States of America United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 34 change blocks. 
81 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/