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

[Qin Wang <[e-mail]>]

Hi Yoshi,

It seems to me that ,besides Symmetric algorithm module like AES-based CCM*
required by 802.15.4e , every node has to equip a Asymmetric algorithm
module as well. correct? If it is true, I'm afraid if it is too heavy for a
node with limited resource.

Thanks
Qin


On Thu, Jun 27, 2013 at 10:51 PM, <[e-mail]> wrote:

>  Hi Thomas,****
>
> ** **
>
> Thank you very much for your comments.  Please my response below.****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *Thomas Watteyne
> *Sent:* Thursday, June 27, 2013 1:24 PM
> *To:* [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]> 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****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>