Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things
Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 21 February 2015 11:44 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB91A6F12; Sat, 21 Feb 2015 03:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 iEUb9MZRwtMW; Sat, 21 Feb 2015 03:44:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA3C1A6F11; Sat, 21 Feb 2015 03:44:48 -0800 (PST)
Received: from [192.168.131.132] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M3i8r-1XYgJw2Iy1-00rJFr; Sat, 21 Feb 2015 12:44:29 +0100
Message-ID: <54E86F9A.8020104@gmx.net>
Date: Sat, 21 Feb 2015 12:44:26 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: consultancy@vanderstok.org, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <cf14f8df23dc2552f062976775e76549@xs4all.nl>
In-Reply-To: <cf14f8df23dc2552f062976775e76549@xs4all.nl>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Gqg86Uv725iahDLQicWAW3taVjFAausoO"
X-Provags-ID: V03:K0:+7T9JUNVIbli+P19R7yBd3/mH+P5lQ4Q6ASMRsDp+QKyt/exPIM opclHI0YbEMm4ShfX7yq8DP+rsj92xxWjh21iy7Zkg9BVYY2/oBeNZEknmTHuwjvnRF7AYn bXd5l+J+ziZoDkMyGHx+oAwJVulSb9aDHkYZlq02RkSQQB4pYrt+oiT1lJ9Jpnahii1LyKJ slb4Mez7LuRDr6Ql6E4zA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch-security/I9EVlWA43GXBHkiShl5qns5AyK8>
X-Mailman-Approved-At: Sun, 22 Feb 2015 09:49:40 -0800
Cc: 6tisch-security@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, "Hedanping (Ana)" <ana.hedanping@huawei.com>, robert.cragie@gridmerge.com, 6lo@ietf.org, anima@ietf.org
Subject: Re: [6tisch-security] [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2015 11:44:52 -0000
Peter, Brian, I would strongly recommend not to use the term bootstrapping. Replacing it with some other word that explains what you want to do. After-all, we are engineers and not marketing guys. I tend to get a bit nervous when I read terms like "zero-touch" and alike that create the impression that there is no configuration that needs to be done by anyone. Of course, that's not the case. With all the security drafts in NETCONF (zerotouch) or in ANIMA I get the impression that we are re-inventing the wheel not only because we want to work on new stuff but largely because we actually don't understand the state of the art ourselves anymore. I fear that the <draft-he-iot-security-bootstrapping-00> document also falls into the category of not understanding the state-of-the-art. I understand if someone is not up-to-speed with the most recent efforts in Thread (because they are only visible to members of that organization) but the ZigBee-IP work should be known. While ZigBee-IP may be considered dead by know it also appears to me that any new work in the IETF on security/routing/etc. for IEEE 802.15.4 will have to compete against Thread. Thread has seen a dramatic growth rate in terms of membership and so I doubt that work in the same area has a lot of chances for success. Sorry for the rant but I believe it will help everyone to figure out that most of the groups are actually developing the same solutions over and over again. Now to the issue of the multi-vendor equipment. Adding new solutions (as it is done in ANIMA) while other groups and organizations have already standardized similar technologies (using different terminology) will not make the interoperability any better. I am sure you know that far too well. It would be great to have a conversation (maybe at the next IETF meeting) how the different environments (home environment, enterprise environments/industrial environments) are different in terms of provisioning credentials and configuration information to IoT devices. Needless to say that there are differences and you can see them when you look at how existing products work. That does, however, not necessarily mean that there are no common building blocks. Ciao Hannes On 02/21/2015 12:14 PM, peter van der Stok wrote: > Hi Brian, > > Just a small annotation to your default approach comment. > Bootstrapping is subject to different installation procedures. > A clear example is the difference between home (plug and play) and the > building control where bootstrapping is organized from a database. > In the professional domain the order of things can depend on the > installer. For example, some may want to bootstrap together with the > setup of the network, others may want the network to be ready and then > do the security bootstrap. > > Although I agree with your concern expressed as "a default procedure to > decide on the bootstrap procedure", I think there is room for 2-4 > different security bootstrap procedures. > These procedures will be chosen as function of the application domain > and application owner, installer. > > Peter > > > > Brian E Carpenter schreef op 2015-02-20 19:51: >> Hannes, >> >> I agree that we need to compare different approaches. I do have one >> concern in the anima context that leads me to the conclusion that >> we *must* pick a preferred solution: if we consider a collection of >> multivendor equipment in factory condition that we want to bootstrap >> itself into a secure network when we apply power, I don't see how >> we can avoid having a single default solution. If not, we get a >> rather ludicrous situation where we need a single default solution >> to the problem of choosing which bootstrap solution to use. >> >> Regards >> Brian >> >> On 21/02/2015 01:27, Hannes Tschofenig wrote: >>> Hi Danping, >>> >>> I would also like to note that >>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible way of >>> distributing new keys (based on already pre-provisioned certificates). I >>> would like to understand how it relates to other approaches. >>> Particularly if you consider an approach "heavy" it would be good to >>> know what your main concerns are since there is no free lunch with >>> security and most of the design decisions are trade-offs. >>> >>> Ciao >>> Hannes >>> >>> On 02/20/2015 12:59 PM, Robert Cragie wrote: >>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch >>>> bootstrapping key infrastructure to allow joining device securely and >>>> automatically bootstraps itself based on 802.1AR certificate. It can't >>>> be directly used in 802.15.4 devices due to the high security >>>> complexity >>>> and heavy communication overhead.": I disagree with this statement. We >>>> used this approach in ZigBee IP. I agree some may think the >>>> communication overhead "heavy" but that doesn't mean it can't be done. >>>> The associated security complexity is also becoming less onerous as >>>> crypto accelerators become built into hardware and cores. >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima
- Re: [6tisch-security] [Anima] [6lo] Comments need… Behcet Sarikaya
- Re: [6tisch-security] [Anima] [6lo] Comments need… Tero Kivinen
- Re: [6tisch-security] [6lo] Comments needed for S… Michael Richardson
- Re: [6tisch-security] [6lo] Comments needed for S… Hedanping (Ana)
- Re: [6tisch-security] [6lo] Comments needed for S… Tero Kivinen
- Re: [6tisch-security] [6lo] Comments needed for S… Robert Cragie
- Re: [6tisch-security] [6lo] Comments needed for S… Hannes Tschofenig
- Re: [6tisch-security] [Anima] [6lo] Comments need… Brian E Carpenter
- Re: [6tisch-security] [6lo] Comments needed for S… Behcet Sarikaya
- Re: [6tisch-security] [Anima] [6lo] Comments need… Brian E Carpenter
- Re: [6tisch-security] [Anima] [6lo] Comments need… Brian E Carpenter
- Re: [6tisch-security] [Anima] [6lo] Comments need… peter van der Stok
- Re: [6tisch-security] [Anima] [6lo] Comments need… Hannes Tschofenig
- Re: [6tisch-security] [6lo] [Anima] Comments need… peter van der Stok
- Re: [6tisch-security] [6lo] [Anima] Comments need… Brian E Carpenter
- Re: [6tisch-security] [6lo] [Anima] Comments need… Behcet Sarikaya
- Re: [6tisch-security] [Anima] [6lo] Comments need… Kent Watsen
- Re: [6tisch-security] [Anima] [6lo] Comments need… Hannes Tschofenig
- Re: [6tisch-security] [Anima] [6lo] Comments need… Brian E Carpenter
- Re: [6tisch-security] [6lo] Comments needed for S… Hedanping (Ana)
- [6tisch-security] Device vs network bootstrapping… Brian E Carpenter
- Re: [6tisch-security] [6lo] [Anima] Comments need… Behcet Sarikaya
- [6tisch-security] Thread [Comments needed for Sec… Brian E Carpenter
- Re: [6tisch-security] [6lo] Device vs network boo… Hedanping (Ana)
- Re: [6tisch-security] [6lo] [Anima] Comments need… Hedanping (Ana)
- Re: [6tisch-security] [6lo] [Anima] Comments need… Paul Duffy
- Re: [6tisch-security] [6lo] Device vs network boo… Brian E Carpenter
- Re: [6tisch-security] [Anima] [6lo] Device vs net… Kent Watsen
- Re: [6tisch-security] [6lo] Device vs network boo… Kris Pister
- Re: [6tisch-security] [6lo] [Anima] Comments need… Thomas Watteyne
- Re: [6tisch-security] [6lo] Device vs network boo… Brian E Carpenter
- Re: [6tisch-security] [6lo] Thread [Comments need… Ralph Droms
- Re: [6tisch-security] [6lo] Thread [Comments need… Brian E Carpenter
- Re: [6tisch-security] [6lo] [Anima] Comments need… peter van der Stok
- Re: [6tisch-security] [Anima] Thread [Comments ne… Hannes Tschofenig
- Re: [6tisch-security] [6lo] [Anima] Thread [Comme… Ralph Droms
- Re: [6tisch-security] [Anima] Thread [Comments ne… Brian E Carpenter
- [6tisch-security] (Fair) competition in pursuing … Rene Struik
- Re: [6tisch-security] (Fair) competition in pursu… Brian E Carpenter
- Re: [6tisch-security] [Anima] (Fair) competition … Sheng Jiang
- Re: [6tisch-security] [Anima] Thread [Comments ne… Hannes Tschofenig
- Re: [6tisch-security] [Anima] (Fair) competition … Rene Struik
- Re: [6tisch-security] [Anima] (Fair) competition … Sheng Jiang
- Re: [6tisch-security] [Anima] (Fair) competition … Hannes Tschofenig
- Re: [6tisch-security] [Anima] (Fair) competition … Robert Cragie
- Re: [6tisch-security] [Anima] [6lo] Thread [Comme… Alper Yegin
- Re: [6tisch-security] [Anima] [6lo] Thread [Comme… Carsten Bormann
- Re: [6tisch-security] [6lo] [Anima] Thread [Comme… Oliver Hahm