[jdev] Alternate MUC Authentication Mechanisms

[Peter Saint-Andre]

On 10/14/10 1:39 PM, Alex Milowski wrote:
> On Thu, Oct 14, 2010 at 4:57 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>
>> Why would we do authentication-in-registration, rather than define a new
>> remote authentication extension? XEP-0077 is already overloaded to a
>> great degree, and the two functions of registration and authentication
>> seem quite separate to me.
> 
> To begin with, I was really thinking of just having the ability to use
> digest password mechanisms.  The flow I am think is:
> 
> 1. The client joining the MUC room sends an
> {urn:ietf:params:xml:ns:xmpp-sasl}auth
>     element selecting the authentication mechanism in the presence mechanism.
> 
> 2. The client receives a {urn:ietf:params:xml:ns:xmpp-sasl}challenge element
>     via stanza response from the room.
> 
> 3. The client responds with a {urn:ietf:params:xml:ns:xmpp-sasl}response element
>     embedded in a response stanza send to the room.
> 
> 4. If authentication succeeds, membership in the room proceeds as it normally
>     would do so.
> 
> The question is what stanza elements should be used for (2) and (3).  These
> stanzas would need to be directed at the room.
> 
> Alternatively, an iq/@type='set' and iq/@type='response' could be used for 1-4
> (two iq set/response messages) as a way to alternatively join the room.  The
> nice thing about doing it with iq stanzas is that the existing way of joining
> a room doesn't have to change.

Yes, something like that. We can encapsulate the SASL protocol from the
RFC into IQ stanzas:

1. Client joins room

<presence
    from='hag66 at shakespeare.lit/pda'
    to='darkcave at chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

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

<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'/>
    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
      <mechanism>SCRAM-SHA-1-PLUS</mechanism>
      <mechanism>SCRAM-SHA-1</mechanism>
      <mechanism>PLAIN</mechanism>
    </mechanisms>
  </error>
</presence>

3. Client authenticates via IQ-set (copy and paste from 3920bis)

<iq from='hag66 at shakespeare.lit/pda'
    id='zxg1d285'
    to='darkcave at chat.shakespeare.lit'
    type='set'>
  <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
              mechanism="SCRAM-SHA-1">
        biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
  </auth>
</iq>

4. Room returns IQ-result with challenge

<iq from='darkcave at chat.shakespeare.lit'
    id='zxg1d285'
    to='hag66 at shakespeare.lit/pda'
    type='result'>
  <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
    TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
    AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
  </challenge>
</iq>

5. Client sends response via IQ-set

<iq from='hag66 at shakespeare.lit/pda'
    id='lk5sd1v4'
    to='darkcave at chat.shakespeare.lit'
    type='set'>
  <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
    jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
    RCa0gyRlhzMFdEWHZKWXc9
  </response>
</iq>

6. Room returns success

<iq from='darkcave at chat.shakespeare.lit'
    id='lk5sd1v4'
    to='hag66 at shakespeare.lit/pda'
    type='result'>
  <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
  </success>
</iq>

7. Client sends new request to join room (kind of like a stream reset)

<presence
    from='hag66 at shakespeare.lit/pda'
    to='darkcave at chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

8. Room allows client to join (it might automatically make the user a
member of the room, and we might want to define a new status code for
"user is authenticated", I suggest 215 -- yes, I know we're going to get
rid of status codes, but until we do...)

<presence
    from='darkcave at chat.shakespeare.lit/thirdwitch'
    to='hag66 at shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='215'/>
  </x>
</presence>

I'll forward this message to the muc at xmpp.org for discussion there.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20101014/df04b3f1/attachment.bin>