Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

Hi Mališa,

Thanks for the update, this addresses my concerns. 

Editorial: Replace "entirely defined" with "specified".

Göran

On 2019-03-27, 23:16, "Mališa Vučinić" <malisa.vucinic@inria.fr> wrote:

    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

    Please let me know if this addresses your review.

    Mališa

    On 24 Mar 2019, at 23:08, Göran Selander <goran.selander@ericsson.com> 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)" <6tisch-bounces@ietf.org on behalf of
    pthubert@cisco.com> 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/6tisch@ietf.org/msg02875.html <https://www.mail-archive.com/6tisch@ietf.org/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 <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
    6tisch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tisch