From 2637bce1a7cee29cbf4e199e753cb581a627a0d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rikard=20H=C3=B6glund?= Date: Fri, 27 Sep 2024 11:32:40 +0200 Subject: [PATCH] Explain why Appendix B.2 is secure while not including PIV in responses --- draft-ietf-core-oscore-key-update.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-key-update.md b/draft-ietf-core-oscore-key-update.md index 7ed518a..2be085a 100644 --- a/draft-ietf-core-oscore-key-update.md +++ b/draft-ietf-core-oscore-key-update.md @@ -174,8 +174,10 @@ The protection of CoAP responses with OSCORE is updated, by adding the following {:quote} > If the server is using a different Security Context for the response compared to what was used to verify the request (e.g., due to an occurred key update), then the server MUST take the second alternative. That is, the server MUST include its Sender Sequence Number as Partial IV in the response and use it to build the AEAD nonce to protect the response. +> +> This prevents the server from using the same AEAD (key, nonce) pair for two responses, protected with different OSCORE Security Contexts. > -> This prevents the server from using the same AEAD (key, nonce) pair for two responses, protected with different OSCORE Security Contexts. An exception is the procedure in {{Section B.2 of RFC8613}}, which is secure although not complying with the above. +> An exception is the procedure in {{Section B.2 of RFC8613}}, which is secure although not complying with the above. The reason is that, in that procedure, the server uses the new OSCORE Security Context only and solely to protect the outgoing response (response #1), and no other message is protected with that OSCORE Security Context. Other procedures where that holds would also remain secure. # Key Update for OSCORE (KUDOS) # {#sec-rekeying-method}