Internet-Draft | COSE GMAC | January 2025 |
Sipos | Expires 27 July 2025 | [Page] |
This document registers COSE algorithm code points for using the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a Message Authentication Code (AES-GMAC). The security strength provided by these registrations is identical to existing COSE registrations for AES-GCM authenticated encryption.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 July 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The base COSE specification [RFC9052] defines a container for Message Authentication Code (MAC) parameters and results. This container is parameterized on an algorithm identifier used to verify the MAC result. This document defines new fully specified algorithm identifiers for the use of Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a MAC (AES-GMAC) as defined in [SP800-38D].¶
Unlike the use of AES-GMAC in CMS [RFC9044] and IPsec [RFC4543], the COSE algorithm identifiers are "fully specified" meaning they rely on no extra parameters (e.g., tag length) to determine their exact operation.¶
This document does not define any new algorithms it only defines code points in a COSE registry so that the AES-GMAC can be used in that security environment with specific combinations of parameters.¶
To avoid confusion, the AES-GMAC algorithm family specified in this document is unrelated to the "AES-MAC" algorithm family from Section 3.2 of [RFC9053].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
While the general GMAC algorithm can be used with any underlying authenticated encryption with additional data (AEAD) block cipher, this document focuses on its use with the AES-GCM cipher.¶
The AES-GMAC defined in [SP800-38D] has a set of parameters associated with its use. For the sake of adhering to COSE best practice about fully specifying what gets assigned an "algorithm" code point, AES-GMAC will be treated as an algorithm family with a single code point referring to the algorithm itself along with a specific set of parameter values.¶
The parameters associated with AES-GMAC are: key length and tag length. This document restricts the allocated code points to the commonly used key lengths of 128, 192, and 256-bits, a fixed IV length of 96 bits (the recommended default), and restricts the use of a single tag length of 128 bits, which happens to be the longest possible tag length, as indicated in Table 1. Future allocations can define the use of AES-GMAC with shortened tag lengths.¶
One required input for AES-GMAC is an initialization vector (IV) which is already provided by the header parameter "IV" from the "COSE Header Parameters" registry of [IANA-COSE]. The use of the AES-GMAC algorithms in COSE SHALL be combined with the IV header parameter in the same COSE layer. A valid IV for these algorithms SHALL be exactly 96 bits (12 octets) in length. The combination of key and IV SHALL be unique for each created MAC. The IV generation mechanism SHALL be deterministic (not random). The specifics of that mechanism are left to an implementation.¶
These IV and tag lengths are consistent with the COSE use of AES-GCM encryption in Section 4.1 of [RFC9053].¶
COSE Value | Algorithm | Key Length | IV Length | Tag Length |
---|---|---|---|---|
TBA1 | AES-GMAC | 128 | 96 | 128 |
TBA2 | AES-GMAC | 192 | 96 | 128 |
TBA3 | AES-GMAC | 256 | 96 | 128 |
Implementations creating and validating AES-GMAC values SHALL validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.¶
When using a COSE key for these algorithms, the following checks are made:¶
This document does not define any new modes of operation for the GMAC algorithm, and so does not introduce any new security considerations. All of the applicable considerations from [SP800-38D] apply when the algorithm is used in COSE.¶
The requirement to use non-random IV generation in Section 2 is meant to satisfy the critical constraint on GMAC (and nonce-based MACs generally) described in Chapter 10 of [PR2011] to guarantee the uniqueness of the combination of key and IV. Whether the mechanism is a simple counter, a determistic PRF, or something else does not affect the constraint to be non-random.¶
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of code points in accordance with BCP 26 [RFC1155].¶
A new set of entries have been added to the "COSE Algorithms" registry [IANA-COSE] with the following parameters.¶