Subject: [6tisch] Fwd: New Version Notification for draft-struik-6tisch-security-considerations-00.txt

From: Rene Struik <[email-masked]>
Date: Fri, 09 Jan 2015 09:56:03 -0500

Dear colleagues:

I posted a write-up on security considerations for 6tisch. This document 
provides lots of footnotes on behavior and security and implementation 
considerations re MAC, networking, and join protocol behavior.

The write-up still has some rough edges (which I will have smoothed up 
in the next round). The result of this may be submitted as a sequel to 
the document draft-struik-6tisch-security-architecture-elements-01, 
rather than as stand-alone document, after consultation with co-authors 
of that document.

Best regards, Rene

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-struik-6tisch-security-considerations-00.txt
Date: 	Fri, 09 Jan 2015 06:48:50 -0800
From: 	[email-masked]
To: 	Rene Struik <[email-masked]>, Rene Struik 
<[email-masked]>

A new version of I-D, draft-struik-6tisch-security-considerations-00.txt
has been successfully submitted by Rene Struik and posted to the
IETF repository.

Name:		draft-struik-6tisch-security-considerations
Revision:	00
Title:		6TiSCH Security Architectural Considerations
Document date:	2015-01-09
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-struik-6tisch-security-considerations-00.txt
Status:         https://datatracker.ietf.org/doc/draft-struik-6tisch-security-considerations/
Htmlized:       http://tools.ietf.org/html/draft-struik-6tisch-security-considerations-00

Abstract:
    This document describes 6TiSCH security architectural elements with
    high level requirements and the security framework that are relevant
    for the design of the 6TiSCH security solution.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Kris Pister <[email-masked]>
Date: Fri, 09 Jan 2015 11:51:14 -0800

Rene - there's a lot here that I agree with.  Some questions/comments:

Just to clarify, I believe that you use both "neighbor node" and "proxy 
network node"
instead of the "Join Assistant" terminology that the rest of us have 
been using, yes?

1.2 MAC Security Considerations
    1., 4., 5.:  In 15.4e, MAC security does not use the macFrameCounter 
for forming
nonces, and ASN is not derived or updated based on the results of 
security processing,
so the idea that the use of a well-known key induces a state change that
messes up security is incorrect.
    6.: Use of the same nonce with a well-known key has no negative 
security impact,
as there was no security to start with.  Use of the same nonce with two 
different keys
has no security impact, period.  Use of the same nonce with the same 
high-entropy
key is bad, as you point out, but is not possible with the protocol that you
have outlined.  So what is the problem exactly?
    7.: If any device's ASN is out of synch with the rest of the network 
it won't be able
to communicate at all, and needs to rejoin.

1.3.2 Join protocol description
Step 4 - neighbor node sends "first join protocol message" to server?

Looks like steps 3 and 5 are a two-message key exchange.  What protocol(s)?

Step 10: I don't see how the server has a key at this point.  If the 
cached server
info was sent JA-->JN in step 5, then it can't have a unique random 
number in it, so
how can there be a secure secret exchanged between the joining node and 
the server?

ksjp

On 1/9/2015 6:56 AM, Rene Struik wrote:
> Dear colleagues:
>
> I posted a write-up on security considerations for 6tisch. This 
> document provides lots of footnotes on behavior and security and 
> implementation considerations re MAC, networking, and join protocol 
> behavior.
>
> rather than as stand-alone document, after consultation with 
> co-authors of that document.
>
> Best regards, Rene
>
> URL:http://www.ietf.org/internet-drafts/draft-struik-6tisch-security-considerations-00.txt
> Status:https://datatracker.ietf.org/doc/draft-struik-6tisch-security-considerations/
> Htmlized:http://tools.ietf.org/html/draft-struik-6tisch-security-considerations-00
>
>
> Abstract:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Rene Struik <[email-masked]>
Date: Fri, 09 Jan 2015 16:22:27 -0500

Hi Kris:

Thanks for your speedy feedback on this draft (rough edges and all). 
This helps me improving the draft further. Some initial feedback below, 
which I hope helps.

Best regards, Rene

On 1/9/2015 2:51 PM, Kris Pister wrote:
> Just to clarify, I believe that you use both "neighbor node" and 
> "proxy network node"
RS>>
Yes. I kept the wording mostly "join language" agnostic for now. I could 
update this once we have a good definition (and better understanding of 
what the neighbor node's role should be during join: e.g., simply relay 
or some more active role [e.g., authentication, DoS minimization]).
<<RS
>    1., 4., 5.:  In 15.4e, MAC security does not use the 
> macFrameCounter for forming
RS>>
These items deal with 802.15.4 security in general, whereas only point 
#6 onwards discuss how 802.15.4e deviates, when in TSCH mode. Perhaps 
worth noting: nonces are maintained on a per-device basis and not on a 
per {device,key} combination basis (see end of #1).
<<RS
> as there was no security to start with.  Use of the same nonce with 
> two different keys
RS>>
As already said, with 802.15.4, nonces are stored on per-device rather 
than on per {device, per key} combination basis. As a result, if A has 
two different keys, successful security processing on either updates 
state (#1) or results in side effects (#2). In particular, if these two 
keys are "default key" and "cryptographic key", then, e.g., receipt of 
frame processed with default key (which could have been sent by any 
device) could result in updates of state on the receiving device related 
to the originating device. This may pose problems, e.g., in case not all 
ASN entries are aligned (this is why I added language in step #13 of the 
join protocol description that the "server" needs to send its ASN, PANID 
view to the device in question, so that potential discrepencies could be 
noted by the joining device. BTW - please see also Question #4 on the 
minimal draft posted Dec 19, 2014, see 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02867.html
See also feedback on #7 below.
<<RS

> to communicate at all, and needs to rejoin.
RS>>
I think it can still communicate, but only to a subset of devices it 
shares the ASN time notion with. The question is what proper course of 
action is when network is partitioned in different "time zones" (e.g., 
how to get those all on the same "page"). This is also slightly related 
to remark #12 on the join protocol description, where one may end up 
with a "hidden node" satellite (where the joining node is circling as a 
moon around its neighbor node (JA) planet on its private time notion. It 
seems that having nodes automatically rejoin if they notice different 
"time zones" may be undesirable, since then one compromised node (or 
simply one out-of-sync node) could make the entire network implode. 
Perhaps, I am missing something here. However, it is precisely those 
failure scenarios and how to recover from those (hopefully) gracefully 
that I am interested in (with viewing the world as a huge security engine).
<<RS
> Step 4 - neighbor node sends "first join protocol message" to server?
RS>>
Perhaps, there is a typo here, since Step #4 only deals with receipt of 
the first join flow from the joining node. Step #5 is a return flow from 
neighbor node to joining node.
Step #3:  Joining dev --> neighbor node: ephemeral key + other stuff
Step #5: Joining dev <-- neighbor node: ephemeral key + other stuff
Once a device has inputs from the other device and local info it can 
compute the shared key (all public key based methods here, since we 
assumed certs on devices).
<<RS
> Looks like steps 3 and 5 are a two-message key exchange.  What 
RS>>
I did not want to nail down protocol references yet here, since current 
draft only focuses on flows, desired/feasible properties, etc. We can 
look into options later on (and consider fit of, e.g., DTLS, IPSec, 
etc.). I wanted to keep this as much protocol-agnostic for now, so as to 
have us focus on fundamentals first, before getting into areas where 
people may have strong opinions (besides, lots of IETF protocols are in 
flux right now, e.g., TLS1.2 --> TLS1.3). For the same reason, I did not 
want to get into certificate format picks yet either.
<<RS
> how can there be a secure secret exchanged between the joining node 
> and the server?
RS>>
The server and joining node establish a shared key based on exchanged 
ephemeral keys, certs, and locally maintained private keys. Here, the 
joining node gets this from its neighbor (if cached); the server gets 
this from the joining node, via its neighbor node ("JA"). NOTE: the text 
in step #8 is somewhat obscure regarding actually sending this ephemeral 
key along, e.g., as part of the piggy-backed info, since it only states 
this in a much more abstract way (" The piggy-backed information 
includes configuration information to be passed from the joining node to 
the server that allows the server to check the joining node’s true 
credentials"). This could indeed be clarified more.
<<RS

>> The write-up still has some rough edges (which I will have smoothed 
>> up in the next round). The result of this may be submitted as a 
>> sequel to the document 
>> draft-struik-6tisch-security-architecture-elements-01, rather than as 
>> stand-alone document, after consultation with co-authors of that 
>> document.
>>
>> Best regards, Rene
>>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363