diff --git a/address-9-oscore/draft-bormann-core-corr-clar.html b/address-9-oscore/draft-bormann-core-corr-clar.html index 35dae7d..867b218 100644 --- a/address-9-oscore/draft-bormann-core-corr-clar.html +++ b/address-9-oscore/draft-bormann-core-corr-clar.html @@ -1590,9 +1590,9 @@

2.5.1. OSCORE, KUDOS, and Group OSCORE

The security protocol Object Security for Constrained RESTful Environments (OSCORE) defined in [RFC8613] provides end-to-end security for CoAP messages at the application level, by using CBOR Object Signing and Encryption (COSE) [RFC9052]. In order to protect their communications, two peers need to have already established an OSCORE Security Context.

-

As an example, Appendix B.2 of [RFC8613] provides a key update procedure, which two OSCORE peers can run for establishing a new shared OSCORE Security Context that replaces their old one. The recent key update protocol KUDOS [I-D.ietf-core-oscore-key-update] specifies how two OSCORE peers can establish a new shared OSCORE Security Context that replaces their old one, with a number of advantages compared to the method defined in Appendix B.2 of [RFC8613].

+

Appendix B.2 of [RFC8613] provides an example for a key update procedure, which two OSCORE peers can run for establishing a new shared OSCORE Security Context that replaces their old one. The recent key update protocol KUDOS [I-D.ietf-core-oscore-key-update] specifies how two OSCORE peers can establish a new shared OSCORE Security Context that replaces their old one, with a number of advantages compared to the method defined in Appendix B.2 of [RFC8613].

The security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) defined in [I-D.ietf-core-oscore-groupcomm] builds on OSCORE and protects group communication for CoAP [I-D.ietf-core-groupcomm-bis]. The management of the group keying material is entrusted to a Group Manager (see Section 3 of [I-D.ietf-core-oscore-groupcomm]), which provides the latest group keying material to a new group member upon its group joining, and can update the group keying material by performing a group rekeying.

-

The following discusses how OSCORE, KUDOS, and Group OSCORE position themselves with respect to the match boxing, the used transport underlying CoAP, and the renewal of the keying material.

+

The following discusses how OSCORE, KUDOS, and Group OSCORE position themselves with respect to the match boxing, the transport used underlying CoAP, and the renewal of the keying material.

@@ -1601,7 +1601,12 @@

The security processing of (Group) OSCORE is agnostic of the value assumed by the CoAP Token and Message ID. Also, (Group) OSCORE can be seamlessly used in the presence of (cross-)proxies that will change the value of the CoAP Token and Message ID on the different communication legs. This does not affect the security processing at the (Group) OSCORE endpoints.

Before any security processing is performed, the only use that (Group) OSCORE makes of the Token value is on the CoAP client upon receiving a response, in order to retrieve the right Security Context to use for decrypting and verifying the response.

Even in case the Token value in a CoAP response is manipulated to induce a Request-Response matching at the client, there is no risk for the client to successfully decrypt the response instead of failing as expected. This is because, per Section 12.3 of [RFC8613], the OSCORE Master Secret of each OSCORE Security Context is required not only to be secret, but also to have a good amount of randomness.

-

Building on that, an HKDF is used to derive the actual encryption keys from the Master Secret and, optionally, from an additional Master Salt. Furthermore, for each OSCORE Security Context, the quartet (Master Secret, Master Salt, ID Context, Sender ID) must be unique. As per Section 3.3 of [RFC8613], this is a hard requirement and guarantees unique (key, nonce) pairs for the used AEAD algorithm.

+

Building on that, an HKDF is used to derive the actual encryption keys +from the Master Secret and, optionally, from an additional Master +Salt. Furthermore, for each OSCORE Security Context, the quartet +(Master Secret, Master Salt, ID Context, Sender ID) must be unique. As +per Section 3.3 of [RFC8613], this is a hard requirement and +guarantees unique (key, nonce) pairs for the AEAD algorithm used.

In Group OSCORE, the Security Context extends that of OSCORE, and the same as above holds (see Sections 2, 2.2, and 13.11 of [I-D.ietf-core-oscore-groupcomm]).

Finally, (Group) OSCORE performs a separate secure match boxing under its own control, by cryptographically binding each protected request with all the corresponding protected responses. This is achieved by means of the COSE external_aad involved during the security processing of protected messages (see Section 5.4 of [RFC8613] and Section 4.4 of [I-D.ietf-core-oscore-groupcomm]).

@@ -1611,12 +1616,14 @@
2.5.1.2. Underlying Transport
-

The security protocol (Group) OSCORE does not have any requirement on binding the used Security Context to specific addressing information used by the transport protocol underlying CoAP. What occurs below (Group) OSCORE with transport-specific addressing information is transparent to (Group) OSCORE, but it needs to work well enough to ensure that received data is delivered to (Group) OSCORE for security processing.

+

The security protocol (Group) OSCORE does not have any requirement on +binding the Security Context in use to specific addressing information used by the transport protocol underlying CoAP. What occurs below (Group) OSCORE with transport-specific addressing information is transparent to (Group) OSCORE, but it needs to work well enough to ensure that received data is delivered to (Group) OSCORE for security processing.

Consistent with the above, (Group) OSCORE does not interfere with any low-layer, transport specific information. Instead, it entrusts data to a Request-Response exchange mechanism that can rely on different means to enforce the Request-Response matching at the transport level (e.g., the 5-tuple, the CoAP Message ID, a file handle). Also, (Group) OSCORE does not alter the fact that a CoAP response needs to come from where the corresponding CoAP request was sent, which simply follows from using transports where that is a requirement.

Furthermore, two peers can seamlessly use (Group) OSCORE also in the presence of cross-proxies that change transport across different communication legs. This does not affect the security processing at the (Group) OSCORE endpoints.

Practically, (Group) OSCORE relies on the underlying CoAP implementation for obtaining received CoAP messages on which to perform the expected security processing.

Upon receiving a protected message, the recipient endpoint retrieves the OSCORE Security Context to use for decryption based on key identifier information specified in the CoAP OSCORE Option of protected requests, and on the value of the CoAP Token of protected responses.

-

In OSCORE, the key identifier information in request messages is typically limited to a "kid", with value the OSCORE Sender ID associated with the message sender. In case Sender IDs are not unique among different OSCORE Security Contexts stored by the same peer, it is possible to disambiguate by additionally using a "kid context" identifying the OSCORE Security Context as a whole. Instead, response messages are not required to convey key identifier information, as the client can rely on the Token conveyed in the response for retrieving the Security Context to use (see above).

+

In OSCORE, the key identifier information in request messages is +typically limited to a "kid", with a value the OSCORE Sender ID associated with the message sender. In case Sender IDs are not unique among different OSCORE Security Contexts stored by the same peer, it is possible to disambiguate by additionally using a "kid context" identifying the OSCORE Security Context as a whole. Instead, response messages are not required to convey key identifier information, as the client can rely on the Token conveyed in the response for retrieving the Security Context to use (see above).

In Group OSCORE, the key identifier information in request messages always includes also a "kid context", whose value is used as identifier of the OSCORE group associated with the Security Context to use for security processing of the exchanged message. Response messages are also required to convey a "kid" as key identifier information (i.e., the OSCORE Sender ID associated with the message sender), if the corresponding request was protected with the group mode of Group OSCORE (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) .

Some particular uses of (Group) OSCORE enable to build OSCORE-based tunneling [I-D.ietf-core-oscore-capable-proxies]. In such a case, a CoAP server might have to enforce that some OSCORE Security Contexts are not just looked up by a "kid" and similar key identifier information from the CoAP OSCORE Option in the incoming request to decrypt. Such a lookup should also rely on the alleged client's address, or on an alternative identifier of the tunnel from which the request came from.

@@ -1630,21 +1637,23 @@

The following provides more details about key update, separately for OSCORE, KUDOS, and Group OSCORE.