Subject: Re: [6tisch-security] EAP-TLS

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Apr 2014 10:07:47 -0400

Thank you for this calculation!

Jonathan Simon <[email-masked]> wrote:
    > Note that the EAP-TLS spec (RFC 5216) says that
    > TLS_RSA_WITH_3DES_EDE_CBC_SHA 
    > is required and lists 3 recommended cipher suites, in addition to the
    > one we’ll 

I think that this could be mutable, so do the calculation with ECDSA and
AES-GCM.  MUST support != MUST use.  What does Zigbee IP use?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Apr 2014 10:09:05 -0400

Rene Struik <[email-masked]> wrote:
    > In your back-of-the-envelope calculation, you seem to assume that joining
    > protocols need to be carried out serially (you mentioned joining node can
    > exchange 1 packet/s, or 10 nodes at 1 packed/10s). Couldn't one
    > conceivably execute these in parallel as well?

No, because there isn't any bandwidth on the network left.

---

From: Paul Duffy <[email-masked]>
Date: Tue, 01 Apr 2014 10:17:46 -0400

On 4/1/2014 10:07 AM, Michael Richardson wrote:
>      > one we'll

TLS_PSK_WITH_AES_128_CCM_8 and
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

>
>
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Rene Struik <[email-masked]>
Date: Tue, 01 Apr 2014 10:21:01 -0400

Hi Michael:

I think you are jumping to conclusions here (to me it is not clear 
whether this may be an artifact of using a centralized time scheduling 
algorithm).

Rene

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

---

From: Paul Duffy <[email-masked]>
Date: Tue, 01 Apr 2014 10:49:13 -0400

And let me underline that RSA and 3DES are not practical for constrained 
devices (compute nor bandwidth).

On 4/1/2014 10:17 AM, Paul Duffy wrote:
>> Jonathan Simon<[email-masked]>  wrote:

---

From: <[email-masked]>
Date: Tue, 1 Apr 2014 17:01:47 +0000

If the problem is due to the minimum draft with 5 slots/s availability, we can have more slots for the minimum profile.  I really think that the minimum number of slots should be a configurable parameter.

Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, April 1, 2014 11:09 PM
To: Rene Struik
Cc: Jonathan Simon; [email-masked]
Subject: Re: [6tisch-security] EAP-TLS

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 5 Apr 2014 13:16:59 -0700

Yoshiro,
+1, I also believe that the minimal draft should be somewhat relaxed, and
provide at least the option of moving away from the 101 slot slotframe with
5 communication slots. I believe the minimal draft will, however, stick
with one rule: the schedule is the same for all nodes and never updated.
There are plenty of mechanisms being worked on for dynamic scheduling, but
the solution proposed by the minimal draft needs to stay, well, minimal.
Regardless, I believe Jonathan's point is that we should be very aware of
the communication implications of the security handshake at join time
(nothing new).

Michael,
Can you confirm that we will have a call on Monday? I assume we will be
discussing this thread?

Thomas

On Tue, Apr 1, 2014 at 10:01 AM, <[email-masked]> wrote:

> If the problem is due to the minimum draft with 5 slots/s availability, we
> can have more slots for the minimum profile.  I really think that the
> minimum number of slots should be a configurable parameter.
>
> Yoshihiro Ohba
>
>

---

From: Rene Struik <[email-masked]>
Date: Mon, 07 Apr 2014 11:16:08 -0400

Dear colleagues:

At the 6TiSCH security conf call, it was suggested that pre-allocating 
dedicated bandwidth(by using flow separation [or, in my words, different 
colors for different type of traffic]) to facilitate the joining process 
would have some merit. I presume this relates to limiting DoS attacks, 
but may have missed something here.

It would help to contrast features of dedicated bandwidth vs. not having 
this. Right now, I do not understand how this would exactly help, while 
I do certainly understand how this forces very sparsely sprinkled 
pre-allocated bandwidth over time (so as not to take away too much 
bandwidth for ordinary operational use). In other words: what are pros 
and cons compared to having join messages just appear as part of 
ordinary traffic flows (where only distinction is on how devices process 
these and whether/how these act on those).

Any more details appreciated.

Best regards, Rene

On 3/31/2014 3:08 PM, Rene Struik wrote:
> Hi Jonathan:
>
> From your note below it is clear that communication latency is a true 
> killer.
>
> In your back-of-the-envelope calculation, you seem to assume that 
> joining protocols need to be carried out serially (you mentioned 
> joining node can exchange 1 packet/s, or 10 nodes at 1 packed/10s). 
> Couldn't one conceivably execute these in parallel as well?
>
> No matter how many smart things one does to compress joining protocol 
> messages, one needs at least three message flows (in practice: four) 
> to obtain a key agreement protocol with the right set of security 
> properties. So, that provides a lower bound.
>
> This also illustrates that the details of the communication channel 
> (viz. 802.15.4e and TSCH) do matter in higher-layer protocol design 
> considerations (nothing new here, but worth pointing out nevertheless).
>
> For some related email traffic on this topic, see our email exchange 
> of February 4, 2014 on the general 6tisch list:
> http://www.ietf.org/mail-archive/web/6tisch/current/msg01782.html
> (At the time, I suggest that scheduling of joining protocol slots 
> deserves lots of attention.)
>
> Best regards, Rene
>
> On 3/31/2014 2:25 PM, Jonathan Simon wrote:
>> Since the last call focused a lot on EAP-TLS, I did a thought 
>> experiment. I am not an expert on this, so I may have parts wrong...
>>
>> I am assuming the minimal draft bandwidth, which is 5 slots/s.  Each 
>> slot can contain about 100 bytes of useable data after MAC headers. 
>>  Since the node will be contending with other nodes, there are about 
>> 1.5 slots/s of useable BW before collapse, so I'll call this 1 
>> packet/s.  Lets assume that the joining nodes can stay synchronized 
>> at no packet cost - i.e. they know when the beacons are coming and 
>> use them to stay synchronized. Note that the beacon schedule is not 
>> communicated in the beacon, only the slots for sending and getting 
>> packets, so this requires either a lot of time in rx or some 
>> pre-shared knowledge of schedule.
>>
>> So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 
>> s.  Later on this will be happening in parallel as more nodes join, 
>> but 10 children at a time per beaconing node seems a reasonable 
>> number for a moderately dense network.
>>
>> In order to get access to the network, the transactions go something 
>> like this:
>>
>> (supplicant)    (authenticator)
>> EAP start ->
>> <- EAP request identity
>> EAP response identity ->
>> <-TLS start
>>  TLS client hello ->
>> <- TLS hello, request cert , etc.
>> TLS response cert ->
>> <- TLS change cipher
>> TLS response ->
>> ..... some time later....
>> <- EAP success
>>
>> So 5 packets to get things started...
>> .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 
>> 6 packets (3 in each direction for mutual authentication).
>> ...add another couple of packets for deriving the session key.
>> .. a few more for agreeing on cipher suite and cleanup.
>>
>> At this point the PCE will be able to send a couple packets to 
>> configure things with CoAP, after which the node can start the 
>> process again for the next hop.
>>
>> So call it 170 s per hop.  That's 1/2 an hour to form a 10 hop, 100 
>> node network. Not great.
>>
>> Note that the EAP-TLS spec (RFC 5216 
>> <http://tools.ietf.org/html/rfc5216>) says that 
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA is _required_ and lists 3 recommended 
>> cipher suites, in addition to the one we'll probably want to use for 
>> DTLS later.  I'm assuming a minimum 2048-bit key for RSA - that's 10+ 
>> packets each way if we use in place of ECDSA above.   If we don't use 
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to support 
>> it to be compliant, no?
>> -- 
>> 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]>
>>
>> **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.
>>
>>
>>
> email:[email-masked]  | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Mon, 07 Apr 2014 11:33:34 -0400

BTW - I am primarily looking for rationale in terms of communication cost.

For simplicity, let us for now presume energy cost of locally performed 
crypto computations can be ignored (i.e., presumed negligible compared 
to communication cost).

On 4/7/2014 11:16 AM, Rene Struik wrote:
> dedicated bandwidth(by using flow separation [or, in my words, 
> different colors for different type of traffic]) to facilitate the 
> joining process would have some merit. I presume this relates to 
> limiting DoS attacks, but may have missed something here.
>
> It would help to contrast features of dedicated bandwidth vs. not 
> having this. Right now, I do not understand how this would exactly 
> help, while I do certainly understand how this forces very sparsely 
> sprinkled pre-allocated bandwidth over time (so as not to take away 
> too much bandwidth for ordinary operational use). In other words: what 
> are pros and cons compared to having join messages just appear as part 
> of ordinary traffic flows (where only distinction is on how devices 
> process these and whether/how these act on those).
>
>>> So a joining node can exchange 1 packet/s, or 10 nodes at 1 
>>> packet/10 s.  Later on this will be happening in parallel as more 
>>> nodes join, but 10 children at a time per beaconing node seems a 
>>> reasonable number for a moderately dense network.
>>>
>>> DTLS later.  I'm assuming a minimum 2048-bit key for RSA - that's 
>>> 10+ packets each way if we use in place of ECDSA above.   If we 
>>> don't use TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code 
>>> to support it to be compliant, no?
>>> -- 
>>> Jonathan Simon, Ph. D
>>> 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

---

From: Jonathan Simon <[email-masked]>
Date: Mon, 7 Apr 2014 11:42:25 -0700

I think co-mingled joining and data flows is a perceived weakness of WirelessHART, but the effect there is limited since the link key for joining slots differs from that used in general communication, so an attacker can act as a link-layer jammer, or infrequently (relative to data flows) inject a join request. Franky, it’s a lot easier to just jam the band if you want to disrupt a network.
-- 
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. 

On Apr 7, 2014, at 8:16 AM, Rene Struik <[email-masked]> wrote:

> Dear colleagues:
> 
> At the 6TiSCH security conf call, it was suggested that pre-allocating dedicated bandwidth(by using flow separation [or, in my words, different colors for different type of traffic]) to facilitate the joining process would have some merit. I presume this relates to limiting DoS attacks, but may have missed something here.
> 
> It would help to contrast features of dedicated bandwidth vs. not having this. Right now, I do not understand how this would exactly help, while I do certainly understand how this forces very sparsely sprinkled pre-allocated bandwidth over time (so as not to take away too much bandwidth for ordinary operational use). In other words: what are pros and cons compared to having join messages just appear as part of ordinary traffic flows (where only distinction is on how devices process these and whether/how these act on those).
> 
>> From your note below it is clear that communication latency is a true killer.
>> 
>> In your back-of-the-envelope calculation, you seem to assume that joining protocols need to be carried out serially (you mentioned joining node can exchange 1 packet/s, or 10 nodes at 1 packed/10s). Couldn't one conceivably execute these in parallel as well?
>> 
>> No matter how many smart things one does to compress joining protocol messages, one needs at least three message flows (in practice: four) to obtain a key agreement protocol with the right set of security properties. So, that provides a lower bound.
>> 
>> This also illustrates that the details of the communication channel (viz. 802.15.4e and TSCH) do matter in higher-layer protocol design considerations (nothing new here, but worth pointing out nevertheless).
>> 
>> For some related email traffic on this topic, see our email exchange of February 4, 2014 on the general 6tisch list:
>> (At the time, I suggest that scheduling of joining protocol slots deserves lots of attention.)
>> 
>> Best regards, Rene
>> 
>>> Since the last call focused a lot on EAP-TLS, I did a thought experiment. I am not an expert on this, so I may have parts wrong… 
>>> 
>>> I am assuming the minimal draft bandwidth, which is 5 slots/s.  Each slot can contain about 100 bytes of useable data after MAC headers.  Since the node will be contending with other nodes, there are about 1.5 slots/s of useable BW before collapse, so I’ll call this 1 packet/s.  Lets assume that the joining nodes can stay synchronized at no packet cost - i.e. they know when the beacons are coming and use them to stay synchronized. Note that the beacon schedule is not communicated in the beacon, only the slots for sending and getting packets, so this requires either a lot of time in rx or some pre-shared knowledge of schedule. 
>>> 
>>> So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 s.  Later on this will be happening in parallel as more nodes join, but 10 children at a time per beaconing node seems a reasonable number for a moderately dense network. 
>>> 
>>> In order to get access to the network, the transactions go something like this:
>>> 
>>> ….. some time later….
>>> .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 packets (3 in each direction for mutual authentication). 
>>> …add another couple of packets for deriving the session key. 
>>> At this point the PCE will be able to send a couple packets to configure things with CoAP, after which the node can start the process again for the next hop.
>>> 
>>> So call it 170 s per hop.  That’s 1/2 an hour to form a 10 hop, 100 node network. Not great.
>>> 
>>> Note that the EAP-TLS spec (RFC 5216) says that TLS_RSA_WITH_3DES_EDE_CBC_SHA is required and lists 3 recommended cipher suites, in addition to the one we’ll probably want to use for DTLS later.  I’m assuming a minimum 2048-bit key for RSA - that’s 10+ packets each way if we use in place of ECDSA above.   If we don’t use TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to support it to be compliant, no?
>>> -- 
>>> Jonathan Simon, Ph. D
>>> [email-masked]
>>>  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. 
>>> 
>>> 
>>> 
> http://cp.mcafee.com/d/k-Kr3wUSyOqen7DChPMUTsSyUepjdEK3CnPqbwUQsEFICzASUYYYUNuVIhF9mI0kva7X7BPpYEvIundWMzpdxB_HYyMqenbZuVtdBNDASrIKsJteOaqJT7-l3PWApmU6CQjq9K_8I9LfzAm4PhOrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4OZfIT6kONJOsGm9BWvpKcFByV2Hsbvg5i-rL00jqr3b3NIQJKjBiNcLjXdNBcIqnjh0qa5EREq8dwwq8blxgQgltd42QvbWuvmSPZ0Qg2dpgd413o8698j9CyAQg0LQzh0d20mbwAaz1IsedYvid

---

From: Rene Struik <[email-masked]>
Date: Mon, 07 Apr 2014 15:41:44 -0400

Hi Jonathan:

Thanks for your note. If w/HART uses different keys for different 
purposes, this is the same as using different colors for different types 
of traffic and, thereby, another mechanism for instantiating flow 
separation (no matter whether keys are secret or not). So, in that 
respect w/HART's co-mingling of joining and data flows is only 
co-mingling in theory, not in practice.

The "perceived weakness" you mentioned seems to have to do with 
forwarding traffic to a centralized server (due to not having a local 
decision point in w/HART re authentication).

The advantage of using logical separation, rather than pre-allocating 
bandwidth, seems to be that one does not unnecessarily waste bandwidth 
if "joining bandwidth" is not used and "other bandwidth" is in short 
supply. Obviously, in real life one may wish to put a cap on traffic 
with the "joining color" (or, fine-tune caps depending on authorization 
negatives).

BTW - this logical partitioning also happens in networks where ordinary, 
operational traffic is secured and where initial joining traffic (prior 
to the joining node and the representative of the network one 
communicates with having a shared key) is unsecured.

Rene

==

On 4/7/2014 2:42 PM, Jonathan Simon wrote:
> I think co-mingled joining and data flows is a perceived weakness of 
> WirelessHART, but the effect there is limited since the link key for 
> joining slots differs from that used in general communication, so an 
> attacker can act as a link-layer jammer, or infrequently (relative to 
> data flows) inject a join request. Franky, it’s a lot easier to just 
> jam the band if you want to disrupt a network.
> -- 
> Jonathan Simon, Ph. D
> original transmission and its attachments without reading or saving in 
> any manner. Thank you.
>
> On Apr 7, 2014, at 8:16 AM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Dear colleagues:
>>
>> At the 6TiSCH security conf call, it was suggested that 
>> pre-allocating dedicated bandwidth(by using flow separation [or, in 
>> my words, different colors for different type of traffic]) to 
>> facilitate the joining process would have some merit. I presume this 
>> relates to limiting DoS attacks, but may have missed something here.
>>
>> too much bandwidth for ordinary operational use). In other words: 
>> what are pros and cons compared to having join messages just appear 
>> as part of ordinary traffic flows (where only distinction is on how 
>> devices process these and whether/how these act on those).
>>
>>> No matter how many smart things one does to compress joining 
>>> protocol messages, one needs at least three message flows (in 
>>> practice: four) to obtain a key agreement protocol with the right 
>>> set of security properties. So, that provides a lower bound.
>>>
>>>> experiment. I am not an expert on this, so I may have parts wrong…
>>>>
>>>> I am assuming the minimal draft bandwidth, which is 5 slots/s. 
>>>>  Each slot can contain about 100 bytes of useable data after MAC 
>>>> headers.  Since the node will be contending with other nodes, there 
>>>> are about 1.5 slots/s of useable BW before collapse, so I’ll call 
>>>> this 1 packet/s.  Lets assume that the joining nodes can stay 
>>>> synchronized at no packet cost - i.e. they know when the beacons 
>>>> are coming and use them to stay synchronized. Note that the beacon 
>>>> schedule is not communicated in the beacon, only the slots for 
>>>> sending and getting packets, so this requires either a lot of time 
>>>> in rx or some pre-shared knowledge of schedule.
>>>>
>>>> .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at 
>>>> least 6 packets (3 in each direction for mutual authentication).
>>>> <http://cp.mcafee.com/d/k-Kr6zqb9EVsuup7f3ztPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTH2dAS6n-LOb1EVsLRXBQSn6ujpKOVORQX8FGTsvVkffGhBrwqrjdICXYyMCY-ehojd79KVI07eJjWtbVKY01M7p5SPWqbxJOsGm9BWvpKcFByV2Hsbvg5i-rL00jqr3b3NIQJKjBiNcLjXdNBcIqnjh0qa5EREq8dwwq8blxgQgltd42QvbWuvmSPZ0Qg2dpgd413o8698j9CyAQg0LQzh0d20mbwAaz1IsedXmUX>) 
>>>> says that TLS_RSA_WITH_3DES_EDE_CBC_SHA is _required_ and lists 3 
>>>> recommended cipher suites, in addition to the one we’ll probably 
>>>> want to use for DTLS later.  I’m assuming a minimum 2048-bit key 
>>>> for RSA - that’s 10+ packets each way if we use in place of ECDSA 
>>>> above.   If we don’t use TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still 
>>>> need tested code to support it to be compliant, no?
>>>> -- 
>>>> Jonathan Simon, Ph. D
>>>> 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.
>>>>
>>>>
>>>>
>> [email-masked] <mailto:[email-masked]>