On 17 December 2014 at 05:15, Kurt Zeilenga <kurt.zeile...@isode.com> wrote: > > While your OP implies that “we” (presumedly “the community”) should take a > step back and consider model and terminology issues, in your latest > comments, it seems more that you want the authors to adopt a this model and > terminology you originally wanted “we” to consider. > > While I would not have issue if you. independent of consideration of this > ProtoXEP opened a discussion about how to model XMPP authorization services > and what terminology should be used, I think it inappropriate to put this > ProtoXEP on “hold” pending such discussions. As you note in your OP, such > an effort might not pan out. > > Further to the note on members@, I would note that if I had not used a veto, the proposal would now be almost a XEP due to timeouts on voting which expire in a few hours. So please note that I've not actually held the protoXEP in any meaningful manner up until now.
We'd also probably not be having this discussion, which is beginning to become quite useful. > But now your demand seems now that the authors recast their protoXEP to > use the ABAC model and terminology when there hasn’t been the greater > discussion and for which you think might actually be “way too difficult”. > This seems like a absurd request to make of the protoXEP authors. > > No, you asked specifically what the authors could do; I gave an answer to that. > As you put it, this is a “specification (that) describes a very specific > solution to a very specific problem”. Your goal is "a single model for > access control”, aside from being simply unrealistic given that XMPP is a > general messaging framework supporting a wide range of applications, should > be viewed as completely beyond the scope of this ProtoXEP. And even if you > limit the scope of your goal to some particular application using XMPP such > as say IM or MUC, you are going to have a hard time getting to a single > model of access control, especially where the one you are promoting is one > of the two access control (role and rule based) models explicitly specified > for us. > > I'll assume a missing "not" there. I dispute that we actually have a model. Also I dispute that such a model is impossible, given that web services - which are at the very least just as wide-ranging - can manage it just fine. Finally, I don't think "Role-Based Access Control" really fits what we're doing anyway, and even if it did, we need a better system. By "Rule-Based Access Control", I assume your intent is to refer to XEP-0258. There's two server implementations of this that I'm aware of, one based around the security label model described in FIPS 188 et al, and the other based around an entirely opaque model. I'm not too concerned with this, since it's a relatively specialist case, and while it's possible to express a security labelling policy in something like XACML, it's not a whole lot of fun. So while I've included mention of this for completeness, I'm not sure if XEP-0258 is really part of the problem. This does, of course, imply that we may be best off with two models instead of one, but I think explicit labelling is somewhat a different problem. By "Role-based Access Control", I assume you're referring to the Affiliations systems present in both MUC and PubSub. The primary problem here is that there are a very small number of fixed roles, and the fixed mapping of rights to roles is limiting actual applications in the real world. The roles are also per-Object, which makes management of these pretty convoluted - there's no mechanism in the current model for saying "MUC Service Administrator" or "Server Administrator", despite those roles existing in many servers. The existence of XEP-0317 should tell us that there are perceived problems with MUC affiliations, and Buddycloud - for example - requires additional affiliation types for its use of PubSub because its use-cases don't quite fit. As for this ProtoXEP, this is either "Identity Based Access Control", or else it's Role-Based with one Role (or, hey, one Role per Identity, depending on which way you squint). In any case it's a new model (which, in turn, is a very simplistic one). As defined, it's possible to grant rights over PEP services via this mechanism - these are actually used in the examples - which has the effect of having a different, conflicting, model. I suppose one could argue that the proposal actually does specify a universal model for XMPP authorization and Discretionary Access Control; but it's not a very good one. So summary: There are problems with the inconsistent and simplistic model we have for authorization in XMPP, and this proposal would make the situation worse. You are asking the authors to re-cast their work away from a model they > understand, which the community understands, and which has already been > used in XMPP and arguably patterned after after existing use in XMPP, to a > model which is likely alien to the authors, alien to many in this > community, and for which there seems no use of ABAC for the authors to > pattern their use after. This seems unlikely to lead to an improvement in > the quality of this ProtoXEP nor progress towards your goal. > > I content that the XMPP standards community has not accepted the use of > the ABAC model and/or its terminology as being appropriate for describing > XMPP authorization services. I content that the ABAC terms are not > “industry terms of art” of access control in application level protocols, > they are terms associated specifically with the ABAC model. The ABAC model > terms are not terms of art for the RoleBAC nor the RuleBAC models, two of > the models explicitly used in XMPP currently. > > We can drop terms back to "Subject". "Object", "Attribute", "Policy", if you prefer. In all honesty I don't care what terms we use, or even what model. I'd like a single model, and a single set of terms of art, and I've proposed the same. You might argue that we should use only SIO for MAC and RoleBAC for DAC; that's a valid argument and I'm willing to be convinced by it (though I'd rather go for an ABAC model). But we actually need to have a Role-Based Access Control model, in that case, rather than a vague collection of different and overlapping models. > While I have no problem with council members suggesting terminology > changes to improve the readability of the particular ProtoXEPs before them, > this does not seem to what is driving your demand to “recast” this > ProtoXEP. If it were, I would content that the ABAC terminology is obtuse > and alien to many application protocol developers and to many in the XMPP > community. The ABAC terminology use, for instance at the IETF, is pretty > much limited to AAA protocols. It not commonly used in application > protocol specs, including specs detailing complex authorization services. > if one was simply desiring to improve the readability of the ProtoXEP, I > think we would be far better for the authors to simply be self-consisent as > well as consistent with the specs they (directly and in some cases > indirectly) reference. I note that RFC 6120 references RFC 4949 for some > of its security terminology and if one is keen on following established > patterns, one set by RFC 6120 is probably a reasonable choice. I'm finding it very amusing that "rule-based access control" isn't defined in RFC 4949, yet you want us to use that. But in any case, while I do care about what model we have, and what terms we use to describe that model, I care considerably less than I do that we *have* a model, and we use consistent terms. If Role Based Access Control and RFC 4949 float your boat more than ABAC and NIST SP 800-162 or XACML or whatever, than that's not something I'll jump up and down over. Mostly, I'd go for ABAC because its terms and model are a superset of Role *and* Rule BACs, and as such as we can describe either; it's not used very often in existing protocols because it's very new - that NIST document is dated January 2014, for example. XACML itself isn't used very heavily, but its model very much is - if you hunt about for self-describing "XACML products", you'll find the vast majority do very little actual XACML syntax; they just all follow the model. Dave.
