I'd like to improve the security layers for password protected rooms.
Specifically, I'd like to be able to use challenge-based
authentication mechanism for password-protected rooms.

Keep in mind that this is all about the room password and not the
user's password for authenticating their connection.  This password
could be a shared secret for the room or it could be, as far as I can
tell, something the service has associated with the user's identity.

Based on a number of suggestions off of the jdev list, here's my
strawman proposal:

1. The client attempts to join a password-protected room:

<presence
  from='[email protected]/pda'
  to='[email protected]/thirdwitch'>
 <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

2. Room returns <not-authorized/> error with supported SASL mechanisms

<presence
  from='[email protected]'
  to='[email protected]/pda'
  type='error'>
 <x xmlns='http://jabber.org/protocol/muc'/>
 <error type='auth'>
  <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>DIGEST-MD5</mechanism>
  </mechanisms>
 </error>
</presence>

If the PLAIN mechanism is not listed, a clear-text mechanism via the
'password' element is not supported.

Note: On the web, we could send the challenge in the not-authorized
response.  Since the 'challenge' element does not support a
'mechanism' attribute, we can't tell the client what mechanism the
server prefers.

3. Client selects an authentication mechanism:

<presence
  from='[email protected]/pda'
  to='[email protected]/thirdwitch'>
 <x xmlns='http://jabber.org/protocol/muc'>
 <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
            mechanism="DIGEST-MD5"/>
</presence>

4. Room returns <not-authorized/> error with challenge:

<presence
  from='[email protected]'
  to='[email protected]/pda'
  type='error'>
 <x xmlns='http://jabber.org/protocol/muc'/>
 <error type='auth'>
  <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">...</challenge>
 </error>
</presence>

5. The user joins with an appropriate response:

<presence
  from='[email protected]/pda'
  to='[email protected]/thirdwitch'>
 <x xmlns='http://jabber.org/protocol/muc'>
 <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">...</response>
 </x>
</presence>


The use of the 'auth', 'challenge', and 'response' elements from the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace seemed appropriate.  They
could easily be adopted into their own namespace.  The advantage would
be that a server could send a challenge directly to the client in step
(2).

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Reply via email to