[Standards] Proposed XMPP Extension: Remote Authentication
waqas20 at gmail.com
Thu Dec 2 15:18:49 UTC 2010
On Thu, Dec 2, 2010 at 7:58 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 12/2/10 7:50 AM, Waqas Hussain wrote:
>> On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor <editor at xmpp.org> 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.
>> Some comments:
>> 1. The SASL mechanisms list can be sent back in the presence error,
>> avoiding a round trip.
> Yeah, I wasn't sure whether to do that or not. My email to the jdev list
> on this topic included the mechanisms in the presence error. I'm still
> mulling it over, but you're right that it would save a round trip. I
> wonder: can that model be generalized to other extensions? (Think
> pubsub, gateways, etc.)
Various fun things come to mind. e.g., my client could authenticate
with an MSN transport using some X-MSN SASL mechanism, and the
transport never needs to know my password. (it can probably change the
password once it's authenticated, but that's besides the point :) )
>> 2. The presence after authentication need not be sent. On successful
>> auth, the initially sent presence can be used, avoiding a round trip.
> Good point -- and a good reason to include the SASL mechanisms in the
> presence error.
>> 3. What the authentication identity looks like is undefined. I'm not
>> sure if this is good or bad.
> I think it's bad. We need to fix that up.
>> 4. The error condition is 'sasl-required'. Does this imply that normal
>> MUC password auth should fail, even with a correct password?
> What do you think?
> Because legacy MUC passwords are sent in the clear, a given MUC service
> might not want to accept that other method, but in practice I think they
> would for quite a while.
I think allow. That is, if the client has already sent us a
<password>***</password>, there isn't much point in ignoring that and
redoing auth. The damage is done already.
>> And finally, an implementation:
> Cool. :)
>> The linked implementation works with Prosody trunk, and verifies that
>> the user knows the room password. This would be far more interesting
>> with some per-user credentials.
> Indeed. How to establish those?
> It would also be interesting to use certificate-based authentication.
I've been very interested in certificate-based auth for clients
lately. S2S poses an issue for normal EXTERNAL auth for remote
>> How about something new instead of `<feature
>> var='muc_passwordprotected'/>' to advertise SASL support.
> Yep, we need that. How about 'urn:ietf:params:xml:ns:xmpp-sasl'? If that
> is not specific enough, we could define urn:xmpp:remote-auth as a
> feature (but not an XML namespace).
+1 to 'urn:ietf:params:xml:ns:xmpp-sasl'
More information about the Standards