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

[Hannes Tschofenig <[e-mail]>]

Hi Matthias,

I have doubts that anyone is using the third party registration functionality for a commissioning tool. Is Siemens or anyone else deploying this functionality? It would be interesting to get this input.

The requirement for applications using Endpoint Client Names that are different from the names in the device certificates/authentication credentials for registration appears fuzzy and not well justified. What identifier do you believe you can put in an endpoint client name but not in a security protocol or what are the needs of an application that cannot be met?

We have been working on LwM2M and have used a subset of the RD functionality for it. Sending an identifier in the security protocol and at the CoAP level (as part of the Endpoint Client Name in the registration) is also wasting bytes on the wire (in addition to the security implications).

Ciao
Hannes

-----Original Message-----
From: Kovatsch, Matthias [mailto:[e-mail]]
Sent: 26 April 2018 03:55
To: Hannes Tschofenig; Jim Schaad; 'Christian Amsüss'; [e-mail]; 'Carsten Bormann'
Cc: [e-mail]
Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft

Dear Hannes

My comment is that your solution to link the Endpoint Client Name to the registration authentication does not work for at least two of the desired use cases:
- A commissioning tool registering a device on its behalf, as the commissioning tool should not have the private keys or similar of the device.
- Applications using Endpoint Client Names that are different from the names in the device certificates/authentication credentials for registration

I fully agree with you, however, that the RD must clearly state that the registering entity must proof that it is authorized to use the Endpoint Client Name it registers. This might have been too implicit so far and there definitely was not enough work to figure this out fully. There are several ways how to do this; I think we should not limit it to just one simple way that breaks at least two use cases. But we can give it, for instance, as minimum MUST when there is no other way to proof authorization to use the Endpoint Client Name for registration.

One more generic way could be to require device and registering entity to be within the same domain, so that "d" can be authenticated. A commissioning tool would need to authenticate its domain, but then can use any Endpoint Client Name within this domain.

Ciao,
Matthias


> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[e-mail]]
> Gesendet: Dienstag, 24. April 2018 12:49
> An: Kovatsch, Matthias (CT RDA IOT EWT-DE); Jim Schaad; 'Christian Amsüss'; [e-mail]; 'Carsten Bormann'
> Cc: [e-mail]
> Betreff: RE: [core] Endpoint Client Name / Endpoint Name in RD draft
>
> Hi Matthias
>
> I fear that you are creating security holes that will be very difficult to fix afterwards.
> It just feels that these are "nice ideas" with limited practical
> experience. Very much like the idea of doing the third party registration with the commissioning tool as defined in the RD specification.
>
> Ciao
> Hannes
>
>
> -----Original Message-----
> From: Kovatsch, Matthias [mailto:[e-mail]]
> Sent: 23 April 2018 19:17
> To: Hannes Tschofenig; Jim Schaad; 'Christian Amsüss'; [e-mail]; 'Carsten Bormann'
> Cc: [e-mail]
> Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft
>
> > Von: Hannes Tschofenig [mailto:[e-mail]]
> > > Applications will use the application-defined identifier, not a handle generated by the RD, not the security context.
> >
> > Who says that? If applications make security decisions based on unauthenticated parameters then they will be toast.
>
> I am not saying they should not authenticate.
> I am saying that the identifier might be different for authorizating
> the registration and lookup by applications. They must be correlatable
> of course; them being the same is a special case, that could be desirable. Yet someone who is authenticated and authorized should be allowed to introduce additional identifiers.
>
> Ciao,
> Matthias
>
> 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.