Subject: [6tisch] security section in minimal

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 11 May 2015 06:24:59 +0200

Dear all,

after the last call we would like to close the security section in minimal.
We wrapped up all comments from the previous days and from the meeting and
here is our proposal:

This draft assumes the existence of two cryptographic keys, K1 and
K2.  EBs SHOULD be authenticated with key K1.  DATA, ACKNOWLEDGEMENT, and
MAC COMMAND frame types SHOULD be authenticated and encrypted with key K2.
For early interoperability, K1 MAY be set to "6TiSCH minimal15".  K2 SHOULD
be a randomly generated high entropy cryptographic key.  Key distribution
is out of scope.

I would like to encourage everybody to see if this texts covers all what we
want for minimal, and provide consensus. We need to move forward.

kind regards,
Xavi

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 11 May 2015 13:43:08 +0800

+1. I agree with description of the text.

Tengfei

On Mon, May 11, 2015 at 12:24 PM, Xavier Vilajosana <
[email-masked]> wrote:

> Dear all,
>
> after the last call we would like to close the security section in
> minimal. We wrapped up all comments from the previous days and from the
> meeting and here is our proposal:
>
> I would like to encourage everybody to see if this texts covers all what
> we want for minimal, and provide consensus. We need to move forward.
>
> kind regards,
> Xavi
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 11 May 2015 06:02:32 +0000

Looks good to me, Xavi.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Tengfei Chang
Sent: lundi 11 mai 2015 07:43
To: Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tisch] security section in minimal

Tengfei

On Mon, May 11, 2015 at 12:24 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

after the last call we would like to close the security section in minimal. We wrapped up all comments from the previous days and from the meeting and here is our proposal:

This draft assumes the existence of two cryptographic keys, K1 and
K2.  EBs SHOULD be authenticated with key K1.  DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be authenticated and encrypted with key K2.  For early interoperability, K1 MAY be set to "6TiSCH minimal15".  K2 SHOULD be a randomly generated high entropy cryptographic key.  Key distribution is out of scope.

I would like to encourage everybody to see if this texts covers all what we want for minimal, and provide consensus. We need to move forward.

kind regards,
Xavi

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 11 May 2015 07:19:27 +0000

Hi Xavi, (all)
the suggested text covers all the discussed we have been having so far.
and it is in line with the scope of minimal.
THUS, +1 from my side.
Thanks!
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, May 11, 2015 8:03 AM
To: Tengfei Chang; Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tisch] security section in minimal

Looks good to me, Xavi.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Tengfei Chang
Sent: lundi 11 mai 2015 07:43
To: Xavier Vilajosana
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] security section in minimal

Tengfei

kind regards,
Xavi

---

From: Alfredo Grieco <[email-masked]>
Date: Mon, 11 May 2015 09:39:20 +0200

+1. cheers. Alfredo
> Il giorno 11/mag/2015, alle ore 09:19, Maria Rita PALATTELLA <[email-masked]> ha scritto:
> 
> Hi Xavi, (all)
> 
> On Mon, May 11, 2015 at 12:24 PM, Xavier Vilajosana <[email-masked]> wrote:
> 
> Dear all,
> 
>  
> 

-- 
Luigi Alfredo Grieco, PhD 
Associate Professor
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]
linkedin: it.linkedin.com/in/alfredogrieco

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 11 May 2015 05:09:00 -0400

It is OK for me.
+1

        Diego

2015-05-11 4:19 GMT-03:00 Maria Rita PALATTELLA <
[email-masked]>:

> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Pascal
> Thubert (pthubert)
> *Sent:* Monday, May 11, 2015 8:03 AM
> *To:* Tengfei Chang; Xavier Vilajosana
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] security section in minimal
>
>
>
> Looks good to me, Xavi.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tengfei Chang
> *Sent:* lundi 11 mai 2015 07:43
> *To:* Xavier Vilajosana
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] security section in minimal
>
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Savio Sciancalepore <[email-masked]>
Date: Mon, 11 May 2015 11:05:58 +0200

+1. Completely agree with the text.

Regards, Savio.

-- 
*Savio Sciancalepore, Ph.D. Student*
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked] <[email-masked]>
phone: +39 080 5963301
web: http://telematics.poliba.it/sciancalepore
<http://telematics.poliba.it/index.php/en/people/sciancalepore>

-- 
*Savio Sciancalepore, Ph.D. Student*
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked] <[email-masked]>
phone: +39 080 5963301
web: http://telematics.poliba.it/sciancalepore
<http://telematics.poliba.it/index.php/en/people/sciancalepore>

---

From: Giuseppe Piro <[email-masked]>
Date: Mon, 11 May 2015 11:12:52 +0200

+1

My consensus is related to the rule that K1 covers in the minimal draft,
which is far away from a real security configuration.

Giuseppe

On Mon, May 11, 2015 at 9:39 AM, Alfredo Grieco <[email-masked]>
wrote:

> +1. cheers. Alfredo
> > Il giorno 11/mag/2015, alle ore 09:19, Maria Rita PALATTELLA <
> [email-masked]> ha scritto:
> >
> > Hi Xavi, (all)
> >
> > K2.  EBs SHOULD be authenticated with key K1.  DATA, ACKNOWLEDGEMENT,
> and MAC COMMAND frame types SHOULD be authenticated and encrypted with key
> K2.  For early interoperability, K1 MAY be set to "6TiSCH minimal15".  K2
> SHOULD be a randomly generated high entropy cryptographic key.  Key
> distribution is out of scope.
> >
> >
> >

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro

---

From: Robert Cragie <[email-masked]>
Date: Mon, 11 May 2015 10:41:24 +0100

I am fine with the text in principle but I have a couple of final suggested
changes on the text just for clarity purposes.

1) It is not entirely clear to the casual reader whether an EB only ever
needs authentication or whether we are saying that is the only security
treatment it will get. It is important to distinguish as the IEs are
payload IEs which could indeed be encrypted but we choose not to.
2) I think the "6TiSCH minimal15" needs to be stated in an octet string
form just to avoid any ambiguity with text encoding, terminating null etc.

Therefore, I would suggest the following small changes.

1) Section 4 needs to revise "EBs are only authenticated and payload is not
encrypted" to "EBs SHOULD be authenticated only, i.e. payload SHALL NOT be
encrypted".
2) The security text would be a little clearer in my opinion as follows (it
does not change the content): "This draft assumes the existence of two
cryptographic keys, K1 and K2.  EBs SHOULD be authenticated only, using key
K1.  DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be
authenticated and encrypted using key K2.  For early interoperability, K1
MAY be set to "6TiSCH minimal15" (0x36 0x54 0x69 0x53 0x43 0x48 0x20 0x6D
0x69 0x6E 0x69 0x6D 0x61 0x6C 0x31 0x35).  K2 SHOULD be a randomly
generated high entropy cryptographic key.  Key distribution is out of
scope."

Notes:

1) I changed "with key" to "using key" as it is preferable language in my
opinion
2) The subtle comma after "only" makes the two cases distinct:
a) "authenticated only, using K1" can only be interpreted as "the EB only
has authentication applied to it and K1 is used" (this is the case)
b) "authenticated only using K1" could be interpreted as "the EB has
authentication applied to it using K1 alone" (this is not the case)

Robert

---

From: Qin Wang <[email-masked]>
Date: Mon, 11 May 2015 13:38:57 +0000 (UTC)

+1
Qin 

     On Monday, May 11, 2015 12:25 PM, Xavier Vilajosana <[email-masked]> wrote:

 Dear all,
This draft assumes the existence of two cryptographic keys, K1 andK2.  EBs SHOULD be authenticated with key K1.  DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be authenticated and encrypted with key K2.  For early interoperability, K1 MAY be set to "6TiSCH minimal15".  K2 SHOULD be a randomly generated high entropy cryptographic key.  Key distribution is out of scope.
kind regards,Xavi

---

From: "Wang, Chonggang" <[email-masked]>
Date: Mon, 11 May 2015 13:40:20 +0000

+1

Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Monday, May 11, 2015 9:39 AM
To: Xavier Vilajosana; [email-masked]
Subject: Re: [6tisch] security section in minimal

+1

Qin

On Monday, May 11, 2015 12:25 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

kind regards,
Xavi

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Mon, 11 May 2015 14:06:38 +0000

+1
Pat

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Monday, May 11, 2015 12:25 AM
To: [email-masked]
Subject: [6tisch] security section in minimal

Dear all,

kind regards,
Xavi

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Mon, 11 May 2015 14:39:08 +0000

+1. 

-raghuram

On 5/11/15, 12:39 AM, "Alfredo Grieco" <[email-masked]> wrote:

>+1. cheers. Alfredo
>> Il giorno 11/mag/2015, alle ore 09:19, Maria Rita PALATTELLA
>><[email-masked]> ha scritto:
>> 
>> Hi Xavi, (all)
>> 
>>and MAC COMMAND frame types SHOULD be authenticated and encrypted with
>>key K2.  For early interoperability, K1 MAY be set to "6TiSCH
>>minimal15".  K2 SHOULD be a randomly generated high entropy
>>cryptographic key.  Key distribution is out of scope.
>> 
>>  
>> 
>> I would like to encourage everybody to see if this texts covers all
>>what we want for minimal, and provide consensus. We need to move
>>forward. 
>> 
>>  
>> 
>> kind regards,
>> 
>> Xavi
>> 
>>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Mon, 11 May 2015 22:08:55 +0530

+1.

Anand

> On 11-May-2015, at 11:13 am, Tengfei Chang <[email-masked]> wrote:
> 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: <[email-masked]>
Date: Mon, 11 May 2015 18:29:00 +0000

+1
- Pouria

> On 11 May 2015, at 06:25, Xavier Vilajosana <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 11 May 2015 16:17:06 -0700

The text seems to capture the compromise.

+1

Mališa

> On 10 May 2015, at 21:24, Xavier Vilajosana <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Nicola Accettura <[email-masked]>
Date: Mon, 11 May 2015 16:27:52 -0700

+1!

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2015 07:00:14 +0300

Xavier Vilajosana writes:
> minimal. We wrapped up all comments from the previous days and from
> the meeting and here is our proposal:

As you can guess, I disagree with the text.

Does this text replace the whole "Security considerations" section or
only some of it?

> K2.  EBs SHOULD be authenticated with key K1.

First of all, the correct therm is data integrity, not authenticate.
Authenticate would mean that we would actually provide verification
that the identity of a peer entity in a current association is as
claimed. Here we just provide protection that data is not modified.

See RFC 4949 for "data integrity", "data integrity service",
"authenticate", and "authentication". 

In which cases it is ok not to integrity protect the EBs with K1?

What happens if EBs are not protected by K1. I.e. what kind of attacks
are possible in such case, and why do you think we do not need to care
about them here.

This is security consideraions section so you should explain those
things here.

Note, that answers to those depends a lot where the minimal is used.
In the bootstrap case we can say that the bootstrap process provides
its own authentication and data integrity services for its messages,
thus L2 protection for the EBs are not really needed.

For the fall-back mode of operation when no dynamic scheduling
solution is availabe or functional, this is not true and in such cases
I think K1 protection is mandatory.

For the third use case i.e. "during early interoperability testing and
development" this is mostly non-issue, as none of those networks are
used in real production use.

> DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be
> authenticated and encrypted with key K2.

If I have understood correctly there are actually lot of cases where
the other frame types are not encrypted, but are only integrity
protected. At least that was my understanding from the comments people
made earlier. Here we still say that they SHOULD be both integrity
protected and encrypted.

Again in which case this SHOULD is not needed, i.e. why it is not
MUST. What are the exceptions where you can send those frames without
integrity protection? I agree that encryption might not be needed, if
upper layer protocols provide end to end data confidentiality service,
so that might be reason why we do not need encryption, but hop by hop
L2 data integrity would still be useful to save resources in the
network level, especially if there is routing protocol routing traffic
between multiple nodes.

The attacker could inject packets to the network and cause them to be
forwarded through the network and consume resources on the network
unless data frames are not protected.

Also this assumes that K2 is in the devices already before they start
running the joining process if all data, acknowledgement, and mac
command frames need to use it. I do not think this is true, so most
likely while using minimal for the bootstrap case the K2 might not be
there yet, thus those frames needs to be sent without protection, and
also those packets might need to forwarded in the network wasting
resources from the network.

On the other hand during the fall-back case the K2 should already be
there, and we should use it always.

> For early interoperability, K1 MAY be set to "6TiSCH minimal15".

This again would need to explain what kind of attacks attacker can do
when he knows the K1. It does not change anythign for the bootstrap
case, but there is huge issues in the fall-back mode case. And if this
is only meant for the interoperability testing case, then I do not
think we should mention it here, but instead add it to the test
specification that is used when running those interoperability tests.
This is how it is done normally.

And if you still claim that there would be uses for well-known K1
because of "network spearation issue", then this needs to be
mentioned, and explainined why you think this is true. On the other
hand that text does not belong to the security considerations section
as it is not security issue, as well-known K1 does not provide any
security services.

So this K1 definition should be moved away from security
considerations section to its own separate section, and in security
considerations section there should only be the warnings saying that
if well-known key is used for K1, then that does not provide ANY
security benefits, and it MUST NOT be used in production network
requiring any kind of security.

> K2 SHOULD be a randomly generated high entropy cryptographic key.
> Key distribution is out of scope.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2015 07:20:12 +0300

Robert Cragie writes:
> I am fine with the text in principle but I have a couple of final
> suggested changes on the text just for clarity purposes.
> 
> 1) It is not entirely clear to the casual reader whether an EB only
> ever needs authentication or whether we are saying that is the only
> security treatment it will get. It is important to distinguish as
> the IEs are payload IEs which could indeed be encrypted but we
> choose not to.

EBs CANNOT be encrypted in TSCH. To be able to decrypt the EBs the
receiving node would need to know the ASN, but it cannot know it as
the ASN would be in the encrypted part of the EB. Because of this EBs
cannot be encrypted when using TSCH.

This is fundamental property of the TSCH, it is not something we
choose not to do.

We should most likely explain this in the security considerations
section (i.e. provide reason why data confidentiality service is not
possible for EBs, and why only data integrity service can be
provided).

We should most likely also explain that even when data integrity
service is provided for the EBs, the receiving devices are able to use
EBs while joining the network even when they do not know the key used
to protect the EBs. I.e. that 802.15.4 do have special rules that this
is allowed even when normally frames which you do not have key for are
dropped. 

When the IETF last call is issued and people not familiar with 6tisch,
and for example the secdir reviewers read this document, they most
likely do not have very good understanding what 802.15.4 does, thus
explaining why we doing certain things as we do, and why certain
issues are not a problem will help solving their comments, even before
they have time to make them...

I.e. if I would be doing the security considerations section and then
started to look what is in the EBs, and what can attacker do by
messing those things up, I would not find anything in the security
considerations section that would give me answer.

Btw, the attackers can do quite efficient denial-of-service attack,
especially when using the full format of the TSCH Timeslot IE is used.
I.e. it can send TSCH Timeslot IE saying that macTsTimeslotLength is
for example 16 seconds (if 24-bit format of macTsTimeslotLength is
supported), or otherwise se the time slot length for 65 ms. Then it
can say in Frame and Link IE that size of slotframe is 255, thus
meaning that the device can send one frame every 16.5 seconds. When it
then tries to send association or any other messages to other end it
will take 16.5 seconds for each frame, thus making the joining process
REALLY SLOW, and most likely it will take minutes before the joining
node gets so far that it notices that this is wrong network, and I
should try to find the better one.

Only using proper K1 would protect against that kind of DoS attacks.
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 11 May 2015 22:19:19 -0700

Hello Tero,

> On 11 May 2015, at 21:20, Tero Kivinen <[email-masked]> wrote:
> 

I am confused by your definition of ‘fundamental’. Isn’t this the consequence of TSCH synchronization IE being part of the payload, instead of the frame header in the IEEE standard? 

Regards,
Mališa Vučinić

---

From: Robert Cragie <[email-masked]>
Date: Tue, 12 May 2015 09:48:36 +0100

Hi Tero,

You raise some good points. Comments inline.

In summary:

  * There may need to be a decision on whether to mandate use of
    integrity protection on MAC enhanced beacons.
  * There may need to be a decision on whether to mandate use of
    integrity protection and encryption on MAC data, command and ack frames.
  * There may need to be a distinction of MAC data frames used for
    carrying authentication exchanges which do not usually have any
    protection
  * The properties of K1 and its purpose may need to be elaborated further

Robert

> Does this text replace the whole "Security considerations" section or
<RCC>Good question - I would assume the whole section</RCC>
> claimed. Here we just provide protection that data is not modified.
<RCC>AES-CCM as it is used provides data origin authenticity. The term 
AE (authenticated encryption) is commonly used with AES-CCM mode of 
operation. So personally I feel "authenticated" is OK but "integrity 
protected" would also work and I agree is probably more accurate wrt. 
AES-CCM</RCC>
> In which cases it is ok not to integrity protect the EBs with K1?
<RCC>We seem to have gone around the houses on "MAY", "SHOULD" or 
"SHALL" for this. "MAY" is pretty pointless as it really says nothing. 
"SHOULD" recommends the use of integrity protection and "SHALL" would 
mandate the use of integrity protection. As far as I can tell, this 
document is a recommended set of parameters for minimal operation., so 
"SHOULD" would appear to be the right choice, although I personally see 
no problem mandating integrity protection. As a recommendation, I don't 
see the need to elaborate on the cases where the choice is to go against 
the recommendation.</RCC>
> This is security consideraions section so you should explain those
<RCC>Again, I don't see the need to elaborate on the cases where the 
choice is to go against the recommendation but again it might be better 
to have this mandatory.</RCC>
> thus L2 protection for the EBs are not really needed.
<RCC>You are confusing the purpose of adding the MIC to the beacon. It 
is not particularly for security reasons, it is to provide the potential 
for better discrimination. This is independent from any security applied 
during the bootstrap process.</RCC>
> I think K1 protection is mandatory.
<RCC>I don't see a particular distinction between this and initial 
synchronisation. Both provide coarse synchronisation mechanisms 
sufficient to allow the node to get itself (back) onto the network. 
Maybe you can explain the differences or point me to some text which 
explains it.</RCC>
> made earlier. Here we still say that they SHOULD be both integrity
<RCC>I assumed differently, i.e. if any of the above frame do have a 
payload, it SHOULD be encrypted. It is not clear to me why you would 
deliberately choose to not encrypt a payload of one of the above frame 
types.</RCC>
> resources from the network.
<RCC>I agree with that point and this perhaps should be elaborated.</RCC>
> requiring any kind of security.
<RCC>I agree it might be worth elaborating on the purpose of using K1</RCC>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 12 May 2015 10:02:44 +0100

Hi Tero,

Comment inline.

Robert

> This is fundamental property of the TSCH, it is not something we
<RCC>The ASN can be placed in the frame counter field in the aux. 
security header and frame counter suppression set to 0 so it can be done 
- surely that is the point of having a 5-octet frame counter available? 
Clearly frame counter suppression can be used if encryption is not used 
and the ASN used directly as he frame counter.</RCC>
> possible for EBs, and why only data integrity service can be
<RCC>We perhaps should be more explicit on the format of the frame</RCC>
> is allowed even when normally frames which you do not have key for are
<RCC>This is why it is important to distinguish the properties of adding 
integrity protection to the beacon using key K1 and dispel any notion of 
"security" using this key, unless it is strictly confidential and can be 
distributed in a secure manner, something clearly not mandated. Any 
integrity protected beacon processed by a node which does not have the 
key can only use the fields as a hint as it cannot authenticate the 
beacon and thus the data should be taken "with a pinch of salt" or, to 
use Rene's expression, "at face value"</RCC>
> Only using proper K1 would protect against that kind of DoS attacks.
<RCC>I agree that security considerations do need to be elaborated</RCC>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 May 2015 08:42:19 -0400

Mališa Vučinić <[email-masked]> wrote:
    tero> EBs CANNOT be encrypted in TSCH. To be able to decrypt the EBs the
    tero> receiving node would need to know the ASN, but it cannot know it as
    tero> the ASN would be in the encrypted part of the EB. Because of this
    tero> EBs cannot be encrypted when using TSCH.

    tero> This is fundamental property of the TSCH, it is not something we
    tero> choose not to do.

    > I am confused by your definition of "fundamental". Isn't this the
    > consequence of TSCH synchronization IE being part of the payload,
    > instead of the frame header in the IEEE standard?

Yes, but from the point of view of 6tisch, the design is a given.
It's not something we can change, it forms the foundation on which we
build...  Maybe fundamental isn't the right word, particularly across three
languages, but Tero's point is that it isn't something we have a choice
about.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2015 21:25:01 +0300

Mališa Vučinić writes:
> I am confused by your definition of ‘fundamental’. Isn’t this the

Yes. I.e. it is something that has been specified in the IEEE 802.15.4
for TSCH, so we cannot do anything for it in the IETF.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2015 16:31:36 +0300

[Back from Vancouver, so now I have time to answer some of these
emails] 

Robert Cragie writes:
> In summary:
> 
>   * There may need to be a decision on whether to mandate use of integrity
>     protection on MAC enhanced beacons.
>   * There may need to be a decision on whether to mandate use of integrity
>     protection and encryption on MAC data, command and ack frames.
>   * There may need to be a distinction of MAC data frames used for carrying
>     authentication exchanges which do not usually have any protection

Yes. This is good summary.

> <RCC>AES-CCM as it is used provides data origin authenticity. The term AE
> (authenticated encryption) is commonly used with AES-CCM mode of operation. So
> personally I feel "authenticated" is OK but "integrity protected" would also
> work and I agree is probably more accurate wrt. AES-CCM</RCC>

The data origin authenticity would be correct term if we would
actually authenticate the sender. I.e. if you do KMP with the other
end and authenticate that the sender is who you think it is, then this
would be ok term. In our case where we mostly use group shared keys or
even well know keys, there is really no authentication for the server.
At best you can know the data origin (sender) is someone who knows the
key, i.e. the ones who has the group shared key. When using well-known
keys there is no idea who the sender is, thus saying we do data origin
authenticity would be quite misleading. 

> <RCC>We seem to have gone around the houses on "MAY", "SHOULD" or "SHALL" for
> this. "MAY" is pretty pointless as it really says nothing. "SHOULD" recommends
> the use of integrity protection and "SHALL" would mandate the use of integrity
> protection. As far as I can tell, this document is a recommended set of
> parameters for minimal operation., so "SHOULD" would appear to be the right
> choice, although I personally see no problem mandating integrity protection.
> As a recommendation, I don't see the need to elaborate on the cases where the
> choice is to go against the recommendation.</RCC>
> 
> <RCC>Again, I don't see the need to elaborate on the cases where the choice is
> to go against the recommendation but again it might be better to have this
> mandatory.</RCC>

Note, that well-known key == no security for EBs at all. So if
well-known key is given in the draft, then you need to explain what
kind of attacks it opens the users. 

> <RCC>You are confusing the purpose of adding the MIC to the beacon. It is not
> particularly for security reasons, it is to provide the potential for better
> discrimination. This is independent from any security applied during the
> bootstrap process.</RCC>

So why are we talking about that in the "Security Considerations"
section?

I myself think protecting EBs with proper key will provide useful
features, and for example will allow nodes to reconnect the network
without doing the full bootstrap and reauthentication process.

> Maybe you can explain the differences or point me to some text which

If the device looses syncronization or gets dropped out of the network
for some reason, and wants to come back, if the EBs are protected with
secure K1 then it can trust information in the EBs and do faster
reconnect.

I.e it will get the ASN etc from the EB, and as the K1 is unique for
this network it can trust this information to be correct. It cannot
verify that it is not replay, as attacker could have stored the EBs
and replay them back to node so it would think the ASN is what it used
to be when EBs were sent.

After that the node can send any frame protected with K1 to
coordinator, and if it will send secured frame back then node will
know the ASN is no replay and after that it has resynced the network.
Now it just needs to join the network again and for that it can use
either K1 or K2 to protect the joining process too.

If EBs are not authenticated (or well-known key is used), node cannot
really trust anything in there, and security analysis gets harder.
I.e. it is not trivial to say that there is no attacks, if node starts
using K2 based on the ASN it cannot trust. Sending any encrypted
frames using K2 would cause issues, so K2 would be needed to send
MICed frames only, and even then I am not sure there cannot be
different types of attack (all depends on what kind of protocol the
rejoining process is).

And of course the K2 might be rekeyed much more frequently than K1, as
K2 might be rekeyed everytime there is change in the network members
(i.e anybody leaves the network).

> deliberately choose to not encrypt a payload of one of the above
> frame types.</RCC>

Good, that my understanding was wrong. There were people saying
something like "they do not see any reason to encrypt anything as
there is higher layer end to end encryption there anyways".

I myself think that encrypting everything going on with K2 is right
way to do it.

Of course it again opens some issues if you want to use K2 in
rejoining based on untrusted ASN... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2015 17:00:44 +0300

> security header and frame counter suppression set to 0 so it can be done 

No it cannot.

The 802.15.4e says clearly that ASN is used instead of Frame Counter
sent in the aux field when using TSCH mode:

	In TSCH mode, the Frame Counter shall be set to the global
	frame counter value, i.e., the Absolute Slot Number as
	described in 5.1.1.5.2, regardless of whether the frame
	counter is carried in the auxiliary security header.

I.e. sending Frame Counter in auxiliary security header does not have
any effect as it is always ignored. Because of this there is Frame
counter suppression bit in the security control field, and in TSCH it
is always set.

So even if you would set frame counter suppression bit to 0, the Frame
Counter value in the auxiliary security header shall be ignored, so it
does not matter what you put there.

> - surely that is the point of having a 5-octet frame counter available? 

I have no idea why they provided 5-octet frame counter option, as it
cannot be used for TSCH. If they meant that ASN could be sent in there
too, then they would not have needed ASN in the TSCH syncronization IE
at all. 

> and the ASN used directly as he frame counter.</RCC>

Clearly it would be against the "shall" in section 7.3.2 which says
that ASN shall be used regardless whether the auxiliary security
header has frame counter or not.

So as defined in the 802.15.4e:

1) when using TSCH ASN is always used in the nonce generation, thus
   there is no point of transmitting frame counter in auxiliary
   security header => there is no reason to ever turn Frame counter
   suppression off for TSCH.

2) There is no way to syncronize to the TSCH network if encrypted
   beacons are used, as TSCH syncronization IE is payload IE, and it
   would be encrypted, and for decryption you would need ASN, which
   you do not have => encrypted beacons cannot be used.

Again if the 802.15.4e would have been written differently then
encrypted beacons could have been used (i.e. if the ASN would always
be transmitted in the auxiliary security header in frame counter
field, or if the TSCH syncronization IE would have been header IE
etc). 

> use Rene's expression, "at face value"</RCC>

Yes. On the other hand after it has K1 it can immediately verify the
parameters, and it can then pick correct network immediately and
mostly trust the information it provides.

It cannot trust that the information is not replays unless it knows
the ASN, but sending any frame and getting response back to it will
only work if the ASN was correct (provided that the response is
related to the request, i.e. it cannot be something that attacker has
also recorded from the last time).

On the other hand we did notice during the Vancouver meeting that TSCH
does not really provide full replay protection.

The reason is that normally replay protection is provided because the
Frame counter is increment for each frame and even if frame is
retransmitted it is always retransmitted with same frame counter. Now
the receiver will know if it has seen this frame before, and will drop
it if the frame counter is not new.

With TSCH this does not work, as the frame counter is not used, but
ASN is used, thus the frame must be CCM* transformed again every time
it is retransmitteed, as the ASN has changed. Thus there is no way for
receiver to detect whether this is retransmission or not, the ASN is
always new. So if the ack is lost and sender retransmits the frame
then duplicate frames will be received by the other ends next higher
layer.

Attacker can of course cause the acks to be lost, so it can cause
several duplicates to be passed to the next higher layer. So attackers
cannot replay old frames, but they can cause sender to resend their
frame multiple times, and cause those duplicate frames to be passed to
the next higher layer.
-- 
[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Tue, 19 May 2015 13:30:08 +0100

Hi Tero,

Comments line. Basically, I don't think it is clearly written in 802.15.4e
and there seem to be a lot of assumptions made.

Robert

On 18 May 2015 at 15:00, Tero Kivinen <[email-masked]> wrote:

> <RCC>I don't think it is clear at all. This section is talking about the
frame counter used for the nonce. At the point this is use for
synchronization, it could easily be interpreted that the synchronizing
device does not have a value at all for ASN as it hasn't synchronized yet.
Therefore it would be quite legitimate to use a value in the frame counter
field of the auxiliary security header at this point</RCC>

> counter suppression bit in the security control field, and in TSCH it

<RCC>Where does it say this in the specification? I don't see it
anywhere.</RCC>

> does not matter what you put there.

<RCC>I think it can be interpreted otherwise - see above</RCC>

> too, then they would not have needed ASN in the TSCH syncronization IE

<RCC>It seems odd that ASN is in a payload IE which can of course be
encrypted. Why not put it in a header IE? In this way, it could be possible
to encrypt parts of the beacon. As it stands, this seems impossible if the
current assumptions about TSCH is true.</RCC>

> header has frame counter or not.

<RCC>I think it can be interpreted otherwise - see above</RCC>

>    suppression off for TSCH.

<RCC>Again, a synchronizing device may not have a valid representation of
ASN. Something carried in a field is not a device's own ASN, it is a remote
device's ASN</RCC>

> field, or if the TSCH syncronization IE would have been header IE

<RCC>It does seem odd to me how it is written</RCC>

> mostly trust the information it provides.

<RCC>It depends entirely on the property of the key. If it is well-known,
you can't trust anything and it is not much better than no security (it is
basically a better CRC)</RCC>

> frame multiple times, and cause those duplicate frames to be passed to

<RCC>This seems completely wrong and conflicts with the clarifying text
added in section 5.1.6.4.3 in 802.15.4-2011. Retransmitted frames should
use the same frame counter. It is almost impossible to use a nonce based
solely on what is effectively implicit data at this level of granularity
There almost always needs to be some additional explicit data.</RCC>

--

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 May 2015 16:23:23 +0300

Robert Cragie writes:
> Comments line. Basically, I don't think it is clearly written in
> 802.15.4e and there seem to be a lot of assumptions made.

That I agree on...

> <RCC>I don't think it is clear at all. This section is talking about the frame
> counter used for the nonce. At the point this is use for synchronization, it
> could easily be interpreted that the synchronizing device does not have a
> value at all for ASN as it hasn't synchronized yet. Therefore it would be
> quite legitimate to use a value in the frame counter field of the auxiliary
> security header at this point</RCC>
  
If we assume that node that is not part of the network yet, and wants
to see encrypted EB, it needs to generate nonce using the ASN it does
not know, and that text above clearly says that we never use Frame
Counter to generate the Nonce, we always use ASN which we do not
know... 

> <RCC>Where does it say this in the specification? I don't see it anywhere.</
> RCC>

The frame counter is used for two uses in 802.15.4. One is nonce
generation. When in TSCH mode the frame counter is never used for
that. The another is replay protection in the inbound security
filtering.

It is true that 802.15.4e does not say that Frame counter is omitted
when using TSCH mode, but when I asked that from the people they did
say that frame counter is always supressed when using TSCH. I.e. this
is my understanding of the issue based on the people who are using
TSCH. 

If this is not true, then comment now, as we did add lots of text in
the security section making frame counter processing to be skipped if
TSCH mode is used, and also actually stating that frame counter
suppression is used when TSCH mode is used.

Using both frame counter and ASN would provide proper replay
protection, that that would also mean that we would need to add extra
4 bytes to each frame, and we could not use frame counter supression.

Note, that ASN cannot be used as replay protection as it does not
protect against duplicate retransmissions. I.e. to provide full replay
protection the TSCH would need to generate nonce using the ASN, and
add the normal 4-octet frame counter to the frame and use that only
for replay protection.

> <RCC>I think it can be interpreted otherwise - see above</RCC> 

The text saying that Nonce is always generated using ASN regardless of
whether the frame counter is carried is quite clear.

I assume you are saying that when node receives encrypted EB frame, it
could take the frame counter from security auxiliary frame, and then
generate ASN from there, and then run the incoming frame security
processing, and generate nonce from the newly generated ASN? This
could be possible, but I do not think there is anything in the
802.15.4 that even hints that you should do that, but there is the
text above which at least for my understanding forbids that.

> encrypted. Why not put it in a header IE? In this way, it could be possible to
> encrypt parts of the beacon. As it stands, this seems impossible if the

Yes. But I think it is too late to change that now. Also as people
seem to be indicating that there is no use for EBs after the join
process, and that might be the reason they didn't see reason to
encrypt them. There is lots of hidden assumptions behind 802.15.4e
which were not written down, thus it is hard to try to understand why
it was designed as it designed.

And again, I myself would think there would be valid reasons to
encrypt and MIC EBs with proper key, but as far as my understanding of
802.15.4e is, it is not really possible to encrypt them as the
specification is written now.

> <RCC>Again, a synchronizing device may not have a valid representation of ASN.
> Something carried in a field is not a device's own ASN, it is a remote
> device's ASN</RCC>

There is only one ASN. It is by definition global absolute sequence
number, thus there is no such notion of device's own ASN or remote
device's ASN. There is only one ASN...

> <RCC>This seems completely wrong and conflicts with the clarifying text added
> in section 5.1.6.4.3 in 802.15.4-2011. Retransmitted frames should use the
> same frame counter. It is almost impossible to use a nonce based solely on
> what is effectively implicit data at this level of granularity There almost
> always needs to be some additional explicit data.</RCC>

With TSCH we cannot use the same frame counter, as the frame counter
must always match the current ASN. I.e. if I transmit frame with ASN
54, and do not get ACK back. My next slot I can use to retransmit that
frame is ASN 67, I need to encrypt the frame again using the new ASN,
as otherwise the receiving device cannot properly decrypt and
authenticate it, as it WILL use current ASN 67 when generating nonce
for decryption.

The reason we noticed this issue with TSCH was that someone made
comment for changing the text from 802.15.4rev from:

	When a frame with the Security Enabled field set to one is
	retransmitted, the frame shall be retransmitted without
	changes and without passing through the outgoing frame
	security procedure, as defined in 9.2.1.

to such that it would say "... frame may be retransmitted ...".

That comment was rejected, because that would break the replay
protection, but then I realized while processing that comment that
this case do have problem with TSCH, because in TSCH when we do
retransmission we will transmit it using different ASN, and nonce
needs to be generated again and encryption needs to be done again.

So for the resolution for that is going to be changing that text to
be:

	When not using TSCH mode, and a frame with the Security
	Enabled field set to one is retransmitted, the frame shall be
	transmitted without changes and without following the outgoing
	frame security procedure, as defined in 9.2.1.

	When using TSCH mode, and a frame with the Security Enabled
	field set to one is retransmitted, the frame shall follow the
	outgoing frame security procedure, as defined in 9.2.1.

And then we add text to the CCM* nonce for TSCH mode saying:

	When TSCH mode is enabled, the nonce needs to be generated
	again for each retransmission, thus receiving device has no
	way of distinguishing whether the frame is retransmission or
	not from the ASN. So full replay protection in TSCH mode is
	not provided.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 May 2015 09:06:10 -0400

> to be when EBs were sent.

1) But, also, the attacker has to race the coordinator who will send a new
   EB with a larger ASN.  The node should accept the largest ASN it sees.

2) I had originally envisioned that there would be two sets of EBs, one
   for joining that might be "protected" with a well-known K1, and one
   for production that is protected with a derived key.

I learnt that (2) was not permitted in 15.4.  I still don't quite
understand why, as I originally thought it was a just a question of having
two active PANs.  I'm told that this is frequently not possible with MAC
firmware; I can't speculate much about what non-open source stacks do,
but the open source stacks don't seem to have seperate firmware for the MAC
engine.

I want to say that all of this is outside of the scope of minimal,
so I've changed the subject.

---

From: Jonathan Simon <[email-masked]>
Date: Thu, 21 May 2015 12:56:19 -0700

Michael - (2) is permitted.  EBs and even regular beacons can be theoretically sent with different keys - in
Zigbee you can solicit a beacon using one key, and have the receiver
send you a beacon on a different key - as long as the aux security
header tells each receiver what key is used (or they know what key to use implicitly because it’s specified in the protocol), it works.

That said, I don’t see a good reason to use EBs for anything other than join in 6TiSCH.
-- 
Jonathan

On May 20, 2015, at 6:06 AM, Michael Richardson <[email-masked]> wrote:

> http://cp.mcafee.com/d/avndz8OcCQm6kQkNO8UsrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCTHefmvvvW_8Tud79EVpKDRXBQQT7ejjsusKyNORQr8EGTd7afaxVZicHs3jq9J4TvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypJOsGm9BO5mUm-waBYTu00CT1RSjpFrsDaBypFtd41EyFZCUOCmd4hEwGWq81EpErjsdN3w1fqZa

---

From: Qin Wang <[email-masked]>
Date: Thu, 21 May 2015 21:41:07 +0000 (UTC)

Hi Micheal and Jonathan,
You bring up a good question, i.e. how to use EBs. I have the related questions.(1) Is it possible for a 6TiSCH network to change its timeslot format, or channel hopping sequence, or Frame & Link structure after ASN starts counting?(2) Is it possible to have more than one EBs in a 6TiSCH network
I have no clear answer. What do you and others think?
ThanksQin

  On Friday, May 22, 2015 3:56 AM, Jonathan Simon <[email-masked]> wrote:

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 May 2015 00:59:59 +0300

Jonathan Simon writes:
> Michael - (2) is permitted.  EBs and even regular beacons can be
> theoretically sent with different keys -

I think Michael was talking about regular beacons sent on regular
intervals. Those are started by calling the MLME-START.request, and I
do not think you can set it to send multiple enhanced beacons for
different PANs and using different keys.

> in Zigbee you can solicit a beacon using one key, and have the
> receiver send you a beacon on a different key - as long as the aux
> security header tells each receiver what key is used (or they know
> what key to use implicitly because it’s specified in the protocol),
> it works.

If you use beacon requsts, then of course the coordinator can reply
with beacon, and that beacon can use different keys. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 May 2015 09:13:31 -0400

Jonathan Simon <[email-masked]> wrote:
    > header tells each receiver what key is used (or they know what key to
    > use implicitly because it’s specified in the protocol), it works.

    > That said, I don’t see a good reason to use EBs for anything other than

Because people are confused by "join", I think you mean to say,

        "That said, I don't see a good reason to use EBs for anything other
        than initial imprint in 6TiSCH."

Various people have suggested that we need a way to get the current ASN for
devices that might have been asleep for long periods of time.

Given that we have an industrial focused scope for 6tisch, and the reason for
this narrow scope was to permit us to make progress without boiling the
oceans, I think that it would be useful to consider that in answers that
might occur.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 May 2015 09:17:02 -0400

Qin Wang <[email-masked]> wrote:
    > (1) Is it possible for a 6TiSCH network to change its timeslot format,
    > or channel hopping sequence, or Frame & Link structure after ASN
    > starts counting?

I have no idea if this permitted; but it seems desireable that there should
be some way to do this, even if it means that a PCE has to reach out
provision everything, or tell all nodes that, "when ASN=xyz12, switch to
schedule FOO"

    > (2) Is it possible to have more than one EBs in a 6TiSCH network

I think that the term "6TiSCH network" is too vague a term to answer the
question.  I think that perhaps "in one PANID" might be easily answered.

(A "6TiSCH network" could span many physical locations, be bridged across
ethernet, and include a multitude of PANIDs, behind a multitude of 6BRs)

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 May 2015 15:53:45 +0200

Qin,

You're e-mail ended in my spam folder. Sorry for the late reply.

> provision everything, or tell all nodes that, "when ASN=xyz12, switch to

<tw>
Changing the timeslot format or channel hopping sequence would while the
network is running would necessarily result in nodes de-synchronizing and
re-synchronizing.
</tw>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 May 2015 11:16:22 -0400

Thomas Watteyne <[email-masked]> wrote:
    > <tw>
    > Changing the timeslot format or channel hopping sequence would while
    > the network is running would necessarily result in nodes
    > de-synchronizing and re-synchronizing.
    > </tw>

1) Does that require access to the EB?
2) Does it matter that the EB be authenticated?

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 22 May 2015 11:28:49 -0700

See inline
-- 
Jonathan 

> different PANs and using different keys.
JS - Yes, but TSCH is specifically listed as being a non-beaconing PAN, so Beacons are not generated on a regular schedule using MLME-START.request. 

> http://cp.mcafee.com/d/k-Kr6h0SyMOCCM-VtMTsSyUepjdEK3CnPqbwUQsEFICzASUYYYUNuVIhF9mI0kva7X7BPpYEvIundKefL---_R-hp7npovuWZOW9EVuhVdVZYsCYDORQX8EGThvVkffGhBrwqrhdECXYyMCY-ehojd79KVIDeqR4IMFQLCXM071dnoovaAVgtHzAVkIjdKjBiNcKgGT2TQ1kLCXM04S-O-Cr1vF6y0QJKjBiNcQKCy0Qhk-Pspjb6y8Qgltd40QcQdITdDjrN