Subject: Re: [Dtls-iot] IP Addresses in Certificates

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 5 Aug 2015 16:54:44 +0200

Hi Stephen,

reading through this issue again I believe you could help us further explain what we could recommend in the document.

Currently, we are saying that folks shouldn't use IP addresses in certificates and in the email below Thomas mentioned one reason for doing so. I also pointed to a separate draft we have been working on to explore the topic further (see <draft-fossati-core-certmode-rd-names-01>).

Ciao

Hannes

Gesendet: Dienstag, 21. Juli 2015 um 14:16 Uhr

Von: "FOSSATI, Thomas (Thomas)" <[email-masked]>

An: "Stephen Farrell" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, "[email-masked]" <[email-masked]>

Betreff: Re: [Dtls-iot] IP Addresses in Certificates

Hi Stephen,

On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell"

<[email-masked] on behalf of [email-masked]> wrote:

>Hiya,

>On 15/07/15 12:07, Hannes Tschofenig wrote:

>> 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?

>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

_______________________________________________

dtls-iot mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 17:47:23 +0100

Hiya,

> what we could recommend in the document.

Assuming that it'd be a bunch of work to recommend how to best
handle certificates for devices that will only ever have a bogon
IP address, I guess the best for now is to just say that that work
is not (yet) done and hence this document makes no recommendation.

Seem ok? (And yes it could be that the current text on that
is just fine, I didn't go look back right now)

S.

> Currently, we are saying that folks shouldn't use IP addresses in certificates 
> and in the email below Thomas mentioned one reason for doing so. I also pointed 
> to a separate draft we have been working on to explore the topic further (see 
> <draft-fossati-core-certmode-rd-names-01>).
> Ciao
> Hannes
> *Gesendet:* Dienstag, 21. Juli 2015 um 14:16 Uhr
> *Von:* "FOSSATI, Thomas (Thomas)" <[email-masked]>
> *An:* "Stephen Farrell" <[email-masked]>, "Hannes Tschofenig" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates
> Hi Stephen,
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 5 Aug 2015 15:48:15 -0400

Hi Stephen et al.

I'm coming in on this fairly late (2 weeks) so let me try and muddy the 
waters:

IEEE 802.1AR is a good source for ideas of how to deal with certificates 
and small devices.   In the case of Zigbee Smart Energy 2.0 for example, 
we use their concepts of LDevID  (Locally significant) and IDevID 
(Initial) device identifiers.  The latter is what gets built into the 
device and SEP2.0 uses the SubjectAltName hardwareModuleName in RFC4108 
as the manufactured in name for the device.  The attachment of a 
certificate to MAC address or even IP address by the manufacturer has a 
number of issues that are painful to address and that don't usually add 
to the security of the system.  (e.g. the handle of the name mostly 
isn't important to the underlying protocols in IOT and the relationship 
between an entity and its IP or MAC generally isn't a necessary 
consideration for trust between entities given certificates - same 
reason that client certificates for TLS rarely have IP addresses in 
them, but do have human personal names or email addresses).

Ideally you want a mapping between what's on the certificate inside the 
device and what's on the label outside - so that humans can basically 
type things in (or barcode them or....) during installation.  I might 
expect a local trust center to issue an LDevID based on the (manual?) 
acceptance of IDevID, and the LDevID *could* contain an IP address as a 
SubjectAltName, but I don't think we've gone that deep and most folk 
balk at running a Mini-CA in their home.

So I think your recommendation of "future work needed" is probably more 
correct than "IP certificates needed".

Later, Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 15:41:05 -0400

Stephen Farrell <[email-masked]> wrote:
    >> Hi Stephen, reading through this issue again I believe you could help
    >> us further explain what we could recommend in the document.

    > Assuming that it'd be a bunch of work to recommend how to best handle
    > certificates for devices that will only ever have a bogon IP address, I
    > guess the best for now is to just say that that work is not (yet) done
    > and hence this document makes no recommendation.

    > Seem ok? (And yes it could be that the current text on that is just
    > fine, I didn't go look back right now)

okay, but we need to do this work for ANIMA, and other places.

I wrote:
  http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-cert/

But elsewhere in this thread I mentioned a current killer-app need for
this is with service processors (ILOM/iDRAC/...) which seldom have anything
other than a rfc1918 dhcp address, and really, the browser location bar
should show the end user the vendor and mac address of the unit, not the IP
address.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 07 Aug 2015 16:21:25 +0200

Hi Mike, Hi Stephen,

I don't understand why we should make any recommendations for how to use
IP addresses in certificates.

IP addresses in certificates are not useful for end devices since their
IP addresses is most likely not known during manufacturing nor does it
add any security value.

Regarding IEEE 802.1AR I don't believe it recommends using IP addresses
in certificates either.

Ciao
Hannes

On 08/05/2015 09:48 PM, Michael StJohns wrote:
>>> reading through this issue again I believe you could help us further
>>> explain
>>> what we could recommend in the document.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 07 Aug 2015 16:24:33 +0200

Hi Michael,

could you explain the idea behind draft-richardson-6tisch-idevid-cert?

I don't see how it relates to Stephen's request to add a description on
how to use IP addresses in certificates for the DTLS/TLS IoT profiles
draft.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2015 13:47:07 -0400

> how to use IP addresses in certificates for the DTLS/TLS IoT profiles

1) I rather agree that putting IP addresses in certificates is not useful.

2) I would prefer to see manufacturer installed certificates with something
   else in them, such as 802.1AR with a clear serial number that would
   be replaced by an LDevID certificate during a bootstrap process.

   The idevid-cert document goes a step further and suggests
   how the device with the installed certificate will validate the peer
   that it interacts with in much the same way that RPKI has been setup.
   I would claim that this is actually more important than what's in
   the device.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Aug 2015 02:02:03 +0100

Hiya,

> IP addresses in certificates.

For which definition of "we"?

I guess it is maybe wrong to consider the DICE WG doing this, but my
comment was really asking the question and not insisting on a given
answer.

> IP addresses is most likely not known during manufacturing nor does it

Fair point.

OTOH, there will be devices whose only visible identifier is an IP
address, right? If so, and if certificates/DTLS are to be of use with
such devices... then what? I do think some variety of "we" ought try
to address this problem.

> Regarding IEEE 802.1AR I don't believe it recommends using IP addresses

Which is entirely fine. There are definitely better ways of naming
things than with addresses, esp relatively-scoped addresses.

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 12:43:08 +0200

Hi Stephen,

> such devices... then what? I do think some variety of "we" ought try

I don't think that there are devices that have no other identifiers than
IP addresses. For example, if a device has a network interface it will
also have a MAC address. There will also be an application sitting on
top of the stack that might introduce identifiers.

Even beacons have identifiers (although they are not identifying
individual devices themselves).

As a software / hardware engineer you will have to figure out what
hardware components and what firmware you put on the device. As such, it
is useful to think about these types of things early, which the document
should be able to do.

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Aug 2015 11:50:05 +0100

On 11/08/15 11:43, Hannes Tschofenig wrote:
> also have a MAC address. 

My hope is that 802 move more and more towards non-static or random
MAC addresses.

> There will also be an application sitting on

Sure, they "might" :-) And if they do, then for sure there shouldn't
be any reason to put an IP address for such a device in a certificate.

My point is that there will be devices where the IP address is the
only reliably-present publicly (maybe public==on-LAN here) visible
identifier and where we'd like to use (D)TLS to talk to that device.
And we have no guidance for that case, and we do have a bunch of
gotchas and pitfalls.

> is useful to think about these types of things early, which the document

Again, I'm not saying this document ought say what to do about
a certificate for 10.0.0.1. But again "we" probably should think
about that for some definition of "we" that is a subset of the
IETF I reckon. (Unless someone else has done a good job already
in which case that's fine.)

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Aug 2015 13:23:15 +0200

Hi Stephen,

> My hope is that 802 move more and more towards non-static or random

Me too but then we (in the IETF) just replace it with something static
at the IP layer (as we managed to remove the randomized IPv6 interface
generation via 6lo....).

> And we have no guidance for that case, and we do have a bunch of

Here is the additional challenges:
1) When are the certificates generated?
2) When are the IP address assignment happens?

If the certificates are generated during the manufacturing time then the
IP address cannot be know. So, what IP address are you going to put in
there?

May I assume that the certificate enrolment request is done using some
protocol during the deployment (such as with EST) then the IoT devices
provides the currently assigned IP address to the enrolment server to
get the certificate back?

Would this mean that every time the IoT device gets a new IP address it
has to request a new certificate?

If not, would we just assume that the IP address in the certificate has
no relationship to what is contained in the certificate?

If we talk about IPv6 addresses why wouldn't we just put the IID into
the certificate rather than the full IP address (assuming that the IID
does not change for certain deployments)?

Ciao
Hannes

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Aug 2015 10:47:16 -0400

> For which definition of "we"?
My guess is that he was referring to DICE given the mailing list...

> comment was really asking the question and not insisting on a given

I didn't take your question as rhetorical either....

> such devices... then what? I do think some variety of "we" ought try

I don't think that's ever correct.  The most visible identifier is 
generally going to be the L2 address which will generally be fixed from 
manufacturing.  But that's immaterial as what's important is not the 
network visible identity, but the identity the device uses for its 
connection to the network and to IOT services.

802.1AR uses the Manufacturer device type OID/Serial number pair as the 
recommended identity for manufactured in certificates and that makes a 
lot of sense as both of those are human usable and tend to also be on 
the label on the device or device box.  That makes it pretty easy to add 
them to access control lists in the IOT services server or to provide a 
secondary (and revokable) credential (after verifying the primary 
manufacturer/serial credential) that the device can use to connect to 
the network or local IOT servers.

> correct than "IP certificates needed".

So I think we should close out this item for DICE.

But might it be a better item for ACE?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2015 11:29:59 -0400

Stephen Farrell <[email-masked]> wrote:
    > address, right?

I'm not sure that I agree.
I'm hard pressed to point a device that will have a stable IP address
that won't also have a stable name.  It might be interesting to figure out
how we can do things like put "printer.local" into a certificate...

If only we had SPKI, then you could say:
   (tcd's stephen.farrell's printer)