Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    > the following.  Michael, Malisa and Tero please confirm that it looks
    > good / help me fix it : )

...

    >    In a TSCH network as specified by IEEE Std. 802.15.4 [IEEE802154],
    > the nonce that is used to secure Link-Layer exchanges includes an
    > address of the source and the ASN.  The ASN itself is supposed to be
    > distributed securely by other means.  If the ASN is compromised and a
    > short address is reused, then a nonce-reuse attack becomes possible.

    >    With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by
    > nodes that have already joined the network.  As the pledge is not in
    > possession of Link-Layer keys for the visited network, it cannot verify
    > the message integrity code (MIC) authenticating the beacon.


- Even if it
- did have the keys, it still could not verify the beacon as it could be
- a replay by an attacker and thus could still announce an ASN that
- represents a time in the past.  That time would match a valid timeslot
- it if is correct modulo the number of channels used for hopping.

+ Even after the join process, when it does have the keys, it still could not
+ verify the freshness of the the beacon as it could be
+ a replay by an attacker and thus could still announce an ASN that
+ represents a time in the past.  That time would match a valid timeslot
+ it if is correct modulo the number of channels used for hopping.


    >    This authentication steps must be such that they cannot be replayed
    + by an attacker, and it must not depend on the tentative ASN being valid.
    > Note that IEEE std. 802.15.4 TSCH does not provide replay protection at
    > all, and that for instance attacker can cause a legitimate node to

    - retransmit a previous message by destroying an ack. It results and
    + retransmit a previous message by destroying an ack. If this results an

    > upper layer protocol must provide a way to detect replayed messages and
    > cope with them.

    >    During the authentication the keying material that the pledge
    > obtains from the JRC does NOT provide protection against spoofed ASN.
    > Once the pledge has obtained the keys to use in the network, it still
    > needs to verify the ASN.  If the nonce used in the Layer-2 security
    > derives from the extended (MAC-64) address, then replaying the ASN
    > alone cannot enable a nonce-reuse attack unless the same node is
    > attacked twice and loses all state in-between.  But if the nonce
    > derives from the short address (e.g., assigned by the JRC) then the
    > nonce-reuse attacks are possible, and the JRC must ensure that it never
    > assigns short addresses that were already given to this or other nodes
    > with the same keys.

I think that in this place, the note about rekeying the network must occur
before running out of short addresses.

    >    At that point, an additional step may be required to ensure that the
    > ASN is correct.  For instance, the pledge could perform a first
    > exchange with a peer node that is trusted and has already joined, e.g.,
    > its RPL time parent, and the message should not be encrypted but only
    > authenticated at the Link-Layer.  The request from the pledge should
    > contain a nonce with a random part that is not ASN, and the
    > authenticated response should contain the current ASN and echo the
    > nonce.

I think that we need to be explicit, not "for instance"

{please forgive me being behind on email. Summer cold and family responsabilities}
--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-