[Standards] Veto on "Privileged Entity"

Dave Cridland dave at cridland.net
Tue Dec 16 18:24:41 UTC 2014


On 16 Dec 2014 18:03, "Goffi" <goffi at goffi.org> wrote:
> even if I understand your point of view, I have the feeling to see the
famous
> XKCD strip: let's do a new standard which cover everyones use cases
> (situation: 15 competing standards) !
>

That's actually what I'm trying to avoid; we currently have lots of
fractional solutions, and no real standard.

> The XACML protocol is more than 150 pages, I can't see any XEP adapting
this
> to XMPP coming before years, and even if we see that one day, I don't
think
> anybody will implement that (for the record: we are proposing XEPs to
have an
> external implementation of PubSub because to my knowledge none of the
server
> has a complete implementation, so we can't bring a decent microbloging
system
> to XMPP; if XEP-0060 is not fully implemented, what about a potentially
larger
> XEP ?)

XACML is indeed huge, and there are several specifications involved. I'm
not suggesting we make that mandatory, merely that we make that possible,
by using a model that is compatible, and using the same terms of art used
in the field.

At least, where possible.

> The Privileged Entity protoXEP is quite simple and do the job, it can be
> implemented in a couple of hours in most servers, and it solve several
issues.
> In addition if some day we actually see an XACML implementation with
XMPP, we
> can still obsolete the Privileged Entity.
>

Yes, the question is whether we can find a mechanism which is both this
simple, and also fits the model that other systems use already.

> So I think putting a veto on this is really severe, and will delay
> microbloging implementations in XMPP for years. We are curently several
> projects stucked with current state of PubSub and PEP implementations, and
> having an external PEP service is an option generic and available quickly.
>

I'd be very interested in knowing what's missing here. I'm sure other
server developers would be as well.

> I'm curious to see some other opinions on this subject.
>

As am I. A veto position need not be permanent, and I'm hoping we can find
the beginning of a solution, and agree a path forward, instead of simply
blocking progress.

> Cheers
> Goffi
>
> Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit :
> > Folks,
> >
> > At the last Council meeting, I entered a position of -1 concerning
> > Privileged Entity:
> >
> > http://xmpp.org/extensions/inbox/privilege-component.html
> >
> > In order to explain my position better, it's worth examining how
> > authorization systems currently model the world. I'm going to use XACML
> > terms here, although in practise these are industry terms of art in most
> > cases.
> >
> > In any access decision, there are a number of "subjects" - at least one,
> > the "Access Subject", and possibly others (an "Authorizing Subject",
> > perhaps). The decision is whether or not to allow the "Access Subject"
to
> > perform an "Action" on a "Resource".
> >
> > The decision is required, and enforced, by a Policy Enforcement Point,
or
> > PEP. The PEP gathers information, and sends it to a Policy Decision
Point,
> > or PDP. The PDP returns a decision. There are also Policy Information
> > Points, which act as information gatherers - typically these might be
> > querying LDAP directories or SQL databases.
> >
> > For our purposes, the XMPP server is mostly considered here as acting
as a
> > PEP.
> >
> > A key issue is that the PDP can be (and often is) external to the PEP,
and
> > centralized. There are standards for this (such as XACML) which allow
both
> > policies to be expressed and also define PEP->PDP wire protocols. Most
> > modern standards are now focussed on Attribute Based Access Control,
which
> > are particularly fine-grained.
> >
> > Currently we have three explicit, and one implicit, authorization
> > mechanisms in XMPP:
> >
> > 1) The Affiliations of MUC and PubSub. This is a Role Based Access
Control
> > mechanism with fixed roles.
> >
> > 2) The Security Information Object mechanism of XEP-0258, used for
> > protective marking schemes. This is, again, a Role Based Access Control
> > mechanism of sorts, with definable Roles. Interestingly, this has a
> > configurable policy.
> >
> > 3) MUC Hats, which is a fairly straightforward Role Based Access Control
> > system using user-defined Roles. Nobody, so far as I know, implements
this,
> > but it was defined on the perceived need of finer-grained access
control to
> > chatrooms.
> >
> > 4) The implicit permissioning of Rosters and vCards, wherein the owner
has
> > access and nobody else.
> >
> > All of these are fairly inflexible, do not integrate with external PDPs,
> > and are all RBAC.
> >
> > The ProtoXEP in question was aiming at defining another, new, RBAC
system
> > which also would have a fixed role, fixed policy.
> >
> > Although the outcome is desirable - that is, replacing (4) above with a
> > more flexible system - I'm concerned that this is patching a specific
> > problem rather than addressing the broader view of where the state of
the
> > art in access control is.
> >
> > Instead, I think we should take a step back and try to cast our
> > authorization model in the form the current ABAC standards can work
with;
> > ideally getting us to a point where enterprise PDPs could be used if
needed
> > to provide centralized policy control.
> >
> > In particular, this means clearly defining the resources involved, the
> > actions available - both generic actions and in some cases specialist
ones
> > - and then look at how we can generically authorize subjects.
> >
> > The result of this might be "woah, this is way too difficult", but I'd
> > rather say that after exploring the are properly - (3) above has done
much
> > of this work already for MUC, so clearly there is *some* interest.
> >
> > Dave.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141216/a64cf64c/attachment.html>


More information about the Standards mailing list