Subject: [Dtls-iot] IP Addresses in Certificates

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Jul 2015 13:07:27 +0200

Stephen wrote:

(5) 6.3: Forgetting CoAP for the moment, surely this profile will be
used with devices that only have (possibly bogon) IP addresses and that
want to have those in certs. I do get that how to handle that well is
not very clear, esp. for certs for e.g. 192.168.0.1, but shouldn't it
really be covered by this profile?

In general, it is not clear how server-side certificates work with IoT
devices that do not use DNS. This motivated us to write a separate
document about this topic, see ​
https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01

For client certificates it does not really matter that much what you put
into the certificates since the content is only matched against an
access control policy (without further interpreting the structure of the
identifier).

So, are you talking about server or client-side certificates?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jul 2015 12:20:12 +0100

Hiya,

> really be covered by this profile?

I should also have mentioned link-local addresses too I guess.

> https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01

That's a new one on me. I can see where you're coming from but
IMEI's in certificates is pretty iccky, even if it's only for
a sensor-with-a-SIM device. So I dunno if that's the "right" or
best answer to be honest.

> So, are you talking about server or client-side certificates?

(D)TLS servers mostly.

I guess to the extent there are devices doing TLS client auth,
those too, but I do agree that in most cases there'll be another
identifier used that isn't an IP address, so the (D)TLS client
side is a secondary issue.

S.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jul 2015 14:17:48 -0400

Hannes Tschofenig <[email-masked]> quoted (I think) Stephen Farrel
    > really be covered by this profile?

  Hanness> https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01

Reading this document....

I think that is indeed a must have document.
Let's take this out of the IoT space for a moment.

Ever turned on a Dell/HP/IBM/Supermicro server that has an "Integrated Lights
Out"/iDrac/ServiceProcessor/IPMI interface?  Basically this is a small
embedded system on the motherboard that speaks http(s), and lets' you manage
the server remotely.  There are is also APIs into it, and you can do things
like install the machine, reboot it, etc.

Such systems could easily come with a built-in "Manufacturer Installed
Certificate" (aka "MIC", which is sadly, a really confusing TLA), except that
the machine will almost always be addressed by IP address, which will either
be SLAAC or RFC1918, and will seldom ever have a name ever, and certainly
won't have a name when first installed.

I see section 3.2.3 would let one have a SubjectAltName that looks like:
  eui-64+01-23-45-67-89-ab-cd-ef

or, I guess equally:
  eui-48+00-28-21-a7-5e-27

if my browser location tab were to say
   https://[somemagicsyntax/eui-48+00-28-21-a7-5e-27]
then we could dispense with a bunch of inappropriate security warnings.

Your document would help very much.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:16:14 +0000

Hi Stephen,

>I should also have mentioned link-local addresses too I guess.

v6 link-local make sense as stable identifiers, but they'd be equivalent
to EUI-64 (which is what 6.3.2 requires for the use case where all the
secure communication happens on the same subnet), only a few bytes larger
than their EUI counterpart.

Other kinds of IP addresses aren't long-term/stable enough to be put in a
certificate -- which is in line with the recommendation we give in CoAP
[https://tools.ietf.org/html/rfc7252#section-9.1.3.3].

Cheers, t