Ascon-AEAD128 for JOSE and COSE

Status of This Memo

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 12 July 2025.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

Constrained networks such as Internet of Things (IoT) networks most of the time are characterized by the limited computational power and autonomy. In this context, the choice of suitable cryptographic algorithms that provide a robust security without consuming large amount of resources is essential. As a winner of lightweight cryptography standardization process conducted by NIST, Ascon family of cryptographic algorithms is a perfect candidate for the described situation.¶

Ascon-Based Lightweight Cryptography Standards for Constrained Devices [NIST.SP.800-232] introduces a suite of algorithms to provide Authenticated Encryption with Associated Data (AEAD), a hash function, and two eXtendable Output Functions (XOFs).¶

This document focuses on the AEAD part of Ascon standard. It enables the usage of Ascon-AEAD128 with JOSE and COSE for the content encryption.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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.¶

3. Ascon algorithms

In the scope of this document, only the authenticated encryption Ascon is allowed for. Ascon's encryption and decryption algorithms are parametrized by the key length k, the rate r, and the internal round numbers a and b. [NIST.SP.800-232] specifies the Ascon-AEAD128 algorithm with the following parameters:¶

Thus, this document requests the registration of the Ascon-AEAD128 algorithm in [IANA.cose]:¶

In COSE, keys may be obtained from either a key structure or a recipient structure [RFC9052].¶

When using a COSE key for this algorithm, the following checks are made:¶

• The "kty" field MUST be present, and it MUST be "Symmetric".¶

• If the "alg" field is present, it MUST match the Ascon-AEAD128 algorithm being used.¶

• If the "key_ops" field is present, it MUST include "encrypt" when encrypting.¶

• If the "key_ops" field is present, it MUST include "decrypt" when decrypting.¶

Also, this document requests the registration of the Ascon-AEAD128 algorithm in [IANA.jose]:¶

Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.¶

4. IV Header Parameter

Unlike some common AEAD algorithms, Ascon distinguishes between the notion of initialization vector (IV) and nonce (N). While N is the input argument for the Ascon encryption/decryption functions, IV is the constant defined for each Ascon algorithm and is based on its parameters.¶

However, [IANA.cose] does not define a separate header parameter to specify Nonce. Thus, in COSE, whenever Full Initialization Vector Header Parameter (Name: IV, Label: 5) or Partial Initialization Vector Header Parameter (Name: Partial IV, Label: 6) is specified it MUST refer to the N argument of the corresponding Ascon function.¶

On the other hand, JSON Web Signature and Encryption Header Parameters registry at [IANA.jose] defines both Nonce Header Parameter ("nonce") and Initialization Vector Header Parameter ("iv"). That is, in JOSE, both "nonce" and "iv" parameters MUST refer to the N argument of the corresponding Ascon function. There SHOULD NOT be "nonce" and "iv" parameters specified at the same time. In case, "nonce" and "iv" parameters are specified simultaneously, Nonce Header Parameter MUST take precedence.¶

5. Security Considerations

The security considerations for [RFC7516], [RFC7517] and [RFC9053] apply to this specification as well.¶

According to the most recent security analysis publications, Ascon did not show any security vulnerabilities so far and the best attacks target the initialization of Ascon reduced to 7 (out of 12) rounds, concluding that Ascon has a security margin of 5 rounds (42 % of the 12 rounds).¶

Refer to the Ascon's List of Published Analysis section at [asconv1.2-nist] for more details.¶

6. IANA Considerations

7. References

Appendix A. Examples

This appendix provides some examples of various Ascon-AEAD128 Encryptions with COSE and JOSE¶

{
  "plaintext": "546869732069732074686520636f6e74656e742e",
  "nonce": "00000000000000000000000000000000",
  "AAD": "8367456E637279707443A1010140",
  "CEK": "849B57219DAE48DE646D07DBB533566E",
  "Encrypt0": "d08344a1011823a1055000000000000000000000000000000000582436ba4da1fa787205e5fff06fd4b645c637c02b505046fb242984864e1f6875c4ae5c9557",
  "Encrypt0_diag": "16([h'A1011823', {5: h'00000000000000000000000000000000'}, h'36BA4DA1FA787205E5FFF06FD4B645C637C02B505046FB242984864E1F6875C4AE5C9557'])"
}

{
  "plaintext": "546869732069732074686520636f6e74656e742e",
  "nonce": "00000000000000000000000000000000",
  "AAD": "8367456E637279707443A1010140",
  "CEK": "849B57219DAE48DE646D07DBB533566E",
  "key": {
    "kid": "6F75722D736563726574",
    "kty": "Symmetric"
  },
  "salt": "61616262636364646565666667676868",
  "Encrypt": "d8608444a1011823a105500000000000000000000000000000000058247b09f4de6d93b6779163d978efa2d7eaac699acad60a6a9779168b5569d57ef92d3102bf818343a10129a2044a6f75722d73656372657433506161626263636464656566666767686840",
  "Encrypt_diag": "96([h'A1011823', {5: h'00000000000000000000000000000000'}, h'7B09F4DE6D93B6779163D978EFA2D7EAAC699ACAD60A6A9779168B5569D57EF92D3102BF', [[h'A10129', {4: h'6F75722D736563726574', -20: h'61616262636364646565666667676868'}, h'']]])"
}

{
  "plaintext": "546869732069732074686520636f6e74656e742e",
  "nonce": "00000000000000000000000000000000",
  "protected": {
    "alg":"dir",
    "enc":"Ascon-AEAD128"
  },
  "CEK": "849B57219DAE48DE646D07DBB533566E",
  "jwe": "eyJhbGciOiJkaXIiLCJlbmMiOiJBc2Nvbi1BRUFEMTI4In0..AAAAAAAAAAAAAAAAAAAAAA.XjkRZmV9Dy0lpQp_4yUYIY1CGN8.zUqKLKMQnqjXFY258aNMgw"
}

Authors' Addresses