Skip to content

Commit

Permalink
Clarified behavior when reaching the limit of applied/removed OSCORE …
Browse files Browse the repository at this point in the history
…layers
  • Loading branch information
marco-tiloca-sics committed Jan 24, 2024
1 parent 6fb36ae commit 718976d
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion draft-ietf-core-oscore-capable-proxies.md
Original file line number Diff line number Diff line change
Expand Up @@ -242,7 +242,7 @@ As mentioned in {{intro}}, this document introduces the following two main devia

An OSCORE endpoint SHOULD define the maximum number of OSCORE layers that it is able to apply (remove) when processing an outgoing (incoming) CoAP message. The defined limit has to appropriately reflect the security requirements of the application. At the same time, it is typically bounded by the maximum number of OSCORE Security Contexts that can be active at the endpoint, and by the number of intermediary OSCORE endpoints that have been explicitly set up by the communicating parties.

If its defined limit is reached when processing a CoAP message, an OSCORE endpoint MUST NOT perform any further OSCORE processing on that message. For an outgoing request, this results in aborting the message sending altogether. For an incoming request, this results in replying with a 4.01 (Unauthorized) error response, which the OSCORE endpoint protects by applying the same OSCORE layers that it successfully removed from the corresponding incoming request, but in the reverse order than the one according to which they were removed (see {{outgoing-responses}}).
If its defined limit is reached when processing a CoAP message, an OSCORE endpoint MUST NOT perform any further OSCORE processing on that message. If the message is an outgoing request and it requires further OSCORE processing beyond the set limit, the endpoint MUST abort the message sending. If the message is an incoming request and it requires further OSCORE processing beyond the set limit, the endpoint MUST reply with a 4.01 (Unauthorized) error response. The endpoint protects such a response by applying the same OSCORE layers that it successfully removed from the corresponding incoming request, but in the reverse order than the one according to which they were removed (see {{outgoing-responses}}).

{{sec-examples}} provides a number of examples where the approach defined in this document is used to protect message exchanges.

Expand Down

0 comments on commit 718976d

Please sign in to comment.