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




Reply via email to