Re: [Roll] home-building-requirements section 7.1

[<[e-mail]>]

Hi Peter

Thank you for the new text.  I have one comment:

The following sentence is incorrect because EAP-PSK is used for Wi-SUN HAN (Home Area Network) not building control. 

"For building control EAP-PSK [RFC4764] is the most suitable approach at this moment."

Since Wi-SUN HAN is mostly specific to Japanese HAN use case, I do not mind removing the sentence.

Thanks,
Yoshihiro Ohba


-----Original Message-----
From: peter van der Stok [mailto:[e-mail]] 
Sent: Monday, January 5, 2015 6:21 PM
To: Kumar, Sandeep; [e-mail]; Michael Richardson; anders Brandt; emmanuel baccelli; ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); robert cragie
Subject: RE: RE: [Roll] home-building-requirements section 7.1

I made some new text for section 7.1. below

Suggestions for improvement will be appreciated,

Peter

<OLD 006>
At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access
(PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] provides a framework for network access and delivery of common link keys.
New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. Other initiatives are likely to emerge in the context of minimal intervention configuration. At this moment it is not clear what the final most widely deployed solution will be.
</OLD 006>

<NEW>
At initial deployment the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. The Protocol for carrying Authentication for Network Access
(PANA) [RFC5191] with an Extensible Authentication Protocol (EAP) provides a framework for network access and delivery of common link keys. Several versions of EAP exist. ZigBee specifies the use of EAP-TLS [RFC5216]. For building control EAP-PSK [RFC4764] is the most suitable approach at this moment.

New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only. Other initiatives are likely to emerge in the context of minimal intervention configuration.
</NEW>

> 
>  -------- Oorspronkelijke bericht --------
>  Onderwerp: RE: [Roll] home-building-requirements section 7.1
>  Datum: 2014-12-11 00:24
>  Afzender: <[e-mail]>
>  Ontvanger: <[e-mail]>, <[e-mail]>,  
> <[e-mail]>
>  Kopie: <[e-mail]>, <[e-mail]>
> 
>  It depends on the requirements on the target system. If the target  
> system is formed in a totally ad-hoc fashon, then the joining order is  
> not determined by network topology.
> 
>  But in home and building networks where some a central management 
> entity  typically exists, there will be a connectivity issue if the 
> joining  order is not determined by network topology. In such a 
> managed network,  the application in a node should be ready to work 
> when the node  successfully connected to the network, which happens 
> when the node  successfully connected to its neighbor that is 
> "already" connected to
> 
>  the network (that's why joining order comes).
> 
>  Having said that I think it is OK to mention PANA in section 7.1. For
> 
>  EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for  
> Wi-SUN HAN, AFAIK. On the other hand, I do not mind having DTLS-relay
> 
>  and ongoing 6tisch security work.
> 
>  Regards,
>  Yoshihiro Ohba
> 
>  -----Original Message-----
>  From: Roll [mailto:[e-mail]] On Behalf Of peter van der  
> Stok
>  Sent: Tuesday, December 9, 2014 4:56 PM
>  To: Michael Richardson
>  Cc: [e-mail]; [e-mail]; Anders Brandt
>  Subject: Re: [Roll] home-building-requirements section 7.1
> 
>  Probably we are not going the EAP-PANA route because EAP PANA imposes 
> an  order of joining determined by the network topology.
>  Today, that order will not, cannot, is unlikely to, be respected by 
> the  installation protocol.
> 
>  Consequently, I like to keep the uncertainty in the document.
> 
>  Michael Richardson schreef op 2014-12-08 19:47:
>  > You ask: > What are enrollment tools?
>  >
>  > By this, I mean that the combination of protocols and/or 
> provisioning  > equipment that allows an installer to make a lightbulb 
> join a  > particular network.
>  >
>  > That's why I want to know, if you are going the EAP-PANA route, 
> that  > one needs to know what EAP methods ought to be supported.
>  >
>  >
>  > peter van der Stok <[e-mail]> wrote:
>  > > thanks for the encouragement.
>  > > Concerning bootstrap and security in general. Many things are  > 
> going on and  > > there are two approaches to this document:
>  > > 1) a conservative one; restrict to what exists and is is proven  
> > to work  > > 2) leaving the doubt that exists today.
>  >
>  > > For the moment I like to leave the doubt, because in 5 years,  > 
> what is sure  > > today will not be implemented is my conviction  >  > 
> > Concerning switching on/off:
>  > > That is SDO stuff; KNX , BACnet , etc... are preparing  > 
> additional standards.
>  >
>  > > What are enrollment tools?
>  >
>  > > Peter
>  >
>  >
>  > > Michael Richardson schreef op 2014-11-23 22:16:
>  > >> I am very pleased with the document; I hope the WG is reading  > 
> it, and is  > >> also happy with it.
>  > >>
>  > >> In secton 7.1 you mention use of PANA to secure new nodes.
>  > >> The reference seems very hesistant, and the DTLS relay is just  
> > kind of  > >> thrown in. Can you make this recommendation more 
> concrete? Or  > remove it.
>  > >>
>  > >> If it's PANA, I assume EAP is involved, and so what what EAP  > 
> methods should  > >> be used?
>  > >>
>  > >> I think that, having read this document, I ought to be able to  
> > create a  > >> light-bulb or light switch --- I think that I can 
> make it  > function in the  > >> network, but I don't think it will 
> use the same enrollment  > tools at all,  > >> and  > >> I'd sure like 
> to change that. I don't mind being really really  > specific  > >> 
> here: I encourage it.
>  > >>
>  > >> I also don't know what protocol to use for turning lights  > 
> on/off, but I  > >> acknowledge that is out of scope for the ROLL WG 
> to specify.
>  > Perhaps there
>  > >> is an informative reference I missed.
>  > >>
>  > >> I think that unless you have a specific way to use the DTLS  > 
> relay, you  > >> should  > >> remove the reference -- it doesn't help 
> anyone trying to  > implement an  > >> interoperable device.
> 
>  _______________________________________________
>  Roll mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/roll [1]
> 
> -------------------------
>  The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original 
> message.
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/roll