Re: [6tsch] FW: draft-ohba-6tsch-security-00

[<[e-mail]>]

Hi Thomas,

Thank you very much for your comments.  Please my response below.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Thomas Watteyne
Sent: Thursday, June 27, 2013 1:24 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [6tsch] FW: draft-ohba-6tsch-security-00

Yoshihiro and co-authors,

It's wonderful you were able to publish this draft so quickly!

Here is a list of pseudo-random thoughts I had while reading it. I'd be happy if we could discuss the clarifying questions below on the ML and during the following weekly calls. Do not hesitate to spawn your answers into different e-mail threads if that's easier. I'm also adding some random remarks and typos at the end of this e-mail; feel free to ignore any or all of them.

Clarifying questions

Credentials for P1 authentication. The draft now reads that during the P1 bootstrapping phase, the new node authenticates to the authentication server. For this to be possible, the node must have something installed. That can be some pre-installed key, a certificate, or something more exotic. In any case, I believe it would be useful to have a section at the very beginning which indicates what the new node is expected to have when trying to join the network. This will have an impact either on the production phase of the devices, or on the pre-deployment routine the installer need to go through.
[YO] I agree. Pascal had a similar comment and he suggested to have phase-0 for commissioning.

Interaction with IEEE802.15.4 security mechanisms. IEEE802.15.4 (and IEEE802.15.4e) comes with a CCM*, a combined encryption and authentication block cipher mode, built on an AES-128 cipher. Using CCM*, a node can encrypt and/or authenticate all MAC-layer frames. CCM* allows you to choose which range of bytes you encrypt and/or authenticate in your packet. In addition, IEEE802.15.4e defines that the nonce counter used by CCM* contains the 5-byte ASN. This brings replay protection, since the ASN rolls over every 350 years with 10ms slots. It would be great if the security mechanism we come up with takes advantage of this capability, since at least parts of it is built into most (all?) IEEE802.15.4 radios/SoCs. Maybe the draft could contain some text explaining how this would work.

[YO] If 5-octet ASN is persistently maintained across coordinator crashes, etc. then frame counter wrap-up may not be a concern.  Otherwise, the issue would still remain, no?


Session with the PCE. The PCE plays a special role in a 6TSCH networks. Since it is responsible for the TSCH schedule (and maybe even for some routing), it's essential that the communication between a node and the PCE be confidential and authenticated. Do we need to have a special requirement for the mote-to-PCE communication? If not, is this completely covered by the discussion about P3?
[YO] I believe mote-to-PCE communication is covered by the discussion about P3. Please let me know if I am missing something.

Authentication relay. I'm a bit confused by the exact natore of the authentication relay. This comes up for example in the following requirement:
   R1-2: Phase-1 KMP MUST support stateless authentication relay operation.
What I understand is that it's the role the motes already in the network play when a new node joins and is multiple hops away from the authentication server. In this case, do those nodes need to play any security role at all? Can they not relay a opaque sequence of bytes which happens to be the (end-to-end secure) authentication traffic between the authentication server and the new mote? The following paragraph seems to indicate this:
   A Phase-3 node can forward Phase-1 KMP messages originated from
   or destined for a Phase-1 node that is joining the mesh network
   through the Phase-3 node.
[YO] An authentication relay will only relay authentication messages. If an opaque sequence happens to have the same format as the intended authentication message the relay will forward the sequence, but authentication won’t succeed unless it is true authentication traffic.  This is a kind of DoS attack and rate limiting at the relay can help mitigating the attack.

Footprint of keying material. The draft indicates that, in the extreme case, a node maintains separate keying material to communicate with each of its neighbors. Is this accurate?
[YO] Yes.

This might introduce a large footprint, both in memory and complexity. Is it possible to optionally relax P2 this for low-end implementations, and e.g. have a common network key? I understand the implication which you highlight in the introduction w.r.t. ZIP.
[YO] I believe a common network key is acceptable for small-sized networks only (e.g., less than 30 mesh nodes) as highlighted in the introduction.  As far as I understand, the required scalability for 6TSCH is more than 1000 nodes which I characterize as a large-sized networks, and that is why the current requirements come. I believe small-footed devices will simply limit the number of neighboring nodes, and a mesh network with smaller node degree will be formed as a result, and it works.

EB protection. I understand the concern you express in Section 6, but thanks to the TSCH nature of our little networks, the counter wraps every 350 years. I believe this significantly lowers the vulnerability of using a pre-installed key.
[YO] If one TSCH node is compromised and the pre-installed key is known to attackers, then the TSCH network can be totally vulnerable. I think pre-installed key is not good regardless of the size of frame counter.

Random remarks

- About section 2, I would argue that definitions live in the terminology draft. It's already referenced at the bottom, so maybe put that cross-reference at the beginning of Section 2?
- The draft lists the requirements for a secure 6TSCH solutions. PANA is listed as one of the candidate KMPs. Maybe remove PANA it from the abstract?
[YO] We will work on revising abstract. Note that PANA is the only candidate for P1 KMP.

Typos and other minor things

- "provide adequate Time Sensitive behaviors" -> "provide adequate levels of determinism"
- Following Metcalf's law: add reference?
- "value of using radios" -> "the value of using radios"
- "wraps up" -> "wraps" (not sure)?
- "temporal PIN" -> "temporary PIN" (again, not sure)?
- "located in the coordinator" -> "co-located with the coordinator"?
- The SA of a link between node i and node j maintains MAC keys.
- MAC key, I assume using CCM*? encryption? authentication? both?
[YO] Yes, it is for CCM* therefore it can be one of ENC or MIC, or both.
- bi-directinal -> bi-directional
- "on required security level" -> "on the required security level"
- "seciton" -> "section"
- "reply protected" -> "replay protected"
- "candiate" -> "candidate"
- "e.g sensor" -> "e.g. sensor"
- DTLS[RFC6347]: please make this s XREF
- "multicast key exportation" -> "exporting multicast keys"?
- "exported key material" -> "exported keying material"?
- "intergrity" -> "integrity"

[YO] I will fix all typos.

Thanks again
Yoshihiro Ohba

Thomas

On Tue, Jun 25, 2013 at 8:30 AM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:

Dear all:



I realized that the list was not copied; fixing this now. The discussion is around section 2 that is missing the expansion of 6TSCH



Cheers,



Pascal



From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
Sent: mardi 25 juin 2013 11:04
To: Pascal Thubert (pthubert); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [6tsch] draft-ohba-6tsch-security-00







From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Tuesday, June 25, 2013 5:46 PM
To: [e-mail]<mailto:[e-mail]>; ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [6tsch] draft-ohba-6tsch-security-00



Hello Xavi and Yoshi.



I’d agree that our terminology is not perfect for that definition. Let us discuss this at the next call.

“

  6TSCH:      Entity that sets up the schedule, controls the

               connectivity graph of the network, and the resources

               allocated to each scheduled cell in that connectivity

               graph.  It may be an adaptation layer, a distributed

               reservation protocol, a centralized path computation

               entity, or any combination thereof.



“

I think that the definition should 1) spell out the acronym “IPv6 over Time Slotted Channel Hopping”, and 2) explain that 6TSCH defines a set of IETF sublayers and protocols, as well as an architecture to bind them together, for use in TSCH based networks. Which in turns reminds me that people are getting confused when we tell them that 6TSCH pronounces “SIXTUS” and that we also have a sublayer called 6TUS. Shouldn’t we change something there?



Yoshi:  I think section 2 should refer to our terminology. There is already a XREF link at the end of the draft. If the terminology expands the acronym for 6TSCH you’re all set : )

[YO] As soon as we agree on the acronym for 6TSCH I will put it in section 2.



About section 3. Could we separate the commissioning from the bootstrapping? I would like to see a phase 0 when the device is prepared and the management systems are provisioned. In particular: What are the expectation on the device off the factory: Some builtin vendor crypto material / certificate? And then when the device is acquired and prepared for installation: Should the OT people configure an IPv6 address? Additional crypto material like a shared secret?



[YO] We could add text for phase 0 for commissioning (I think Figure 1 can still start with phase 1 since phase 0 does not need to be standardized).  The purpose of phase 0 is to install phase 1 KMP credentials in a physically secured and managed location before the devices are placed where they are expected to operate.



Regards,

Yoshihiro Ohba





Cheers,



Pascal

_______________________________________________
6tsch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tsch