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
