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

["Pascal Thubert (pthubert)" <[e-mail]>]

All good, Tero.

I think we are in perfect line. If you can find the time please have a look at https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-6 to make sure all is correct, I think it is.
At this point it is up to Malisa to add more details in the security section of minimal security and I trust that this thread helps.

All the best,

Pascal

> -----Original Message-----
> From: Tero Kivinen <[e-mail]>
> Sent: mercredi 10 juillet 2019 23:14
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: David Mandelberg <[e-mail]>; Mališa Vučinić
> <[e-mail]>; Michael Richardson <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: secdir review of draft-ietf-6tisch-architecture-21
> 
> Pascal Thubert (pthubert) writes:
> >    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.
> 
> Note, that attacker can pick time, and channel correctly so that it will always
> match. I.e., if he wants to reply beacon with ASN=1235 and that was sent on
> channel X, it simply needs to replay that same
> ASN=1235 on channel X, regardless what current ASN and channel would be
> for others in the network. It is actually beneficial for it to use some offset, so
> JN will not accidently see any real messages...
> 
> Most likely JN will start listening beacons on channel X, then if does not hear
> anything for some time, it moves to X+1 etc. Most likely it will stay on channel
> X so long that it will hear beacon from there. So attacker stores that beacon
> on channel X and the ASN is so that it is assuming channel X for hopping.
> 
> Now if attacker retransmits this out on channel X immediately when it
> assumes JN is listening, JN will pick it, and will then pick wrong offset for
> channel hopping.
> 
> So, that sentence about Time and module to number of channels, is not
> useful.
> 
> >    After obtaining that tentative ASN, the pledge authenticates itself
> >    to the network using some mechanism outside of IEEE Std 802.15.4.
> >    With 6TiSCH, a Join Proxy (JP) helps the pledge for the join
> >    procedure by relaying the link-scope Join Request over the IP network
> >    to a Join Registrar/Coordinator (JRC) that can authenticate the
> >    pledge and validate that it is attached to the appropriate network.
> >    As a result of this exchange the pledge is in possession of a Link-
> >    Layer material including a key and a short address, and assuming that
> >    the ASN is correct, all traffic can be secured at the Link-Layer.
> >
> >    This authentication steps must be such that they cannot be replayed
> >    by an attacker, and it must not depend on th 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 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.
> >
> >    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.
> 
> Sending ASNs in the mssage is almost impossible, as upper layer does not
> have any idea what ASN will be used to send message out. It does not know
> when the next slot to the JN will be, and it does not know whether that slot
> will be free etc.
> 
> Because of this I think it is better to use some other method, i.e., if JN just
> generates random cookie and sends that to JP/JRC, and JP/JRC will then echo
> that same cookie back then JN will know that exchange is fresh, and if that
> was authenticated using L2 key K1, then ASN was implictly verified also, as
> JP/JRC who do know correct ASN, will drop the incoming frame as it will have
> wrong MIC because of wrong nonce.
> --
> [e-mail]