[jdev] Alternate MUC Authentication Mechanisms

[Kurt Zeilenga]

So my previous suggestion was subject to a limited replay attack.  In particular, someone who was able to hijack the C2S, S2S, or the intermediate server could do a replay.  Here's another suggestion that eliminates this replay attack and doesn't require any additional roadtrips.

This would look something like:

<iq from='hag66 at shakespeare.lit/pda'
   id='disco3'
   to='darkcave at chat.shakespeare.lit'
   type='get'>
 <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='darkcave at chat.shakespeare.lit'
   id='disco3'
   to='hag66 at shakespeare.lit/pda'
   type='result'>
 <query xmlns='http://jabber.org/protocol/disco#info'>
   <identity
       category='conference'
       name='A Dark Cave'
       type='text'/>
   <feature var='http://jabber.org/protocol/muc'/>
   <feature var='muc_cr_protected'/>
   <challenge xmlns='http://jabber.org/protocol/muc/cr' algorithm="cr-sha2" challenge-attributes="" />
 </query>
</iq>

No hash provided:

<presence
   from='darkcave at chat.shakespeare.lit'
   to='hag66 at shakespeare.lit/pda'
   type='error'>
 <x xmlns='http://jabber.org/protocol/muc'/>
 <error type='auth'>
   <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
</presence>

User provides hash:

<presence
   from='hag66 at shakespeare.lit/pda'
   to='darkcave at chat.shakespeare.lit/thirdwitch'>
 <x xmlns='http://jabber.org/protocol/muc'>
   <response xmlns='http://jabber.org/protocol/muc/hash' algorithm="cr-sha2" response-attributes="" />response</response>
 </x>
</presence>

This would support any single round-trip challenge-response algorithm, with salts, nonces, and whatever other goodies one might want in the non-cleartext mechanism.  I would suggest something loosely based on SCRAM.  That is, a one-roundtrip version of SCRAM (no mutual auth, no channel binding).  This would should be more than sufficient to mitigate the threat posed by eavesdroppers, would not be subject to replay attack.

Of course, like most of the suggestions discussed in this thread, this would be subject to various hijack attacks.  In particular, if an attacker can hijack the S2S session in/out of the MUC service or the subscribers C2S session, the attacker can then downgrade the disco advertisement to muc_password, wait for the client to respond, and win the password.

If folks were interested in such a single-roundtrip approach, I would be willing to draft an XEP on this.

-- Kurt