Subject: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security call

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Mar 2014 09:51:58 -0400

I want to start the discussion with Jonathan's message.
I'd like some clear opinions about whether you want to do layer-2
provisioning using a protocol which is common with the application target
(i.e. CoAP over DTLS).
Or whether one wants to use a layer-2 specification which is already to some
extend (ZigbeeIP) "out there" -- but which may have significant code impact.

Some would like to see 1x rather than PANA as the layer-2.5.

Subject: Re: 2014-03-17: 6tisch security call
From: Jonathan Simon <[email-masked]>
To: [email-masked]
Cc: [email-masked], Thomas Watteyne <[email-masked]>, Michael Richardson <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 17 Mar 2014 11:19:45 -0700

WirelessHART does not have a separate provisioning network. It does have two separate endpoint secure transport sessions - one for network management (PCE) that is set up immediately, and a separate one for data.  The data session can be delayed until the joining device is checked against an access control list or blacklist - this is referred to as “quarantine” in the HART spec.   HART also uses a “proxy” node to handle routing, since the joining node lacks route information when it joins.  To join, the new node synchronizes to a beacon, then sends in information about itself and discovered neighbors, encrypted with its shared key.  The manager decrypts this and sends a response including a runtime session key, again encrypted with the shared key. They then switch to using the session security.

I had envisioned something similar for centrally managed in 6TiSCH, but with PK.  The beaconing node would proxy the PCE certificate. Joining nodes would get the certificate at L2, and check it against a vendor or site cert (a la M. Behringer), and then send in an L4 join request encrypted with the PCEs public key. The PCE would respond with runtime session info, encrypted with the node’s public key.   Using a highly elided X509 cert (only has key and signature), this exchange takes 2 messages in the upstream direction, and 2 L2 messages to get the PCE’s cert. 

-- 
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 Mar 17, 2014, at 10:40 AM, [email-masked] wrote:

> Does WirelessHART model requires a separate provisioning network?  If so, it can be a deployment issue.
>  
> I do agree that Rene¡¯s bottom up approach is needed to fully understand the problem space, and I would like to contribute to such efforts.
>  
> Yoshihiro Ohba
>  
>  
> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Tuesday, March 18, 2014 12:28 AM
> To: Thomas Watteyne
> Cc: Michael Richardson; Rene Struik; Tom Phinney; Patrick Wetterwald (pwetterw); Maik Seewald (maseewal); Subir Das; ohba yoshihiro(´óˆ xÑó ¡ð£Ò£Ä£Ã¡õ£Î£Ó£Ì); Michael Behringer (mbehring); Jonathan Simon ([email-masked]); Paul Duffy (paduffy); Giuseppe Piro; Nancy Cam-Winget (ncamwing); Hank Mauldin (hmauldin)
> Subject: RE: 2014-03-17: 6tisch security call
>  
> Hello Thomas:
>  
> I do agree with the desire to stick to simple model ala WirelessHART. At the same time, some flows will have to be mapped to IETF, and Michael¡¯s flow 2 at the 6TiSCH meeting was about mapping to RPL flows.
> I was indicating that mapping onto to the necessary ND registration flows would save round trips and be a better match than RPL.
> In any fashion, I tend to agree with Ren¨¦ that the bottom up approach in solution space is good work but not sufficient.
> Seems to me that we have not yet figured the whole problem space, usage scenarios, and  requirements from scalability and constrained devices/ medium.
> This needs to be documented somewhere, together with the support in existing standards as examples on how things can be done with which expected security properties and hardware requirements.
>  
> Cheers,
>  
> Pascal
>  
> From: Thomas Watteyne [mailto:[email-masked]] 
> Sent: dimanche 16 mars 2014 23:17
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; Rene Struik; Tom Phinney; Patrick Wetterwald (pwetterw); Maik Seewald (maseewal); Subir Das; Yoshihiro Ohba ([email-masked]); Michael Behringer (mbehring); Jonathan Simon ([email-masked]); Paul Duffy (paduffy); Giuseppe Piro; Nancy Cam-Winget (ncamwing)
> Subject: Re: 2014-03-17: 6tisch security call
>  
> Thanks a millin for coordinating this effort Michael. The schedule works for me.
>  
> I believe we now have very clear options (thanks for presenting those in London). 
>  
> I strongly believe in the simplicity as very well proven track record of the WirelessHART approach. Let's keep it as simple as possible and not introduce dependencies on RPL and/or ND. Looking forward to hearing more about your private discussions, and discussing this next Monday.
>  
> Hello from SFO.
>  
> Thomas
> 
> On Sunday, March 16, 2014, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Works for me!
> 
> Thanks Michael (adding Nancy)
> 
> Pascal
> 
> > Le 16 mars 2014 ¨¤ 20:44, "Michael Richardson" <[email-masked]> a ¨¦crit :
> >
> >
> > 1) I've asked the IETF secretariat for a mailing list for 6tisch security
> >   discussion.
> >   There are perhaps people on this CC who are missing.
> >
> > 2) is there a liason to 802.15.9 among us?  I understand that 15.9 has
> >   renewed vigor, and is on it's way to define a 1x mechanism over 15.4*.
> >   I think that this may be preferable to PANA, so I'd like to hear more.
> >
> > 3) Pascal and I have discussed a way initialize the WirelessHART-like
> >   mechanism using efficient-ND rather than RPL DIO, and this needs
> >   to be researched and written up.
> >
> > 4) my understanding is that the IEEE 802.1AR vendor certificates are
> >   being very successfully deployed by VoIP providers.  This is a real
> >   and live mechanism, supported by a number of PKI suppliers.  My
> >   understanding is that this will be the right size for most industrial
> >   uses, but simply will not work at the home level. That's okay, 6tisch
> >   is not targetted initially a unmanaged homes.
> >
> > ====
> >
> > I'd like to cancel the 2014-03-17 call, and do a call on the 24th, and
> > then April 7th, 14th. The 21st is a holiday for many, so we skip that.
> > By the 21st, I'd like to have a document that, while it may have
> > controversial and/or undecided pieces, the pieces should be understood by
> > all.   By the 28th, I'd like to have a discussion to resolve whatever
> > issues may still exist.
> >
> > How does this work?
> >
> > --
> > Michael Richardson <[email-masked]>, Sandelman Software Works
> > -= IPv6 IoT consulting for hire =-
> >
> >
> >
> 
> 
> --
> Thomas Watteyne, Ph. D
> Sr. Networking Design Engineer
> Linear Technology, Dust Networks Product Group
> 30695 Huntwood Ave
> Hayward, CA 94544-7021
> +1 (510) 400-2978
> [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-2978, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 24 Mar 2014 11:05:01 +0000

Sorry, while the US has switched to daylight saving and Europe not yet, I have an overlap, and can't make today. Next week it's okay again...
Michael

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 20 March 2014 14:52
To: [email-masked]
Subject: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security call

I want to start the discussion with Jonathan's message.
I'd like some clear opinions about whether you want to do layer-2 provisioning using a protocol which is common with the application target (i.e. CoAP over DTLS).
Or whether one wants to use a layer-2 specification which is already to some extend (ZigbeeIP) "out there" -- but which may have significant code impact.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 09:49:56 -0400

The URL to access is:
  https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

I'm at +1 613 276-6809, IM: [email-masked] or [email-masked],
if you need more than that to get in.

To remind two things:
  1) the Note Well applies.
  2) the call is being recorded.
  3) the list is being archived.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 10:00:18 -0400

please join the notes at:
  http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security?useMonospaceFont=true

---

From: <[email-masked]>
Date: Mon, 24 Mar 2014 15:27:06 +0000

During today's call, I mentioned support for both certificate-based authentication and pre-shared key based authentication to allow the widest deployment of 6tisch, and EAP fits to support both types of credentials.

I know that CoAP/DTLS can also support both types of credentials.  However, another advantage of supporting EAP is that it allows us to make use of existing AAA (authentication, authorization and accounting) infrastructure via RADIUS.  Use of CoAP/DTLS would need more protocol extension work on both DTLS/CoAP and RADIUS for interfacing with AAA, and this protocol impact should be considered when choosing a solution or solutions for 6tisch security.

Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, March 24, 2014 11:00 PM
To: [email-masked]
Subject: [6tisch-security] 2014-03-24: 6tisch security call - etherpad

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 24 Mar 2014 15:41:04 +0000

Sorry for not being able to join today's call. 

Regarding the CoAP vs EAP discussion, has anyone written down in a table format what the differences, pros and cons of each are? I'm starting to make that table in my head to be able to follow this discussion, but it strikes me that probably someone better than me has already done that :-) 

Michael

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 24 March 2014 16:27
To: [email-masked]; [email-masked]
Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad

Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, March 24, 2014 11:00 PM
To: [email-masked]
Subject: [6tisch-security] 2014-03-24: 6tisch security call - etherpad

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 12:32:12 -0400

<[email-masked]> wrote:
    > During today's call, I mentioned support for both certificate-based
    > authentication and pre-shared key based authentication to allow the
    > widest deployment of 6tisch, and EAP fits to support both types of
    > credentials.

Yes, but there are several ways that EAP can do this.
There are some non-TLS methods that can use PSKs, and there are PSK methods
that use TLS.  I assume we want the latter!
Ditto DTLS...

The PSK poses significant scaling and lifecycle problems.

    > I know that CoAP/DTLS can also support both types of credentials.
    > However, another advantage of supporting EAP is that it allows us to
    > make use of existing AAA (authentication, authorization and accounting)
    > infrastructure via RADIUS.  Use of CoAP/DTLS would need more protocol
    > extension work on both DTLS/CoAP and RADIUS for interfacing with AAA,
    > and this protocol impact should be considered when choosing a solution
    > or solutions for 6tisch security.

Should we go with an ESP-TLS solution, one of things that we need to specify
is how that bootstrap results in an introduction between the mote and an
(ACE-inspired) authorization server.   That authorization server would have
"super-user" on the mote, and be able to create new trust relationships
appropriate for the PCE (if there is one), and whatever applications exist.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Mar 2014 12:10:01 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > Regarding the CoAP vs EAP discussion, has anyone written down in a
    > table format what the differences, pros and cons of each are? I'm
    > starting to make that table in my head to be able to follow this
    > discussion, but it strikes me that probably someone better than me has
    > already done that :-)