Subject: [core] Certificate mode in -16

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Apr 2013 19:28:53 +0200

I just made an attempt at addressing the IESG comments on section 9.1.3.3, X.509 Certificates.
I think I'm done with #316 and #318 (and have closed those), but I would like to hear your input on #317.  I'm reproducing the formatted version of 9.1.3.3 as of [1346] below.  The changes are:
-- point to RFC5280 section 6 (#316)
-- add a paragraph about cert status checking (#317)
-- RSA is out, ECDHE is in for cert-with-PSK, too (#318)

Grüße, Carsten

9.1.3.3.  X.509 Certificates

   Implementations in Certificate Mode MUST support the mandatory to
   implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
   specified in [RFC5246].

   The Authority Name in the certificate is the name that would be used
   in the Host part of a CoAP URI.  It is worth noting that this would
   typically not be either an IP address or DNS name built in the usual
   way but would instead be built out of a long term unique identifier
   for the device such as the EUI-64 [EUI64].  The discovery process
   used in the system would build up the mapping between IP addresses of
   the given devices and the Authority Name for each device.  Some
   devices could have more than one Authority and would need more than a
   single certificate.

   When a new connection is formed, the certificate from the remote
   device needs to be verified.  If the CoAP node has a source of
   absolute time, then the node SHOULD check that the validity dates of
   the certificate are within range.  The certificate MUST be validated
   as appropriate for the security requirements, using functionality
   equivalent to the algorithm specified in [RFC5280] section 6.  If the
   certificate contains a SubjectAltName, then the Authority Name MUST
   match at least one of the authority names of any CoAP URI found in a
   field of URI type in the SubjectAltName set.  If there is no
   SubjectAltName in the certificate, then the Authoritative Name must
   match the CN found in the certificate using the matching rules
   defined in [RFC2818] with the exception that certificates with
   wildcards are not allowed.

   CoRE support for certificate status checking requires further work.
   As a mapping of OCSP [RFC2560] onto CoAP is not currently defined and
   OCSP may also not be easily applicable in all environments, an
   alternative approach may be using the TLS Certificate Status Request
   extension ([RFC6066] section 8, also known as "OCSP stapling"), if
   the limitations of that extension are acceptable.

   If the system has a shared key in addition to the certificate, then a
   cipher suite that includes the shared key such as
   TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] SHOULD be used.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 30 Apr 2013 14:43:51 -0400

Hi Carsten,

First, thank you for all your hard work in systematically answering the IESG comments.  It is very impressive!

I have a question on the (extracted) text below from the X.509 Certificates text.  

   for the device such as the EUI-64 [EUI64].

I don't follow the logic where it is implying above that the host part of the CoAP URI would NOT be the IP address or DNS name.  For example, this then does not comply to the text in section 6.1 (coap URI Scheme).  Does it?

/Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, April 30, 2013 1:29 PM
To: [email-masked] ([email-masked])
Subject: [core] Certificate mode in -16

Grüße, Carsten

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Tue, 30 Apr 2013 22:35:01 +0300

> I don't follow the logic where it is implying above that the host part of the CoAP URI would NOT be the IP address or DNS name.  For example, this then does not comply to the text in section 6.1 (c…

In the typical Web certificate world the Authority Name would be your DNS name and/or IP addresses (the Host part of a CoAP URI). What this is trying to say is that an endpoint (at least a constrained one)  doesn't typically have a DNS name, and the IP address is usually volatile. So instead, the way we identify things is with a more stable identifier such as the EUI-64. This is saying to use this stable identifier as the Authority Name in the certificate. Of course if you did happen to have a DNS name, you can use that. So this text is not changing the way we use the Host part of a CoAP URI. This has come up before, so we probably need to do some word-smithing to clarify that paragraph.

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: "Rahman, Akbar" <[email-masked]>
Date: Tue, 30 Apr 2013 16:07:08 -0400

Hi Zach,

Thanks.  Yes, I definitely think some word-smithing would be useful.
Also, purely for my personal interest, did anyone use EUI-64 in any of
the CoAP interops?  Or are there any CoAP deployments that you are aware
of that use EUI-64?

Akbar

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Tuesday, April 30, 2013 3:35 PM
To: Rahman, Akbar
Cc: Carsten Bormann; [email-masked]
Subject: Re: [core] Certificate mode in -16

On Apr 30, 2013, at 9:43 PM, "Rahman, Akbar"
<[email-masked]> wrote:

> I don't follow the logic where it is implying above that the host part
of the CoAP URI would NOT be the IP address or DNS name.  For example,
this then does not comply to the text in section 6.1 (coap URI Scheme).
Does it?

In the typical Web certificate world the Authority Name would be your
DNS name and/or IP addresses (the Host part of a CoAP URI). What this is
trying to say is that an endpoint (at least a constrained one)  doesn't
typically have a DNS name, and the IP address is usually volatile. So
instead, the way we identify things is with a more stable identifier
such as the EUI-64. This is saying to use this stable identifier as the
Authority Name in the certificate. Of course if you did happen to have a
DNS name, you can use that. So this text is not changing the way we use
the Host part of a CoAP URI. This has come up before, so we probably
need to do some word-smithing to clarify that paragraph.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Tue, 30 Apr 2013 23:26:29 +0300

> Thanks.  Yes, I definitely think some word-smithing would be useful.

Any chance you could suggest text for that first sentence to make that really clear? Should we just stop using the analogy to the CoAP URI? 

> the CoAP interops?  Or are there any CoAP deployments that you are aware

Well, this is talking about the Authority Name of certificates, and there hasn't been an interop with certificate mode yet. We do have an implementation of certificate mode where the Authority Name of constrained nodes has been set as the EUI-64 and other serial numbers, e.g. IMEI for Cellular devices. 

I would also note that the Authority Name should be the same as the Resource Directory Endpoint Name (the OMA LWM2M standard requires this for authentication when registering), and we have been using EUI-64 and other serial numbers there for a long time.

Zach

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 30 Apr 2013 21:38:17 +0100

>> Thanks.  Yes, I definitely think some word-smithing would be useful.

A releated question is whether we need, in case EUI-64 is used as
Authority Name, to define a new NameType of type "EUI-64" for SNI.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 30 Apr 2013 17:32:20 -0400

Hi Zach,

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.

Akbar

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Tuesday, April 30, 2013 4:26 PM
To: Rahman, Akbar
Cc: Carsten Bormann; [email-masked]
Subject: Re: [core] Certificate mode in -16

> Thanks.  Yes, I definitely think some word-smithing would be useful.

Any chance you could suggest text for that first sentence to make that
really clear? Should we just stop using the analogy to the CoAP URI? 

> the CoAP interops?  Or are there any CoAP deployments that you are 
> aware of that use EUI-64?

Well, this is talking about the Authority Name of certificates, and
there hasn't been an interop with certificate mode yet. We do have an
implementation of certificate mode where the Authority Name of
constrained nodes has been set as the EUI-64 and other serial numbers,
e.g. IMEI for Cellular devices. 

I would also note that the Authority Name should be the same as the
Resource Directory Endpoint Name (the OMA LWM2M standard requires this
for authentication when registering), and we have been using EUI-64 and
other serial numbers there for a long time.

Zach

---

From: Paul Duffy <[email-masked]>
Date: Tue, 30 Apr 2013 18:05:16 -0400

Folks,

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.

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

Cheers

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 May 2013 00:37:30 +0200

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:

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

(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: Zach Shelby <[email-masked]>
Date: Wed, 1 May 2013 09:21:51 +0300

> Authority Name, to define a new NameType of type "EUI-64" for SNI.

Yes, I agree that we eventually will need that, but in a separate draft. For now CN should be used for this purpose.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Wed, 1 May 2013 09:24:45 +0300

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 May 2013 08:31:40 +0200

On Apr 30, 2013, at 22:07, "Rahman, Akbar" <[email-masked]> wrote:

> did anyone use EUI-64 in any of
> the CoAP interops? 

We will have to wait for the next CoAP interop to do some real CoAP/DTLS testing.
(In fact, I think secure CoAP should be the focus for that.)
Maybe in Vancouver this November...

Grüße, Carsten