Subject: [6tisch] ASN replay attack -- proposed text

From: Mališa Vučinić <[email-masked]>
Date: Fri, 26 Jul 2019 20:22:59 +0200

Dear all,

I worked on the initial version of the text describing the ASN replay attack and its resolution discussed during the Montreal meeting.

The text can be found at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31

Please let me know if you have any comments.

Mališa

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 26 Jul 2019 23:07:48 +0200 (CEST)

Malisa,
The text IMO explains both the problem and the solution very well, congrats.
Thomas

> On 26 Jul 2019, at 20:23, Mališa Vučinić <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Jul 2019 21:20:54 +0000

Agreed:

I'm wondering about the delayed security processing. That processing may be delayed beyond the current ASN. Is the ASN of the receive time attached to the frame as a meta of sorts to enable the delayed validation?

All the best,

Pascal

> -----Original Message-----
> From: 6tisch <[email-masked]> On Behalf Of Thomas Watteyne
> Sent: vendredi 26 juillet 2019 17:08
> To: Mališa Vučinić <[email-masked]>
> Cc: 6tisch <[email-masked]>
> Subject: Re: [6tisch] ASN replay attack -- proposed text
> 
> Malisa,
> > I worked on the initial version of the text describing the ASN replay attack
> and its resolution discussed during the Montreal meeting.
> >
> > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-
> security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31
> >

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 27 Jul 2019 06:57:53 +0300

Mališa Vučinić writes:
> I worked on the initial version of the text describing the ASN
> replay attack and its resolution discussed during the Montreal
> meeting. 
> 

Looks good.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 27 Jul 2019 07:08:14 +0300

Pascal Thubert (pthubert) writes:
> I'm wondering about the delayed security processing. That processing
> may be delayed beyond the current ASN. Is the ASN of the receive
> time attached to the frame as a meta of sorts to enable the delayed
> validation? 

There is TimeStamp parameter to the MCSP-DATA.indication which tells
when the frame was received. TimeStamp is also available in the
PANDescriptor when you are scanning the network for beacons, and when
joining to TSCH network the upper layer needs to somehow calculate
current ASN from the TimeStamp of received beacon and the TSCH
Synchorinization IE contained in the Beacon. This means this kind of
operation where timestamp is converted to timeslots is something upper
layer needs to be able to do anyways, so it should be able to convert
the TimeStamp of received frame to ASN and then use that ASN to do
security processing.
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 30 Jul 2019 11:23:30 +0200

Pascal,

As Tero outlined, this information is typically available as the metadata to the frame being received. It is up to the implementations to ensure that such information is available when processing the frame with a delay, otherwise things won’t really work..

Mališa

> On 26 Jul 2019, at 23:20, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Agreed:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jul 2019 09:54:59 +0000

All good, I expected it and wanted confirm : )

All the best,

Pascal

> From: Mališa Vučinić <[email-masked]>
> Sent: mardi 30 juillet 2019 05:24
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Thomas Watteyne <[email-masked]>; 6tisch <[email-masked]>
> Subject: Re: ASN replay attack -- proposed text
> 
> Pascal,
> 
> As Tero outlined, this information is typically available as the metadata to the
> frame being received. It is up to the implementations to ensure that such
> information is available when processing the frame with a delay, otherwise
> things won’t really work..
> 
> Mališa
> 
> > I'm wondering about the delayed security processing. That processing may
> be delayed beyond the current ASN. Is the ASN of the receive time attached to
> the frame as a meta of sorts to enable the delayed validation?
> >
> > All the best,
> >
> > Pascal
> >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2019 09:15:23 -0400

> At the time of the synchronization, the EB frame can neither be authenticated
> nor its freshness verified.

I suggest:

> At the time of the synchronization, the EB frame can neither be authenticated
> nor its freshness verified.  An attacker could have fabricated the EB, or
> may have simply replayed a previous EB (see RFC7416, many sections,
> including section-7.3.5). The pledge has no way to know at this point.

I think that you should move the attack description earlier.
The attack described is a kind of wormhole MITM attack, and I think it is
useful to reference 7416.

> that is normally in use in the network.

this is probably too vague.  I think it's the active K1.

- The frames should be passed to the upper layer for processing using the
- promiscuous mode of {{IEEE802.15.4}} or another appropriate mechanism.

+ The pledge should be placed into promiscuous mode of {{IEEE802.15.4}}
+ (or another appropriate mechanism implementation specific mechanism)
+ in order that they can be passed to the upper layer for processing
+ despite the frames failing the security check due to lack of a key.

{I can put these into github if you like, but I will finish reading the
thread first}

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [