[Standards] Proposed XMPP Extension: Remote Authentication

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Thu Dec 2 16:35:11 UTC 2010


On Dec 1, 2010, at 6:54 PM, XMPP Extensions Editor wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Remote Authentication
> 
> Abstract: This document defines an XMPP protocol extension that enables entities to use SASL for authentication with remote services (such as Multi-User Chat rooms).
> 
> URL: http://www.xmpp.org/extensions/inbox/remote-auth.html
> 
> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
> 

While I have no objection at present to this becoming a XEP, I have some concerns.

It's not clear what exactly the problem is that this extension is trying to solve.

It doesn't seem to be trying to generally solve how to provide secure communications between any two entities.

It seems more focused on addressing the MUC password issues.  I note that MUC passwords are not about identity authentication, so it's not clear to me why SASL, which is about identity authentication and channel protection, is applicable to this problem.

Assuming this is about the MUC password issue, I note that the concern here has generally been that about eavesdroppers being about to discover the passwords (such as when C2S or S2S streams are not protected via TLS).  To address this, I think the best answer is "use TLS, damn it".  It might be useful to design an extension which advises the entity one provides a stanza to as to what the stanza should only be forwarded via protected channels.  If that's insufficient (because one doesn't want to rely on advisory), then one really needs to utilize a complete e2e solution (which this Proto-XEP doesn't offer).

There are also MUC password concerns that a subscriber's server could grab it and use it.  But I note that this Proto-XEP solution doesn't adequately defend against that threat as the remains downgrade and hijack attack vectors.

So, I guess I ought to be looking at this more as a facility for operating services requiring remote identity authentication.  Okay, I can seem some value in offering a solution to this, even one which doesn't protect against downgrade and hijack attack.  But then why the MUC password comparison?  Seems an apples to oranges comparison to me.

-- Kurt







More information about the Standards mailing list