| Internet-Draft | Encrypted OSCORE Partial IV | July 2025 |
| Tiloca & Preuß Mattsson | Expires 8 January 2026 | [Page] |
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE option, where the field Partial IV specifies the sequence number value used by the message sender. In the interest of encrypting as much information as reasonably possible, this document defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option. Therefore, it updates RFC 8613. Combined with the update of OSCORE identifiers, the encryption of Partial IV values helps counteracting on-path adversaries that attempt to correlate the sequence numbers observed in different network paths, in order to track OSCORE endpoints that perform a network path migration. The defined encryption method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE).¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-core-oscore-piv-enc.¶
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 8 January 2026.¶
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 security protocol Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP) [RFC7252]. OSCORE operates at the application layer by using CBOR Object Signing and Encryption (COSE) [RFC9052] and is independent of the specific transport used to exchange CoAP messages.¶
Messages protected with OSCORE include the CoAP OSCORE option, which specifies information for the message recipient to correctly perform decryption and verification upon message reception. In particular, the OSCORE option can include a Partial IV, which specifies the sequence number value used by a sender endpoint when protecting an outgoing message. A Partial IV is always present in request messages, while it is typically absent in response messages, with a few exceptions mandating its presence.¶
Following a message protection with OSCORE, the OSCORE option added to the message is not encrypted, since its content provides a recipient endpoint with information for processing the OSCORE-protected incoming message. However, sending the Partial IV in plaintext enables on-path adversaries to perform trivial tracking of OSCORE endpoints across different network paths, by correlating the sequence numbers observed in those network paths (e.g., following a network path migration, possibly across different network segments).¶
In the interest of encrypting as much information as reasonably possible, this document updates [RFC8613] and defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option.¶
This method does not require an in-band signaling and its use does not arbitrarily change on a per-message basis. Instead, upon establishing an OSCORE Security Context, the communicating OSCORE endpoints already have an agreement on either encrypting or not encrypting the Partial IV when they use that Security Context, for every OSCORE-protected message where a Partial IV is included.¶
Like for the overall protection of messages with OSCORE, the encryption of the Partial IV is agnostic of how exactly the OSCORE Security Context was established and of how the agreement on encrypting the Partial IV was reached. Nevertheless, this document also defines means that endpoints can use to reach that agreement. Absent an explicit agreement, the Partial IV specified in the OSCORE option remains unencrypted, in order to preserve interoperability.¶
Although it is a self-standing functionality, the encryption of the Partial IV is intended to be combined with the update of OSCORE identifiers defined in [I-D.ietf-core-oscore-id-update]. When OSCORE endpoints perform a network path migration with consequent change of their addressing information, such a combination helps against on-path adversaries that attempt to track OSCORE endpoints across different network paths.¶
The encryption method defined in this document is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] that protects group communication for CoAP [I-D.ietf-core-groupcomm-bis]. In the interest of such a case, this document also defines means to synchronize the members of an OSCORE group with respect to the encryption of the Partial IV within the group.¶
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.¶
Readers are expected to be familiar with the terms and concepts related to CoAP [RFC7252], Concise Data Definition Language (CDDL) [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949], COSE [RFC9052], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶
When the encryption of the Partial IV is enabled, the (Group) OSCORE Security Context is extended with one additional parameter in the Common Context.¶
The new parameter PIV Encryption Key specifies the encryption key for deriving a keystream to encrypt/decrypt a Partial IV, when this is included in a message protected with (Group) OSCORE.¶
The PIV Encryption Key is derived as defined for the Sender/Recipient Keys in Section 3.2.1 of [RFC8613], with the following differences.¶
The 'id' element of the 'info' array is the empty byte string.¶
The 'type' element of the 'info' array is "PIVEKey". The label is an ASCII string and does not include a trailing NUL byte.¶
If the Security Context is used for Group OSCORE and the Group Encryption Algorithm in the Common Context is set (see Section 2.1.7 of [I-D.ietf-core-oscore-groupcomm]), then:¶
The 'alg_aead' element of the 'info' array specifies the Group Encryption Algorithm from the Common Context encoded as a CBOR integer or text string, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm [COSE.Algorithms].¶
The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the key for the Group Encryption Algorithm specified in the Common Context. While the obtained PIV Encryption Key is never used with the Group Encryption Algorithm, its length was chosen to obtain a matching level of security.¶
If the Security Context is used for Group OSCORE and the Group Encryption Algorithm in the Common Context is not set (see Section 2.1.7 of [I-D.ietf-core-oscore-groupcomm]), then:¶
The 'alg_aead' element of the 'info' array specifies the AEAD Algorithm from the Common Context (see Section 2.1.1 of [I-D.ietf-core-oscore-groupcomm]) encoded as a CBOR integer or text string, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm [COSE.Algorithms].¶
The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the key for the AEAD Algorithm specified in the Common Context. While the obtained PIV Encryption Key is never used with the AEAD Algorithm, its length was chosen to obtain a matching level of security.¶
Once composed an OSCORE-protected outgoing message MSG that includes the Partial IV in the OSCORE option (see Section 6.1 of [RFC8613]), the sender endpoint performs the following steps.¶
Compose SAMPLE as the first N bytes of the CoAP payload of MSG, where N = min(LENGTH, 16) and LENGTH denotes the length in bytes of the CoAP payload of MSG.¶
Note that:¶
LENGTH is guaranteed to have a minimum value of 9.¶
If MSG was protected with OSCORE [RFC8613] or instead with Group OSCORE using the pairwise mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]), then the CoAP payload is the ciphertext of the COSE object.¶
If MSG was protected with Group OSCORE using the group mode (see Section 7 of [I-D.ietf-core-oscore-groupcomm]), then the CoAP payload is the ciphertext of the COSE object concatenated with the encrypted countersignature.¶
Compose INPUT as follows:¶
Compute the 16-byte IV_KEYSTREAM as below:¶
IV_KEYSTREAM = AES-ECB(PIV Encryption Key, INPUT)¶
where:¶
Compute the encrypted Partial IV, by XORing the plain Partial IV from the OSCORE option of MSG with the Q bytes from the IV_KEYSTREAM's start, where Q is the length in bytes of the plain Partial IV.¶
For example, if the plain Partial IV from the OSCORE option of MSG is 0x001122 (Q = 3 bytes) and IV_KEYSTREAM is 0xffeeddccbbaa99887766554433221100 (16 bytes), then the bytes of IV_KEYSTREAM to XOR with the plain Partial IV are 0xffeedd.¶
Replace the plain Partial IV in the OSCORE option of MSG with the encrypted Partial IV computed at Step 4.¶
Once completed the steps above, the sender endpoint transmits MSG as expected.¶
Upon receiving an incoming message MSG that includes an encrypted Partial IV and after having retrieved the (Group) OSCORE Security Context to process the message, the recipient endpoint performs the following steps.¶
Compute IV_KEYSTREAM by means of the same method defined at Steps 1-3 of Section 3.¶
Compute the plain Partial IV, by XORing the encrypted Partial IV from the OSCORE option of MSG with the Q bytes from the IV_KEYSTREAM's start, where Q is the length in bytes of the encrypted Partial IV.¶
Replace the encrypted Partial IV in the OSCORE option of MSG with the plain Partial IV computed at Step 2.¶
Once completed the steps above, the recipient endpoint continues processing MSG as expected.¶
If an endpoint that encrypts the Partial IV expects to send more than 256 messages including a Partial IV and protected with the same Sender Context, then that Sender Context SHOULD use 65536 as lowest value for the Sender Sequence Number of that endpoint.¶
This ensures that the Partial IV is encoded in at least 3 bytes in the OSCORE option, hence defeating attempts to track an endpoint by leveraging the transition between the encoding of Partial IVs from 1 to 2 bytes in size, or from 2 to 3 bytes in size.¶
Absent explicit information associated with the (Group) OSCORE Security Context used and an agreement with its peer(s), an endpoint does not encrypt/decrypt the Partial IV when using that Security Context, thereby preserving interoperability.¶
The rest of this section defines means that endpoints can use to reach an agreement about encrypting the Partial IV as specified in this document.¶
TBD¶
Editor's note: expected means to cover include:¶
TBD¶
Editor's note: expected means to cover include:¶
The same security considerations from [RFC8613] and [I-D.ietf-core-oscore-groupcomm] hold for this document when messages are protected with OSCORE or Group OSCORE, respectively. Furthermore, the following considerations also apply.¶
The method defined in this document provides confidentiality protection of the Partial IV against passive adversaries.¶
An active adversary could guess the plain Partial IV and have a recipient OSCORE endpoint confirm the guesses, e.g., taking advantage of timing side channels. For instance, this can be the case when the recipient endpoint discards an incoming message that is detected as a replay, i.e., without attempting to decrypt and verify the message and hence revealing information through timing side channels.¶
Similarly, depending on whether the processing of an incoming request message fails due to a replay detection or instead to a failed decryption and verification, the recipient endpoint would follow-up by sending different, unprotected error response messages, which the adversary can leverage to confirm the guesses.¶
When performing the steps at Section 3 and Section 4, using the same PIV Encryption Key and SAMPLE more than once risks compromising the encryption of the Partial IV. That is, encrypting two different Partial IVs by leveraging the same PIV Encryption Key and SAMPLE reveals the exclusive OR of the encrypted Partial IVs.¶
Assuming that SAMPLE is consistent with the outcome of a pseudorandom function (PRF), if L bits are sampled, then the odds that two SAMPLE byte strings of length L are identical approach P = 2-L/2, that is, the birthday bound. For messages protected with (Group) OSCORE, SAMPLE has a minimum length L_MIN of 72 bits and a maximum length L_MAX of 128 bits. Therefore, P is at least 236 (when the CoAP payload has a length of L_MIN bits) and at most 264 (when the CoAP payload has a length of L_MAX bits or more).¶
The method defined in [I-D.ietf-core-oscore-id-update] allows OSCORE endpoints to update their OSCORE identifiers. Switching to a new OSCORE identifier is particularly useful when an endpoint migrates to a new network path, as it counteracts attempts to track the endpoint across different network paths by leveraging its OSCORE identifier.¶
Clearly, an on-path adversary might still be able to track an endpoint, e.g., by leveraging addressing information that does not change upon network migration or by attempting to correlate the Partial IV values observed on different network paths. The method for encrypting the OSCORE Partial IV defined in this document helps against the latter. That is, in case the OSCORE Partial IV is not encrypted, endpoints could be successfully tracked even when different OSCORE identifiers are used on each network path.¶
The tracking of an OSCORE endpoint that migrates to a new network path can be largely counteracted by using the method defined in this document, if combined with the use of new source addressing information (e.g., IP address and link-layer address) and of a new OSCORE identifier that the endpoint has not used before in other network paths. This does not prevent other properties of network packets, e.g., their timing or length, from being used to correlate activities of the same endpoint across different network paths.¶
TBD¶
Editor's note: expected actions are registrations of new parameters that effectively enable the means defined in Section 6.¶
The authors sincerely thank Rikard Höglund and Göran Selander for their comments and feedback.¶
This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.¶