Skip to content

Commit

Permalink
"kid" in Group OSCORE responses
Browse files Browse the repository at this point in the history
  • Loading branch information
marco-tiloca-sics committed Jul 8, 2024
1 parent d16eb1a commit bcdb64e
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion draft-bormann-core-corr-clar.md
Original file line number Diff line number Diff line change
Expand Up @@ -411,7 +411,7 @@ Upon receiving a protected message, the recipient endpoint retrieves the OSCORE

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 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 protected with the group mode of Group OSCORE (see {{Section 8 of -group-oscore}}) 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 also protected with the group mode.
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 -group-oscore}}) .

Some particular uses of (Group) OSCORE enable to build OSCORE-based tunneling {{-oscore-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.

Expand Down

0 comments on commit bcdb64e

Please sign in to comment.