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

[peter van der Stok <[e-mail]>]

Hi Yoshira Ohba,

I changed the phrasing in <new-2>. Is this better?
see below

Peter

[e-mail] schreef op 2015-01-09 13:23:
> 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
> 

> 
> 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-2>
> 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]. Wi-SUN
> HAN (Home Area Network) uses EAP-PSK [RFC4764], which also looks 
> promising for  building control 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-2>
> 
>> 
>>  -------- 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