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

peter van der Stok <stokcons@xs4all.nl> Mon, 12 January 2015 08:17 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932531A8A75 for <roll@ietfa.amsl.com>; Mon, 12 Jan 2015 00:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ehL-uleY-lV for <roll@ietfa.amsl.com>; Mon, 12 Jan 2015 00:17:34 -0800 (PST)
Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BD81A8A67 for <roll@ietf.org>; Mon, 12 Jan 2015 00:17:34 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud3.xs4all.net with ESMTP id ewHT1p00H4Hiz6i01wHTAn; Mon, 12 Jan 2015 09:17:29 +0100
Received: from AMontpellier-654-1-150-230.w90-0.abo.wanadoo.fr ([90.0.221.230]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Jan 2015 09:17:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Jan 2015 09:17:27 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: yoshihiro.ohba@toshiba.co.jp
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local>
References: <f7fb6260cd8b6f260ac3a2091df64cab@xs4all.nl> <rkrc26a5s31jxibbjxa0udwj.1419006023304@email.android.com> <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl> <674F70E5F2BE564CB06B6901FD3DD78B29D2DDDD@TGXML210.toshiba.local>
Message-ID: <83c4345653211a6d3bcac7a8e39a9696@xs4all.nl>
X-Sender: stokcons@xs4all.nl (3vwxqljoX35nDVFyuAftAyd9pzgASUBj)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/osK8aCSD00RKV79eRQzrdb6pCxA>
Cc: mcr@sandelman.ca, roll@ietf.org, sandeep.kumar@philips.com, anders_Brandt@sigmadesigns.com
Subject: Re: [Roll] home-building-requirements section 7.1
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 08:17:37 -0000

Hi Yoshira Ohba,

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

Peter

yoshihiro.ohba@toshiba.co.jp 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: <yoshihiro.ohba@toshiba.co.jp>
>>  Ontvanger: <consultancy@vanderstok.org>rg>, <roll@ietf.org>rg>,
>> <mcr+ietf@sandelman.ca>
>>  Kopie: <mcr@sandelman.ca>ca>, <abr@sdesigns.dk>
>> 
>>  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:roll-bounces@ietf.org] On Behalf Of peter van der
>> Stok
>>  Sent: Tuesday, December 9, 2014 4:56 PM
>>  To: Michael Richardson
>>  Cc: roll@ietf.org; mcr@sandelman.ca; 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 <stokcons@xs4all.nl> 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
>>  Roll@ietf.org
>>  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