Re: [core] Endpoint Client Name / Endpoint Name in RD draft

[Hannes Tschofenig <[e-mail]>]

Hi Peter,

The problem is actually documented in the security consideration section of the RD draft and I modified it slightly.

Consider the following threat: two devices A and B are managed by a single server.  Both devices have unique, per-device credentials for use with DTLS (or any other security protocol since there is nothing DTLS specific here).

Now, imagine that device A wants to sabotage device B.  Device A uses its own credentials during the DTLS exchange.  Then, device A puts the endpoint name of device B into the registration message.

If the RD server does not check whether the identifier provided in the DTLS handshake matches the endpoint name used at the CoAP layer in the registration message and if the server uses the endpoint name then device A can impersonate device B.

Does this concern make sense?

Ciao
Hannes


-----Original Message-----
From: peter van der Stok [mailto:[e-mail]]
Sent: 24 April 2018 16:28
To: Hannes Tschofenig
Cc: [e-mail]; Jaime Jiménez; [e-mail]
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft



Hannes Tschofenig schreef op 2018-04-23 05:08:
> Hi Peter,
>
> The mailing list discussion reconfirms my worry that people will get
> this wrong and will introduce security vulnerabilities.

Well, I'm one of those getting it wrong, because I did not understand the worry.

>
> I am saying that the security protocol used to protect the
> communication will have an authenticated identifier and this
> identifier then has to be used for identification of the IoT device.
> This identifier will then also be used for lookups .

This I understand. If I do clearly follow, guidelines must be produced about the use of authorized RD accesses.
Assume authorized access to the RD, using oauth-authz.
I do surmise that the registration may then return an signed identifier instead the path name of the registration.
The signed identifier can be used for updates.
The payload will be encrypted, and thus the actual use of ep, and d can be maintained as specified in the lookup, but are hidden to others.

Is that a correct extrapolated suggestion of your comments? probably there is a caveat I don't see.

>
> I am furthermore arguing that the multiple IoT device cannot share the
> same identifier.

sorry, what is a multiple IoT device? one with multiple registrations in the RD, or one with multiple links? or....

I agree with Jim that for third party registrations
> we cannot completely get rid of the endpoint client name/endpoint name
> functionality but for the third party registration you are most likely
> using a different approach anyway. I am not sure anyone using the RD
> specification for commissioning tool functionality today since the
> main purpose of the RD document is for something entirely different.

I do not agree with your conclusion. The use of RD is still being discussed as far as I know, and each SDO seems to have its own approach and use cases. The use of a CT is completely within scope to my knowledge.


Thanks hannes for your comments.
Looking forward to getting things more precise and understandable for me.

Peter

>
> Ciao
> Hannes
>
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: 09 April 2018 15:04
> To: Hannes Tschofenig
> Cc: Jaime Jiménez; [e-mail]
> Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
>
>>
>> I am curious what we lose if we remove this identifier altogether.
>> The only thing that comes to my mind is a debugging capability where
>> you might want to test your system without any security protocol.
> Hi Hannes,
>
> Probably, I completely misunderstand your suggestion.
> Registrations in the RD need identification so that they can be
> changed, removed , updated, etc...
> Registrations are identified by the (ep, d) pair, unique within a
> given RD.
> Removing ep identifier will force you to find another identifier for a
> registration.........
> and you are back to square 1 it seems.
>
>
> Peter
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.