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

> -----Original Message-----
> From: Kovatsch, Matthias <matthias.kovatsch@siemens.com>
> Sent: Friday, April 20, 2018 8:46 AM
> To: Jim Schaad <ietf@augustcellars.com>; 'Christian Amsüss'
> <christian@amsuess.com>; consultancy@vanderstok.org; 'Carsten Bormann'
> <cabo@tzi.org>
> Cc: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>; 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.

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

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