On Dec 2, 2010, at 8:35 AM, Kurt Zeilenga wrote: > 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
I also note that there is an object level encryption proposal which could be used to protect MUC passwords. http://xmpp.org/internet-drafts/draft-miller-3923bis-02.html -- Kurt
