Subject: [6tisch-security] EAP-TLS

From: Jonathan Simon <[email-masked]>
Date: Mon, 31 Mar 2014 11:25:37 -0700

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) 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]

**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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 31 Mar 2014 18:30:01 +0000

Hello Jonathan:

Thanks for this! Certainly does not look promising, and gives us a better outlook on what our constraints are.
OTOH, I understand that DICE is working on a lighter DTLS, which hopefully would better fit in constrained devices.
It will be interesting to run the exact same computation on their proposal;

Pascal

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: lundi 31 mars 2014 20:26
To: [email-masked]
Subject: [6tisch-security] EAP-TLS

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.

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

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

---

From: Rene Struik <[email-masked]>
Date: Mon, 31 Mar 2014 15:08:47 -0400

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.
>
> .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 
> packets (3 in each direction for mutual authentication).
> 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.
>
> 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
> [email-masked] <mailto:[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.
>
>
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

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