Nits from 2nd WGLC review by Göran Selander

Göran Selander (https://mailarchive.ietf.org/arch/msg/6tisch/kD6_u12x1VC7saIYiNeN_XSe48Q) wrote:

A related concern is on the use of persistent memory:

"In case of a reboot on either side, the retrieval of mutable security context parameters is feasible from the persistent memory such that there is no risk of AEAD nonce reuse due to a reinitialized Sender Sequence number, or of a replay attack due to the reinitialized replay window."

Section B.1.1 of OSCORE details some issues with writing to non-volatile memory that are applicable in particular to the JRC, and this text should be updated accordingly. Depending on the JRC implementation, this may be another reason why the pledges/joined nodes need to support the protocol in Appendix B.2 in the case of JRC losing context.

Minor concerns:

"Implementations MUST ensure that multiple CoAP requests to different JRCs are properly incrementing the sequence numbers "

I don't know why this is restricted to different JRCs: Implementations MUST ensure that multiple CoAP requests properly incrementing the sequence numbers.

OLD "Since the pledge's OSCORE ID "

NEW "Since the pledge's OSCORE Sender ID "

" A simple implementation technique is to instantiate the OSCORE security context with a given PSK only once and use it for all subsequent requests. "

Reference 7.5 and/or appendix B.1. Note that these are rewritten so references here may have changed (see below).

OLD "The (6LBR) pledge and the JRC use the OSCORE security context parameters (e.g. sender and recipient identifiers) as they were used at the moment of context derivation, regardless of whether they currently act as a CoAP client or a CoAP server. "

I think this text is intended as a clarification of OSCORE functionality, but it doesn't make clear that that is what it is. Here is an attempt, perhaps you can do better:

NEW Note that when the (6LBR) pledge and JRC changes roles between CoAP client and CoAP server, the same OSCORE security context as initially derived in each endpoint remains in use and the derived parameters are unchanged, for example Sender ID when sending and Recipient ID when receiving, see section 3.1 of [I-D.ietf-core-object-security].

"A technique that prevents reuse of sequence numbers, detailed in Section 7.5.1 of [I-D.ietf-core-object-security], MUST be implemented. Each update of the OSCORE Replay Window MUST be written to persistent memory."

Section 7.5.1 is now B.1.1, and the procedure is slightly different, there are two parameters to set, K and F. Do you want to recommend any settings here?

Comments (1)