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

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:matthias.kovatsch@siemens.com]
Sent: 20 April 2018 22:46
To: Jim Schaad; 'Christian Amsüss'; consultancy@vanderstok.org; 'Carsten Bormann'
Cc: Hannes Tschofenig; core@ietf.org
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.

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:core-bounces@ietf.org] Im Auftrag von Jim Schaad
> Gesendet: Sonntag, 15. April 2018 21:31
> An: 'Christian Amsüss'; consultancy@vanderstok.org; 'Carsten Bormann'
> Cc: 'Hannes Tschofenig'; core@ietf.org
> Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
>
>
>
> > -----Original Message-----
> > From: core <core-bounces@ietf.org> On Behalf Of Christian Amsüss
> > Sent: Friday, April 13, 2018 8:11 AM
> > To: consultancy@vanderstok.org; Carsten Bormann <cabo@tzi.org>
> > Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; core@ietf.org
> > Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
> >
> > On Mon, Apr 09, 2018 at 10:04:07AM +0200, peter van der Stok wrote:
> > > > 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.
> > >
> > > Probably, I completely misunderstand your suggestion.
> > > Registrations in the RD need identification so that they can be
> > > changed, 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.
> > > Removing ep identifier will force you to find another identifier
> > > for a registration.........
> > > and you are back to square 1 it seems.
> >
> > 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".
>
> 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.
>
> >
> > 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."
>
> 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
> >
> > --
> > To use raw power is to make yourself infinitely vulnerable to greater powers.
> >   -- Bene Gesserit axiom
>
> _______________________________________________
> core mailing list
> core@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.