[core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

[Hannes Tschofenig]

I was referring to this functionality: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5.3.2


From: Mohit Sethi [mailto:***@ericsson.com]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; ***@ietf.org
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft


Hi Hannes,

Thank you for summarizing the discussion on this important topic thus far.

Could you also very briefly explain what does third-party provisioning mean for you?

--Mohit

On 05/07/2018 04:50 PM, Hannes Tschofenig wrote:
Hi all,

I hope that all the discussion around the endpoint name / endpoint client name have helped to make you think about the security implications of sending an unauthenticated identifier.

I would like to come to a conclusion and here is my attempt.

Since we the RD document also defines the third party provisioning I would suggest to make the endpoint name optional in the draft.

I would also encourage the chairs to find out whether the third party provisioning is actually something in this group has gained some experience with..

Ciao
Hannes

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.



_______________________________________________

core mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/core

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.

[Kovatsch, Matthias]

Dear Hannes,
dear list

To my knowledge, third-party provisioning functionality is in particular used for lighting systems; maybe Peter can comment on this. I am aware of a few business units that would also want to have this functionality in the RD.. Furthermore, I have use cases for Web Things that provide a REST interface, but do not implement RD registration; with the third-party provisioning they can become part of CoRE environments as well.


Making the Endpoint Client Name optional is a good solution in my opinion, when it is clearly defined which security protocol identifiers shall be taken as Endpoint Client Name. I am not even sure if I understand the current "mostly mandatory" correctly). Overall, it would be good to describe the usage of security context well, as there are different possibilities (cf. certificate vs Raw Public Key vs PSK).

Furthermore, the draft is a bit too fuzzy about the authorization, in particular for registration. It feels obvious that also third-party provisioning needs to be authorized to use the Endpoint Client Name to be registered, but hearing Hannes's concerns, it probably should be stated concretely. The role of Domain is also rather implicit here; to my understanding, there can be duplicate Endpoint Client Names as long as they have different Domains.

Kind regards,
Matthias


Von: core [mailto:core-***@ietf.org] Im Auftrag von Hannes Tschofenig
Gesendet: Montag, 7. Mai 2018 16:17
An: Mohit Sethi; ***@ietf.org
Betreff: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

I was referring to this functionality: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5..3.2<https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5.3.2>


From: Mohit Sethi [mailto:***@ericsson.com]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft


Hi Hannes,

Thank you for summarizing the discussion on this important topic thus far.

Could you also very briefly explain what does third-party provisioning mean for you?

--Mohit

On 05/07/2018 04:50 PM, Hannes Tschofenig wrote:
Hi all,

I hope that all the discussion around the endpoint name / endpoint client name have helped to make you think about the security implications of sending an unauthenticated identifier.

I would like to come to a conclusion and here is my attempt.

Since we the RD document also defines the third party provisioning I would suggest to make the endpoint name optional in the draft.

I would also encourage the chairs to find out whether the third party provisioning is actually something in this group has gained some experience with..

Ciao
Hannes

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.


_______________________________________________

core mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/core

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.

[Mohit Sethi]

Hi Matthias,

Thanks for bringing forward the use-case.

I have implemented an earlier version of the RD. I agree, the current
text on "mostly mandatory" leaves much to be desired. And +1 on request
for more clear text about different possibilities (cf. certificate vs
Raw Public Key vs PSK).

--Mohit

Post by Kovatsch, Matthias
Dear Hannes,
dear list
To my knowledge, third-party provisioning functionality is in
particular used for lighting systems; maybe Peter can comment on this.
I am aware of a few business units that would also want to have this
functionality in the RD. Furthermore, I have use cases for Web Things
that provide a REST interface, but do not implement RD registration;
with the third-party provisioning they can become part of CoRE
environments as well.
Making the Endpoint Client Name optional is a good solution in my
opinion, when it is clearly defined which security protocol
identifiers shall be taken as Endpoint Client Name. I am not even sure
if I understand the current “mostly mandatory” correctly). Overall, it
would be good to describe the usage of security context well, as there
are different possibilities (cf. certificate vs Raw Public Key vs PSK).
Furthermore, the draft is a bit too fuzzy about the authorization, in
particular for registration. It feels obvious that also third-party
provisioning needs to be authorized to use the Endpoint Client Name to
be registered, but hearing Hannes’s concerns, it probably should be
stated concretely. The role of Domain is also rather implicit here; to
my understanding, there can be duplicate Endpoint Client Names as long
as they have different Domains.
Kind regards,
Matthias
Tschofenig
*Gesendet:* Montag, 7. Mai 2018 16:17
*Betreff:* Re: [core] Conclusion -- Endpoint Client Name / Endpoint
Name in RD draft
https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5...3.2
<https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5.3.2>
*Sent:* 07 May 2018 15:54
*Subject:* Re: [core] Conclusion -- Endpoint Client Name / Endpoint
Name in RD draft
Hi Hannes,
Thank you for summarizing the discussion on this important topic thus far.
Could you also very briefly explain what does third-party provisioning mean for you?
--Mohit
Hi all,
I hope that all the discussion around the endpoint name / endpoint
client name have helped to make you think about the security
implications of sending an unauthenticated identifier..
I would like to come to a conclusion and here is my attempt.
Since we the RD document also defines the third party provisioning
I would suggest to make the endpoint name optional in the draft.
I would also encourage the chairs to find out whether the third
party provisioning is actually something in this group has gained
some experience with.
Ciao
Hannes
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
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.
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core