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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 May 2018 13:50:02 +0000

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.

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 7 May 2018 16:54:08 +0300

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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 May 2018 14:16:49 +0000

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:[email-masked]]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; [email-masked]
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

Hi Hannes,

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

--Mohit

Ciao
Hannes

core mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 7 May 2018 16:09:28 +0000

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:[email-masked]] Im Auftrag von Hannes Tschofenig
Gesendet: Montag, 7. Mai 2018 16:17
An: Mohit Sethi; [email-masked]
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:[email-masked]]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

Hi Hannes,

--Mohit

Ciao
Hannes

core mailing list

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 7 May 2018 20:59:52 +0300

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

On 05/07/2018 07:09 PM, Kovatsch, Matthias wrote:
>
> 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:[email-masked]] *Im Auftrag von *Hannes 
> Tschofenig
> *Gesendet:* Montag, 7. Mai 2018 16:17
> *An:* Mohit Sethi; [email-masked]
> *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:[email-masked]]
> *Sent:* 07 May 2018 15:54
> *To:* Hannes Tschofenig; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [core] Conclusion -- Endpoint Client Name / Endpoint 
> Name in RD draft
>
> Hi Hannes,
>
>     implications of sending an unauthenticated identifier..
>
>     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.
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 May 2018 08:54:32 +0200

> for more clear text about different possibilities (cf. certificate vs 

Samuel and I have thought about a similar issue in the ACE context (i.e. 
mapping PSK and RPK to endpoint identifiers, see 
https://tools.ietf.org/html/draft-erdtman-ace-rpcc-02).

For RPK I like the method implemented in Californium quite much (thanks 
Matthias I guess), based on RFC 6920 section 3 (ni URI format).

Here's the relevant text form our draft:

"Note to implementers: Authorization servers can use the following
    method to map a Raw Public Key to a client identifier: The client
    identifier is generated from the Raw Public Key using the procedure
    specified in section 3 of [RFC6920].  The digest is calculated on the
    Raw Public Key only (not on the SubjectPublicKeyInfo used in the
    handshake).  An example is shown in Figure 1."

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: peter van der Stok <[email-masked]>
Date: Tue, 08 May 2018 09:22:24 +0200

> particular used for lighting systems; maybe Peter can comment on this.

On request, some background.
For buildings, the installation is done by installation companies with 
their own tools and procedures.
Installation can be done in phases by different companies.
Their is at this moment not one general approach or installation 
protocol.

The problem is that the architect and people around have produced 
drawings with cabling and equipment situated at precise physical 
locations in the drawing.
Equipment, cabling etc are identified with numbers ,names, what have 
you.
There are descriptions which discuss the functionality and the relation 
between the equipment.
All this knowledge has to be transferred to the equipment without making 
too many "one of a kind" pieces.
In he "olde times" much was solved by the cabling, that limited the 
control possibilities.
These IP times, anything can reach anything else.
One approach is to store parts of this information into the RD, which 
can be queried by the equipment.

I hope this make the wish for an RD with third party access 
understandable.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 08 May 2018 09:35:43 +0200

Hi Hannes,

> implications of sending an unauthenticated identifier.

To summarize what I understand.
A token provided by the authorization server (AS) contains the 
authenticated endpoint value (eventually the domain value).
This endpoint value can be provided by the AS client or is provided by 
the AS.
Provision by the AS client makes the token larger.
> would suggest to make the endpoint name optional in the draft.

I probably misunderstand the meaning of optional.
What I understand from making ep optional,
is that ep is not returned in the lookup interface unless explicitly 
requested
Differentiation between registrations (endpoints) cannot be done by ep 
(,d) value, but should be done differently (how?).
> provisioning is actually something in this group has gained some

I sent an earlier e-mail about this subject, I hope it was clear enough
> Ciao

I am not clear how to go forward.
I could imagine an additional draft that specifies how to use RD with 
the AS and additional functionality needed in AS and RD.

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 May 2018 11:20:24 +0000

Peter,

I would personally feel more comfortable if we standardize functionality that some people have gained some experience already. If we don't involve the domain experts then we will most likely get it wrong.

What about separating this functionality from the RD draft, reach out to these companies, and then put the result of the investigations into a separate document? There are some folks in the group who work closely with indoor commercial lighting companies and they could for sure help.

Ciao
Hannes

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 08 May 2018 08:22
To: Kovatsch, Matthias
Cc: Hannes Tschofenig; Mohit Sethi; [email-masked]
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

On request, some background.
For buildings, the installation is done by installation companies with their own tools and procedures.
Installation can be done in phases by different companies.
Their is at this moment not one general approach or installation protocol.

The problem is that the architect and people around have produced drawings with cabling and equipment situated at precise physical locations in the drawing.
Equipment, cabling etc are identified with numbers ,names, what have you.
There are descriptions which discuss the functionality and the relation between the equipment.
All this knowledge has to be transferred to the equipment without making too many "one of a kind" pieces.
In he "olde times" much was solved by the cabling, that limited the control possibilities.
These IP times, anything can reach anything else.
One approach is to store parts of this information into the RD, which can be queried by the equipment.

I hope this make the wish for an RD with third party access understandable.
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.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 09 May 2018 10:02:56 +0200

Hi Hannes,

I share your concerns, But there are some additional aspects.
for 3rd party registration the con= is used.
con= will also be used to indicate alternative transports. Suppressing 
con= seems really a waste in this stage.
On the other hand, even suppressing con= for third parties, the anchor 
attribute also permits to refer to third parties. Removing the anchor 
attribute is cumbersome to say the least.

Possibly @others want to react.

For the moment using con= for 3rd party registration creates one 
registration at the time.
The Authorization server can also in this case assign endpoint values 
and prevent ep value stealing.

I will try to get some concrete feedback on 3rd party registration. I 
will keep you informed.

Peter

Hannes Tschofenig schreef op 2018-05-08 13:20:
> Peter,
> 
> I would personally feel more comfortable if we standardize
> functionality that some people have gained some experience already. If
> we don't involve the domain experts then we will most likely get it
> wrong.
> 
> What about separating this functionality from the RD draft, reach out
> to these companies, and then put the result of the investigations into
> a separate document? There are some folks in the group who work
> closely with indoor commercial lighting companies and they could for
> sure help.
> 
> Ciao
> Hannes
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 9 May 2018 08:20:29 +0000

Hi Peter,

I have not even looked at the con parameter but I wonder how well it can work in practice given firewalls and NATs...

Ciao
Hannes

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 09 May 2018 09:03
To: Hannes Tschofenig
Cc: [email-masked]; Kovatsch, Matthias; Mohit Sethi; [email-masked]
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

Hi Hannes,

I share your concerns, But there are some additional aspects.
for 3rd party registration the con= is used.
con= will also be used to indicate alternative transports. Suppressing con= seems really a waste in this stage.
On the other hand, even suppressing con= for third parties, the anchor attribute also permits to refer to third parties. Removing the anchor attribute is cumbersome to say the least.

For the moment using con= for 3rd party registration creates one registration at the time.
The Authorization server can also in this case assign endpoint values and prevent ep value stealing.

I will try to get some concrete feedback on 3rd party registration. I will keep you informed.

Peter

---

From: peter van der Stok <[email-masked]>
Date: Thu, 10 May 2018 09:28:12 +0200

Hannes Tschofenig schreef op 2018-05-09 10:20:
> Hi Peter,
> 
> I have not even looked at the con parameter but I wonder how well it
> can work in practice given firewalls and NATs...
> 
Hi Hannes,

some more background.
Resource Directory was originally foreseen to handle unicast resource 
discovery within a Lowpan.
Building installations foresee that the resources and the RD are all 
located within the same administration domain
(e.g. no NATs, or Firewalls between RD and interested endpoints.)
When services administered by the RD are accessed from outside the 
administration domain, the use of DNS is recommended.
For that reason we prepare the RD-DNS-SD draft.
When the Commissioning Tool is outside the administration domain (you 
never know), access from CT to the RD also should pass via DNS IMO.
Independent of the network location of the CT, the CT can for example 
fill link-local addresses into the RD, when RD and endpoints are all on 
the same link.

I think that the best way forward is indeed an additional secure RD 
draft.
I don't know what my co-authors or Matthias think.

Cheerio,

Peter

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 15 May 2018 07:28:36 +0000

> Von: core [mailto:[email-masked]] Im Auftrag von peter van der Stok

> What I understand from making ep optional, is that ep is not returned in the lookup interface unless explicitly requested Differentiation
> between registrations (endpoints) cannot be done by ep

To my understanding, the proposal is the following:

A registration can be done without the "ep" query parameter, iff the Endpoint Client Name can be derived in another way from the registration message. This way should (or I guess Hannes would say MUST) be the security context. In that sense, "ep" as registration query parameter becomes optional, but "ep" remains a central, mandatory attribute in the RD for each registered resource (used for endpoint lookup, filtering etc.).

Thanks Ludwig for your pointer how this could work.

@Hannes: Could you provide some more detail, how exactly the Endpoint Client Name is extracted from "security context"? Overall, I like this, but we should provide concrete text on how people should do it.

Best,
Matthias

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 May 2018 08:15:07 +0000

You want to store the security context on the server side and the Endpoint Client Name points to the identifier part of it.
(Other parts of the security context will be relevant for other purposes.)

 * For PSK-based credential the Endpoint Client Name becomes the PSK Identity
 * For raw-public keys the Endpoint Client Name becomes the SubjectPublicKeyInfo structure (or a hash of it).
 * For certificates the Endpoint Client Name becomes the leftmost CN component of subject name or the SubjectAltName of the certificate, depending on what you use.

Ciao
Hannes

---

From: peter van der Stok <[email-masked]>
Date: Wed, 23 May 2018 14:43:56 +0200

Hi Hannes and Matthias,

thanks for this e-mail and the later one by Hannes explaining the 
question below.
I have no problem with the proposed ep value handling as security 
identifier as explained in Hannes e-mail.
However, it will be useful that optionally in the token another ep-value 
and d-value are transported.
The larger token is acceptable in many cases where the installation 
management requires identifiers that correspond with the naming of the 
components of the installation.

Peter

Kovatsch, Matthias schreef op 2018-05-15 09:28:
>> What I understand from making ep optional, is that ep is not returned 
>> in the lookup interface unless explicitly requested Differentiation
> A registration can be done without the "ep" query parameter, iff the
> Endpoint Client Name can be derived in another way from the
> registration message. This way should (or I guess Hannes would say
> MUST) be the security context. In that sense, "ep" as registration
> query parameter becomes optional, but "ep" remains a central,
> mandatory attribute in the RD for each registered resource (used for
> endpoint lookup, filtering etc.).
> 
> 
> @Hannes: Could you provide some more detail, how exactly the Endpoint
> Client Name is extracted from "security context"? Overall, I like
> this, but we should provide concrete text on how people should do it.
> 
> Best,
> Matthias

---

From: peter van der Stok <[email-masked]>
Date: Wed, 23 May 2018 14:57:08 +0200

Hi Hannes,

I have had some feedback on the 3rd party registration and the use of 
con= parameter.
Third party registration is a "must" for building installation and 
people are counting on it.
It is especially (but not limited to) registering very small devices and 
sleeping devices.
There is an experimental installation in which 3rd party registration 
has been tried out with very positive results supporting the 
installation process quite naturally.

The experiment only concerns the functional aspects (that you 
challenged).
It is clear that the security aspects need to be considered in more 
detail.
However, it is generally considered that both the RD and the 
commissioning tool (3rd party) will not be (very) constrained. Some 
overhead for the larger tokens is certainly allowed.

I hope that we can conclude the discussion on the presence of 3rd party 
registration for the RD; and continue the security discussion.

Peter