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

[Don Sturek <[e-mail]>]

Hi Michael,

One approach we used for Smart Energy Profile 2.0 (now IEEE 2030.5) is to
use IEEE 802.1ar certificates.   These are secure device identity
certificates just for authentication.   We don't support OCP on these
certificates, however, it is possible to use CRL.

The purpose is to simply authenticate the device.   If authorization is
wanted, an operational certificate or a whitelist/blacklist can be used.

Don


On 3/21/14 7: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