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

[Hannes Tschofenig <[e-mail]>]

Hi Peter,

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?

[Hannes] Yes.

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.

[Hannes] RD does not provide such encrypted identifier and hence the example is not valid.


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

[Hannes] The problem goes away when we use the authenticated identifier used by the security protocol.

Ciao
Hannes


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