Subject: Re: [core] Certificate mode in -16

From: Paul Duffy <[email-masked]>
Date: Wed, 01 May 2013 08:36:51 -0400

On 4/30/2013 6:37 PM, Carsten Bormann wrote:
> On May 1, 2013, at 00:05, Paul Duffy <[email-masked]> wrote:
>
>> OCSP and CRLs are likely to prove challenging to support within an LLN environment.  For this reason, Zigbee IP avoids them.
> Is it just me, or did I just read:

Its you ;)

>
>> Lifeboats are likely to prove challenging to support within an ocean cruise.  For this reason, the Titanic avoids them.

You have the ocean part correct, but you are not sitting on the 
Titanic.  You are on a 16' Sears aluminum skiff with a 2 hp outboard, 
and a 5 gallon fuel tank.  Bon voyage!

You are often not going to be able to use the usual set of certificate 
management mechanisms for IoT as you can for enterprise or consumer 
computing.

I can't say more than that just yet, SEP2 is working a solution.

> (I'm not saying I have a solution, but the thing may be a bit more complex than this sentence makes it look like.)
>
> Grüße, Carsten
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 01 May 2013 16:35:42 +0300

>>OCSP and CRLs are likely to prove challenging to support within an LLN environment.  For this reason, Zigbee IP avoids them.

So, what is the story Zigbee IP provides? No revocation checking?

---

From: Don Sturek <[email-masked]>
Date: Wed, 01 May 2013 07:08:29 -0700

Hi Hannes,

ZigBee IP does not support OCSP, however, we do support
blacklisting/whitelisting.

Many IoT devices using ZigBee IP do not support update of their
certificates, download of new certificates, etc. due to resource
limitations.    Manufacturers plan to burn in Device Certificates, into
devices with 20+ years of lifetime without the ability to change/update
certificates.  Also, many deployments are in settings without any
connectivity to the Internet (imagine a smart appliance purchased into a
home without internet access, managed locally by an energy management
system). 

We have created a method to update security (while supporting older
devices) but have precluded the use of OCSP for our applications.

Don

On 5/1/13 6:35 AM, "Hannes Tschofenig" <[email-masked]> wrote:

>>>OCSP and CRLs are likely to prove challenging to support within an LLN
>>>environment.  For this reason, Zigbee IP avoids them.
>
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Wed, 1 May 2013 21:18:12 +0300

On May 1, 2013, at 12:32 AM, "Rahman, Akbar" <[email-masked]> wrote:

> How about something like this?
> 
> 
>   The Authority Name in the certificate would be based out of a long
> term unique identifier for
>   the device such as the EUI-64 [EUI64].  The Authority Name could also
> be based on the FQDN
>   that was used as the Host part of the CoAP URI.  However, the
> device's IP address should not typically
>   be used as the Authority name as it would change over time.

Looks good, I now included this in [1367].

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 May 2013 20:44:41 +0300

Hi Don,

interesting. I guess problems like with DigiNotar, TurkTrust, or Comodo 
should better not happen with these devices...

I was told that there is a fairly deep certificate hierarchy envisioned 
in the ZigBee IP specs and I am curious whether this is indeed the case.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 May 2013 20:48:37 +0300

Hi Zach, Hi Paul,

are you planning to use the same certificate with the device identifiers 
for application layer protocols (like CoAP) and for network access 
authentication (in an EAP method)?

Ciao
Hannes

05/01/2013 09:24 AM, Zach Shelby wrote:
> On May 1, 2013, at 1:05 AM, Paul Duffy <[email-masked]> wrote:
>
>> Re: EUI-64 as the unique device identity.  My understanding is that it is far better practice to use a concatention of manufacturer-id, product-code, serial number (or similar) versus the MAC address.
>>
>> You might also consider a review IEEE 802.1ar for secure device identify guidance.
>
> Right, EUI-64 is just mentioned in that paragraph as an example, I agree there are better identifiers. Our job in the CoAP specification isn't to normatively require which to use though. Do you think that an informative reference to IEEE 802.1ar would be useful in this paragraph?
>
> Zach
>