Re: [TLS] bootstrapping of constrained devices (was: Re: Should TLS 1.3 use an augmented PAKE by default?)

["Max Pritikin (pritikin)" <[e-mail]>]

Generating keys “on the first use/setup” of the device means that first connection is unsecured. I have serious concerns about that!

Manufacturing generated credentials can be integrated into the sales process. I agree with Ander’s that binding other information to the credential is a good thing, but even if its a raw key pair (“self-signed”) the hash can still be printed onto a barcode or distributed electronically as part of the bill of sale. 

I think the best compromise is a manufacturer CA method that can be as lightweight as the manufacturer wishes. If they want to manage their CA keys poorly because of the perceived complexity they can do so. Other manufacturers can provide a more secure product. The relying parties (and the standards they rely on) can expect real certificate chains and seamlessly support products with security goals. They can tell, based on the issuing CA, something about the constrained device. 

Don’t forget too that constrained devices need a mechanism to ensure they’re bootstrapping into the correct network/management-infrastructure. To do so they need some root of trust installed prior to deployment. I’d suggest this is the same root of trust they use for software upgrades although for constrained devices perhaps many feel updates are out-of-scope. 

- max


On Mar 21, 2014, at 8:57 AM, Michael Sweet <[e-mail]> wrote:

> Tom,
> 
> Yes, self-signed device certificates are the common implementation choice and are often generated on the first use/setup of the device (simpler than doing it in the factory...)
> 
> 
> On Mar 21, 2014, at 10:44 AM, t.petch <[e-mail]> wrote:
> 
>> ----- Original Message -----
>> From: "Michael Sweet" <[e-mail]>
>> To: "Rene Struik" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Friday, March 21, 2014 12:26 PM
>> 
>> 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...
>> 
>> <tp>
>> 
>> Michael
>> 
>> In the context of syslog security, some years ago now, the question of
>> device certificates arose and it was said there that they were quite
>> common.  They would be self-signed, which gives much of the needed
>> security, while avoiding issues of CA and root compromise.
>> 
>> Tom Petch
>> 
>> On Mar 20, 2014, at 9:52 PM, Rene Struik <[e-mail]> 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" <[e-mail]>
>> 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
>>>> 
>>>>> --
>>> email: [e-mail] | Skype: rstruik
>>> cell: [phone] | US: [phone]
>> 
>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls