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

peter van der Stok <stokcons@xs4all.nl> Mon, 05 January 2015 09:20 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 5D59A1A3B9C for <roll@ietfa.amsl.com>; Mon, 5 Jan 2015 01:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.15
X-Spam-Level: *
X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RPGLNnI8u8Jp for <roll@ietfa.amsl.com>; Mon, 5 Jan 2015 01:20:38 -0800 (PST)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBAD1A212D for <roll@ietf.org>; Mon, 5 Jan 2015 01:20:38 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id c9Lb1p0034Hiz6i019Lba5; Mon, 05 Jan 2015 10:20:36 +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, 05 Jan 2015 10:20:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 05 Jan 2015 10:20:35 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: "Kumar, Sandeep" <sandeep.kumar@philips.com>, roll@ietf.org, Michael Richardson <mcr@sandelman.ca>, anders Brandt <anders_Brandt@sigmadesigns.com>, emmanuel baccelli <emmanuel.baccelli@inria.fr>, yoshihiro.ohba@toshiba.co.jp, robert cragie <robert.cragie@gridmerge.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <rkrc26a5s31jxibbjxa0udwj.1419006023304@email.android.com>
References: <f7fb6260cd8b6f260ac3a2091df64cab@xs4all.nl> <rkrc26a5s31jxibbjxa0udwj.1419006023304@email.android.com>
Message-ID: <1c811f02f91bb4d3fa29ea58c90dbc4b@xs4all.nl>
X-Sender: stokcons@xs4all.nl (AV78m+eKgNUMQGkvlO3zQiWOyvp/kh+D)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/OM-r6OktfEhW0aVPJ1l6BYJR_vI
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, 05 Jan 2015 09:20:41 -0000

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: <yoshihiro.ohba@toshiba.co.jp>
>  Ontvanger: <consultancy@vanderstok.org>, <roll@ietf.org>,
>  <mcr+ietf@sandelman.ca>
>  Kopie: <mcr@sandelman.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