[Standards] Veto on "Privileged Entity"

Goffi goffi at goffi.org
Wed Dec 17 18:01:56 UTC 2014


On 17/12/2014 18:06, Dave Cridland wrote:
> OK, I entirely forgot about that. And in fairness, I think Section 6 is
> reasonable; I think Sections 4 and 5 are the problem.

Ok, it become more precise, I'll work on it


> This document is not about building an external PEP service; this
> document - or at least sections 4/5 of it - is about access control.

right


> In this case, as I wrote, every PEP node already has an access-model,
> and applying a different access model based service-wide around the iq
> type is clearly both duplicating the access control of PEP, and making
> it worse, and failing to interact properly.

PEP node is a restricting access model, not something used to give more 
access (or privileged as called in the protoXEP), it is definitely not 
the same thing as PEP access control.


> Well, that's sort of the problem - the protocols are already defined on
> a per-extension basis, and you've applied a generic solution across the
> top. The two just don't fit.

What I mean is if you want to give access to a feature, in XMPP terms 
it's a XEP (and an associated namespace). As you mentioned in a former 
email, XEP have not a consistent model once in the <query> par of <iq> 
stanza. So how can you give an generic attribute based access control, 
if XEP are organised in all different ways ? You can explicitly mention 
XEP by XEP how to do, but that's not generic anymore, and need to be 
updated when new XEPs appear.


> I really think it's worth addressing just the immediate requirements to
> begin with.

The whole XEP address the immediate requirement, except maybe the 
"client mode" part which is a "bonus".


> Like the roster access-model already in PubSub? (I'm pretty sure M-Link
> does this already for PEP nodes).

Exactly like the roster access-model already in PubSub which is 
implemented nowhere (or at least, in none of the servers I have tested: 
Prosody, Metronome, OpenFire, Ejabberd, which is already a good set), 
except in our PubSub component.

But in Berlin summit I talked about this with Ralph Meijer, and it seems 
that in fact I misunderstood and the "roster" in question in the PubSub 
roster, not publisher's roster like I thought (and I need access based 
on publisher's roster). So it's a model which doesn't exists yet, and 
would be sort of "publisher-roster access-model". That means that before 
having a valid and standard way of doing this, we need a new XEP, 
discussions, etc. And before having this implemented in most of servers 
we can wait... well... ages.


> A client *can* manage its own PEP service, can't it?

No it can't, it can only have the PEP service implemented in its server


> This protocol would
> be enabling it to manage someone else's, surely?

No it wouldn't, access is restricted to the client which accepted the 
privileged (see section 5.1 of the protoXEP)


> Moreover, if you want
> to run your own PEP service as a client, you only need the other
> protoXEP, not this one.

No, the "Namespace delegation" is not sufficient, as a PEP service need 
to send <message> stanza and access <presence> informations, which are 
addressed by the "privileged entity" XEP in section 6. And that also 
means access to roster, also addressed by "privileged entity".


> I pointed out the problem with MAM, for example. I have no idea what
> else is there, but there are problems with PEP as above (and Pubsub and
> MUC in the same way), and MAM. I wondered about Search, and anything
> involving ad-hoc is clearly a bit weird.

You pointed out that there is no granularity, but that's not a security 
issue (if you give access to MAM to a component, expect it to do things 
with MAM).


> You're asking server administrators to understand the protocol-level issues?

No, I'm asking administrators to understand what they put in 
configuration, and which permissions they allow in a *whitelist* (as 
recommended in section 11): allowing privileged on roster is something 
acceptable, allowing privilege on "http://jabber.org/protocol/xhtml-im" 
make no sens, you don't need to understand the protocol level to 
understand that. In addition, server can have they own hard coded list 
of acceptable namespaces.


> But anyway, the problems basically all derive from this being generic.

Yes, the goal is to avoid to be stucked on server implementation for any 
past present or future XEP.


> You know you could just write a server? You needn't bother with S2S; you
> can just run yours as a component into another one. PEP/Pubsub-onna-jid
> is *way* harder to do than the rest of C2S, and I suspect it's actually
> easier than doing all this proxying.

You mean having a server as a component ? Something like 
myextraserver.myactualserver.tld ? Above the complexity of the thing, it 
will just not work for PEP, the myactualserver implementation will 
manage all PEP requests, and anyway myextraserver couldn't send 
notification in the name of the client entity. Maybe I misunderstood 
what you suggest, but I'm curious to see a working solution here.


> Basically, unless you really want to do the ocean-boiling exercise of
> doing this properly - and I really don't dispute that it's hard work -
> then why not strip this down to just section 6 for now?

I can try to work on it anyway, just let me a couple of days to think 
quietly about this and study a bit more XACML and your concerns, maybe 
we can have a satisfying solution without writing an entire new thing 
(and hopefully without postponing by months or years).


Goffi




More information about the Standards mailing list