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

[Christian Amsüss <[e-mail]>]

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

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