From f59a6023172fd983a6daf4a4327d4107b3401af9 Mon Sep 17 00:00:00 2001 From: crimson Date: Sun, 28 Jul 2024 18:25:26 +0200 Subject: [PATCH] Rephrased consequences on loss of Recipient Contexts --- draft-ietf-core-oscore-groupcomm.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-groupcomm.md b/draft-ietf-core-oscore-groupcomm.md index 93028c9..9fa9e58 100644 --- a/draft-ietf-core-oscore-groupcomm.md +++ b/draft-ietf-core-oscore-groupcomm.md @@ -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. @@ -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.