Re: [TLS] bootstrapping of constrained devices

Robert Cragie <robert.cragie@gridmerge.com> Fri, 21 March 2014 15:18 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EFD1A09B9 for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 08:18:37 -0700 (PDT)
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] 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 cs7-bAYSnEiB for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 08:18:33 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan23.extendcp.co.uk [176.32.226.69]) by ietfa.amsl.com (Postfix) with ESMTP id D12291A0128 for <tls@ietf.org>; Fri, 21 Mar 2014 08:18:32 -0700 (PDT)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan5.hi.local) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1WR1DB-0004Em-FG; Fri, 21 Mar 2014 15:18:21 +0000
Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan5.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1WR1D9-00087i-Hi; Fri, 21 Mar 2014 15:18:21 +0000
Received: from host86-151-9-208.range86-151.btcentralplus.com ([86.151.9.208] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1WR1D8-0005Jl-MD; Fri, 21 Mar 2014 15:18:19 +0000
Message-ID: <532C5867.2050704@gridmerge.com>
Date: Fri, 21 Mar 2014 15:19:03 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rene Struik <rstruik.ext@gmail.com>
References: <53288C43.9010205@mit.edu> <5328B6DF.8070703@fifthhorseman.net> <5328C0C8.9060403@mit.edu> <6b79e0820d349720f12b14d4706a8a5d.squirrel@webmail.dreamhost.com> <CALCETrUz8zCBHiq42GTnkkSaBcpA5pjSvk6kwwPjzn+MtBKMgA@mail.gmail.com> <e38419e3ada3233dbb3f860048703347.squirrel@webmail.dreamhost.com> <CALCETrVgJxfdCxZqc9ttHHNKHm-hdtGbqzHvsQ-6yd5BK=9PDw@mail.gmail.com> <67BAC033-2E23-4F03-A4D9-47875350E6B5@gmail.com> <532B0EAA.5040104@fifthhorseman.net> <8D8698DF-5C06-4F2A-8994-E0A36A987D6D@vpnc.org> <532B1739.80907@fifthhorseman.net> <CADrU+d+GkGU1Da3W6xGuOq4qvd40DdT6+sO6WEZeEag7Q1OiVQ@mail.gmail.com> <532B9B65.4030708@gmail.com> <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com>
In-Reply-To: <8FD78E18-C3C7-4085-9E3F-8B60B20F2CB5@apple.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms040003060001020800080803"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SjIkUOWFGO_U62mONlsh1YMkT_A
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] bootstrapping of constrained devices
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 15:18:37 -0000

Hi Rene,

There is certainly a place for device certificates but they are 
generally quite expensive in terms of the infrastructure needed to 
support them as Michael points out.

There are no specific links I can point to but the use case is using 
relatively short codes which are put into e.g. a home router through a 
web interface to provide steering, a basis for authenticating another 
device onto the network and a secure channel for delivery of 
configuration/bootstrapping information. WPS PIN is an example of this 
(notwithstanding its implementational flaws). Using TLS/DTLS as a basis 
provides the possibility of reuse at the application layer, which is a 
bonus for the relatively constrained devices generally considered to be 
in use in the IoT.

Robert

On 21/03/2014 12:26 PM, Michael Sweet wrote:
> Rene,
>
> Installing device certificates during manufacturing is not a simple 
> process - the factory would need to act as a CA or would need to have 
> a supply of certificates that matches whatever identifiers are used by 
> the devices.  Not to mention how you'd manage revocation if the root 
> was compromised...
>
>
> On Mar 20, 2014, at 9:52 PM, Rene Struik <rstruik.ext@gmail.com 
> <mailto:rstruik.ext@gmail.com>> wrote:
>
>> Hi Robert:
>>
>> Wouldn't it be much easier to embed device certificates with 
>> constrained devices at manufacturing? This may do away with need to 
>> store info that is not public on servers.
>>
>> If you could provide some links to discussions in "IoT community 
>> groups" interested in this, that would help.
>>
>> Best regards, Rene
>>
>> ==
>> There is a lot of interest in the IoT community in using some form of 
>> PAKE in conjunction with DTLS (or TLS with EAP) for authenticating 
>> commissioning/bootstrapping of IoT devices onto IoT networks
>>
>> On 3/20/2014 1:21 PM, Robert Cragie wrote:
>>>
>>> It should be remembered that TLS is used in places other than web 
>>> browsers - the existence of the DICE WG is testament to this. There 
>>> is a lot of interest in the IoT community in using some form of PAKE 
>>> in conjunction with DTLS (or TLS with EAP) for authenticating 
>>> commissioning/bootstrapping of IoT devices onto IoT networks. I 
>>> realise this is different to the original proposition in this thread 
>>> but wanted to draw this to the attention of the WG nevertheless.
>>>
>>> Robert
>>>
>>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net 
>>> <mailto:dkg@fifthhorseman.net>> wrote:
>>>
>>>     On 03/20/2014 12:18 PM, Paul Hoffman wrote:
>>>     > As an important note, you did not define "we" above. A few
>>>     possible expansions would be:
>>>     >
>>>     > - The TLS WG, where this thread currently lives, does not get
>>>     to define Web UI without a charter change.
>>>     >
>>>     > - The HTTPbis WG has not asked the TLS WG to take over this
>>>     work, nor has it embraced anything like it.
>>>     >
>>>     > - The IETF doesn't do this kind of work as a whole body.
>>>     >
>>>     > - The IAB (of which none of us are part of the "we") might
>>>     take the topic on and suggest ways which the IETF might do the work.
>>>
>>>     yep, thanks for the clarification.  I actually meant "we" in the
>>>     broad
>>>     sense of "the community of people who care about making
>>>     communications
>>>     on the web more secure", which includes groups you didn't even
>>>     mention
>>>     above, like web site designers, systems administrators, etc.
>>>
>>>     It's still on-topic here (despite the broad scope implied above)
>>>     because
>>>     the TLS WG does have a role to play, by considering the merits of
>>>     proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as
>>>     well as considering alternatives that deal with this particular
>>>     use case.
>>>
>>>     >> option (A) is seriously hard, maybe impossible given the
>>>     state of the
>>>     >> web.  option (B) is terrible.
>>>     >
>>>     > Exactly right, for any value of "we".
>>>
>>>     :(
>>>
>>>             --dkg
>>>
>>>
>>>     _______________________________________________
>>>     TLS mailing list
>>>     TLS@ietf.org <mailto:TLS@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> -- 
>> email:rstruik.ext@gmail.com  | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>