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

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

This is great and concise information; I'd be happy to add it in the security section even if it is available elsewhere...

All the best,

Pascal

> -----Original Message-----
> From: David Mandelberg <[e-mail]>
> Sent: mardi 25 juin 2019 02:31
> To: Tero Kivinen <[e-mail]>; Pascal Thubert (pthubert)
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Thomas Watteyne <[e-mail]>; Michael Richardson
> <[e-mail]>; Mališa Vučinić <[e-mail]>
> Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
> 
> 
> 
> On 6/24/19 7:45 PM, Tero Kivinen wrote:
> > Pascal Thubert (pthubert) writes:
> >> Hello David:
> >>
> >> Many thanks for your review. I do hope that you found it interesting.
> >>
> >>> Sections 4.2.1 and 4.3.4 talk about the security of joining a
> >>> network, and time synchronization, respectively. Do any of the
> >>> security mechanisms in 4.2.1 rely on having an accurate clock?
> >>> (E.g., to distrust old/expired keys.) Is time synchronization done
> >>> before the join process, and is there any way to exploit time
> >>> synchronization in order to cause a node to join a malicious
> >>> network?
> >>
> >> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who
> >> was one of the inventors of TSCH, as well as Michael and Malisa who
> >> led the join process study.
> >>
> >> Time synchronization (date):
> >> --------------------------------------
> >> For all I know, the time sync is about giving a epoch time from which
> >> an Absolute Slot Number (ASN, expressed in slot duration e.g.,
> >> 10ms) is derived. ASN plays a key role as it is used in NONCE. An
> >> attack that one could think of would be to fool the new node into
> >> thinking that ASN is earlier. This could happen before the keys are
> >> exchanged, or if an authorized peer is compromised. For the former,
> >> I'll defer to the others to answer fully how we protect the new
> >> comer. For the latter, 6TiSCH provides an additional protection since
> >> we derive time from a RPL parent. RPL has its own protections, some
> >> of them in the standard itself, some of them in zerotrust papers that
> >> need publishing.
> >
> > In normal TSCH in 802.15.4 the joining node will listen to beacons
> > sent by the nodes already part of the network, and they will find out
> > the ASN from there. As they do not yet have keys for the network they
> > cannot verify the message integrity code authenticating the beacon,
> > and even if they did have the keys, they still cannot verify it as it
> > could be replay by attacker.
> >
> > After they find out the ASN, they need to authenticate themself to the
> > network using some mechanism outside the 802.15.4. This authentication
> > step must be such that it cannot be replayed by attacker, i.e., they
> > must not trust ASN giving them any protection.
> >
> > Note, that in general 802.15.4 TSCH DOES NOT provide replay protection
> > at all. I.e., attacker can cause legimite node to retransmit its
> > previous message by destroying ack, and upper layer protocol must
> > provide way to detect replays and cope with them.
> >
> > During the authentication the JRC needs to provide the keying material
> > to the joining node, but that does NOT provide protection against
> > spoofed ASN. After the node has actual keys used in the network it
> > still needs to verify the ASN by sending some message to JRC using
> > authentication and verify that JRC replies to that.
> >
> > If this 2nd step is omitted attacker do following attack:
> >
> > Joining node (JN)   attacker	     		  JRC
> > 		    <- beacon for ASN=23	  <- beacon for ASN=44
> > See beacon
> > from attacker,
> > assume ASN=23.
> >
> > Auth->JRC
> > (no security)					  Check authentication
> > 						  Return keys
> > 						  keys->JN
> >
> > Receive keys
> > send first
> > frame using
> > keys using ASN=23->
> >
> >
> > Now, if JN is using extended address to generate nonce, the nonce will
> > be different for all other nonces ever used, even the ASN is faked,
> > and has been used before. On the other hand if JN also receives short
> > address assignment from the JRC, JRC needs to make sure that short
> > address has not been assigned to anybody else before, as if it was
> > used by someone else, and frame sent by JN is encrypted, then attacker
> > will now have two packets with same ASN, and short address, meaning
> > same nonce, and it can now decrypt packets.
> 
> Is this discussion of nonce reuse in any relevant documents already, or is it
> something that should be added somewhere?
> 
> > Note, that attacker might be able to replay valid ACKs for the frame
> > sent by the JN, provided that the JRC (or whoever JN sent the message
> > to) happened to ack message using the same ASN attacker faked for JN.
> >
> > If JN sends message to JRC which only JRC can reply, and uses wrong
> > ASN, the JRC will not be able to decrypt/validate that frame because
> > of wrong ASN in nonce, and will drop it silently, so if JN uses wrong
> > ASN it might be getting ACKs, but it will not get any real reply
> > frames back from real participants in the network. After it will not
> > receive confirmation from JRC that it has proper keys and ASN, it
> > knows something went wrong.
> >
> >
> >> Time synthonization (precise tic, hourless)
> >> --------------------------------------------------------
> >> This is the process whereby a node corrects its tic to realign with
> >> the parent. ASN is not changed but the drift of crystals is
> >> compensated. An attacker could try to inject a sense of time that it
> >> slightly shifted to the point that the node lose sync with the rest
> >> of the network (the guard time is like an event horizon). Then again,
> >> RPL provides an additional protection on top of the MAC provisions.
> >
> > Those time syncronization IEs are also protected by MAC level
> > authentication, so attackers who do not know the keys cannot generate
> > them. Attackers who do know keys can do whatever they like anyways...
> >
> > Btw, I will be leaving for vacation tomorrow, so I might not be able
> > to reply any messages related to this until I get back end of next
> > week.
> >