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

[peter van der Stok <[e-mail]>]

Hannes Tschofenig schreef op 2018-04-24 12:38:
> 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?

Hi Hannes,

thanks for the example.
I think a more simple and as unnerving example is the following.
Assume the RD has no registrations yet.
Device A registers multiple times with different ep and d values 
covering a large spectrum of the ep, d value space.
No other device will be able to register any more; all ep and d values 
are taken.

Same problem, correct?

Suppose A registers without ep and d values
Suppose the RD returns an encrypted identifier.
The encrypted identifier remains private to A.
Somewhere there should be a lookup identifier, for example an IP 
address, to be filled into the registration by A.
lookup identifier is needed because for example B wants to discover 
registrations with given attributes,
B needs the identifier to send requests to the associated discovered 
device.

And still A can create many registrations with as many possible IP 
addresses.

Do you agree, with the examples? Do you have a remedy?
I need to think a bit about it.

Peter


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