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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Christian Amsüss
> Sent: Friday, April 13, 2018 8:11 AM
> To: [e-mail]; Carsten Bormann <[e-mail]>
> Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
> 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