Re: [Dtls-iot] IP Addresses in Certificates

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

On 8/5/2015 12:47 PM, Stephen Farrell wrote:
> Hiya,
>
> On 05/08/15 15:54, Hannes Tschofenig 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)
>
> 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)" <thomas.fossati@alcatel-lucent.com>
>> *An:* "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "Hannes Tschofenig"
>> <hannes.tschofenig@gmx.net>, "dtls-iot@ietf.org" <dtls-iot@ietf.org>
>> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates
>> Hi Stephen,
>>
>> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell"
>> <dtls-iot-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> 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
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>