Subject: [6tisch] proposed text for minimal security

From: Kris Pister <[email-masked]>
Date: Tue, 05 May 2015 14:46:49 -0700

This is my proposed text for all of section 8.  This does not force 
anyone to
use well-known keys, or 32 bit MICs, or send EBs unencrypted.
It does make it easy to do interop.
People who want to use pre-configured secret keys, long MICs, encrypted EBs,
or no keys at all, are free to do so.

ksjp
---------------
8.    Security
Minimal assumes the existence of two keys, K1 and K2.  EBs MAY be
authenticated with key K1 using security level 1 (32 bit MIC).
DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be
authenticated with key K2 using security level 1.

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.  EBs MAY be filtered based on PANID.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 May 2015 10:29:18 +0000

+1

I think it says is all.

Pascal

> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
> Sent: mardi 5 mai 2015 23:47
> To: [email-masked]
> Subject: [6tisch] proposed text for minimal security
> 
> This is my proposed text for all of section 8.  This does not force anyone to use
> well-known keys, or 32 bit MICs, or send EBs unencrypted.
> For early interoperability, K1 MAY be set to "6TiSCH minimal15". K2 SHOULD be
> a randomly generated high entropy cryptographic key.
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 6 May 2015 12:36:10 +0200

This is the second proposal we presented at the last 6tisch webex meeting.
I am in favor of it but it raised some discussion. I still support it so +1.

regards,
Xavi

2015-05-06 12:29 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> anyone to use

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 15:42:42 +0300

> use well-known keys, or 32 bit MICs, or send EBs unencrypted.

EBs cannot be encrypted ever, so that is not a point. 

> It does make it easy to do interop. People who want to use
> pre-configured secret keys, long MICs, encrypted EBs, or no keys at
> all, are free to do so.
> 
> ksjp
> ---------------
> 8.    Security

Is there any reason to specify the security level 1 there? I mean if
it is MAY, then there is no point of mentioning it. On the other hand
EBs cannot be sent using security levels 5-7, so that most likely
should be mentioned. 

> authenticated with key K2 using security level 1.

For this I would just say that those frame types SHOULD be protected
using key K2, and leave the security level unspecified. I do see why
you have SHOULD NOT encrypt for DATA frames.

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

This would need to provide explination why this is done, and what are
the effects caused by sing such key, i.e. that no protection is
offered in that and it is exactly same as not using K1 at all, but
instead sending everything without MIC (note, that this is security
considerations section, so for security those two are identical, even
when there are other differences (filtering, different packet lengths
etc) in frames.

Of course when you end up having paragraph or two explaining that in
here, I would expect that in last call phase people will be asking,
"why are you then doing that", so be prepared to explain that too.

Or you could move all of that out from here, and say that EBs might be
unauthenticated and unprotected, and then have separate section
explaining that in such cases the security level 1 could be used to
filter minimal implementations from other 802.15.4 TSCH networks. 

> K2 SHOULD be a randomly generated high entropy cryptographic key.
> Key distribution is out of scope.

That text is ok. 

> EBs MAY be filtered based on PANID.

No they really cannot be.

The PAN ID is generated by the PAN coordinator when he forms the
network. The exact algorithm to pick one is left outside the scope of
802.15.4, but "This is achieved by choosing a PAN ID that is not
currently used by any other network within the radio communications
range."

Also if somehow there is another PAN in the radio range which has same
PAN ID then "If this conflict happens, the PAN coordinator and its
devices shall perform the PAN ID conflict resolution procedure".

Then: "The next higher layer of the PAN coordinator may then perform
an active scan and, using the information from the scan, select a new
PAN ID. The algorithm for selecting a suitable PAN ID is outside the
scope of this standard". Note, that if it does not pick new PAN ID
then next beacon will trigger this PAN ID Confliction notification
again.

If it does pick new PAN ID, it will send that to everybody using
broadcast coordinator realignment MAC command, which will then
reconfigure the whole network to use PAN ID. I.e. the PAN ID can be
changed at any time during the normal operation of the network. 

Thus PAN Coordinator cannot know which PAN ID it is going to be using.
Also while doing active or passive scanning, the 802.15.4 MAC will
return all networks (and their PAN IDs) in radio range.

What you can do, is to select the network you want to join by
selecting the best network in radio range from those returned by
scanning. That selecting function might use PAN ID as selector in some
unspecified manner, but sa PAN ID is not stable nor it cannot be
fixed, that is bit hard.
-- 
[email-masked]