draft-ietf-lamps-cms-aes-gmac-alg-03.txt   draft-ietf-lamps-cms-aes-gmac-alg-04.txt 
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Standards Track 27 January 2021 Intended status: Standards Track 8 March 2021
Expires: 31 July 2021 Expires: 9 September 2021
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-03 draft-ietf-lamps-cms-aes-gmac-alg-04
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 algorithms 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 Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 July 2021. This Internet-Draft will expire on 9 September 2021.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Message Authentication Code Algorithms . . . . . . . . . . . 2 3. Message Authentication Code Algorithms . . . . . . . . . . . 2
3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Implementation Considerations . . . . . . . . . . . . . . . . 3 4. Implementation Considerations . . . . . . . . . . . . . . . . 3
5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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][GCM] Message Authentication Code (MAC) algorithm with the [AES][GCM] Message Authentication Code (MAC) algorithm with the
Cryptographic Message Syntax (CMS) [RFC5652]. Cryptographic Message Syntax (CMS) [RFC5652].
2. Terminology 2. Terminology
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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
authentication tag length (MACLength) MUST be fixed.
When IV lengths other than 96 bits are used, the GHASH function is
used to process the provided IV, which introduces a potential of IV
collisions. However, IV collisions are not a concern with CMS
AuthenticatedData because a fresh content-authentication key is
usually generated for each message.
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).
This nearly ideal authentication protection is achieved for CMS
AuthenticatedData when a fresh content-authentication key is
generated for each message. However, the strength of GMAC degrades
slightly as a function of the length of the message being
authenticated [F2005][MV2005]. Implementations SHOULD use 16-octet
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 pseudo-random 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].
8. References 8. Acknowledgements
8.1. Normative References Many thanks to 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
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS "Advanced Encryption Standard (AES)", FIPS
Publication 197, November 2001. Publication 197, November 2001.
[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, November 2007.
[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
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<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>.
8.2. Informative References 9.2. Informative References
[F2005] Ferguson, N., "Authentication weaknesses in GCM", 20 May
2005, <https://csrc.nist.gov/csrc/media/projects/block-
cipher-techniques/documents/bcm/comments/cwc-gcm/
ferguson2.pdf>. Comments to the NIST Modes of Operation
process.
[MV2005] McGrew, D. and J. Viega, "GCM Update", 31 May 2005,
<https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-
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>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Agility and Selecting Mandatory-to-Implement Algorithms",
DOI 10.17487/RFC5912, June 2010, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc7696>.
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. 12 change blocks. 
15 lines changed or deleted 56 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/