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

[Thomas Watteyne <[e-mail]>]

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.

*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.

*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?

*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.

*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? 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.

*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.

*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?

*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?
- 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"

Thomas

On Tue, Jun 25, 2013 at 8:30 AM, Pascal Thubert (pthubert) <
[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]]
>
> *Sent:* mardi 25 juin 2013 11:04
> *To:* Pascal Thubert (pthubert); [e-mail];
> [e-mail]
>
> *Cc:* [e-mail]
> *Subject:* RE: [6tsch] draft-ohba-6tsch-security-00****
>
>  ** **
>
> ** **
>
> ** **
>
> *From:* Pascal Thubert (pthubert) [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Tuesday, June 25, 2013 5:46 PM
> *To:* [e-mail]; ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ);
> [e-mail]
> *Cc:* [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]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>