draft-ietf-lamps-cms-aes-gmac-alg-04.txt   draft-ietf-lamps-cms-aes-gmac-alg-05.txt 
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Standards Track 8 March 2021 Intended status: Standards Track 2 April 2021
Expires: 9 September 2021 Expires: 4 October 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-04 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 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 9 September 2021. This Internet-Draft will expire on 4 October 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 19 skipping to change at page 2, line 19
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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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.,
as a pseudo-random function), AES-GMAC MUST be used only one time by
that algorithm. For instance, AES-GMAC MUST NOT be used as the
pseudo-random function for PBKDF2.
When IV lengths other than 96 bits are used, the GHASH function is 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 used to process the provided IV, which introduces a potential of IV
collisions. However, IV collisions are not a concern with CMS collisions. However, IV collisions are not a concern with CMS
AuthenticatedData because a fresh content-authentication key is AuthenticatedData because a fresh content-authentication key is
usually generated for each message. 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
skipping to change at page 6, line 34 skipping to change at page 6, line 40
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. Acknowledgements
Many thanks to Quynh Dang, Roman Danyliw, Tim Hollebeek, Ben Kaduk, Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
Mike Ounsworth, and Magnus Westerlund for their careful review and Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus
thoughtful improvements. Westerlund for their careful review and thoughtful improvements.
9. References 9. References
9.1. Normative 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
 End of changes. 6 change blocks. 
8 lines changed or deleted 13 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/