]> RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

Ericsson AB

Kista 164 40 Sweden john.mattsson@ericsson.com

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden rikard.hoglund@ri.se

Ericsson AB

Kista 164 40 Sweden goran.selander@ericsson.com

WIT CoRE Working Group Internet-Draft 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 Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP) . OSCORE operates at the application layer by using CBOR Object Signing and Encryption (COSE) 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.

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 . 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 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) that protects group communication for CoAP . 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.

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 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 , Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , COSE , OSCORE , and Group OSCORE . This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . This document also refers to the following terms:

• Ordinary 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 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 ).
• 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 ).
• 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. 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.

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 , 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 ), 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 .
• If the Security Context is used for Group OSCORE and the Group Encryption Algorithm in the Common Context is not set (see ), the following applies. The 'alg_aead' element of the 'info' array specifies the AEAD Algorithm from the Common Context (see ) encoded as a CBOR integer or text string, consistent with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm .
• The L parameter of the HMAC-based key derivation function (HKDF) and the 'L' element of the 'info' array are 16.

Processing in OSCORE This section and its subsections describe how the method defined in this document is specifically employed for messages protected with OSCORE .

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 , 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 ). As an exception, this requirement does not apply to the special case discussed in . Once MSG is composed, if at least one among the "Partial IV" and "kid" fields is included in the OSCORE Option (see ), 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.
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 .
   • ENC_KEY is the Obfuscation Key from the Common Context of the Security Context used to produce MSG (see ). ENC_KEY is used as the encryption key for the AES-ECB encryption. An exception applies in the special case discussed in , 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.
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 .
   • ENC_KEY is the Obfuscation Key from the Common Context of the Security Context used to produce MSG (see ). ENC_KEY is used as the encryption key for the AES-ECB encryption. An exception applies in the special case discussed in , 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).
   • 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 ).

Finally, the sender endpoint continues processing MSG as expected.

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 ). 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 ). After that, the recipient endpoint uses CTX to decrypt and verify MSG. As further discussed in and , an exception applies if MSG is sent as a message of the procedure Key Update for OSCORE (KUDOS) , 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 and do not apply to the special case of the LAKE + OSCORE request discussed in , 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.

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:

• CTX is an Ordinary Security Context. In this case, the client uses CTX to decrypt and verify MSG as defined in , with the exception of the special case mentioned below and discussed in .
• CTX is an Obfuscating Security Context. In this case, the client performs the steps defined in , 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 , with the exception of the special case mentioned below and discussed in . If the request to which MSG replies is a LAKE + OSCORE request (see ) 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 , 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 . 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 . An exception applies if MSG is sent as a message of the procedure KUDOS , 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. 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 and of . Then, this algorithm moves to Step 4.
   • Otherwise, the server performs the same error handling as defined in Sections and of . 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 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 , 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 , 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 . 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 . 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. 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 , 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 . An exception applies in the special case discussed in , 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 and of .
    • The OSCORE Option of MSG is restored to be as it was before running the algorithm in .
    • 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 ), the server performs the same error handling defined at Step 6 of 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 ), the server performs the same error handling defined in for the case where a replay has been detected. Then, this algorithm terminates. Otherwise,
    • The server performs the same error handling defined at Step 2 of for the case where a Security Context is not found.

Reversing the Field Obfuscation Given an Obfuscating Security Context CTX that was retrieved according to what is specified in , 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 ).
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 . 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 . Note that, if the recipient endpoint is a server, then INPUT_1 was already computed when actually performing Step 5 of .
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.

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

LAKE + OSCORE Request Two endpoints can run the protocol Lightweight Authenticated Key Exchange (LAKE) , in order to establish an OSCORE Security Context (see ). In particular, LAKE messages can be transported over CoAP (see ). 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 . 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 ), 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 , 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.
• 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 , 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.

KUDOS Two endpoints can use Key Update for OSCORE (KUDOS) , 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. 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.

6TiSCH The Constrained Join Protocol (CoJP) defined in 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 , 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 ). 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. 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 ).
• 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 :
  • 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 ).

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 . In particular, the following presents the differences that apply with respect to the case where OSCORE is used (see ).

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 ) and with one additional parameter Obfuscation Recipient Key in each Recipient Context (see ).

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. The Obfuscation Sender Key is derived as the output OKM of an HKDF-Expand step , 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.

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

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 . That is, the OSCORE Option always includes those fields in a request and may include those fields in a response. Once MSG is composed, if at least one among the "Partial IV" and "kid" fields is included in the OSCORE Option (see ), the sender endpoint performs the same steps of , 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 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 , 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 .

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.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. Consequently, within CTX, the recipient endpoint has to determine the specific Recipient Context REC_CTX to use for decrypting and verifying MSG (see ). 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 ). After that, the recipient endpoint uses REC_CTX to decrypt and verify MSG. The procedures defined in and do not apply to the special case of an incoming Deterministic Request discussed in , 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 .

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 , 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 . 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 ) and the "kid" field is not included in the OSCORE Option of MSG, the same as discussed for the case above applies, with the 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 . 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 , 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 . 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 . 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).
   • 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 , 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 . 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 ) 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 . 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 , , and of , some of the corresponding error handling is inherited from Sections and of .
   • The OSCORE Option of MSG is restored to be as it was before running the algorithm in .
   • This algorithm moves to Step 4.
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 ), 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 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.
    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 . 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 ).
    • 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 , 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 . 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 ) 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 . 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 , , and of , some of the corresponding error handling is inherited from Sections and of .
    • 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 ).
    • The OSCORE Option of MSG is restored to be as it was before running the algorithm in .
    • 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 and of 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 ), the server performs the same error handling defined in for the case where a replay has been detected. Then, this algorithm terminates. Otherwise,
    • The server performs the same error handling defined in Sections and of for the case where a Security Context is not found.

Reversing the Field Obfuscation Given a Recipient Context REC_CTX that was retrieved according to what is specified in , 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 ).
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 . 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 . Note that, except for the particular case discussed at the beginning of where the recipient endpoint is a client, INPUT_1 was already computed when actually performing Step 2 of .
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.

External Signature Checkers As defined in , 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 ). In particular, describes how the Group Manager supports signature checkers and what information it provides them with. The realization of Group Manager specified in provides such support through the operations defined in Sections , , , , and of . 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 , 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 ).
• 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 ). 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 . 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 , 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 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 . That also includes the special case discussed for a client at the beginning of , where MSG is a response that fulfills certain criteria. At the same time, the following differences apply:

• Of the 17 steps compiled in , 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 . 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 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. 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.

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

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 ).
• 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 ).

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.

Agreement for OSCORE TBD Editor's note: expected means to cover include:

• Pre-provisioning
• In LAKE
• In the OSCORE profile of the ACE framework
• In OMA Lightweight Machine-to-Machine (LwM2M)

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.

Security Considerations The same security considerations from and 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.

Minimum Length of Sender Sequence Numbers As per , 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 , for the one-off LAKE + OSCORE request defined in (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.
• In , 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) .

Robustness of the Encryption of the Partial IV When performing the steps in and , 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³⁶ (when SAMPLE_1 has a length of L_MIN bits) and at least one in 2⁶⁴ (when SAMPLE_1 has a length of L_MAX bits or more).

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.

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. 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 ). 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 ). 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 ). 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. 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 ). 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 ), 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 ). 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 ). 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 ), 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 ). 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 ). 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 ), 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. 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 . 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 .

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 defines how to use the Static Context Header Compression and fragmentation (SCHC) framework 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. 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.

IANA Considerations TBD Editor's note: expected actions are registrations of new parameters that effectively enable the means defined in .

References Normative References This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. RISE AB RISE AB Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. NIST IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. RISE AB IMT Atlantique IRISA Consultant This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices, and it uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Acknowledgments The authors sincerely thank , , and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.