Subject: [6tsch] draft-ohba-6tsch-security-00

From: <[email-masked]>
Date: Mon, 24 Jun 2013 02:10:11 +0000

6tsch-security draft has been submitted to IETF:

http://tools.ietf.org/html/draft-ohba-6tsch-security-00

Regards,
Yoshihiro Ohba

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jun 2013 15:30:31 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: mardi 25 juin 2013 11:04
To: Pascal Thubert (pthubert); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [6tsch] draft-ohba-6tsch-security-00

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 5:46 PM
To: [email-masked]<mailto:[email-masked]>; ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 26 Jun 2013 21:24:09 -0700

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

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 14:51:06 +0000

Hi Thomas,

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

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

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"
[YO] Yes, it is for CCM* therefore it can be one of ENC or MIC, or both.

[YO] I will fix all typos.

Thanks again
Yoshihiro Ohba

Thomas

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

Dear all:

Cheers,

Pascal

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

Hello Xavi and Yoshi.

“

“

Regards,

Yoshihiro Ohba

Cheers,

Pascal

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 28 Jun 2013 02:19:26 +0800

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, <[email-masked]> wrote:

>  Hi Thomas,****
>
> ** **
>
> Thank you very much for your comments.  Please my response below.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Thomas Watteyne
> *Sent:* Thursday, June 27, 2013 1:24 PM
> *To:* [email-masked]
> *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!****
>
> ** **
>
> 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
> installer need to go through.****
>
> *[YO] I agree. Pascal had a similar comment and he suggested to have
> phase-*0 for commissioning.****
>
> ** **
>
> 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?*
>
> * *
>
> ** **
>
> 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.****
>
> ** **
>
> requirement:****
>    R1-2: Phase-1 KMP MUST support stateless authentication relay
> operation.****
>
> 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.*****
>
> ** **
>
> 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.****
>
> ** **
>
> 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*****
>
> ** **
>
> cross-reference at the beginning of Section 2?****
>
> ****
> *[YO] We will work on revising abstract. Note that PANA is the only
> candidate for P1 KMP.*****
>
> ** **
>
> *Typos and other minor things*****
>
> ** **
>
> 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****
>
> ** **
>
> [email-masked]> wrote:****
>
> Dear all:****
>
>  ****
>
>  ****
>  ****
>  ****
> [email-masked]****
>
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> are placed where they are expected to operate.*****
>
> * *****
>
> *Regards,*****
>
> *Yoshihiro Ohba*****
>
>  ****
>
>  ****
>
> Cheers,****
>
>  ****
>
> Pascal****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Jonathan Simon <[email-masked]>
Date: Thu, 27 Jun 2013 14:09:11 -0700

Section 1

"6TSCH builds on a series of semi-proprietary wireless protocols..."
Is it really relevant that TSCH was built on concepts in WirelessHART?  TSCH is not proprietary, and saying it builds on proprietary protocols is a red flag.

"Following Metcalf's law..."
Not only is it not clear what point is being made, Metcalf’s law measures “utility” in connections.  For a networked sensor device, there are likely a finite number of consumers of its data, and the total number of nodes is an irrelevant utility metric. Additionally, in terms of mesh connectivity, in general there is little additional utility to having 1000 neighbors (which may be more than the node can store) over 100, and perhaps 100 over 10 provided there is sufficient connectivity for the network to function.

General

So the problem this draft is trying to solve is shared link-layer keys in the network.  It does this by proposing an 3-phase authentication scheme with unstated overhead to provide unique per-peer link-layer keys, among other things.

a) Each node would need to be preconfigured with every node's certificate material (bad), or communicate with the coordinator to validate PK certs for every device attempting to join (nearly as bad if this takes a lot of packets).  Without seeing the overhead, its hard to tell if this would even work - if a device has to stay synchronized for a long time using unsecured frames, how is that any better than a shared secret? There's still a DoS vector in the unsecured bandwidth.

b) I agree that in protocols with a well-known key for authenticating join requests, an attacker can perform a DoS attack by simulating many devices joining.  These messages are passed up to the coordinator (and rejected).  However this requires distributed injection of messages to be maximally effective, and this is little worse than flooding the network with packets authenticated with the wrong key, so I don't see how per-peer keys is an effective DoS mitigator.
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 23:20:31 +0000

Hi Qin,

First, I would like to clarify that asymmetric keys are not used for protecting MAC frames, but for mutual authentication and key establishment for CCM* keys between neighboring nodes.

Second, there is an open source EC cryptographic module for sensors and its evaluation is available: http://discovery.csc.ncsu.edu/pubs/ipsn08-TinyECC-IEEE.pdf.

Yoshihiro Ohba

From: Qin Wang [mailto:[email-masked]]
Sent: Friday, June 28, 2013 3:19 AM
To: ohba yoshihiro
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] FW: draft-ohba-6tsch-security-00

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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,

Clarifying questions

Random remarks

Thanks again
Yoshihiro Ohba

Thomas

Dear all:

Cheers,

Pascal

Hello Xavi and Yoshi.

“

“

Regards,

Yoshihiro Ohba

Cheers,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Jun 2013 19:54:01 -0400

Qin Wang <[email-masked]> wrote:

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

People keep assuming this, yet other people point to running code.
How many asymmetric operations per decade can a mute sustain?
The answer may be too small for our use, but it can not be zero.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: <[email-masked]>
Date: Fri, 28 Jun 2013 00:53:53 +0000

Hi Jonathan,

Thank you for your feedback.

Let me answer on the General part.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: Friday, June 28, 2013 6:09 AM
To: ohba yoshihiro
Cc: [email-masked]
Subject: Re: [6tsch] draft-ohba-6tsch-security-00

Section 1

General

a) Each node would need to be preconfigured with every node's certificate material (bad), or
communicate with the coordinator to validate PK certs for every device attempting to join (nearly as bad if this takes a lot of packets).
[YO] Actually neither one is correct.  What each node has to have as P2 credentials are a CA certificate as the trust anchor and its own certificate signed by the CA public key. Once P2 credentials are obtained, Node A and Node B can locally exchange their certificates to perform mutual authentication to securely exchange MAC keys without communicating with the coordinator.  Node A does not need to retain Node B’s  certificate and vice versa once the MAC keys are established.

Without seeing the overhead, its hard to tell if this would even work - if a device has to stay synchronized for a long time using unsecured frames, how is that any better than a shared secret? There's still a DoS vector in the unsecured bandwidth.
[YO] We know that we cannot eliminate all DoS attacks. There has to be engineering decisions as to which DoS attacks are acceptable and which are not.  In any case, it seems that beacon security in TSCH is a problem that requires deeper investigations.

b) I agree that in protocols with a well-known key for authenticating join requests, an attacker can perform a DoS attack by simulating many devices joining.  These messages are passed up to the coordinator (and rejected).  However this requires distributed injection of messages to be maximally effective, and this is little worse than flooding the network with packets authenticated with the wrong key, so I don't see how per-peer keys is an effective DoS mitigator.
[YO] Per-peer keys are mainly for avoiding difficulty with updating a common network key.

Best Regards,
Yoshihiro Ohba
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]<mailto:[email-masked]>

On Jun 23, 2013, at 7:10 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Yoshihiro Ohba

---

From: Kris Pister <[email-masked]>
Date: Thu, 27 Jun 2013 17:59:20 -0700

It all depends on the hardware.  The latest round of radio+mcu from 
several vendors include a cortex m3 and at least 8kB of RAM.  No problem 
running ECC on that platform.
But if you're trying to run the whole IPv6 stack, and a simple OS, and 
your application, it's not a guarantee that you have enough RAM left for 
ECC.

I'm a big fan of ECC, and my mote platform of choice has 72kB of RAM, so 
I'm eager to see a good PKI-for-motes standard emerge. But I'm not sure 
that we should make it a MUST that all motes have enough RAM for PKI.

ksjp

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jun 2013 09:34:23 -0400

You said, "PKI".
Nobody talked about the "I" part.
Please clarify.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 28 Jun 2013 16:54:50 +0200

Hi Kris, all

El 28/06/2013, a las 02:59, Kris Pister escribió:

> It all depends on the hardware.  The latest round of radio+mcu from several vendors include a cortex m3 and at least 8kB of RAM.  No problem running ECC on that platform.
> But if you're trying to run the whole IPv6 stack, and a simple OS, and your application, it's not a guarantee that you have enough RAM left for ECC.

I guess it is basically a question between level of security and scalability vs resources (i.e. enough RAM). If we want to guarantee certain level of security and scalability maybe there is a minimum amount memory/resources we need to meet. Less than that amount of resources makes infeasible that security requirements.

> 
> I'm a big fan of ECC, and my mote platform of choice has 72kB of RAM, so I'm eager to see a good PKI-for-motes standard emerge.  But I'm not sure that we should make it a MUST that all motes have enough RAM for PKI.

Perhaps we do not need all the functions assumed to a complete PKI.

My 0.02 cents.

>> The answer may be too small for our use, but it can not be zero.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Jun 2013 15:00:38 +0000

Hello Jonathan:

On top of Yoshi's answers, please see inline

[] Yes, the wording is probably ill chosen. WiHART and ISA100.11a have successfully demonstrated the feasibility and value of the TSCH technique.
The idea is that 6TSCH will build on that knowledge to provide an open standard suite of protocols closely following the same principles...

"Following Metcalf's law..."
Not only is it not clear what point is being made, Metcalf's law measures "utility" in connections.  For a networked sensor device, there are likely a finite number of consumers of its data, and the total number of nodes is an irrelevant utility metric. Additionally, in terms of mesh connectivity, in general there is little additional utility to having 1000 neighbors (which may be more than the node can store) over 100, and perhaps 100 over 10 provided there is sufficient connectivity for the network to function.
[] And here I respectfully disagree; 6TSCH brings 2 things: 1) better guarantees (deterministic) for a network of limited size under the control of a PCE and for that piece I'm entirely with you but also 2) better scalability for applications such as monitoring using distributed routing (RPL). For the latter, size definitely matters. Take rust monitoring, intrusion detection, etc, one may want to deploy a large number of devices with very low reporting rate. The number of connected devices and the fact that we can correlate inputs from multiple parties, all this augments the value of the network, though maybe not by the square since the idea came from any to any communication. This does not mean that the network is very dense and/or that nodes will need to neighbor with tons of one hop devices. But sometimes brute force has value. I'm curious what Kris had in mind with the idea of sensor dust...

Cheers,

Pascal

General

Regards,
Yoshihiro Ohba

---

From: Kris Pister <[email-masked]>
Date: Fri, 28 Jun 2013 10:12:59 -0700

Michael -
  I'm not an expert on security, so I may not have used the term 
properly.  My understanding of Ohba-san's draft was that it included 
certificates.  I thought that having certificates implied the "I" part.

ksjp