Re: [Dtls-iot] IP Addresses in Certificates

[Michael StJohns <[e-mail]>]

On 8/9/2015 9:02 PM, Stephen Farrell wrote:
> Hiya,
>
> On 07/08/15 15:21, Hannes Tschofenig wrote:
>> Hi Mike, Hi Stephen,
>>
>> I don't understand why we should make any recommendations for how to use
>> IP addresses in certificates.
> For which definition of "we"?
My guess is that he was referring to DICE given the mailing list...

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

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

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

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.


Going back to what I said before:

> So I think your recommendation of "future work needed" is probably more
> 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?

>
>> Regarding IEEE 802.1AR I don't believe it recommends using IP addresses
>> in certificates either.
> Which is entirely fine. There are definitely better ways of naming
> things than with addresses, esp relatively-scoped addresses.
>
>
> S.
>
>> Ciao
>> Hannes
>>
>> On 08/05/2015 09:48 PM, Michael StJohns wrote:
>>> 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)" <[e-mail]>
>>>>> *An:* "Stephen Farrell" <[e-mail]>, "Hannes Tschofenig"
>>>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>>>> *Betreff:* Re: [Dtls-iot] IP Addresses in Certificates
>>>>> Hi Stephen,
>>>>>
>>>>> On 15/07/2015 12:20, "dtls-iot on behalf of Stephen Farrell"
>>>>> <[e-mail] on behalf of [e-mail]>
>>>>> 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
>>>>>