Key Usage Limits for OSCORE

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 14 September 2023.¶

Copyright Notice

Copyright (c) 2023 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

Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] provides end-to-end protection of CoAP [RFC7252] messages at the application-layer, ensuring message confidentiality and integrity, replay protection, as well as binding of response to request between a sender and a recipient.¶

In particular, OSCORE uses AEAD algorithms to provide confidentiality and integrity of messages exchanged between two peers. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used to perform encryption or decryption [I-D.irtf-cfrg-aead-limits].¶

The original OSCORE specification [RFC8613] does not consider such key usage limits. However, should they be exceeded, an adversary may break the security properties of the AEAD algorithm, such as message confidentiality and integrity, e.g., by performing a message forgery attack. Among other reasons, approaching the key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines what steps an OSCORE peer should take to preserve the security of its communications, by stopping to use the OSCORE Security Context shared with another peer when approaching the key usage limits.¶

2. AEAD Key Usage Limits in OSCORE

This section details how key usage limits for AEAD algorithms can be considered when using OSCORE. In particular, it discusses specific limits for common AEAD algorithms used with OSCORE; parameters to track associated to an OSCORE Security Context; and additions to the OSCORE message processing.¶

+------------------------+----------------+----------------+
| Algorithm name         | IA probability | CA probability |
|------------------------+----------------+----------------|
| AEAD_AES_128_CCM       | 2^-64          | 2^-66          |
| AEAD_AES_128_GCM       | 2^-97          | 2^-89          |
| AEAD_AES_256_GCM       | 2^-97          | 2^-89          |
| AEAD_CHACHA20_POLY1305 | 2^-73          | -              |
+------------------------+----------------+----------------+

+------------------------+----------+----------+-----------+
| Algorithm name         | l=2^6 in | l=2^8 in | l=2^10 in |
|                        | bytes    | bytes    | bytes     |
|------------------------+----------+----------|-----------|
| AEAD_AES_128_CCM       | 1024     | 4096     | 16384     |
| AEAD_AES_128_GCM       | 1024     | 4096     | 16384     |
| AEAD_AES_256_GCM       | 1024     | 4096     | 16384     |
| AEAD_AES_128_CCM_8     | 1024     | 4096     | 16384     |
| AEAD_CHACHA20_POLY1305 | 4096     | 16384    | 65536     |
+------------------------+----------+----------+-----------+

3. Security Considerations

This document mainly covers security considerations about using AEAD keys in OSCORE and their usage limits, in addition to the security considerations of [RFC8613].¶

[TODO: Add more considerations.]¶

4. IANA Considerations

This document has no IANA actions.¶

Appendix A. Detailed considerations for AEAD_AES_128_CCM_8

For the AEAD_AES_128_CCM_8 algorithm when used as AEAD Algorithm for OSCORE, larger IA and CA values are achieved, depending on the value of 'q', 'v' and 'l'. Figure 3 shows the resulting IA and CA probabilities enjoyed by AEAD_AES_128_CCM_8, when taking different values of 'q', 'v' and 'l' as input to the formulas defined in [I-D.irtf-cfrg-aead-limits].¶

As shown in Figure 3, it is especially possible to achieve the lowest IA = 2^-50 and a good CA = 2^-70 by considering the largest possible value of the (q, v, l) triplet equal to (2^20, 2^10, 2^8), while still keeping a good security level. Note that the value of 'l' does not impact on IA, while CA displays good values for every considered value of 'l'.¶

+-----------------------+----------------+----------------+
| 'q', 'v' and 'l'      | IA probability | CA probability |
|-----------------------+----------------+----------------|
| q=2^20, v=2^20, l=2^8 | 2^-44          | 2^-70          |
| q=2^15, v=2^20, l=2^8 | 2^-44          | 2^-80          |
| q=2^10, v=2^20, l=2^8 | 2^-44          | 2^-90          |
| q=2^20, v=2^15, l=2^8 | 2^-49          | 2^-70          |
| q=2^15, v=2^15, l=2^8 | 2^-49          | 2^-80          |
| q=2^10, v=2^15, l=2^8 | 2^-49          | 2^-90          |
| q=2^20, v=2^14, l=2^8 | 2^-50          | 2^-70          |
| q=2^15, v=2^14, l=2^8 | 2^-50          | 2^-80          |
| q=2^10, v=2^14, l=2^8 | 2^-50          | 2^-90          |
| q=2^20, v=2^10, l=2^8 | 2^-54          | 2^-70          |
| q=2^15, v=2^10, l=2^8 | 2^-54          | 2^-80          |
| q=2^10, v=2^10, l=2^8 | 2^-54          | 2^-90          |
|-----------------------+----------------+----------------|
| q=2^20, v=2^20, l=2^6 | 2^-44          | 2^-74          |
| q=2^15, v=2^20, l=2^6 | 2^-44          | 2^-84          |
| q=2^10, v=2^20, l=2^6 | 2^-44          | 2^-94          |
| q=2^20, v=2^15, l=2^6 | 2^-49          | 2^-74          |
| q=2^15, v=2^15, l=2^6 | 2^-49          | 2^-84          |
| q=2^10, v=2^15, l=2^6 | 2^-49          | 2^-94          |
| q=2^20, v=2^14, l=2^6 | 2^-50          | 2^-74          |
| q=2^15, v=2^14, l=2^6 | 2^-50          | 2^-84          |
| q=2^10, v=2^14, l=2^6 | 2^-50          | 2^-94          |
| q=2^20, v=2^10, l=2^6 | 2^-54          | 2^-74          |
| q=2^15, v=2^10, l=2^6 | 2^-54          | 2^-84          |
| q=2^10, v=2^10, l=2^6 | 2^-54          | 2^-94          |
+-----------------------+----------------+----------------+

Appendix B. Estimation of 'count_q'

This section defines a method to compute an estimate of the counter 'count_q' (see Section 2.2.2), hence not requiring a peer to store it in its own Sender Context.¶

This method relies on the fact that, at any point in time, a peer has performed at most ENC = (SSN + SSN*) encryptions using its own Sender Key, where:¶

• SSN is the current value of this peer's Sender Sequence Number.¶
• SSN* is the current value of other peer's Sender Sequence Number. That is, SSN* is an overestimation of the responses without Partial IV that this peer has sent.¶

Thus, when protecting an outgoing message (see Section 2.3.1), the peer aborts the message processing if the estimated est_q > limit_q, where est_q = (SSN + X) and X is determined as follows.¶

• If the outgoing message is a response, X is the Partial IV specified in the corresponding request that this peer is responding to. Note that X < SSN* always holds.¶
• If the outgoing message is a request, X is the highest Partial IV value marked as received in this peer's Replay Window plus 1, or 0 if it has not accepted any protected message from the other peer yet. That is, X is the highest Partial IV specified in message received from the other peer, i.e., the highest seen Sender Sequence Number of the other peer. Note that, also in this case, X < SSN* always holds.¶

Appendix C. Document Updates

RFC EDITOR: PLEASE REMOVE THIS SECTION.¶

Acknowledgments

The authors sincerely thank Christian Amsüss, Carsten Bormann, John Preuß Mattsson, Göran Selander and Rafa Marin-Lopez for their feedback and comments.¶

The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652).¶

Authors' Addresses