CoRE Working Group M. Tiloca Internet-Draft RISE AB Updates: 8613 (if approved) J. Preuß Mattsson Intended status: Standards Track Ericsson AB Expires: 6 May 2027 R. Höglund RISE AB G. Selander Ericsson AB 2 November 2026 Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option draft-tiloca-core-oscore-piv-enc-04 Abstract 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 "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. Discussion Venues 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Tiloca, et al. Expires 6 May 2027 [Page 1] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 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 6 May 2027. Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Obfuscation Key . . . . . . . . . . . . . . . . . . . . . . . 6 3. Processing in OSCORE . . . . . . . . . . . . . . . . . . . . 7 3.1. Sender Side . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Recipient Side . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Retrieving the Security Context to Use . . . . . . . 10 3.2.2. Reversing the Field Obfuscation . . . . . . . . . . . 15 3.3. Special Cases . . . . . . . . . . . . . . . . . . . . . . 16 3.3.1. LAKE + OSCORE Request . . . . . . . . . . . . . . . . 16 3.3.2. KUDOS . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.3. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . 18 4. Processing in Group OSCORE . . . . . . . . . . . . . . . . . 19 4.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 19 4.1.1. Obfuscation Sender Key . . . . . . . . . . . . . . . 19 4.1.2. Obfuscation Recipient Key . . . . . . . . . . . . . . 20 4.2. Sender Side . . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Recipient Side . . . . . . . . . . . . . . . . . . . . . 21 4.3.1. Retrieving the Recipient Context to Use . . . . . . . 22 4.3.2. Reversing the Field Obfuscation . . . . . . . . . . . 29 Tiloca, et al. Expires 6 May 2027 [Page 2] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 4.4. External Signature Checkers . . . . . . . . . . . . . . . 30 4.5. Deterministic Requests . . . . . . . . . . . . . . . . . 33 5. Agreement on Obfuscating Fields in the OSCORE Option . . . . 34 5.1. Agreement for OSCORE . . . . . . . . . . . . . . . . . . 34 5.2. Agreement for Group OSCORE . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.1. Minimum Length of Sender Sequence Numbers . . . . . . . . 35 6.2. Robustness of the Encryption of the Partial IV . . . . . 36 6.3. Impact on Endpoint Trackability . . . . . . . . . . . . . 36 6.4. Trial Decryptions . . . . . . . . . . . . . . . . . . . . 36 6.5. Not Obfuscating the "kid" Field . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Normative References . . . . . . . . . . . . . . . . . . 41 8.2. Informative References . . . . . . . . . . . . . . . . . 43 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction 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, some of the fields that can be included in the OSCORE Option comprise: * The "Partial IV" field, which specifies the sequence number value used by the sender endpoint when protecting an outgoing message. This field is always present in request messages, while it is typically absent in response messages, with a few exceptions mandating its presence. * The "kid" field, which specifies the identifier of the sender endpoint protecting an outgoing message (i.e., the sender endpoint's OSCORE Sender ID). This field is always present in request messages, while it is typically absent in response messages. Tiloca, et al. Expires 6 May 2027 [Page 3] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 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, the information conveyed in plaintext by the "Partial IV" and "kid" fields could be used for fingerprinting traffic from OSCORE endpoints, e.g., by leveraging the leaked order of messages sent by an endpoint, from which behavioral patterns could be implied and certain traffic types could be easier to identify and selectively disrupt [EuroSandP]. Also, such information could be used to perform trivial tracking of OSCORE endpoints across different network paths, by correlating the values of those fields that are observed in those network paths (e.g., following a network path migration, possibly across different network segments). In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document updates [RFC8613] and defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand- in identifier. This method does not require in-band signaling and its use is not arbitrarily determined on a per-message basis. Upon establishing an OSCORE Security Context with which this method is used, the communicating OSCORE endpoints already have an agreement about obfuscating the two fields of the OSCORE Option when that Security Context is used, for every OSCORE-protected message that includes the "Partial IV" field or the "kid" field. In the interest of specific use cases, such an agreement can be about always obfuscating both the "Partial IV" and "kid" fields, or instead about always obfuscating only the "Partial IV" field. Like for the overall protection of messages with OSCORE, this method is agnostic of how exactly the OSCORE Security Context was established and of how the agreement on using this method was reached. Nevertheless, this document also defines means that endpoints can use to reach that agreement. Absent an explicit agreement, the "Partial IV" and "kid" fields in the OSCORE Option are not obfuscated and retain their original values, in order to preserve interoperability. With minor adaptations to what is defined for the case where OSCORE is used, the 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 Tiloca, et al. Expires 6 May 2027 [Page 4] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 protects group communication for CoAP [I-D.ietf-core-groupcomm-bis]. In the interest of such a case, this document also defines means to align the members of an OSCORE group about obfuscating the "Partial IV" and "kid" fields of protected messages exchanged within the group. 1.1. 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. 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]. This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in [RFC9528]. This document also refers to the following terms: * Ordinary Security Context: an OSCORE Security Context [RFC8613] or a Group OSCORE Security Context [I-D.ietf-core-oscore-groupcomm] such that, when employed to process a message, the method defined in this document is not used to perform/reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option. An Ordinary Security Context does not include an Obfuscation Key in the Common Context (see Section 2). * Obfuscating Security Context: an OSCORE Security Context or a Group OSCORE Security Context such that, when employed to process a message, the method defined in this document is used to perform/ reverse the obfuscation of the "Partial IV" field in the OSCORE Option. An Obfuscating Security Context includes an Obfuscation Key in the Common Context (see Section 2). * Incognito Security Context: an Obfuscating Security Context such that, when employed to process a message, the method defined in this document is also used to perform/reverse the obfuscation of the "kid" field in the OSCORE Option. Unless a Security Context is an Incognito Security Context, the "kid" field (if present) in the OSCORE Option is left unaltered. Tiloca, et al. Expires 6 May 2027 [Page 5] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 The particular way to mark an Obfuscating Security Context as an Incognito Security Context is implementation specific. For example, implementations can use an additional parameter in the Security Context. 2. Obfuscation Key When obfuscation is enabled for the OSCORE Option, the (Group) OSCORE Security Context is extended with one additional parameter in the Common Context. The result is an Obfuscating Security Context. The new parameter Obfuscation Key specifies the encryption key for deriving two separate keystreams, namely PIV_KEYSTREAM and KID_KEYSTREAM. On the sender side, PIV_KEYSTREAM and KID_KEYSTREAM are used to obfuscate the "Partial IV" and "kid" fields in the OSCORE Option, respectively, when those fields are included in the OSCORE Option of an outgoing message protected with (Group) OSCORE. On the recipient side, the same keystreams are used to reverse the obfuscation of the two fields. The Obfuscation 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 "OBFKey". 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]), the following applies. 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, consistent with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm [COSE.Algorithms]. * 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]), the following applies. Tiloca, et al. Expires 6 May 2027 [Page 6] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 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, consistent with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm [COSE.Algorithms]. * The L parameter of the HMAC-based key derivation function (HKDF) and the 'L' element of the 'info' array are 16. 3. Processing in OSCORE This section and its subsections describe how the method defined in this document is specifically employed for messages protected with OSCORE [RFC8613]. 3.1. Sender Side This section applies to a sender endpoint that produces a protected message MSG by using an Obfuscating Security Context. When a sender endpoint uses a fresh Sender Sequence Number value from its own Sender Context to protect an outgoing message, that Sender Sequence Number value MUST be at least 65536. Consequently, the "Partial IV" field of the OSCORE Option will have a length of at least 3 bytes. As an exception, this requirement does not apply to the special case of the LAKE + OSCORE request discussed in Section 3.3.1, where: i) the Sender Sequence Number used can have a value smaller than 65536; and ii) the "Partial IV" and "kid" fields of the OSCORE Option are not obfuscated. When composing a protected outgoing message MSG, the OSCORE Option MUST NOT include the "s" and "kid context" fields (see Section 6.1 of [RFC8613]). As an exception, this requirement does not apply to the special case discussed in Section 3.3.3. Once MSG is composed, if at least one among the "Partial IV" and "kid" fields is included in the OSCORE Option (see Section 6.1 of [RFC8613]), the sender endpoint performs the following steps. 1. Consider ENC_PAYLOAD the portion of the message payload of MSG that starts with the ciphertext of the COSE object. Then, compose SAMPLE_1 as the first N bytes from ENC_PAYLOAD's start, where N = min(LENGTH, 16) and LENGTH denotes the length in bytes of ENC_PAYLOAD. Note that LENGTH is guaranteed to be at least 9 and is typically equal to the length of the message payload. Tiloca, et al. Expires 6 May 2027 [Page 7] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 2. Compose the 16-byte INPUT_1 as follows: * If the length of SAMPLE_1 is less than 16 bytes, INPUT_1 is obtained by left-padding SAMPLE_1 with zeroes to exactly 16 bytes. * If the length of SAMPLE_1 is 16 bytes, then INPUT_1 takes SAMPLE_1. If the OSCORE Option of MSG includes the "Partial IV" field, move to Step 3. Otherwise, move to Step 6. 3. Compute the 16-byte PIV_KEYSTREAM as below: PIV_KEYSTREAM = AES-ECB(ENC_KEY, INPUT_1) where: * AES-ECB is the AES algorithm in ECB mode [AES]. * ENC_KEY is the Obfuscation Key from the Common Context of the Security Context used to produce MSG (see Section 2). ENC_KEY is used as the encryption key for the AES-ECB encryption. An exception applies in the special case discussed in Section 3.3.2, where the Obfuscation Key used as ENC_KEY is the one from the Common Context of a different Security Context, from which the Security Context used to produce MSG was derived. * INPUT_1 is the result of Step 2. It is used as the plaintext for the AES-ECB encryption. 4. Compute the ENC_PIV value, by XORing with each other: * The PIV value encoded within the "Partial IV" field of the OSCORE Option of MSG; and * The Q bytes from PIV_KEYSTREAM's start, where Q is the length in bytes of the "Partial IV" field and PIV_KEYSTREAM is the result of Step 3. For example, if the PIV value encoded within the "Partial IV" field of the OSCORE Option of MSG is 0x001122 (Q = 3 bytes) and PIV_KEYSTREAM is 0xffeeddccbbaa99887766554433221100 (16 bytes), then the bytes of PIV_KEYSTREAM to XOR with the PIV value are 0xffeedd. Tiloca, et al. Expires 6 May 2027 [Page 8] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 5. In the "Partial IV" field of the OSCORE Option of MSG, replace its current PIV value with the ENC_PIV value computed at Step 4. If the OSCORE Option of MSG includes the "kid" field, then move to Step 6. Otherwise, terminate this algorithm. 6. If the Security Context used to produce MSG is an Incognito Security Context, compose the 16-byte INPUT_2, by taking INPUT_1 from Step 2 and negating its last bit. Then, move to Step 7. Otherwise, terminate this algorithm. 7. Compute the 16-byte KID_KEYSTREAM as below: KID_KEYSTREAM = AES-ECB(ENC_KEY, INPUT_2) where: * AES-ECB is the AES algorithm in ECB mode [AES]. * ENC_KEY is the Obfuscation Key from the Common Context of the Security Context used to produce MSG (see Section 2). ENC_KEY is used as the encryption key for the AES-ECB encryption. An exception applies in the special case discussed in Section 3.3.2, where the Obfuscation Key used as ENC_KEY is the one from the Common Context of a different Security Context, from which the Security Context used to produce MSG was derived. * INPUT_2 is the result of Step 6. It is used as the plaintext for the AES-ECB encryption. 8. Compute the 3-byte STAND_IN_KID value, by XORing with each other: * The 3 bytes from LATEST_PIV's start, where LATEST_PIV is determined as follows. - If the OSCORE Option of MSG includes the "Partial IV" field, then LATEST_PIV is the ENC_PIV value computed at Step 4. Otherwise, - MSG is a response and LATEST_PIV is the value encoded within the "Partial IV" field of the OSCORE Option of the corresponding request as it was sent on the wire (i.e., in its obfuscated form). Tiloca, et al. Expires 6 May 2027 [Page 9] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM is the result of Step 7. 9. In the "kid" field of the OSCORE Option of MSG, replace the current KID value with the STAND_IN_KID value computed at Step 8. Unless the original KID value had a length of 3 bytes, this step alters the length of the OSCORE Option value. In such a case, the sender endpoint MUST update the "Option Length" field of the OSCORE Option accordingly (see Section 3.1 of [RFC7252]). Finally, the sender endpoint continues processing MSG as expected. 3.2. Recipient Side Upon receiving a protected incoming message MSG, the recipient endpoint has to determine the OSCORE Security Context to use for processing MSG (see Section 3.2.1). If a Security Context CTX is found and CTX is an Obfuscating Security Context, then the recipient endpoint uses CTX to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate (see Section 3.2.2). After that, the recipient endpoint uses CTX to decrypt and verify MSG. As further discussed in Section 3.2.1 and Section 3.3.2, an exception applies if MSG is sent as a message of the procedure Key Update for OSCORE (KUDOS) [I-D.ietf-core-oscore-key-update], in which case the Security Context CTX* used to decrypt and verify MSG is different from CTX; specifically, CTX* is derived from CTX. The procedures defined in Section 3.2.1 and Section 3.2.2 do not apply to the special case of the LAKE + OSCORE request discussed in Section 3.3.1, where: i) the "Partial IV" and "kid" fields of the OSCORE Option are not obfuscated; and ii) CTX is specifically the Security Context established from the ongoing key exchange session. 3.2.1. Retrieving the Security Context to Use If the recipient endpoint is a client, hence MSG is a response, the Security Context CTX to use is the same one that was used to process the request to which MSG replies. That is, CTX is retrieved by leveraging the CoAP Token value that is specified in the "Token" field of MSG and was specified in the "Token" field of the corresponding request. Then, the following two cases are possible: Tiloca, et al. Expires 6 May 2027 [Page 10] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * CTX is an Ordinary Security Context. In this case, the client uses CTX to decrypt and verify MSG as defined in Section 8.4 of [RFC8613], with the exception of the special case mentioned below and discussed in Section 3.3.2. * CTX is an Obfuscating Security Context. In this case, the client performs the steps defined in Section 3.2.2, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate, by using CTX. Building on the result, the client uses CTX to decrypt and verify MSG as defined in Section 8.4 of [RFC8613], with the exception of the special case mentioned below and discussed in Section 3.3.2. If the request to which MSG replies is a LAKE + OSCORE request (see Section 3.3.1) and CTX is specifically an Incognito Security Context, then the client MUST treat MSG as invalid and discard it, in the case that the OSCORE Option of MSG includes the "kid" field but does not include the "Partial IV" field. In the special case discussed in Section 3.3.2, the Security Context CTX* used to decrypt and verify MSG is different from the retrieved Security Context CTX that is possibly used to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option as appropriate; specifically, CTX* is derived from CTX. Instead, if the recipient endpoint is a server, hence MSG is a request, the Security Context CTX to use is determined as follows. 1. If the server stores at least one Ordinary Security Context, then move to Step 2. Otherwise, move to Step 3. 2. The server assumes that the "Partial IV" and "kid" fields in the OSCORE Option of MSG were not obfuscated. Then, the server attempts to retrieve a Security Context as defined in Section 8.2 of [RFC8613]. If this results in retrieving a Security Context CTX and CTX is an Ordinary Security Context, then the server uses CTX to decrypt and verify MSG as defined in Section 8.2 of [RFC8613]. An exception applies if MSG is sent as a message of the procedure KUDOS [I-D.ietf-core-oscore-key-update], in which case the Security Context CTX* used to decrypt and verify MSG is different from CTX; specifically, CTX* is derived from CTX. In the case of successful decryption and verification, this algorithm terminates and the server continues processing MSG as expected. Tiloca, et al. Expires 6 May 2027 [Page 11] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Instead, if no such CTX is found or if MSG is not successfully decrypted and verified, the following applies: * If the server stores at least one Obfuscating Security Context, the server MUST NOT presently reply with any of the optional 4.01 (Unauthorized) or 4.00 (Bad Request) error responses defined in Sections 7.4 and 8.2 of [RFC8613]. Then, this algorithm moves to Step 4. * Otherwise, the server performs the same error handling as defined in Sections 7.4 and 8.2 of [RFC8613]. Then, this algorithm terminates. 3. If the server stores at least one Obfuscating Security Context, then move to Step 4. Otherwise, the server performs the same error handling as defined at Step 2 of Section 8.4 of [RFC8613] for the case where a Security Context is not found. Then, this algorithm terminates. 4. Compose SAMPLE_1 by means of the same method at Step 1 of Section 3.1, with reference to the present incoming message MSG. 5. Compose the 16-byte INPUT_1 by means of the same method at Step 2 of Section 3.1, using as SAMPLE_1 the result of Step 4 of the present algorithm. 6. Compose the 16-byte INPUT_2, by taking INPUT_1 from Step 5 and negating its last bit. 7. Select a Security Context CTX, such that CTX is an Obfuscating Security Context and has not been tested yet during this execution of the present algorithm. In particular, if there are selectable Obfuscating Security Contexts that are not Incognito Security Contexts, the selection of CTX is first attempted among those, using the same retrieval process defined in Section 8.2 of [RFC8613]. Tiloca, et al. Expires 6 May 2027 [Page 12] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 In the case that the "kid" field of the OSCORE Option is obfuscated, the time spent to select and later successfully use the right Incognito Security Context could leak information about the plain OSCORE identifier (i.e., the OSCORE Sender ID of the sender of MSG). Implementations ought to counteract and limit such information leakage, e.g., by uniformly randomizing the selection process performed over the Incognito Security Contexts. Further details are left to the specific implementation and are out of the scope of this document. If no such CTX is found, then move to Step 12. Otherwise, the selected CTX is marked as tested and the following applies: * If CTX is an Incognito Security Context, check the length of the "kid" field of the OSCORE Option of MSG. If the length is 3 bytes, move to Step 8. Otherwise, perform Step 7 again. * If CTX is not an Incognito Security Context, the value encoded in the "kid" field of the OSCORE Option of MSG is equal to the Recipient ID specified in the Recipient Context of CTX. Hence, CTX is the Security Context to use for processing MSG, and this algorithm moves to Step 11. 8. Compute the 16-byte KID_KEYSTREAM by means of the same method at Step 7 of Section 3.1. In particular: * ENC_KEY is the Obfuscation Key from the Common Context of the latest CTX selected at Step 7 of the present algorithm. * INPUT_2 is the result of Step 6 of the present algorithm. 9. Compute the 3-byte STAND_IN_KID value, by XORing with each other: * The 3 bytes from ENC_PIV's start, where ENC_PIV is the value encoded within the "Partial IV" field of the OSCORE Option of MSG. * The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM is the result of Step 8. 10. If the STAND_IN_KID value computed at Step 9 is not equal to the value encoded in the "kid" field of the OSCORE Option of MSG, then move to Step 7. Tiloca, et al. Expires 6 May 2027 [Page 13] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Otherwise, the latest CTX selected at Step 7 is the Security Context to use for processing MSG, and this algorithm moves to Step 11. 11. Run the algorithm in Section 3.2.2, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate, by using the latest CTX selected at Step 7. Building on the result, the server uses CTX to decrypt and verify MSG as defined in Section 8.2 of [RFC8613]. An exception applies in the special case discussed in Section 3.3.2, where the Security Context CTX* used to decrypt and verify MSG is different from CTX; specifically, CTX* is derived from CTX. In the case of successful decryption and verification, this algorithm terminates and the server continues processing MSG as expected. Otherwise, if MSG is not successfully decrypted and verified, the following applies: * The server MUST NOT presently reply with any of the optional 4.01 (Unauthorized) or 4.00 (Bad Request) error responses defined in Sections 7.4 and 8.2 of [RFC8613]. * The OSCORE Option of MSG is restored to be as it was before running the algorithm in Section 3.2.2. * This algorithm moves to Step 7. 12. The following applies: * If, since Step 4 of this execution of the present algorithm, the server has performed and failed at least one decryption and verification of MSG (see Step 6 of Section 8.2 of [RFC8613]), the server performs the same error handling defined at Step 6 of Section 8.2 of [RFC8613] for the case where decryption has failed. Then, this algorithm terminates. Otherwise, * If, since Step 4 of this execution of the present algorithm, the server has performed and failed at least one replay check on MSG (see Step 3 of Section 8.2 of [RFC8613]), the server performs the same error handling defined in Section 7.4 of [RFC8613] for the case where a replay has been detected. Then, this algorithm terminates. Otherwise, Tiloca, et al. Expires 6 May 2027 [Page 14] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * The server performs the same error handling defined at Step 2 of Section 8.2 of [RFC8613] for the case where a Security Context is not found. 3.2.2. Reversing the Field Obfuscation Given an Obfuscating Security Context CTX that was retrieved according to what is specified in Section 3.2.1, the recipient endpoint performs the following steps, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of the protected incoming message MSG. 1. If the OSCORE Option of MSG includes the "kid" field and CTX is an Incognito Security Context, then move to Step 2. Otherwise, move to Step 3. 2. In the "kid" field of the OSCORE Option of MSG, replace the current STAND_IN_KID value with the Recipient ID specified in the Recipient Context of CTX. Unless the Recipient ID has a length of 3 bytes, this step alters the length of the OSCORE Option value. In such a case, the recipient endpoint MUST update the "Option Length" field of the OSCORE Option accordingly (see Section 3.1 of [RFC7252]). 3. If the OSCORE Option of MSG includes the "Partial IV" field, move to Step 4. Otherwise, terminate this algorithm. 4. Compute the 16-byte PIV_KEYSTREAM by means of the same method defined at Step 3 of Section 3.1. In particular: * ENC_KEY is the Obfuscation Key from the Common Context of the Security Context CTX that is used during this execution of the present algorithm. * INPUT_1 is composed by means of the same method defined at Step 5 of Section 3.2.1. Note that, if the recipient endpoint is a server, then INPUT_1 was already computed when actually performing Step 5 of Section 3.2.1. 5. Compute the PIV value, by XORing with each other: * The ENC_PIV value encoded within the "Partial IV" field of the OSCORE Option of MSG; and * The Q bytes from PIV_KEYSTREAM's start, where Q is the length in bytes of the "Partial IV" field and PIV_KEYSTREAM is the result of Step 4. Tiloca, et al. Expires 6 May 2027 [Page 15] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 6. In the "Partial IV" field of the OSCORE Option of MSG, replace its current ENC_PIV value with the PIV value computed at Step 5. 3.3. Special Cases This section discusses some special cases where the use of the method defined in this document deviates from what is specified as normal behavior in Section 3.1 and Section 3.2. 3.3.1. LAKE + OSCORE Request Two endpoints can run the protocol Lightweight Authenticated Key Exchange (LAKE) [RFC9528], in order to establish an OSCORE Security Context (see Appendix A.1 of [RFC9528]). In particular, LAKE messages can be transported over CoAP (see Appendix A.2 of [RFC9528]). When doing so, if the endpoint that sends the first LAKE message acts as a CoAP client, it is possible to use the optimized workflow defined in Section 3 of [RFC9668]. In such a case, the first OSCORE- protected CoAP request sent by the client additionally embeds the final LAKE message, and it is produced using the OSCORE Security Context established from the present and still ongoing LAKE session. Upon receiving such a LAKE + OSCORE request (denoted as "EDHOC + OSCORE request" in [RFC9668]), the server first extracts and processes the LAKE message embedded therein, completes the LAKE session, establishes the OSCORE Security Context, and finally uses the latter to process the OSCORE-protected CoAP request. When using this optimized workflow, the method defined in this document cannot be used to obfuscate the "Partial IV" and "kid" fields in the OSCORE Option of the LAKE + OSCORE request. Therefore, the following applies for the OSCORE Option of that specific request: * The "Partial IV" field conveys in plaintext the Sender Sequence Number used by the client when protecting the request. That is, even if the OSCORE Security Context under establishment is an Obfuscating Security Context, the "Partial IV" field in the OSCORE Option of the LAKE + OSCORE request is not obfuscated. As an exception to the requirement defined in Section 3.1, the "Partial IV" field can have a length smaller than 3 bytes. In fact, it is expected to have a length of 1 byte and to encode the value 0. Tiloca, et al. Expires 6 May 2027 [Page 16] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * The "kid" field conveys the actual OSCORE Sender ID of the client, which the server offered earlier in the LAKE session as its own LAKE connection identifier C_R. Upon receiving the LAKE + OSCORE request, the server needs to retrieve such an identifier as-is from the request, in order to correctly retrieve the LAKE session and complete it, before establishing the OSCORE Security Context shared with the client. That is, even if the OSCORE Security Context under establishment is an Incognito Security Context, the "kid" field in the OSCORE Option of the LAKE + OSCORE request is not obfuscated. Note that, if LAKE is instead run as per the original workflow (see Appendix A.2.1 of [RFC9528], the OSCORE Sender ID of the client is anyway exposed at least once, since C_R is prepended to LAKE message_3 within the message payload of a request sent by the client. Furthermore, the following applies when producing a response to an LAKE + OSCORE request: if the OSCORE Security Context used to produce the response is an Incognito Security Context and the OSCORE Option of the response includes the "kid" field, then the server MUST include its Sender Sequence Number in the "Partial IV" field of the OSCORE Option of the response and use it to build the AEAD nonce to protect the response. 3.3.2. KUDOS Two endpoints can use Key Update for OSCORE (KUDOS) [I-D.ietf-core-oscore-key-update], a lightweight procedure for updating their OSCORE keying material by establishing a new OSCORE Security Context. Given the Security Context CTX_OLD to be replaced, there are two possible types of KUDOS messages that are exchanged during a KUDOS execution: * A divergent KUDOS message is protected with a temporary OSCORE Security Context CTX_TEMP, which is derived from CTX_OLD. * A convergent KUDOS message is protected with the OSCORE Security Context CTX_NEW, which is derived from CTX_OLD and is intended to replace CTX_OLD. If CTX_OLD is an Ordinary, Obfuscating, or Incognito Security Context, then CTX_TEMP/CTX_NEW derived thereof is correspondingly an Ordinary, Obfuscating, or Incognito Security Context. Tiloca, et al. Expires 6 May 2027 [Page 17] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 When using the method defined in this document to obfuscate the "Partial IV" and "kid" fields in the OSCORE Option of a KUDOS message, the following applies. * The Obfuscation Key to use MUST be the one specified in the Common Context of the Security Context CTX_OLD, from which the Security Context CTX_TEMP (CTX_NEW) is derived for protecting a divergent (convergent) KUDOS message. That is, with reference to a divergent (convergent) KUDOS message, the Obfuscation Key to use is not the one specified in the Common Context of the Security Context CTX_TEMP (CTX_NEW) that is used to protect the message. 3.3.3. 6TiSCH The Constrained Join Protocol (CoJP) defined in [RFC9031] specifies a "secure join" solution for a new device, called a "pledge", to securely join a 6TiSCH network where communications are protected with OSCORE. The Join process is assisted by a central entity called Join Registrar/Coordinator (JRC). As defined in Section 7.3 of [RFC9031], the following holds for a given pledge and the JRC sharing an OSCORE Security Context: * The OSCORE ID Context in the OSCORE Security Context is set to the pledge identifier. * The OSCORE Sender ID of the pledge is set to the empty byte string. * The OSCORE Sender ID of the JRC is set to the byte string 0x4a5243 ("JRC" in ASCII). In the Join Request that the pledge sends to the JRC, the OSCORE Option includes the "s" and "kid context" fields, with the latter encoding the OSCORE ID Context (see Section 6.1 of [RFC8613]). If the OSCORE Security Context shared by the pledge and the JRC is an Obfuscating Security Context, the following applies to protected CoJP messages: * If the "s" and "kid context" fields are present in the OSCORE Option of an outgoing CoJP message, the sender endpoint MUST remove the "kid context" field and MUST update the "s" field to encode the value 0. Tiloca, et al. Expires 6 May 2027 [Page 18] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 This step alters the length of the OSCORE Option value. Therefore, the sender endpoint MUST update the "Option Length" field of the OSCORE Option accordingly (see Section 3.1 of [RFC7252]). * If the OSCORE Option of an incoming CoJP message MSG does not include the "kid context" field and includes the "s" field encoding the value 0, the recipient endpoint performs the following steps in addition to those compiled in Section 3.2.2: - Add the "kid context" field to the OSCORE Option of MSG. - In the "kid context" field of the OSCORE Option, set as value the ID Context that is specified in the OSCORE Security Context CTX to be used for processing MSG. - In the "s" field of the OSCORE Option, set as value the length in bytes of the "kid context" field added above. Unless the ID Context has a length of 0 bytes, this step alters the length of the OSCORE Option value. In such a case, the recipient endpoint MUST update the "Option Length" field of the OSCORE Option accordingly (see Section 3.1 of [RFC7252]). 4. Processing in Group OSCORE This section and its subsections describe how the method defined in this document is specifically employed for messages protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm]. In particular, the following presents the differences that apply with respect to the case where OSCORE is used (see Section 3). 4.1. Keying Material When the Group OSCORE Security Context is an Obfuscating Security Context, it is further extended with one additional parameter Obfuscation Sender Key in the Sender Context (see Section 4.1.1) and with one additional parameter Obfuscation Recipient Key in each Recipient Context (see Section 4.1.2). 4.1.1. Obfuscation Sender Key Within the Sender Context, the new parameter Obfuscation Sender Key specifies the encryption key for deriving the keystreams PIV_KEYSTREAM and KID_KEYSTREAM, when those are used to obfuscate the "Partial IV" and "kid" fields in the OSCORE Option of an outgoing message. Tiloca, et al. Expires 6 May 2027 [Page 19] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 The Obfuscation Sender Key is derived as the output OKM of an HKDF- Expand step [RFC5869], i.e., OKM = HKDF-Expand(PRK, info, L), where: * The HKDF used is the HKDF Algorithm specified in the Common Context. * PRK is the Obfuscation Key from the Common Context. * info is the Sender ID specified in the Sender Context. * L is the length in bytes of the Obfuscation Key from the Common Context. 4.1.2. Obfuscation Recipient Key Within a given Recipient Context, the new parameter Obfuscation Recipient Key specifies the encryption key for deriving the keystreams PIV_KEYSTREAM and KID_KEYSTREAM, when those are used to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of an incoming message. The Obfuscation Recipient Key is derived as the output OKM of an HKDF-Expand step [RFC5869], i.e., OKM = HKDF-Expand(PRK, info, L), where: * The HKDF used is the HKDF Algorithm specified in the Common Context. * PRK is the Obfuscation Key from the Common Context. * info is the Recipient ID specified in the Recipient Context. * L is the length in bytes of the Obfuscation Key from the Common Context. 4.2. Sender Side This section applies to a sender endpoint that produces a protected message MSG by using an Obfuscating Security Context. When composing a protected outgoing message MSG, the OSCORE Option includes the "s" and "kid context" fields according to what is specified for Group OSCORE in [I-D.ietf-core-oscore-groupcomm]. That is, the OSCORE Option always includes those fields in a request and may include those fields in a response. Tiloca, et al. Expires 6 May 2027 [Page 20] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Once MSG is composed, if at least one among the "Partial IV" and "kid" fields is included in the OSCORE Option (see Section 6.1 of [RFC8613]), the sender endpoint performs the same steps of Section 3.1, with the following differences: * At Step 3, ENC_KEY is the Obfuscation Sender Key from the Sender Context. * At Step 7, ENC_KEY is the Obfuscation Sender Key from the Sender Context. As an exception to the requirement in Section 3.1 about the minimum value of Sender Sequence Number to use, the requirement does not apply to the special case of an outgoing Deterministic Request discussed in Section 4.5, where: i) the Sender Sequence Number used has a value smaller than 65536; and ii) the "Partial IV" and "kid" fields of the OSCORE Option are not obfuscated. That is, the processing of an outgoing Deterministic Request is as per [I-D.ietf-core-cacheable-oscore]. 4.3. Recipient Side Upon receiving a protected incoming message MSG, the recipient endpoint determines the Group OSCORE Security Context CTX to use according to what is specified in [I-D.ietf-core-oscore-groupcomm], i.e.: * If MSG is a request, CTX is retrieved by leveraging the Group Identifier value (Gid) of the group, which is encoded within the "kid context" field in the OSCORE Option of MSG. * If MSG is a response, CTX is the same Group OSCORE Security Context that was used to protect the request to which MSG replies. That is, CTX is retrieved by leveraging the CoAP Token value that is specified in the "Token" field of MSG and was specified in the "Token" field of the corresponding request. The possible presence of the "kid context" field in the OSCORE Option can further aid the client, e.g., in the case that the group has been rekeyed and its Gid has changed. If the retrieved Group OSCORE Security Context CTX is an Obfuscating Security Context, then the method defined in this document is used to obfuscate the "Partial IV" field in the OSCORE Option of every protected message exchanged within the group. Furthermore, if CTX is specifically an Incognito Security Context, then the method defined in this document is used to obfuscate also the "kid" field in the OSCORE Option of every protected message exchanged within the group. Tiloca, et al. Expires 6 May 2027 [Page 21] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Consequently, within CTX, the recipient endpoint has to determine the specific Recipient Context REC_CTX to use for decrypting and verifying MSG (see Section 4.3.1). Then, the recipient endpoint uses REC_CTX to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate (see Section 4.3.2). After that, the recipient endpoint uses REC_CTX to decrypt and verify MSG. The procedures defined in Section 4.3.1 and Section 4.3.2 do not apply to the special case of an incoming Deterministic Request discussed in Section 4.5, where: i) the "Partial IV" and "kid" fields of the OSCORE Option are not obfuscated; and ii) REC_CTX is simply the Recipient Context identified by the "kid" field. That is, the processing of an incoming Deterministic Request is as per [I-D.ietf-core-cacheable-oscore]. 4.3.1. Retrieving the Recipient Context to Use Given the retrieved Group OSCORE Security Context CTX as an Obfuscating Security Context, the following describes how the recipient endpoint retrieves from CTX the specific Recipient Context REC_CTX to use. If the recipient endpoint is a client, hence MSG is a response, the client is able to simply retrieve the Recipient Context REC_CTX to use, in the case that both the following conditions apply: * The request corresponding to MSG was protected with the pairwise mode of Group OSCORE; and * The "kid" field is not included in the OSCORE Option of MSG. In such a case, REC_CTX is the Recipient Context associated with the other endpoint for which the request corresponding to MSG was protected. That is, this client protected such request by using its Pairwise Sender Key associated with that other endpoint. Consequently, the client performs the steps defined in Section 4.3.2, in order to reverse the obfuscation of the "Partial IV" field (if present) in the OSCORE Option of MSG as appropriate, by using REC_CTX. Building on the result, the client uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-oscore-groupcomm]. The specific operations to perform depend on whether MSG is protected with the group mode or with the pairwise mode of Group OSCORE. If the request to which MSG replies is a Deterministic Request (see Section 4.5) and the "kid" field is not included in the OSCORE Option of MSG, the same as discussed for the case above applies, with the Tiloca, et al. Expires 6 May 2027 [Page 22] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 following differences: i) REC_CTX is the Recipient Context associated with the other endpoint to which the request was sent, although the protection of the request did not rely on the Pairwise Sender Key associated with that other endpoint; ii) after reversing the obfuscation of the "Partial IV" field in the OSCORE Option of MSG, the client uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-cacheable-oscore]. In any other case, the recipient endpoint determines the Recipient Context REC_CTX to use as follows. 1. If CTX is an Incognito Security Context and the length of the "kid" field of the OSCORE Option of MSG is different from 3 bytes, move to Step 17. Otherwise, consider ENC_PAYLOAD as the portion of the message payload of MSG that starts with the ciphertext of the COSE object. Then, compose SAMPLE_1 as the first N bytes from ENC_PAYLOAD's start, where N = min(LENGTH, 16) and LENGTH denotes the length in bytes of ENC_PAYLOAD. Note that LENGTH is guaranteed to be at least 9 and is typically equal to the length of the message payload. 2. Compose the 16-byte INPUT_1 by means of the same method at Step 2 of Section 3.1, using as SAMPLE_1 the result of Step 1 of the present algorithm. 3. Compose the 16-byte INPUT_2, by taking INPUT_1 from Step 2 and negating its last bit. 4. Within CTX, select a Recipient Context REC_CTX that has not been tested yet during this execution of the present algorithm. In the case that CTX is not an Incognito Security Context, the selection of REC_CTX relies on the same retrieval process that is used in Section 6 of [I-D.ietf-core-oscore-groupcomm]. Tiloca, et al. Expires 6 May 2027 [Page 23] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 In the case that CTX is an Incognito Security Context, hence the "kid" field of the OSCORE Option is obfuscated (if present therein), the time spent to select and later successfully use the right Recipient Context could leak information about the plain OSCORE identifier (i.e., the OSCORE Sender ID of the sender of MSG). Implementations ought to counteract and limit such information leakage, e.g., by uniformly randomizing the selection process performed over the Recipient Contexts within CTX. Further details are left to the specific implementation and are out of the scope of this document. If no such REC_CTX is found, then move to Step 9. Otherwise, the selected REC_CTX is marked as tested and the following applies: * If CTX is an Incognito Security Context, move to Step 5. * If CTX is not an Incognito Security Context, the value encoded in the "kid" field of the OSCORE Option of MSG is equal to the Recipient ID specified in REC_CTX. Hence, REC_CTX is the Recipient Context to use for decrypting and verifying MSG, and this algorithm moves to Step 8. 5. Compute the 16-byte KID_KEYSTREAM by means of the same method at Step 7 of Section 3.1. In particular: * ENC_KEY is the Obfuscation Recipient Key from the latest REC_CTX selected at Step 4 of the present algorithm. * INPUT_2 is the result of Step 3 of the present algorithm. 6. Compute the 3-byte STAND_IN_KID value, by XORing with each other: * The 3 bytes from LATEST_PIV's start, where LATEST_PIV is determined as follows. - If the OSCORE Option of MSG includes the "Partial IV" field, then LATEST_PIV is the value encoded within that field. Otherwise, - MSG is a response and LATEST_PIV is the value encoded within the "Partial IV" field of the OSCORE Option of the corresponding request as it was sent on the wire (i.e., in its obfuscated form). Tiloca, et al. Expires 6 May 2027 [Page 24] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM is the result of Step 5. 7. If the STAND_IN_KID value computed at Step 6 is not equal to the value encoded in the "kid" field of the OSCORE Option of MSG, then move to Step 4. Otherwise, the latest REC_CTX selected at Step 4 is the Recipient Context to use for decrypting and verifying MSG, and this algorithm moves to Step 8. 8. Run the algorithm in Section 4.3.2, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate, by using the latest REC_CTX selected at Step 4. Building on the result, the recipient endpoint uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-oscore-groupcomm]. The specific operations to perform depend on whether MSG is protected with the group mode or with the pairwise mode of Group OSCORE. An exception applies in the case that MSG is a response to a Deterministic Request (see Section 4.5) and the "kid" field is included in the OSCORE Option of MSG. In such case, the recipient endpoint uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-cacheable-oscore]. In the case of successful decryption and verification, this algorithm terminates and the recipient endpoint continues processing MSG as expected. Otherwise, if MSG is not successfully decrypted and verified, the following applies: * If MSG is a request, the recipient endpoint MUST NOT presently reply with any of the optional 4.01 (Unauthorized), 5.03 (Service Unavailable), or 4.00 (Bad Request) error responses that pertain to a failed processing of incoming requests. Note that, although such processing is defined in Sections 5.3, 7.2, and 8.4 of [I-D.ietf-core-oscore-groupcomm], some of the corresponding error handling is inherited from Sections 7.4 and 8.2 of [RFC8613]. * The OSCORE Option of MSG is restored to be as it was before running the algorithm in Section 4.3.2. * This algorithm moves to Step 4. Tiloca, et al. Expires 6 May 2027 [Page 25] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 9. If the application admits the dynamic derivation of new Recipient Contexts and the recipient endpoint intends to take advantage of that, move to Step 10. Otherwise, move to Step 17. 10. The recipient endpoint contacts the Group Manager responsible for the OSCORE group (see Section 12 of [I-D.ietf-core-oscore-groupcomm]), and it retrieves a set of pairs P = (ID, CRED) from the Group Manager. Within each pair, ID is the Sender ID of a current group member and CRED is the public authentication credential of that group member. Depending on the particular realization of Group Manager, it can also be possible to retrieve a selected subset of those pairs, e.g., such that the ID specified therein is not part of a list provided in the request to the Group Manager. The realization of Group Manager specified in [I-D.ietf-ace-key-groupcomm-oscore] makes it possible to do so. 11. From the set obtained at Step 10, select a pair P such that: * P has not been selected yet during this execution of the present algorithm; and * The ID specified within P is not the Recipient ID stored in any of the Recipient Contexts within CTX. If no such P is found, then move to Step 17. Otherwise, move to Step 12. In the case that CTX is not an Incognito Security Context, the first pair P to select (if present) ought to be the one such that the ID specified therein is equal to the value encoded in the "kid" field of the OSCORE Option of MSG. 12. Check if either of the following conditions applies: * CTX is an Incognito Security Context; or * CTX is not an Incognito Security Context and the value encoded in the "kid" field of the OSCORE Option of MSG is equal to the ID specified within the latest pair P selected at Step 11. Tiloca, et al. Expires 6 May 2027 [Page 26] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 If any of the two conditions above apply, then establish within CTX a new Recipient Context REC_CTX associated with the same other group member with which the latest pair P selected at Step 11 is associated. That is, within REC_CTX, ID and CRED from P are stored as the Recipient ID and the public authentication credential associated with the other group member. If the first of the two conditions above applies, this algorithm moves to Step 13. If the second of the two conditions above applies, REC_CTX is the Recipient Context to use for decrypting and verifying MSG, and this algorithm moves to Step 16. If none of the two conditions above applies, this algorithm moves to Step 11. 13. Compute the 16-byte KID_KEYSTREAM by means of the same method at Step 7 of Section 3.1. In particular: * ENC_KEY is the Obfuscation Recipient Key from the latest REC_CTX established at Step 12 of the present algorithm. * INPUT_2 is the result of Step 3 of the present algorithm. 14. Compute the 3-byte STAND_IN_KID value, by XORing with each other: * The 3 bytes from LATEST_PIV's start, where LATEST_PIV is the same one determined at Step 6. * The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM is the result of Step 13. 15. If the STAND_IN_KID value computed at Step 14 is not equal to the value encoded in the "kid" field of the OSCORE Option of MSG, then the following applies: * Depending on what is specified by the application, the recipient endpoint MAY delete the latest REC_CTX established at Step 12. If REC_CTX is deleted in this particular circumstance, then this deletion does not require the recipient endpoint to initialize as invalid the Replay Window of any new Recipient Context created later within CTX (see Section 2.6.1.2 of [I-D.ietf-core-oscore-groupcomm]). Tiloca, et al. Expires 6 May 2027 [Page 27] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * This algorithm moves to Step 11. Otherwise, the latest REC_CTX established at Step 12 is the Recipient Context to use for decrypting and verifying MSG, and this algorithm moves to Step 16. 16. Run the algorithm in Section 4.3.2, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate, by using the latest REC_CTX established at Step 12. Building on the result, the recipient endpoint uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-oscore-groupcomm]. The specific operations to perform depend on whether MSG is protected with the group mode or with the pairwise mode of Group OSCORE. An exception applies in the case that MSG is a response to a Deterministic Request (see Section 4.5) and the "kid" field is included in the OSCORE Option of MSG. In such case, the recipient endpoint uses REC_CTX to decrypt and verify MSG as defined in [I-D.ietf-core-cacheable-oscore]. In the case of successful decryption and verification, this algorithm terminates and the recipient endpoint continues processing MSG as expected. Otherwise, if MSG is not successfully decrypted and verified, the following applies: * If MSG is a request, the recipient endpoint MUST NOT presently reply with any of the optional 4.01 (Unauthorized), 5.03 (Service Unavailable), or 4.00 (Bad Request) error responses that pertain to a failed processing of incoming requests. Note that, although such processing is defined in Sections 5.3, 7.2, and 8.4 of [I-D.ietf-core-oscore-groupcomm], some of the corresponding error handling is inherited from Sections 7.4 and 8.2 of [RFC8613]. * Depending on what is specified by the application, the recipient endpoint MAY delete the latest REC_CTX established at Step 12. If REC_CTX is deleted in this particular circumstance, then this deletion does not require the recipient endpoint to initialize as invalid the Replay Window of any new Recipient Context created later within CTX (see Section 2.6.1.2 of [I-D.ietf-core-oscore-groupcomm]). Tiloca, et al. Expires 6 May 2027 [Page 28] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * The OSCORE Option of MSG is restored to be as it was before running the algorithm in Section 4.3.2. * This algorithm moves to Step 11. 17. The following applies: * If, during this execution of the present algorithm, the server has performed and failed at least one decryption and verification of MSG, the server performs the same error handling defined in Sections 7.2 and 8.4 of [I-D.ietf-core-oscore-groupcomm] for the case where decryption or signature verification has failed. Then, this algorithm terminates. Otherwise, * If, during this execution of the present algorithm, the server has performed and failed at least one replay check on MSG (see Section 5.3 of [I-D.ietf-core-oscore-groupcomm]), the server performs the same error handling defined in Section 5.3 of [I-D.ietf-core-oscore-groupcomm] for the case where a replay has been detected. Then, this algorithm terminates. Otherwise, * The server performs the same error handling defined in Sections 7.2 and 8.4 of [I-D.ietf-core-oscore-groupcomm] for the case where a Security Context is not found. 4.3.2. Reversing the Field Obfuscation Given a Recipient Context REC_CTX that was retrieved according to what is specified in Section 4.3.1, the recipient endpoint performs the following steps, in order to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of the protected incoming message MSG. 1. If the OSCORE Option of MSG includes the "kid" field and CTX is an Incognito Security Context, then move to Step 2. Otherwise, move to Step 3. 2. In the "kid" field of the OSCORE Option of MSG, replace the current STAND_IN_KID value with the Recipient ID specified in REC_CTX. Unless the Recipient ID has a length of 3 bytes, this step alters the length of the OSCORE Option value. In such a case, the recipient endpoint MUST update the "Option Length" field of the OSCORE Option accordingly (see Section 3.1 of [RFC7252]). Tiloca, et al. Expires 6 May 2027 [Page 29] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 3. If the OSCORE Option of MSG includes the "Partial IV" field, move to Step 4. Otherwise, terminate this algorithm. 4. Compute the 16-byte PIV_KEYSTREAM by means of the same method defined at Step 3 of Section 3.1. In particular: * ENC_KEY is the Obfuscation Recipient Key from the REC_CTX that is used during this execution of the present algorithm. * INPUT_1 is composed by means of the same method defined at Step 2 of Section 4.3.1. Note that, except for the particular case discussed at the beginning of Section 4.3.1 where the recipient endpoint is a client, INPUT_1 was already computed when actually performing Step 2 of Section 4.3.1. 5. Compute the PIV value, by XORing with each other: * The ENC_PIV value encoded within the "Partial IV" field of the OSCORE Option of MSG; and * The Q bytes from PIV_KEYSTREAM's start, where Q is the length in bytes of the "Partial IV" field and PIV_KEYSTREAM is the result of Step 4. 6. In the "Partial IV" field of the OSCORE Option of MSG, replace its current ENC_PIV value with the PIV value computed at Step 5. 4.4. External Signature Checkers As defined in Section 7.5 of [I-D.ietf-core-oscore-groupcomm], it is possible to designate external signature checkers to verify the signature of messages protected with the group mode of Group OSCORE and sent to a group. Since it does not join the group as a member, an external signature checker needs to retrieve from the Group Manager the authentication credentials and other information (e.g., the Sender IDs) associated with group members, together with other selected group data such as the current Signature Encryption Key (see Section 2.1.9 of [I-D.ietf-core-oscore-groupcomm]). In particular, Section 12.3 of [I-D.ietf-core-oscore-groupcomm] describes how the Group Manager supports signature checkers and what information it provides them with. The realization of Group Manager specified in [I-D.ietf-ace-key-groupcomm-oscore] provides such support through the operations defined in Sections 8.5.1, 9.3, 9.5, 9.6, and 9.10 of [I-D.ietf-ace-key-groupcomm-oscore]. Tiloca, et al. Expires 6 May 2027 [Page 30] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 The rest of this section describes how a signature checker verifies the signature of messages sent to a group where the Group OSCORE Security Context CTX is an Obfuscating Security Context. In addition to what is defined in Section 12.3 of [I-D.ietf-core-oscore-groupcomm], the signature checker also needs to retrieve the following two pieces of information about the group from the Group Manager: * The current Obfuscation Key (see Section 2). * An indication of whether CTX is specifically an Incognito Security Context or not. The particular way to provide such information to the signature checker depends on the specific realization of Group Manager and is out of the scope of this document. Building on the information about a group obtained from the Group Manager, the signature checker locally stores multiple Verification Recipient Contexts, each associated with a group member X and including: * The public authentication credential of X. * The Recipient ID associated with X, i.e., the Sender ID of X. * The Obfuscation Recipient Key associated with X (see Section 4.1.2). The signature checker derives the Obfuscation Recipient Key like group members do, i.e., by using the Obfuscation Key and the Recipient ID associated with X as the PRK parameter and the info parameter of the HKDF-Expand step, respectively. Since it does not store CTX, the signature checker more generally stores the Verification Recipient Contexts together with the other group data obtained from the Group Manager. When processing a message MSG protected in group mode and sent to the group, the signature checker first has to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of MSG as appropriate. After that, the signature checker processes the message as defined in Section 7.5 of [I-D.ietf-core-oscore-groupcomm]. Tiloca, et al. Expires 6 May 2027 [Page 31] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 The process by which the signature checker reverses the obfuscation of the "Partial IV" and "kid" fields is the same as the one defined in Section 4.3.2, with the difference that the Recipient Context REC_CTX is replaced by a Verification Recipient Context V_REC_CTX that the signature checker determines as defined below. With the same caveats discussed in Section 7.5 of [I-D.ietf-core-oscore-groupcomm] about the possible omission of the "Partial IV", "kid", and "kid context" fields in the OSCORE Option of a response, the process by which the signature checker determines the right V_REC_CTX to use is analogous to the process performed by a group member that receives MSG and determines the right Recipient Context REC_CTX to use as per Section 4.3.1. That also includes the special case discussed for a client at the beginning of Section 4.3.1, where MSG is a response that fulfills certain criteria. At the same time, the following differences apply: * Of the 17 steps compiled in Section 4.3.1, only Steps 1-9 and Step 17 are performed, with the modifications described below. * Step 17 is replaced by the execution of the expected, particular actions that the signature checker performs following an unsuccessful verification of the message signature. * At Step 4, the selection of a Verification Recipient Context does not occur within CTX, but rather within the collection of Verification Recipient Contexts that the signature checker stores for the group. * At Step 8, the Group OSCORE processing performed by the signature checker using the determined V_REC_CTX is limited to the verification of the signature in MSG, as per Section 7.5 of [I-D.ietf-core-oscore-groupcomm]. If the message signature is successfully verified, the signature checker sets the value of the OSCORE Option of MSG to the same value that the OSCORE Option had when MSG was received. Then, the signature checker performs the expected, particular actions that follow a successful verification of the message signature, and the algorithm in Section 4.3.1 terminates. * The actions at Step 9 are replaced by the following actions. The signature checker contacts the Group Manager responsible for the OSCORE Group, and it retrieves the set of pairs P = (ID, CRED) from the Group Manager. Within each pair, ID is the Sender ID of a current group member and CRED is the public authentication credential of that group member. Tiloca, et al. Expires 6 May 2027 [Page 32] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 For each pair P, the signature checker determines whether it currently stores a Verification Recipient Context that includes ID as the Recipient ID and CRED as the public authentication credential. If that is not the case, the signature checker creates such a Verification Recipient Context, for which it also derives and stores therein the Obfuscation Recipient Key associated with the corresponding group member. Then, the Group Manager attempts to determine the right Verification Recipient Context V_REC_CTX among the just created ones. That is, the signature checker starts over its processing of MSG, but looking for the right V_REC_CTX to use only among the latest, just created Verification Recipient Contexts. If this round of attempts yields a successful verification of the message signature, the signature checker sets the value of the OSCORE Option of MSG to the same value that the OSCORE Option had when MSG was received. Then, the signature checker performs the expected, particular actions that follow a successful verification of the message signature and this algorithm terminates. Otherwise, the signature checker fails the signature verification process and performs the particular actions that replaced Step 17 (see above). To limit the interactions with the Group Manager that would interrupt the ongoing processing of a message, the signature checker ought to regularly contact the Group Manager for retrieving the current set of authentication credentials of group members, in the interest of already having an available up-to-date collection of Verification Recipient Contexts when needed. 4.5. Deterministic Requests This section discusses a special case where: i) a value smaller than 65536 is used as the Sender Sequence Number; and ii) the "Partial IV" and "kid" fields of the OSCORE Option are not obfuscated, even if the Group OSCORE Security Context is an Obfuscating Security Context or specifically an Incognito Security Context. The specification [I-D.ietf-core-cacheable-oscore] defines an approach for restoring cacheability of CoAP responses that are protected end-to-end with Group OSCORE. The approach relies on the concept of Deterministic Request, i.e., a request protected with the pairwise mode of Group OSCORE that any client in the OSCORE group is able to compose. Tiloca, et al. Expires 6 May 2027 [Page 33] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 When composing a Deterministic Request, a client effectively impersonates a Deterministic Client, i.e., a fictitious member of the OSCORE group associated with a dedicated OSCORE Sender ID. Also, each Deterministic Request is computed by using the Sender Sequence Number 0. Therefore, even when the Group OSCORE Security Context used is an Obfuscating Security Context or specifically an Incognito Security Context, the following applies to the OSCORE Option of a Deterministic Request: * The "Partial IV" field retains a length of 1 byte and encodes the value 0 in plaintext. * The "kid" field conveys the actual OSCORE Sender ID of the Deterministic Client in plaintext. 5. Agreement on Obfuscating Fields in the OSCORE Option If an endpoint does not have an explicit agreement with its peer(s) about employing the method specified in this document when using a (Group) OSCORE Security Context CTX, the following applies in order to preserve interoperability: * The endpoint MUST NOT obfuscate the "Partial IV" and "kid" fields in the OSCORE Option of its outgoing messages protected with CTX (or with a Security Context derived from CTX, see Section 3.3.2). * The endpoint MUST NOT attempt to reverse the obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option of incoming messages protected with CTX (or with a Security Context derived from CTX, see Section 3.3.2). The rest of this section defines means that endpoints can use to reach an agreement about obfuscating the "Partial IV" and "kid" fields as per the method specified in this document. 5.1. Agreement for OSCORE TBD Editor's note: expected means to cover include: * Pre-provisioning * In LAKE * In the OSCORE profile of the ACE framework Tiloca, et al. Expires 6 May 2027 [Page 34] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * In OMA Lightweight Machine-to-Machine (LwM2M) 5.2. Agreement for Group OSCORE TBD Editor's note: expected means to cover include: * The OSCORE Group Manager based on the ACE framework - Messages to (candidate) group members - Messages to external signature verifiers - Message to/from an Administrator * A CoAP server supporting observe multicast notifications and self- managing the OSCORE group for its group observations. 6. Security Considerations 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. The method defined in this document provides confidentiality protection of the obfuscated fields in the OSCORE Option against passive adversaries. Furthermore, the following considerations also apply. 6.1. Minimum Length of Sender Sequence Numbers As per Section 3.1, a Sender Sequence Number value has to be at least 65536 when using the method defined in this document. This ensures that the "Partial IV" field of the OSCORE Option has a length of at least 3 bytes. In turn, this defeats possible attempts to track an endpoint or to fingerprint its traffic that leverage a transition of the length of the "Partial IV" field from 1 to 2 bytes, or from 2 to 3 bytes. The requirement above does not apply for the special cases discussed: * In Section 3.3.1, for the one-off LAKE + OSCORE request defined in [RFC9668] (denoted therein as "EDHOC + OSCORE request"). However, the requirement does apply for all the messages that the two endpoints exchange after the LAKE + OSCORE request and that are protected with the same OSCORE Security Context. Tiloca, et al. Expires 6 May 2027 [Page 35] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 * In Section 4.5, for a Deterministic Request that is intrinsically designed to be replayed, as intended to be identically sent multiple times by multiple clients to the same server(s) [I-D.ietf-core-cacheable-oscore]. 6.2. Robustness of the Encryption of the Partial IV When performing the steps in Section 3.1 and Section 3.2, using the same Obfuscation Key and SAMPLE_1 more than once risks compromising the encryption of the PIV value in the "Partial IV" field. That is, encrypting the PIV_A and PIV_B values of two different "Partial IV" fields by leveraging the same Obfuscation Key and SAMPLE_1 reveals the exclusive OR of PIV_A and PIV_B. Assuming that SAMPLE_1 is consistent with the outcome of a pseudorandom function (PRF), if L bits are sampled, then the probability that two SAMPLE_1 byte strings of length L are identical approaches P = 2^(-L/2), that is, the birthday bound. For messages protected with (Group) OSCORE, SAMPLE_1 has a minimum length L_MIN of 72 bits and a maximum length L_MAX of 128 bits. Therefore, P is at most one in 2^36 (when SAMPLE_1 has a length of L_MIN bits) and at least one in 2^64 (when SAMPLE_1 has a length of L_MAX bits or more). 6.3. Impact on Endpoint Trackability 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). If addressing information does not change upon network migration, an on-path adversary might still be able to track an endpoint. Even if combined with the change of addressing information upon network migration, the method defined in this document 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. 6.4. Trial Decryptions Due to the possible obfuscation of the "kid" field of the OSCORE Option, a recipient endpoint could end up performing trial decryptions on an incoming message, when attempting to retrieve the right Recipient Context to use. Tiloca, et al. Expires 6 May 2027 [Page 36] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Such trial decryptions fail when the recipient endpoint retrieves a Recipient Context that appears to be the right one to use, while in fact it is not and its selection was the result of a false positive matching of a (stand-in) key identifier. This could be the case in the following circumstances. * OSCORE is used and the recipient endpoint is a server (see Section 3.2.1). In particular: - If the recipient endpoint stores at least one Ordinary Security Context, the endpoint first assumes that the "Partial IV" and "kid" fields in the OSCORE Option of the incoming message were not obfuscated. Consequently, the endpoint first attempts to retrieve an Ordinary Security Context to process the message (see Step 2 in Section 3.2.1). If a Security Context is found and the OSCORE processing of the incoming message fails, the endpoint proceeds with looking for Obfuscating Security Contexts to use. Note that, for a false positive to be possible, the recipient endpoint has to store an Ordinary Security Context such that the Recipient ID therein has a length of exactly 3 bytes. Therefore, in order to prevent this kind of false positive, it is NOT RECOMMENDED for endpoints supporting Incognito Security Contexts to use OSCORE Sender/Recipient IDs with a length of 3 bytes within Ordinary Security Contexts. - If the recipient endpoint stores Obfuscating Security Contexts and only some of those are specifically Incognito Security Contexts, the recipient endpoint first assumes that the "kid" field in the OSCORE Option of the incoming message is not obfuscated. That is, it performs the inspection of its stored Obfuscating Security Contexts starting from those that are not Incognito Security Contexts (see Step 7 in Section 3.2.1). If a Security Context is found and the OSCORE processing of the incoming message fails, the endpoint continues inspecting the set of Obfuscating Security Contexts. Tiloca, et al. Expires 6 May 2027 [Page 37] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Note that, for a false positive to be possible, the recipient endpoint has to store an Obfuscating Security Context such that it is not an Incognito Security Context and the Recipient ID therein has a length of exactly 3 bytes. Therefore, in order to prevent this kind of false positive, it is NOT RECOMMENDED for endpoints supporting Incognito Security Contexts to use OSCORE Sender/Recipient IDs with a length of 3 bytes within Obfuscating Security Contexts that are not Incognito Security Contexts. - If the recipient endpoint stores Incognito Security Contexts, multiple of those might result in computing a STAND_IN_KID value that is equal to the value encoded in the "kid" field of the OSCORE Option of the incoming message (see Step 10 in Section 3.2.1). In the case of a positive match, the selected Incognito Security Context is used for the OSCORE processing of the incoming message (see Step 11 in Section 3.2.1), which fails unless the selected Security Context is actually the right one to use. If the OSCORE processing fails, the endpoint continues inspecting the set of Obfuscating Security Contexts. Assuming that STAND_IN_KID is consistent with the outcome of a PRF and since it has a length of 3 bytes, the probability that a computed STAND_IN_KID value results in a false positive matching is P = 2^-12, that is, the birthday bound. * Group OSCORE is used, the Group OSCORE Security Context is an Incognito Security Context, and the incoming message includes the "kid" field (see Section 4.3.1). In particular: - Within the Group OSCORE Security Context, multiple Recipient Contexts might result in computing a STAND_IN_KID value that is equal to the value encoded in the "kid" field of the OSCORE Option of the incoming message (see Step 7 in Section 4.3.1). In the case of a positive match, the selected Recipient Context is used for the Group OSCORE processing of the incoming message (see Step 8 in Section 4.3.1), which fails unless the selected Recipient Context is actually the right one to use. If the Group OSCORE processing fails, the endpoint continues inspecting the set of Recipient Contexts. - If the recipient endpoint does not find an eligible Recipient Context among the stored ones, the endpoint might proceed with the dynamic derivation of new Recipient Contexts, if allowed by the application (see Step 9 in Section 4.3.1). Tiloca, et al. Expires 6 May 2027 [Page 38] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 After establishing a new Recipient Context, this might result in computing a STAND_IN_KID value that is equal to the value encoded in the "kid" field of the OSCORE Option of the incoming message (see Step 15 in Section 4.3.1). In the case of a positive match, the newly established Recipient Context is used for the Group OSCORE processing of the incoming message (see Step 16 in Section 4.3.1), which fails unless the Recipient Context is actually the right one to use. If the Group OSCORE processing fails, the endpoint can continue establishing and trying further available Recipient Contexts, as long as information to do so is available. Assuming that STAND_IN_KID is consistent with the outcome of a PRF and since it has a length of 3 bytes, the probability that a computed STAND_IN_KID value results in a false positive matching is P = 2^-12, that is, the birthday bound. Although the specific circumstances above are new and introduced by the method defined in this document, trial decryptions are in fact already a possibility in the following cases: * When using OSCORE, a server receiving a request might end up processing it with multiple OSCORE Security Contexts in sequence. This can happen, e.g., in the case of collisions with the values of ID Context and Recipient ID across stored Security Contexts. * When using OSCORE, a client receiving a response might end up processing it with multiple OSCORE Security Contexts in sequence. This can happen, e.g., in the case that the same Token value is used for multiple message exchanges that are simultaneously active. * When using Group OSCORE, a server receiving a request might end up processing it with multiple Group OSCORE Security Contexts in sequence. This can happen, e.g., in the case of collisions with the values of ID Context and Recipient ID across stored Security Contexts. For example, both the sender endpoint and the recipient endpoint can be in two different OSCORE groups under different Group Managers, with both OSCORE groups identified by the same Group ID and with the sender endpoint using the same Sender ID in both groups. In either case, the recipient endpoint can attempt using multiple available Security Contexts in sequence, until the right one is possibly found and message decryption and verification succeed. Tiloca, et al. Expires 6 May 2027 [Page 39] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Regardless of the specific circumstance by which trial decryptions occur, recipient endpoints still have to keep updated the status of their keying material, including after decryption failure. In particular, symmetric keys ought not to be used beyond certain key usage limits, i.e., after having reached a maximum number of failed decryptions [I-D.ietf-core-oscore-key-limits][I-D.irtf-cfrg-aead-limits]. Clearly, broadening the opportunities for trial decryption increases the pace by which key usage limits are approached, thereby increasing the frequency by which keying material needs to be updated, e.g., by using the key update procedure KUDOS [I-D.ietf-core-oscore-key-update]. 6.5. Not Obfuscating the "kid" Field When using an Obfuscating Security Context that is not an Incognito Security Context, the method specified in this document results only in obfuscating the "Partial IV" field of the OSCORE Option, but not the "kid" field. This is useful in some use cases where such information is effectively still obfuscated by other means. In such use cases, obfuscating the "kid" field by using the method defined in this document would simply result in unjustified (performance) penalties. For example, the specification [I-D.ietf-schc-8824-update] defines how to use the Static Context Header Compression and fragmentation (SCHC) framework [RFC8724] for compressing headers of CoAP messages, also when messages are protected with OSCORE or Group OSCORE. Two endpoints using (Group) OSCORE and SCHC header compression can enforce SCHC compression Rules that include a Field Descriptor for the "kid" field of the OSCORE Option. The intent of such a SCHC Rule is typically to match with a protected message where the "kid" field conveys the same value specified in the corresponding Field Descriptor of the Rule. As a result, the SCHC compression elides the "kid" field from the message before transmission, and the field will be reconstructed by the recipient endpoint when performing SCHC Decompression per the same SCHC Rule. Tiloca, et al. Expires 6 May 2027 [Page 40] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 In such a scenario, obfuscating the "kid" field by means of the method defined in this document will prevent the intended SCHC compression Rule to match with the protected message to compress, since the stand-in identifier that is overwritten in the "kid" field of the OSCORE Option will differ from the static, expected value specified in the Field Descriptor of the SCHC Rule. In fact, unless other installed SCHC compression Rules produce a match, the message as a whole will simply not be compressed. To ensure that at least other fields of the message are compressed, the SCHC Rule would instead have to include the Field Descriptor for the "kid" field that always results in preserving the "kid" field as- is, without compression. Clearly, it is instead better to enforce the originally intended SCHC Rule, while not obfuscating the "kid" field through the method specified in this document. With the exception of such use cases that effectively achieve obfuscation of the "kid" field by other means, endpoints that support the method defined in this document and explicitly agree to use it ought to rely on Incognito Security Contexts and thus obfuscate the "kid" field of the OSCORE Option accordingly. 7. IANA Considerations TBD Editor's note: expected actions are registrations of new parameters that effectively enable the means defined in Section 5. 8. References 8.1. Normative References [AES] NIST, "Advanced Encryption Standard (AES)", May 2023, . [COSE.Algorithms] IANA, "COSE Algorithms", . Tiloca, et al. Expires 6 May 2027 [Page 41] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 [I-D.ietf-core-cacheable-oscore] Amsüss, C. and M. Tiloca, "End-to-End Protected and Cacheable CoAP Responses using Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-cacheable- oscore-02, 6 July 2026, . [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23 December 2025, . [I-D.ietf-core-oscore-key-update] Höglund, R. and M. Tiloca, "Key Update for OSCORE (KUDOS)", Work in Progress, Internet-Draft, draft-ietf- core-oscore-key-update-14, 6 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Tiloca, et al. Expires 6 May 2027 [Page 42] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, . [RFC9668] Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024, . 8.2. Informative References [EuroSandP] Lenders, M. S., Schmidt, T. C., and M. Wählisch, "Secrets Best Not Shared: DNS Privacy Enhancements for the Constrained IoT", June 2026, . [I-D.ietf-ace-key-groupcomm-oscore] Tiloca, M. and F. Palombini, "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-21, 14 March 2026, . Tiloca, et al. Expires 6 May 2027 [Page 43] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 [I-D.ietf-core-groupcomm-bis] Dijk, E. and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 18, 10 February 2026, . [I-D.ietf-core-oscore-key-limits] Höglund, R. and M. Tiloca, "Key Usage Limits for OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-oscore- key-limits-08, 7 September 2026, . [I-D.ietf-schc-8824-update] Tiloca, M., Toutain, L., Martínez, I., and A. Minaburo, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-schc-8824-update-10, 26 July 2026, . [I-D.irtf-cfrg-aead-limits] Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft- irtf-cfrg-aead-limits-13, 3 September 2026, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . Acknowledgments The authors sincerely thank Christian Amsüss, Carsten Bormann, and Martine Lenders for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS. Authors' Addresses Tiloca, et al. Expires 6 May 2027 [Page 44] Internet-Draft OSCORE - Stand-in KID and Encrypted PIV November 2026 Marco Tiloca RISE AB Isafjordsgatan 22 SE-164 40 Kista Sweden Email: marco.tiloca@ri.se John Preuß Mattsson Ericsson AB SE-164 40 Kista Sweden Email: john.mattsson@ericsson.com Rikard Höglund RISE AB Isafjordsgatan 22 SE-164 40 Kista Sweden Email: rikard.hoglund@ri.se Göran Selander Ericsson AB SE-164 40 Kista Sweden Email: goran.selander@ericsson.com Tiloca, et al. Expires 6 May 2027 [Page 45]