Re: [Dtls-iot] IP Addresses in Certificates

[Hannes Tschofenig <[e-mail]>]

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:
> 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
>>>
>>> _______________________________________________
>>> dtls-iot mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>>
>> _______________________________________________
>> dtls-iot mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
> 
> _______________________________________________
> dtls-iot mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtls-iot