Re: [6tisch-security] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things
Robert Cragie <robert.cragie@gridmerge.com> Fri, 20 February 2015 12:12 UTC
Return-Path: <robert.cragie@gridmerge.com>
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 7DF9E1A8A1A; Fri, 20 Feb 2015 04:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 RZQtkP3iS4Wv; Fri, 20 Feb 2015 04:12:19 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E69A1A6F3D; Fri, 20 Feb 2015 03:59:36 -0800 (PST)
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g75.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1YOmF4-0002ma-N3; Fri, 20 Feb 2015 11:59:34 +0000
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1YOmF2-0008EX-Ag; Fri, 20 Feb 2015 11:59:34 +0000
Received: from host86-171-66-135.range86-171.btcentralplus.com ([86.171.66.135] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YOmEx-0005Ur-B4; Fri, 20 Feb 2015 11:59:28 +0000
Message-ID: <54E7219B.6040006@gridmerge.com>
Date: Fri, 20 Feb 2015 11:59:23 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Hedanping (Ana)" <ana.hedanping@huawei.com>, Michael Richardson <mcr+ietf@sandelman.ca>
References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050800090303060805030500"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch-security/A2Si9DF-bA21wTY1RkFB9NlZZy8>
X-Mailman-Approved-At: Fri, 20 Feb 2015 06:23:45 -0800
Cc: "anima@ietf.org" <anima@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch-security] [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
Reply-To: robert.cragie@gridmerge.com
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: Fri, 20 Feb 2015 12:12:24 -0000
Hi Danping, I have some general comments on the draft and some additional comments inline, bracketed by <RCC></RCC> General comments: I think the general model is good but could be simplified to two cases: 1) Where the authenticator is in direct communication 2) Where the authenticator is not in direct communication (relay case) My reasoning is because: a) There isn't much distinction between RFD and FFD from an authentication perspective b) There isn't much distinction between joining an existing network and initial joining If you think there are distinctions, then they need clarifying. Other points: * "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard security bootstrapping protocol should be light-weight with low complexity.": I think it would be better to say "should ideally be light-weight with low complexity". There may be requirements where high security strength is required and therefore this will necessarily involve more communication overhead and processing. * I think the hierarchical joining description is generally useful. * It is conceivable for an RFD to communicate directly with a 6LBR so I don't think that should be excluded from Figure 1 * "[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. * The document mentions a couple of protocols (EAP and PANA) but doesn't go into enough detail on how those are deployed. Also, there are other choices. The document could give generic names to the particular communications and then add a section to give examples. Robert On 02/02/2015 08:13, Hedanping (Ana) wrote: > Hi Michael, > Thank you for the interest and the questions are illuminating. Please see my reply inline. > > > I have added a number of CCs, I think that this fits into ANIMA best. > > > > > Hedanping (Ana) <ana.hedanping@huawei.com> wrote: > > > A new draft is submitted, it's about the security bootstrapping > > > architecture and methods for IoT networks that implement IETF > > protocols > > > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. > > > Two types of bootstrapping methods are developed: network level > > > bootstrapping and joining device level bootstrapping > > > > > The link is: > > > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00 > > > > I read the document with great interest. > > I found that you explained the incremental boot-strapping process quite well, > > and nobody has clearly articulated the process yet. People have just assumed > > that everyone knows this process, but really it needs to get written down, so I > > thank you for doing that. > > Thank you for the praise. As it is the initial version, more discussions and comments are needed to make it better. <RCC>I agree that it has not generally been articulated well. To some extent, it is because up to now, there has been no "the one way to do it". Therefore, something ZigBee IP is a profile which defines one particular way of doing it. There are other ways as well, of course. I guess the question is whether it can be generalised sufficiently to be generally applicable and whether that is in fact worth doing</RCC> > > > > > Given that: > > > > Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard > > security bootstrapping protocol should be light-weight with low > > complexity. The protocol must allow for commissioning of devices > > > > I was surprised that the draft then suggested EAP with PANA as a transport: <RCC>I realise that PANA/EAP/EAP-TLS gets roundly criticised for being "heavyweight". Indeed, there are overheads in the use of these three very well-established protocols which could be removed in certain cases. However, this would result in the development of new protocols. Having done a lot of work in looking at DTLS options, I can confidently say that the difference at the end of the day is quite small</RCC> > > > > If EAP is used, PANA can be used to relay the authentication message > > from configured FFDs to 6LBR. If the validation is successful, the > > IP address and network key are generated and delivered to the FFD. > > > > But, EAP-TLS with PANA is exactly what the Zigbee IP specification has specified. > > Do you envision any changes from that specification? > > Zigbee IP specification was developed to enable IP address for Zigbee application, thus the protocol stack are built on IETF's standards, including EAP-TLS. > As discussed in many working groups, TLS might result in a significant amount of retransmissions due to unreliable communication capability of the network and device, thus energy will be consumed fast. > I think EAP over DTLS /profiled DTLS could be a good option. <RCC>EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore has little to do with TLS as it is normally used, i.e. over TCP. If you then start to look at the difference between EAP-TLS (over UDP) and DTLS handshakes over UDP, there is actually not much difference. In some areas, EAP is actually preferable (fragmentation and header overhead)</RCC> > > > A minority of people had prefered this mechanism for 6tisch-security, but > > none stepped forward to write up that mechanism. Perhaps this draft could > > fulfill that need? > > Yes, we should describe more clearly on this mechanism, and maybe this draft is a right place. It would be great if folks in the mailing list make comments and contribution on this technical point. <RCC>I am happy to write up that mechanism</RCC> > > > You write that the IP address would be generated; usually that occurs via > > distribution of PIOs via ND (router-adveristments) or RPL. Were you going to > > suggest something else here? > > According to my knowledge, IP address can be generated once a device is authenticated to network access, afterwards, other further protocols can use IP to communicate. > Besides, PANA needs IP as well. The incremental bootstrapping takes advantage of such IP address generation mechanism, so that PANA can be run without any problem. <RCC>ZigBee IP solved this problem by using SLAAC IPv6 addresses based on the EUI-64. These can be used in PANA straight away without the need for any other configuration</RCC> > > > > From the ANIMA and 6tisch-security point of view, my view is that this is all > > about the choice of certificates for the TLS setup. Do you have any view on > > how that might work? > > For unconstrained environment, I agree with you. But when it comes to constrained device and constrained network communication, TLS might not be a good choice as mentioned before. Certificate is not a good choice either due to the high cost. > I would like to say: it is about the choice of credential type for secure channel setup. The good candidates of credential types are Raw public key, Physical Unclonable Function (PUF). <RCC>There certainly are overheads in certificates but in the 802.1AR scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear value.</RCC> > > > > > The 6tisch-security bootstrap process aims to create a > > YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and the > > Joining Node: over that management link, security (and timeslot scheduling) > > would be provisioned. > > CoAP-DTLS coincides with my idea. > Yang sounds like at a higher level, but I think EAP is actually the mechanism running behind ^_^ <RCC>Again, in this document, it might be better to abstract this session and describe what it is used for</RCC> > > > Regards, > Ana > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >
- 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