]> RISE AB

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

Ericsson AB

Stockholm 164 80 Sweden john.mattsson@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 field Partial IV specifies the sequence number value used by the message sender. In the interest of encrypting as much information as reasonably possible, this document defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option. Therefore, it updates RFC 8613. Combined with the update of OSCORE identifiers, the encryption of Partial IV values helps counteracting on-path adversaries that attempt to correlate the sequence numbers observed in different network paths, in order to track OSCORE endpoints that perform a network path migration. The defined encryption method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). 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, the OSCORE option can include a Partial IV, which specifies the sequence number value used by a sender endpoint when protecting an outgoing message. A Partial IV is always present in request messages, while it is typically absent in response messages, with a few exceptions mandating its presence. Following a message protection with OSCORE, the OSCORE option added to the message is not encrypted, since its content provides a recipient endpoint with information for processing the OSCORE-protected incoming message. However, sending the Partial IV in plaintext enables on-path adversaries to perform trivial tracking of OSCORE endpoints across different network paths, by correlating the sequence numbers observed in those network paths (e.g., following a network path migration, possibly across different network segments). In the interest of encrypting as much information as reasonably possible, this document updates and defines a lightweight add-on method for encrypting the Partial IV within the OSCORE option. This method does not require an in-band signaling and its use does not arbitrarily change on a per-message basis. Instead, upon establishing an OSCORE Security Context, the communicating OSCORE endpoints already have an agreement on either encrypting or not encrypting the Partial IV when they use that Security Context, for every OSCORE-protected message where a Partial IV is included. Like for the overall protection of messages with OSCORE, the encryption of the Partial IV is agnostic of how exactly the OSCORE Security Context was established and of how the agreement on encrypting the Partial IV was reached. Nevertheless, this document also defines means that endpoints can use to reach that agreement. Absent an explicit agreement, the Partial IV specified in the OSCORE option remains unencrypted, in order to preserve interoperability. Although it is a self-standing functionality, the encryption of the Partial IV is intended to be combined with the update of OSCORE identifiers defined in . When OSCORE endpoints perform a network path migration with consequent change of their addressing information, such a combination helps against on-path adversaries that attempt to track OSCORE endpoints across different network paths. The encryption method defined in this document is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP . In the interest of such a case, this document also defines means to synchronize the members of an OSCORE group with respect to the encryption of the Partial IV within the group.

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 .

PIV Encryption Key When the encryption of the Partial IV is enabled, the (Group) OSCORE Security Context is extended with one additional parameter in the Common Context. The new parameter PIV Encryption Key specifies the encryption key for deriving a keystream to encrypt/decrypt a Partial IV, when this is included in a message protected with (Group) OSCORE. The PIV Encryption Key is derived as defined for the Sender/Recipient Keys in , with the following differences.

• The 'id' element of the 'info' array is the empty byte string.
• The 'type' element of the 'info' array is "PIVEKey". The label is an ASCII string and does not include a trailing NUL byte.
• If the Security Context is used for Group OSCORE and the Group Encryption Algorithm in the Common Context is set (see ), then:
  • The 'alg_aead' element of the 'info' array specifies the Group Encryption Algorithm from the Common Context encoded as a CBOR integer or text string, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm .
  • The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the key for the Group Encryption Algorithm specified in the Common Context. While the obtained PIV Encryption Key is never used with the Group Encryption Algorithm, its length was chosen to obtain a matching level of security.
• If the Security Context is used for Group OSCORE and the Group Encryption Algorithm in the Common Context is not set (see ), then:
  • 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, consistently with the "Value" field in the entry of the "COSE Algorithms" Registry for this algorithm .
  • The L parameter of the HKDF and the 'L' element of the 'info' array are the length in bytes of the key for the AEAD Algorithm specified in the Common Context. While the obtained PIV Encryption Key is never used with the AEAD Algorithm, its length was chosen to obtain a matching level of security.

Encryption of the Partial IV Once composed an OSCORE-protected outgoing message MSG that includes the Partial IV in the OSCORE option (see ), the sender endpoint performs the following steps.

1. Compose SAMPLE as the first N bytes of the CoAP payload of MSG, where N = min(LENGTH, 16) and LENGTH denotes the length in bytes of the CoAP payload of MSG. Note that:
   • LENGTH is guaranteed to have a minimum value of 9.
   • If MSG was protected with OSCORE or instead with Group OSCORE using the pairwise mode (see ), then the CoAP payload is the ciphertext of the COSE object.
   • If MSG was protected with Group OSCORE using the group mode (see ), then the CoAP payload is the ciphertext of the COSE object concatenated with the encrypted countersignature.
2. Compose INPUT as follows:
   • If the length of SAMPLE is less than 16 bytes, INPUT is obtained by left-padding SAMPLE with zeroes to exactly 16 bytes.
   • If the length of SAMPLE is 16 bytes, then INPUT takes SAMPLE.
3. Compute the 16-byte IV_KEYSTREAM as below: IV_KEYSTREAM = AES-ECB(PIV Encryption Key, INPUT) where:
   • AES-ECB is the AES algorithm in ECB mode .
   • PIV Encryption Key is taken from the Common Context of the Security Context used to produce MSG (see ). It is used as encryption key for the AES-ECB encryption.
   • INPUT is the result of Step 2. It is used as plaintext for the AES-ECB encryption.
4. Compute the encrypted Partial IV, by XORing the plain Partial IV from the OSCORE option of MSG with the Q bytes from the IV_KEYSTREAM's start, where Q is the length in bytes of the plain Partial IV. For example, if the plain Partial IV from the OSCORE option of MSG is 0x001122 (Q = 3 bytes) and IV_KEYSTREAM is 0xffeeddccbbaa99887766554433221100 (16 bytes), then the bytes of IV_KEYSTREAM to XOR with the plain Partial IV are 0xffeedd.
5. Replace the plain Partial IV in the OSCORE option of MSG with the encrypted Partial IV computed at Step 4.

Once completed the steps above, the sender endpoint transmits MSG as expected.

Decryption of the Partial IV Upon receiving an incoming message MSG that includes an encrypted Partial IV and after having retrieved the (Group) OSCORE Security Context to process the message, the recipient endpoint performs the following steps.

1. Compute IV_KEYSTREAM by means of the same method defined at Steps 1-3 of .
2. Compute the plain Partial IV, by XORing the encrypted Partial IV from the OSCORE option of MSG with the Q bytes from the IV_KEYSTREAM's start, where Q is the length in bytes of the encrypted Partial IV.
3. Replace the encrypted Partial IV in the OSCORE option of MSG with the plain Partial IV computed at Step 2.

Once completed the steps above, the recipient endpoint continues processing MSG as expected.

Considerations on Effectiveness If an endpoint that encrypts the Partial IV expects to send more than 256 messages including a Partial IV and protected with the same Sender Context, then that Sender Context SHOULD use 65536 as lowest value for the Sender Sequence Number of that endpoint. This ensures that the Partial IV is encoded in at least 3 bytes in the OSCORE option, hence defeating attempts to track an endpoint by leveraging the transition between the encoding of Partial IVs from 1 to 2 bytes in size, or from 2 to 3 bytes in size.

Agreement on Encrypting the Partial IV Absent explicit information associated with the (Group) OSCORE Security Context used and an agreement with its peer(s), an endpoint does not encrypt/decrypt the Partial IV when using that Security Context, thereby preserving interoperability. The rest of this section defines means that endpoints can use to reach an agreement about encrypting the Partial IV as specified in this document.

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

• Pre-provisioning
• In EDHOC
• 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. Furthermore, the following considerations also apply.

Limitations The method defined in this document provides confidentiality protection of the Partial IV against passive adversaries. An active adversary could guess the plain Partial IV and have a recipient OSCORE endpoint confirm the guesses, e.g., taking advantage of timing side channels. For instance, this can be the case when the recipient endpoint discards an incoming message that is detected as a replay, i.e., without attempting to decrypt and verify the message and hence revealing information through timing side channels. Similarly, depending on whether the processing of an incoming request message fails due to a replay detection or instead to a failed decryption and verification, the recipient endpoint would follow-up by sending different, unprotected error response messages, which the adversary can leverage to confirm the guesses.

Encryption Robustness When performing the steps at and , using the same PIV Encryption Key and SAMPLE more than once risks compromising the encryption of the Partial IV. That is, encrypting two different Partial IVs by leveraging the same PIV Encryption Key and SAMPLE reveals the exclusive OR of the encrypted Partial IVs. Assuming that SAMPLE is consistent with the outcome of a pseudorandom function (PRF), if L bits are sampled, then the odds that two SAMPLE byte strings of length L are identical approach P = 2^-L/2, that is, the birthday bound. For messages protected with (Group) OSCORE, SAMPLE has a minimum length L_MIN of 72 bits and a maximum length L_MAX of 128 bits. Therefore, P is at least 2³⁶ (when the CoAP payload has a length of L_MIN bits) and at most 2⁶⁴ (when the CoAP payload has a length of L_MAX bits or more).

Impact on Endpoint Trackability The method defined in allows OSCORE endpoints to update their OSCORE identifiers. Switching to a new OSCORE identifier is particularly useful when an endpoint migrates to a new network path, as it counteracts attempts to track the endpoint across different network paths by leveraging its OSCORE identifier. Clearly, an on-path adversary might still be able to track an endpoint, e.g., by leveraging addressing information that does not change upon network migration or by attempting to correlate the Partial IV values observed on different network paths. The method for encrypting the OSCORE Partial IV defined in this document helps against the latter. That is, in case the OSCORE Partial IV is not encrypted, endpoints could be successfully tracked even when different OSCORE identifiers are used on each network path. The tracking of an OSCORE endpoint that migrates to a new network path can be largely counteracted by using the method defined in this document, if combined with the use of new source addressing information (e.g., IP address and link-layer address) and of a new OSCORE identifier that the endpoint has not used before in other network paths. This does not prevent other properties of network packets, e.g., their timing or length, from being used to correlate activities of the same endpoint across different network paths.

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

References Normative References 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. 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. 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 CoAP messages exchanged 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. 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 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 RISE AB Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure.

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.