| Internet-Draft | GMAC/KMAC in COSE/JOSE | December 2024 |
| Sipos | Expires 15 June 2025 | [Page] |
This document registers JOSE and COSE algorithm code points for using two new Message Authentication Code (MAC) algorithm families. One is the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) to generate a MAC (AES-GMAC), the other is the SHA-3-derived Keccak MAC (KMAC).¶
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 15 June 2025.¶
Copyright (c) 2024 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, and the base JOSE specification [RFC7515] defines a similar container for "Signature" data including MAC results. Each type of 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], as well as the SHA-3-derived Keccak MAC (KMAC) as defined in [SP800-185].¶
Unlike the use of AES-GMAC in CMS [RFC9044] and IPsec [RFC4543] or KMAC in CMS [RFC8702], the COSE and JOSE 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 COSE and JOSE registries so that the AES-GMAC and KMAC can be used in those respective security environments 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.¶
Both the AES-GMAC algorithm from [SP800-38D] and the KMAC algorithm from [SP800-185] have a set of parameters associated with their uses. For the sake of adhering to COSE and JOSE best practices about fully specifying what gets assigned an "algorithm" code point in each respective registry, the AES-GMAC and KMAC 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.¶
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 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 | JOSE Name | Algorithm | Key Length | IV Length | Tag Length |
|---|---|---|---|---|---|
| TBA1 | A128GMAC128 | AES-GMAC | 128 | 96 | 128 |
| TBA2 | A192GMAC128 | AES-GMAC | 192 | 96 | 128 |
| TBA3 | A256GMAC128 | 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:¶
The KMAC family is actually two different variants, KMAC128 and KMAC256, related to the provided security strength of 128 and 256-bits respectively and expected to be used with identical respective minimum key lengths.¶
The parameters associated with KMAC are: key length and tag length. This document restricts the allowed code points to the commonly used key lengths of 128 and 256-bits and restricts the use of a single "standard" tag length for each variant as indicated in Table 2. Future allocations can define the use of KMAC with other tag lengths.¶
An optional input for KMAC is a "customization bit string" used as additional context data. When used with COSE the KMAC customization bit string SHALL be the ASCII [RFC20] text string "COSE" without null termination. When used with JOSE the KMAC customization bit string SHALL be the ASCII [RFC20] text string "JOSE" without null termination.¶
| COSE Value | JOSE Name | Algorithm | Key Length | Tag Length |
|---|---|---|---|---|
| TBA4 | KMAC128 | KMAC128 | 128 | 256 |
| TBA5 | KMAC256 | KMAC256 | 256 | 512 |
Implementations creating and validating KMAC 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 relevant MAC algorithms, and so does not introduce any new security considerations. All of the applicable considerations from [SP800-38D] and [SP800-185] apply when the algorithm is used in COSE or JOSE.¶
The requirement to use non-random IV generation in Section 2.1 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.¶
A new set of entries have been added to the "JSON Web Signature and Encryption Algorithms" registry [IANA-JOSE] with the following parameters.¶
Others TBD¶