Skip to content

Commit

Permalink
Rephrased consequences on loss of Recipient Contexts
Browse files Browse the repository at this point in the history
  • Loading branch information
marco-tiloca-sics committed Jul 28, 2024
1 parent b254ac7 commit f59a602
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion draft-ietf-core-oscore-groupcomm.md
Original file line number Diff line number Diff line change
Expand Up @@ -525,7 +525,9 @@ An adversary may leverage the above to perform a Denial of Service attack and pr

The Security Context may contain a large and variable number of Recipient Contexts. A Recipient Context may need to be deleted, because the maximum number of Recipient Contexts has been reached (see {{ssec-sender-recipient-context}}), or due to some other reason.

When a Recipient Context is deleted, information about previously received messages from the corresponding other endpoint is lost. Therefore, if the Recipient Context is derived again from the same Security Context, there is a risk that a replayed message is not detected. If one Recipient Context has been deleted from the current Security Context, then the Replay Window of any new Recipient Context in this Security Context MUST be initialized as invalid. Messages associated with a Recipient Context that has an invalid Replay Window MUST NOT be delivered to the application.
When a Recipient Context is deleted, this does not only result in losing information about previously received messages from the corresponding other endpoint. It also results in the inability to be aware of the Security Contexts from which information has been lost.

Therefore, if the Recipient Context is derived again from the same Security Context, there is a risk that a replayed message is not detected. If one Recipient Context has been deleted from the current Security Context, then the Replay Window of any new Recipient Context in this Security Context MUST be initialized as invalid. Messages associated with a Recipient Context that has an invalid Replay Window MUST NOT be delivered to the application.

If the endpoint receives a request to process with the new Recipient Context and the endpoint supports the CoAP Echo Option {{RFC9175}}, then it is RECOMMENDED to follow the procedure specified in {{sec-synch-challenge-response}} which establishes a valid Replay Window. In particular, the endpoint MUST use its Partial IV when generating the AEAD nonce and MUST include the Partial IV in the response message conveying the Echo Option.

Expand Down Expand Up @@ -1984,6 +1986,8 @@ As discussed in {{ssec-gid-collision}}, if endpoints are deployed in multiple gr

* Removed mentioning of the CBOR encoding of the HKDF Algorithm.

* Rephrased consequences on loss of Recipient Contexts.

* Added IANA consideration on the "CoAP Option Numbers" registry.

* Updated references.
Expand Down

0 comments on commit f59a602

Please sign in to comment.