Subject: [6tisch] security text on minimal

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 21 Apr 2015 11:18:24 +0200

Hi Rene, Michael and Jonathan,

I am working on the text for the security section in the minimal draft. I
included Rene's suggestion but I still have doubts as during the IETF
meeting there was some discussion about it.

the security section is composed of 2 paragraphs.

As this document refers to the interaction between Layer 3 and Layer
   2 protocols, this interaction MUST be secured by L2 security
   mechanisms as defined by [IEEE802154e].  Two security mechanisms are
   considered, authentication and encryption, authentication applies to
   the all packet content while encryption applies to header IEs and MAC
   payload.  *Key distribution is out of scope of this document, but*
*   examples include pre-configured keys at the nodes, shared keys among*
*   peers or well-known keys*.  Refer to the 6TiSCH architecture document
   [I-D.ietf-6tisch-architecture] for further details on key
   distribution and advanced security aspects.

   The present document assumes the existence of two cryptographic keys,
   which can be pre-configured.  One of the keys (K1) is used to
   authenticate EBs.  As defined in Section 4, EBs MUST be
   authenticated, with no payload encryption.  This facilitates logical
   segregation of distinct networks.  A second key (K2) is used to
   authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and
   respective header IEs, with payload encryption.  Depending on
   security policy, these keys could be the same (i.e., K1=K2).

The second paragraph is what Rene proposed and had consensus on the ML.  In
red is my doubt that raises from the discussions during the WG meeting at
the IETF in Dallas. I think that someone was opposing to the text
indicating *well-known keys.*

can you please advice me on that?
thanks!
Xavi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2015 14:17:54 +0300

Xavier Vilajosana writes:
> included Rene's suggestion but I still have doubts as during the IETF meeting
> there was some discussion about it.
> 
    	     	    	    	  	     	     	^^^^^^^^^^
Header IEs are not encrypted, they are only authenticated. Payload IEs
are encrypted and authenticated.

Most of the TSCH IEs are Payload IEs (or actually a Nested IEs inside
the MLME payload IE). These include TSCH Synchronization IE, TSCH
Slotframe and Link IE, and TSCH Timeslot IE. Those IEs are encrypted.

TSCH uses also one Header IE, i.e. Time Correction IE, and it is only
authenticated. 

>    payload.  Key distribution is out of scope of this document, but
>    examples include pre-configured keys at the nodes, shared keys among
>    peers or well-known keys.  Refer to the 6TiSCH architecture document
> red is my doubt that raises from the discussions during the WG meeting at the
> IETF in Dallas. I think that someone was opposing to the text indicating 
> well-known keys.

I think well-known keys will just make security weaker, and completely
remove the security if K1=K2.

Also if the K1 is well-known then it will NOT provide the "logical
segregation of distinct networks".

Also if K1 is well known, then EBs do not have any protection, i.e.
anybody can generate fake EBs and mess up the network totally by
giving completely wrong schedule for everybody. If the K1 is something
that you get after you join the network, then you can verify that EBs
are sent by someone who is part of the network, thus you can trust
them bit more.

Also if well-known K1 and EBs are used for time syncronization, i.e.
keeping the ASN in sync after sleep, then nodes which wake up and
whole do know the well-known K1 and private K2, cannot trust the ASN
he gets from the EBs, as it might be faked, thus he cannot use K2 key
before rejoining the network. Otherwise the attacker might roll ASN
backwards during the sleep and cause the device to use same ASN twice
(== same nonce twice == encryption provided by the K2 key would be
broken).
-- 
[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 21 Apr 2015 15:32:35 +0200

Dear Tero,

thanks for your comments. I will clarify that headers are only
authenticated and payloads are both authenticated and encrypted. As for
well-known keys, that was exactly the discussion at the meeting. My point
is to remove it but I want to see everybody's opinion.

regards,
Xavi

---

From: Kris Pister <[email-masked]>
Date: Tue, 21 Apr 2015 08:24:25 -0700

> segregation of distinct networks".

Tero, we've been over this many times.  A well-known K1 does not provide
any security, but it does in fact provide segregation of distinct networks.
Specifically, if we use "6tischRFCxxxx-15" as K1, it segregates 6tisch 
networks
that use that standard from all of the other networks that don't.

The world is filled with 802.15.4 networks.  The vast majority of them 
do not
abide by any protocol defined by the IEEE or the IETF.  They send 
whatever bytes
they want as PDU without regard to the 1,000 page documents that they 
haven't
read.  Or sometimes they use some of the structure and ignore the rest, so
filtering just based on EB structure is risky.
Using a well-known key to generate a MIC (that is calculated in hardware
essentially for free) doesn't give you any security, but it does tell 
you with very
high probability that the EB you just heard is from the kind of network 
you want
to join.  It could be faked, it isn't secure, but with high probability 
all of the bits
in the message are what the sender sent, and for good or ill, the sender 
was trying
to send a 6tisch EB.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Tue, 21 Apr 2015 08:32:16 -0700

Tero wrote:
 > Payload IEs are encrypted and authenticated.
Is it not correct to say that payload IEs *may* be encrypted and/or 
authenticated,
rather than that they are?

Xavi wrote:
 > As for well-known keys [...] My point is to remove it but I want to 
see everybody's opinion.

I disagree with this.  The discussion is not about whether well-known 
keys provide
security.  I think that everyone on this list will agree that they do not.
If the choices are:
1) use a PSK so that you have a secure beacon, and you know that it's a 
6tisch
network that is the kind that you want to join
2) use a well-known key so that you know that at least someone is 
intentionally
sending 6tisch EBs (although they may be faked) and that no bits have 
changed in this EB
3) don't use anything at all

Then I am in favor of options 1 or 2.  That's what the current text allows.

Is there an argument in favor of option 3?

In WirelessHART, we had a discussion about option 1: "Should we keep 
[K1] secret?"
The conclusion was: all devices from now until the end of time need to 
know K1,
so that a node that we deploy tomorrow will be able to join a network 
that we
deploy today.  It's going to be public eventually, we may as well reveal 
it today.
Its purpose is not security - it is message integrity.

ksjp

On 4/21/2015 6:32 AM, Xavier Vilajosana wrote:
> authenticated and payloads are both authenticated and encrypted. As 
> for well-known keys, that was exactly the discussion at the meeting. 
> My point is to remove it but I want to see everybody's opinion.
>
> regards,
> Xavi
>
>
>
> 2015-04-21 13:17 GMT+02:00 Tero Kivinen <[email-masked] 
> <mailto:[email-masked]>>:
>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Apr 2015 17:35:25 -0400

> I am working on the text for the security section in the minimal
    > draft. I included Rene's suggestion but I still have doubts as during
    > the IETF meeting there was some discussion about it.

    > The second paragraph is what Rene proposed and had consensus on the
    > ML. In red is my doubt that raises from the discussions during the WG
    > meeting at the IETF in Dallas. I think that someone was opposing to
    > the text indicating well-known keys.

Just so that you know, html markup does not survive IETF lists (by
intention. See homerswebpage.com... so your "red" doesn't survive.

I think that we agreed that the K1 key was of no cryptographic value.
{I saw a danger in the suggestion that K1 could be the same as K2,
as an implementor might assume this to always be the case.}

I think that your text captures consensus.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Apr 2015 15:26:25 +0000

Dear All: 

The goal of minimal is not to be our security architecture, what we want is a minimal text that we expect to authenticate the IEs and the RPL control messages and we expect that L2 security will do that for us.

Tomorrow, it would be good to be able to conclude on the  security section of minimal.

> I think that your text captures consensus.

That's exactly the sort of answer we need on this thread. I understand that you will not be there at that time in the agenda but that your vote is OK. Shepherd hat on, a note is well taken.

Thanks Michael!

Pascal

> -----Original Message-----
> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: mardi 21 avril 2015 23:35
> To: [email-masked]
> Subject: Re: [6tisch] security text on minimal
> 
> 
> Just so that you know, html markup does not survive IETF lists (by intention. See
> homerswebpage.com... so your "red" doesn't survive.
> 
> {I saw a danger in the suggestion that K1 could be the same as K2, as an
> implementor might assume this to always be the case.}
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>