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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Apr 2018 13:41:22 +0000

Hi all,

I noticed that the term "endpoint name" is used in the IETF RD draft while the OMA LwM2M spec uses the term "endpoint client name". Endpoint is a confusing term since it is used differently in the CoAP spec than in the Web environment.

For this reason I believe it would be better to use the term "endpoint client name" also in the RD draft. This would improve alignment between the two specs.

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: Jaime Jiménez <[email-masked]>
Date: Wed, 4 Apr 2018 14:31:49 +0000

Hi,

Note that endpoint can refer to both source and destination, being and IP:port in its simplest form: 
https://tools.ietf.org/html/rfc7252#page-6 <https://tools.ietf.org/html/rfc7252#page-6> 

The fact that LWM2M swaps those role names might actually add to the confusion, probably OMA LWM2M should be the one changing the terminology as the device is mostly a “server” hosting resources and only is a “client” during bootstrapping and registration. We could have used terms like “servient” instead but it might be too late for that.

Ciao!
- - Jaime Jiménez

> On 4 Apr 2018, at 16.41, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all, 
>  
> I noticed that the term “endpoint name” is used in the IETF RD draft while the OMA LwM2M spec uses the term “endpoint client name”. Endpoint is a confusing term since it is used differently in the CoAP spec than in the Web environment.
>  
> For this reason I believe it would be better to use the term “endpoint client name” also in the RD draft. This would improve alignment between the two specs.
>  
> 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] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Apr 2018 17:40:40 +0000

Hi Jaime,

using IP address and port for an endpoint (client) name would not be a good idea.
In general, it was not a good idea to have this parameter defined in the first place. It might actually be better to remove it altogether.

Ciao
Hannes

From: Jaime Jiménez [mailto:[email-masked]]
Sent: 04 April 2018 17:32
To: Hannes Tschofenig
Cc: [email-masked] WG; Carsten Bormann
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi,

Note that endpoint can refer to both source and destination, being and IP:port in its simplest form:
https://tools.ietf.org/html/rfc7252#page-6

Ciao!
- - Jaime Jiménez

On 4 Apr 2018, at 16.41, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 4 Apr 2018 11:05:41 -0700

Hannes,

I am not completely clear.  Are you saying that the RD should not have the endpoint name parameter as a defined property or something else?

Jim

From: core <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 4, 2018 10:41 AM
To: Jaime Jiménez <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Jaime, 

Ciao

Hannes

From: Jaime Jiménez [mailto:[email-masked]] 
Sent: 04 April 2018 17:32
To: Hannes Tschofenig
Cc: [email-masked] <mailto:[email-masked]>  WG; Carsten Bormann
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi,

Ciao!

- - Jaime Jiménez

On 4 Apr 2018, at 16.41, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Hi all, 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Apr 2018 19:01:29 +0000

Hi Jim,

I had various comments:

First, I argue that the LwM2M spec and the RD draft should be in sync regarding the name of the parameter.

Second, I believe that the security consideration section is correct in the threat description but came to the wrong conclusion regarding the use of the parameter. In essence, the parameter should be optional and probably only used for debugging.

Third, I went as far as saying that the endpoint name parameter should actually be removed altogether. I can already see how those deploying it will get it wrong and will introduce security problems.

Ciao
Hannes

From: Jim Schaad [mailto:[email-masked]]
Sent: 04 April 2018 21:06
To: Hannes Tschofenig; 'Jaime Jiménez'
Cc: [email-masked]
Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft

Hannes,

Jim

From: core <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 4, 2018 10:41 AM
To: Jaime Jiménez <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Jaime,

Ciao
Hannes

From: Jaime Jiménez [mailto:[email-masked]]
Sent: 04 April 2018 17:32
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]> WG; Carsten Bormann
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi,

Ciao!
- - Jaime Jiménez

Hi all,

Ciao
Hannes

---

From: Jaime Jiménez <[email-masked]>
Date: Thu, 5 Apr 2018 05:52:14 +0000

Hi,

You mean we should remove the “endpoint name” altogether, so not using URNs to identify CoAP endpoints for example?

The rationale for using endpoint name was at least discussed in 2014, back then it seemed useful in the context of LWM2M.

http://ietf.org/mail-archive/web/core/current/msg05645.html

Ciao!

El 4 abr 2018, a las 22:01, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> escribió:

Hi Jim,

I had various comments:

Ciao
Hannes

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

Hannes,

Jim

Hi Jaime,

Ciao
Hannes

Hi,

Ciao!
- - Jaime Jiménez

Hi all,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Apr 2018 10:02:44 +0000

Hi Jaime,

Thanks for the pointer to earlier discussions on this topic.

Looking at the discussions from 2014 it appears that there is some misunderstanding of how this endpoint name interacts with the security protocol and what vulnerabilities are created by relying on an identifier that is unauthenticated.

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. In any practical deployment I would not recommend to use RD without security.

Ciao
Hannes

From: Jaime Jiménez [mailto:[email-masked]]
Sent: 05 April 2018 07:52
To: Hannes Tschofenig
Cc: Jim Schaad; [email-masked]
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi,

You mean we should remove the "endpoint name" altogether, so not using URNs to identify CoAP endpoints for example?

Ciao!

I had various comments:

Ciao
Hannes

Hannes,

Jim

Hi Jaime,

Ciao
Hannes

Hi,

The fact that LWM2M swaps those role names might actually add to the confusion, probably OMA LWM2M should be the one changing the terminology as the device is mostly a "server" hosting resources and only is a "client" during bootstrapping and registration. We could have used terms like "servient" instead but it might be too late for that.

Ciao!
- - Jaime Jiménez

Hi all,

Ciao
Hannes

---

From: Jim Schaad <[email-masked]>
Date: Fri, 6 Apr 2018 22:08:27 -0700

Hannes,

I have been thinking about this both from what you said, but also from the
point of view that I have been trying to figure out how to get security
implemented for a resource directory and how to specify the what the set of
legal security options would be for a registration.

I agree that it makes no sense for an endpoint registering itself to provide
an endpoint name, this should be inferred from the security context.
However, the parameter is needed for third party registrations.  If you have
somebody registering a set of end points, the security context might say
that you can register any endpoint matching floor3-* 

My initial idea was to just use the path + queries to control access so

/rd/ep-register?ep=device1

However, I am now trying to deal with the difference between, if present it
must be this vs if present it must be this, if not present then default to
this.

Jim

From: Hannes Tschofenig <[email-masked]> 
Sent: Thursday, April 5, 2018 3:03 AM
To: Jaime Jiménez <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]
Subject: RE: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Jaime, 

Looking at the discussions from 2014 it appears that there is some
misunderstanding of how this endpoint name interacts with the security
protocol and what vulnerabilities are created by relying on an identifier
that is unauthenticated. 

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. In any practical
deployment I would not recommend to use RD without security.

Ciao

Hannes

From: Jaime Jiménez [mailto:[email-masked]] 
Sent: 05 April 2018 07:52
To: Hannes Tschofenig
Cc: Jim Schaad; [email-masked] <mailto:[email-masked]> 
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi,

You mean we should remove the “endpoint name” altogether, so not using URNs
to identify CoAP endpoints for example? 

The rationale for using endpoint name was at least discussed in 2014, back
then it seemed useful in the context of LWM2M.

Ciao!

El 4 abr 2018, a las 22:01, Hannes Tschofenig <[email-masked]
<mailto:[email-masked]> > escribió:

Hi Jim, 

I had various comments: 

First, I argue that the LwM2M spec and the RD draft should be in sync
regarding the name of the parameter. 

Second, I believe that the security consideration section is correct in the
threat description but came to the wrong conclusion regarding the use of the
parameter. In essence, the parameter should be optional and probably only
used for debugging. 

Third, I went as far as saying that the endpoint name parameter should
actually be removed altogether. I can already see how those deploying it
will get it wrong and will introduce security problems. 

Ciao

Hannes

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

Hannes,

I am not completely clear.  Are you saying that the RD should not have the
endpoint name parameter as a defined property or something else?

Jim

From: core <[email-masked] <mailto:[email-masked]> > On Behalf
Of Hannes Tschofenig
Sent: Wednesday, April 4, 2018 10:41 AM
To: Jaime Jiménez <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  WG <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Jaime, 

using IP address and port for an endpoint (client) name would not be a good
idea. 

In general, it was not a good idea to have this parameter defined in the
first place. It might actually be better to remove it altogether. 

Ciao

Hannes

Hi,

Note that endpoint can refer to both source and destination, being and
IP:port in its simplest form: 

The fact that LWM2M swaps those role names might actually add to the
confusion, probably OMA LWM2M should be the one changing the terminology as
the device is mostly a “server” hosting resources and only is a “client”
during bootstrapping and registration. We could have used terms like
“servient” instead but it might be too late for that.

Ciao!

- - Jaime Jiménez

On 4 Apr 2018, at 16.41, Hannes Tschofenig <[email-masked]
<mailto:[email-masked]> > wrote:

Hi all, 

I noticed that the term “endpoint name” is used in the IETF RD draft while
the OMA LwM2M spec uses the term “endpoint client name”. Endpoint is a
confusing term since it is used differently in the CoAP spec than in the Web
environment.

For this reason I believe it would be better to use the term “endpoint
client name” also in the RD draft. This would improve alignment between the
two specs.

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

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.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 09 Apr 2018 10:04:07 +0200

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Apr 2018 10:14:54 +0200

On Apr 9, 2018, at 10:04, peter van der Stok <[email-masked]> wrote:
> 
> Removing ep identifier will force you to find another identifier for a registration.........

I read Hannes’ proposal as “server [RD] always selects the endpoint name” (as opposed to what is in section 5.3, where the client provides an endpoint name).

The argument seems to be that if a client holds an authorization to register at an RD, that authorization may imply a specific endpoint name.  (I’m not sure that is always true, as the authorization may be based on a claim that does not happen to provide an obvious candidate for that.)

To discuss this further, we’ll need to discuss authorization models for RD access.  Maybe high time in any case…

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 13 Apr 2018 17:11:23 +0200

> removed , updated, etc...

Well, the manipulation (change, removal, update) already happens
independently of the endpoint name or domain; that is just bound to the
registration resource.

In the current text, we allow that the endpoint name is not given at
registration time if it is explicitly configured and the RD can
recognize the endpoint by its security context.

> Registrations are identified by the (ep, d) pair, unique within a given RD.

In any authenticated context, that can identifier can be the security
context. How that can be expressed at lookup is an open question.
An endpoint name string can be what glues those together.

On Mon, Apr 09, 2018 at 10:14:54AM +0200, Carsten Bormann wrote:
> The argument seems to be that if a client holds an authorization to
> register at an RD, that authorization may imply a specific endpoint
> name.  (I’m not sure that is always true, as the authorization may be
> based on a claim that does not happen to provide an obvious candidate
> for that.)
> 
> To discuss this further, we’ll need to discuss authorization models
> for RD access.  Maybe high time in any case…

Could everybody maybe sketch how they'd express the permissions they
would like to set on their RDs?

I'll start with some arbitrary ones that might be useful (at least with
some help from Cunningham's Law):

TrustTheWebCAs: "This RD accepts any registration, provided who
registers can present a X509 certificate chain to my system certificates
that carries a Common Name or Subject Alternative Name that matches the
host name they give in their con".

RequireEKU: "Like TrustTheWebCAs, and if it wants to set an endpoint
type (et=), that must be justified by an Extended Key Usage in the
certificate."

EPFromACE: "This RD uses /reg/${domain}/${endpoint} as registration
URIs. An endpoint can only register if it holds an ACE-AIF token to POST
to that resource issued by my Authorization Server (AS)."

PNFromACE: "This RD allows registration of arbitrary endpoints, but
advertising an at=... (registration) or ol=... (link) attribute (see
core-protocol-negotiation) requires that that value is contained in an
ACE token from my AS."

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Apr 2018 12:30:52 -0700

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Christian Amsüss
> Sent: Friday, April 13, 2018 8:11 AM
> To: [email-masked]; Carsten Bormann <[email-masked]>
> Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
> > > 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.
> >
> > Registrations in the RD need identification so that they can be
> > changed, removed , updated, etc...
> 
> registration time if it is explicitly configured and the RD can recognize the
> endpoint by its security context.
> 
> In any authenticated context, that can identifier can be the security context.
> How that can be expressed at lookup is an open question.
> I'll start with some arbitrary ones that might be useful (at least with some
> help from Cunningham's Law):
> 
> TrustTheWebCAs: "This RD accepts any registration, provided who registers
> can present a X509 certificate chain to my system certificates that carries a
> Common Name or Subject Alternative Name that matches the host name
> they give in their con".

TrustTheWebCAs + GodBit: This RD accepts any registration, provided who registers can present an X509 certificate chain to my system certificates that carries a common or alternative name (or maybe an EKU) that matches to the God criteria.

> 
> RequireEKU: "Like TrustTheWebCAs, and if it wants to set an endpoint type
> (et=), that must be justified by an Extended Key Usage in the certificate."

I would probably generalize this rule to - The RD may extract additional information from the certificate beyond the naming to either enforce or supplement attributes set such as endpoint types or domains.

> 
> EPFromACE: "This RD uses /reg/${domain}/${endpoint} as registration URIs.
> An endpoint can only register if it holds an ACE-AIF token to POST to that
> resource issued by my Authorization Server (AS)."

EPFromACE2:  This RD uses /reg?ep=${endpoint}&d=${domain} as registration URIs.  An endpoint can only register if it holds an ACE-AIF token to POST to that resource issued by my Authorization Server (AS).  The token may contain values for fields in the URI-queries which are to be either enforced, or set if not present in the registration request.  Examples are ep, d, et.

> core-protocol-negotiation) requires that that value is contained in an ACE
> token from my AS."

RSFromACE: This RD allows registration of endpoints, but restricts the resources that can be registered.  All resources registered must be filtered by matching one of a number of patterns potentially with values that can be defaulted in.

Jim

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Fri, 20 Apr 2018 15:46:20 +0000

Dear list

"ep" is an application-defined identifier for the registered endpoint. It is a parameter for registration, but also a target attribute that will have the same value. The RD must store the "ep" parameter for each registered endpoint and attach it as target attribute to all the corresponding links it returns. As Peter stated, when "ep" is not unique, the client must also provide "d", which must be processed similarly by the RD.

As target parameter, it is used during lookup. Applications will use the application-defined identifier, not a handle generated by the RD, not the security context. When a commissioning tool is registering an endpoint, the security context is also different from the endpoint's security context, and hence it cannot be used as endpoint identifier.

As a result, "ep" must not be removed.

I think "ep", just like the other registration parameters that are also target attributes, should receive its own sub-section with a proper definition and explanation.

Related to this is the proper definition of "ins", which unfortunately was moved over to the core-rd-dns-sd draft. "ins" is used to distinguish resources with the same "rt". Originally, it was used for resource within the same device (e.g., </t1>;rt=temperature;ins=indoor,</t2>;rt=temperature;ins=outdoor). By now, it often is assumed to require global uniqueness. I claim that this is not required when "ep" is used correctly. Using a hierarchy of "d" -> "ep" -> "ins" provides more flexibility than making "ins" globally unique. "ins" can still have a global meaning (cf. indoor vs outdoor), but it should be re-usable for all resources with similar instance semantics. Uniqueness is achieved through "d" and "ep".

I think "ins" should become part of the RD draft again to be defined together with "d" and "ep", as they are part of a larger discovery framework.

Best wishes,
Matthias

> -----Ursprüngliche Nachricht-----
> Von: core [mailto:[email-masked]] Im Auftrag von Jim Schaad
> Gesendet: Sonntag, 15. April 2018 21:31
> An: 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'
> Cc: 'Hannes Tschofenig'; [email-masked]
> Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> 
> 
> > > > The only thing that comes to my mind is a debugging capability
> > > > where you might want to test your system without any security protocol.
> > >
> > independently of the endpoint name or domain; that is just bound to
> > the registration resource.
> >
> > > name.  (I’m not sure that is always true, as the authorization may
> > > be based on a claim that does not happen to provide an obvious
> > > candidate for that.)
> > >
> > I'll start with some arbitrary ones that might be useful (at least
> > with some help from Cunningham's Law):
> >
> > registers can present a X509 certificate chain to my system
> > certificates that carries a Common Name or Subject Alternative Name
> > that matches the host name they give in their con".
> 
> TrustTheWebCAs + GodBit: This RD accepts any registration, provided who registers can present an X509 certificate chain to my
> system certificates that carries a common or alternative name (or maybe an EKU) that matches to the God criteria.
> 
> >
> > type (et=), that must be justified by an Extended Key Usage in the certificate."
> 
> I would probably generalize this rule to - The RD may extract additional information from the certificate beyond the naming to either
> enforce or supplement attributes set such as endpoint types or domains.
> 
> >
> > An endpoint can only register if it holds an ACE-AIF token to POST to
> > that resource issued by my Authorization Server (AS)."
> 
> EPFromACE2:  This RD uses /reg?ep=${endpoint}&d=${domain} as registration URIs.  An endpoint can only register if it holds an ACE-
> AIF token to POST to that resource issued by my Authorization Server (AS).  The token may contain values for fields in the URI-queries
> which are to be either enforced, or set if not present in the registration request.  Examples are ep, d, et.
> 
> >
> RSFromACE: This RD allows registration of endpoints, but restricts the resources that can be registered.  All resources registered must
> be filtered by matching one of a number of patterns potentially with values that can be defaulted in.
> 
> Jim
> 
> >
> >
> > Best regards
> > Christian
> >
> > --
> [email-masked]

---

From: Jim Schaad <[email-masked]>
Date: Fri, 20 Apr 2018 16:37:55 -0700

> From: Kovatsch, Matthias <[email-masked]>
> Sent: Friday, April 20, 2018 8:46 AM
> To: Jim Schaad <[email-masked]>; 'Christian Amsüss'
> <[email-masked]>; [email-masked]; 'Carsten Bormann'
> <[email-masked]>
> Cc: 'Hannes Tschofenig' <[email-masked]>; [email-masked]
> Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> Dear list
> 
> 
> "ep" is an application-defined identifier for the registered endpoint. It is a
> parameter for registration, but also a target attribute that will have the same
> value. The RD must store the "ep" parameter for each registered endpoint
> and attach it as target attribute to all the corresponding links it returns. As
> Peter stated, when "ep" is not unique, the client must also provide "d",
> which must be processed similarly by the RD.
> 
> As target parameter, it is used during lookup. Applications will use the
> application-defined identifier, not a handle generated by the RD, not the
> security context. When a commissioning tool is registering an endpoint, the
> security context is also different from the endpoint's security context, and
> hence it cannot be used as endpoint identifier.
> 
> I think "ep", just like the other registration parameters that are also target
> attributes, should receive its own sub-section with a proper definition and
> explanation.
> 
> 
> Related to this is the proper definition of "ins", which unfortunately was
> moved over to the core-rd-dns-sd draft. "ins" is used to distinguish resources
> with the same "rt". Originally, it was used for resource within the same
> device (e.g.,
> </t1>;rt=temperature;ins=indoor,</t2>;rt=temperature;ins=outdoor). By
> now, it often is assumed to require global uniqueness. I claim that this is not
> required when "ep" is used correctly. Using a hierarchy of "d" -> "ep" -> "ins"
> provides more flexibility than making "ins" globally unique. "ins" can still have
> a global meaning (cf. indoor vs outdoor), but it should be re-usable for all
> resources with similar instance semantics. Uniqueness is achieved through
> "d" and "ep".
> 
> I think "ins" should become part of the RD draft again to be defined together
> with "d" and "ep", as they are part of a larger discovery framework.

If "ins" does not need to be handled in a special manner by the RD, then I would see no reason for it to be part of the RD draft.  Both "ep" and "d" are treated in a special manner as the pair is required to be globally unique in the RD.  This is not a true statement for the "ins" attribute even in the core-rd-dns-sd draft.

Jim

> context.
> > > > The argument seems to be that if a client holds an authorization
> > > > to register at an RD, that authorization may imply a specific
> > > > endpoint name.  (I’m not sure that is always true, as the
> > > > authorization may be based on a claim that does not happen to
> > > > provide an obvious candidate for that.)
> > > >
> > > > To discuss this further, we’ll need to discuss authorization
> > > > models for RD access.  Maybe high time in any case…
> > >
> > >
> > TrustTheWebCAs + GodBit: This RD accepts any registration, provided
> > who registers can present an X509 certificate chain to my system
> certificates that carries a common or alternative name (or maybe an EKU)
> that matches to the God criteria.
> >
> > >
> > I would probably generalize this rule to - The RD may extract
> > additional information from the certificate beyond the naming to either
> URIs.
> > > An endpoint can only register if it holds an ACE-AIF token to POST
> > EPFromACE2:  This RD uses /reg?ep=${endpoint}&d=${domain} as
> > registration URIs.  An endpoint can only register if it holds an ACE-
> > AIF token to POST to that resource issued by my Authorization Server (AS).
> The token may contain values for fields in the URI-queries which are to be
> either enforced, or set if not present in the registration request.  Examples
> are ep, d, et.
> >
> > >
> > > core-protocol-negotiation) requires that that value is contained in
> > > an ACE token from my AS."
> >
> > RSFromACE: This RD allows registration of endpoints, but restricts the
> > resources that can be registered.  All resources registered must be filtered
> by matching one of a number of patterns potentially with values that can be
> defaulted in.
> >
> > Jim
> >
> > >
> > >
> > > Best regards
> > > Christian
> > >
> > > --

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Apr 2018 03:08:30 +0000

Hi Peter,

The mailing list discussion reconfirms my worry that people will get this wrong and will introduce security vulnerabilities.

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 .

I am furthermore arguing that the multiple IoT device cannot share the same identifier. 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.

Ciao
Hannes

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 09 April 2018 15:04
To: Hannes Tschofenig
Cc: Jaime Jiménez; [email-masked]
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Hannes,

Registrations in the RD need identification so that they can be changed, removed , updated, etc...

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Apr 2018 03:11:49 +0000

Hi Matthias,

I am not suggesting that the endpoint client name/endpoint name is generated by the RD. In fact, I believe the identifier used for identifying the IoT device will be selected outside the RD protocol.

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

Ciao
Hannes

-----Original Message-----
From: Kovatsch, Matthias [mailto:[email-masked]]
Sent: 20 April 2018 22:46
To: Jim Schaad; 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'
Cc: Hannes Tschofenig; [email-masked]
Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft

Dear list

Best wishes,
Matthias

> who registers can present an X509 certificate chain to my system certificates that carries a common or alternative name (or maybe an EKU) that matches to the God criteria.
>
> >
> additional information from the certificate beyond the naming to either enforce or supplement attributes set such as endpoint types or domains.
>
> >
> AIF token to POST to that resource issued by my Authorization Server (AS).  The token may contain values for fields in the URI-queries which are to be either enforced, or set if not present in the registration request.  Examples are ep, d, et.
>
> >
> resources that can be registered.  All resources registered must be filtered by matching one of a number of patterns potentially with values that can be defaulted in.
>
> Jim
>
> >
> >
> > Best regards
> > Christian
> >
> > --

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 23 Apr 2018 12:16:32 +0000

> Von: Hannes Tschofenig [mailto:[email-masked]]

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

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 Apr 2018 11:27:41 +0200

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

> 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: Tue, 24 Apr 2018 11:40:22 +0200

> If "ins" does not need to be handled in a special manner by the RD,
> then I would see no reason for it to be part of the RD draft.  Both
> "ep" and "d" are treated in a special manner as the pair is required
> to be globally unique in the RD.  This is not a true statement for the
> "ins" attribute even in the core-rd-dns-sd draft.
> 
> Jim
> 
"Ins" is used to specify the instance name for DNS records necessary for 
DNS-sd service specification
the RD-DNS-SD draft specifies the rules to generate ins values
As such it is totally proper that "ins" rules are specified in a 
separate draft,
because "ins" treatment is disconnected from the special treatment
specified for "ep" and "d".

Matthias, Are you expressing that an additional need exists to 
distinguish registrations?

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Apr 2018 10:38:01 +0000

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?

Ciao
Hannes

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 24 April 2018 16:28
To: Hannes Tschofenig
Cc: [email-masked]; Jaime Jiménez; [email-masked]
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

> this wrong and will introduce security vulnerabilities.

Well, I'm one of those getting it wrong, because I did not understand the worry.

> 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

sorry, what is a multiple IoT device? one with multiple registrations in the RD, or one with multiple links? or....

> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Apr 2018 10:48:36 +0000

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:[email-masked]]
Sent: 23 April 2018 19:17
To: Hannes Tschofenig; Jim Schaad; 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'
Cc: [email-masked]
Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft

Ciao,
Matthias

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 Apr 2018 16:15:24 +0200

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

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

> I do surmise that the registration may then return an signed
> identifier instead the path name of the registration.
> 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.
> 
> sorry, what is a multiple IoT device? one with multiple registrations
> in the RD, or one with multiple links? or....
> 
> 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.
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Apr 2018 02:17:10 +0000

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.

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

Ciao
Hannes

Peter

>> I am furthermore arguing that the multiple IoT device cannot share
>> the same identifier.
>
>> 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.
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Wed, 25 Apr 2018 20:55:17 +0000

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

> Gesendet: Dienstag, 24. April 2018 12:49
> An: Kovatsch, Matthias (CT RDA IOT EWT-DE); Jim Schaad; 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'
> Cc: [email-masked]
> Betreff: RE: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> Hi Matthias
> 
> 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
> 
> 
> 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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Apr 2018 03:05:32 +0000

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:[email-masked]]
Sent: 26 April 2018 03:55
To: Hannes Tschofenig; Jim Schaad; 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'
Cc: [email-masked]
Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft

Dear Hannes

Ciao,
Matthias

> 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
>
>
> 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
>
> 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: Thu, 26 Apr 2018 11:33:58 +0200

Hi Hannes,

This e-mail of you to Matthias answers my questions I had before. 
thanks.
I was under the impression that you wanted to cater for malicious nodes 
that forged the authorization token.

> 
> 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?
> 
For example, the d=value is typically installation dependent.
To my knowledge, using d= is envisaged in building installations.
at the same time, the ep=value does not need a value with a semantic 
meaning, so any identifier will do in my opinion.

I could imagine that a claim with "d"= is added to the token when 
required.
Same approach for installations which can afford the overhead and want 
human readable ep names.

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Apr 2018 10:34:36 +0000

Great to hear that I managed to clarify the issue.

Note that I am arguing for having the endpoint name in the RD become optional since I notice the third party registration scenario (even though I consider it somewhat half-baked).

Ciao
Hannes

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 26 April 2018 16:34
To: Hannes Tschofenig
Cc: Kovatsch, Matthias; Jim Schaad; 'Christian Amsüss'; [email-masked]; 'Carsten Bormann'; [email-masked]
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Hi Hannes,

This e-mail of you to Matthias answers my questions I had before.
thanks.
I was under the impression that you wanted to cater for malicious nodes that forged the authorization token.

For example, the d=value is typically installation dependent.
To my knowledge, using d= is envisaged in building installations.
at the same time, the ep=value does not need a value with a semantic meaning, so any identifier will do in my opinion.

I could imagine that a claim with "d"= is added to the token when required.
Same approach for installations which can afford the overhead and want human readable ep names.

Peter