Re: [TLS] bootstrapping of constrained devices

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Fri, 21 March 2014 16:04 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 2EE081A09E8 for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 09:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 aAJ3ZhztqxUT for <tls@ietfa.amsl.com>; Fri, 21 Mar 2014 09:04:09 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0721A09EE for <tls@ietf.org>; Fri, 21 Mar 2014 09:04:08 -0700 (PDT)
Received: from mail62-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 16:03:59 +0000
Received: from mail62-co9 (localhost [127.0.0.1]) by mail62-co9-R.bigfish.com (Postfix) with ESMTP id CAC13A803E9; Fri, 21 Mar 2014 16:03:58 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: PS-25(zzbb2dI98dI9371I1432I7f52h1447Idb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz8dhz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h2052h20b3h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h)
Received-SPF: pass (mail62-co9: domain of rhul.ac.uk designates 157.56.248.5 as permitted sender) client-ip=157.56.248.5; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AMSPRD0310HT004.eurprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(24454002)(51914003)(479174003)(377454003)(199002)(189002)(87266001)(80022001)(92566001)(83716003)(53806001)(325944007)(66066001)(65816001)(87936001)(76482001)(33656001)(81542001)(74876001)(83072002)(76796001)(54316002)(92726001)(51856001)(95666003)(54356001)(2656002)(46102001)(69226001)(94316002)(93136001)(79102001)(93516002)(63696002)(20776003)(49866001)(94946001)(86362001)(85306002)(1411001)(59766001)(97186001)(77982001)(56776001)(47446002)(19580395003)(74366001)(19580405001)(74482001)(83322001)(82746002)(50986001)(81816001)(31966008)(74662001)(74502001)(4396001)(80976001)(15975445006)(74706001)(81342001)(76786001)(36756003)(95416001)(561944002)(47736001)(85852003)(47976001)(15202345003)(56816005)(90146001)(81686001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:F4DBF1F5.AFFA67E0.BFF461BB.C2E5F541.205E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail62-co9 (localhost.localdomain [127.0.0.1]) by mail62-co9 (MessageSwitch) id 1395417837501571_14211; Fri, 21 Mar 2014 16:03:57 +0000 (UTC)
Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.243]) by mail62-co9.bigfish.com (Postfix) with ESMTP id 6BDD46A0076; Fri, 21 Mar 2014 16:03:57 +0000 (UTC)
Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 16:03:57 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 16:03:51 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 16:03:50 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 16:03:50 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] bootstrapping of constrained devices
Thread-Index: AQHPRRjdGRG2NbhO+U2QyRiSBBsmfJrrr/cAgAAEITA=
Date: Fri, 21 Mar 2014 16:03:49 +0000
Message-ID: <D79ABD07-635D-4804-9934-2E426DE3A5B2@rhul.ac.uk>
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> <532C5867.2050704@gridmerge.com>, <CACsn0c=autfnANnTuszX+-EOgtSa6N7+S-hbEnj5ukyQPPUMVQ@mail.gmail.com>
In-Reply-To: <CACsn0c=autfnANnTuszX+-EOgtSa6N7+S-hbEnj5ukyQPPUMVQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.42.226.146]
x-forefront-prvs: 0157DEB61B
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0OsZvvgxuWhphP46hR-uaVmDYsM
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
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 16:04:13 -0000

> On 21 Mar 2014, at 15:50, "Watson Ladd" <watsonbladd@gmail.com> wrote:
> 
> On Fri, Mar 21, 2014 at 8:19 AM, Robert Cragie
> <robert.cragie@gridmerge.com> wrote:
>> 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.
> 
> There are drafts for AugPAKE  and J-PAKE that could be done as RFCs
> relatively quickly, The reason we haven't modernized the PAKEs is the
> one scheme that was presented, Dragonfly, wasn't good enough. I don't
> see any reason for either AugPAKE or J-PAKE to go through.
> 
> Granted, I've not studied them in enough detail quite yet, but they
> look good so far.
> 

As far as I am aware, there's no complete formal security analysis of J-PAKE. There are claims in the original paper about the security conferred by the use of ZK proofs, and some informal security analysis (stated as theorems and proofs), but, as far as I know, there's no security proof using a recognised PAKE security model. 

Cheers

Kenny


> Sincerely,
> Watson Ladd
> 
>> 
>> 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> 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> 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
>>> 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
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> 
>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> -- 
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>