Dear Göran, Many thanks for the review! As we discussed during the WG meeting, I added new text in the draft to stress that the procedure in Appendix B.2 of OSCORE should be used in the case of a failure event occurring at the JRC. The use of this procedure is now RECOMMENDED, and in case it is not supported by a particular pledge implementation, we require the reprovisioning of the affected devices with fresh parameters.
Other comments have also been taken into account and the draft has been aligned with the references in oscore-16. The related diff providing changes in respect to your comments is available at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10-goran#diff <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10-goran#diff> Please let me know if this addresses your review. Mališa > On 24 Mar 2019, at 23:08, Göran Selander <[email protected]> wrote: > > Dear 6TiSCH, > > Sorry for very late response, here are a some post-2nd WGLC comments on > draft-ietf-6tisch-minimal-security-09: > > Summary: With one exception detailed below the draft seems to be in good > shape and essentially only need some harmonizing updates following the last > changes to OSCORE which has now completed IESG review. > > Main concern: > > Section 8.3: > The recovery from complete failure of the JRC as currently described is not > satisfactory and may lead to loss of confidentiality of data sent from the > JRC to the pledge. During reinitialization of pledges due to complete > failure of JRC, the new JRC cannot detect replays of old initialization > messages, nor does it know the latest sequence number used by the failed JRC: > * It is not described how the new JRC reacts to a received CoJP request to > avoid accepting a replay request or why it is not a problem with nonce reuse > in the CoJP response. > * The procedure for the first Parameter Update with randomized payload may > have different known CoAP header parameter values than the message with which > nonce is reused, leading to a two-time pad which may to break > confidentiality. It should at least be described why this is not an issue. > * There is no security consideration about properties of the encryption > algorithm, in this case AES-CCM, which limits this attack to confidentiality. > > There are different ways to resolve this. Here are two alternatives: > > Appendix B.2 in OSCORE specifies a challenge-response based protocol for > updating the security context based on an exchange of nonces. This protocol > can be directly applied here where the replaced JRC in the role of CoAP > server would trigger the protocol by responding to the reinitialization > request with a new security context as is detailed in appendix B.2. The > pledge then repeats the CoJP request with another security context and the > JRC responds with the CoJP response using the agreed security context. In > this way the old security context is replaced by a new, thereby removing the > risks associated with accepting replayed messages and reusing nonces. > > The procedure in the previous paragraph does however not support the > lightweight implementation option in Appendix B of this draft, since the > master secret is needed for deriving the new security context. If this is > very important to support, considering that CoJP is a special application of > OSCORE it may be possible to specify a bespoke synchronization protocol. One > setting for this is based on a reserved JRC sequence number for responses to > reinitialization requests, the Echo option, and transport of the pledge > record of last used JRC sequence number. This would require a careful > analysis in particular of the use of JRC sequence numbers. > > 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? > > > Göran > > > > On 2019-03-07, 15:45, "6tisch on behalf of Pascal Thubert (pthubert)" > <[email protected] on behalf of [email protected]> wrote: > > Dear all: > > At the last IETF, we concluded the WGLC on > draft-ietf-6tisch-minimal-security and concluded it was mostly ready. It > received 7 reviews during the last WGLC, all of which had been integrated, > and received reviewers approval. > Two final changes were still needed. Malisa was to discuss those on the > ML, integrate them into a new version of the draft if consensus was found. > There was in particular a dependency / alignlent to be made on OSCORE. > > More in > https://www.mail-archive.com/[email protected]/msg02875.html > <https://www.mail-archive.com/[email protected]/msg02875.html>. It appears that > the issues are now resolved. Mališa, can you please summarize the status with > OSCORE? > > As promised, the Chairs now open a 1-week WGLC on > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09 focusing > on those changes, though any bug you can find is good to mention too. > The WGLC ends on Friday March 15th. Please have a good last look at the > spec and let us know. > > Looking forward to meeting you all in Prague, > > The chairs > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
