On 10/14/10 1:39 PM, Alex Milowski wrote: > On Thu, Oct 14, 2010 at 4:57 AM, Peter Saint-Andre <[email protected]> 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='[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>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='[email protected]/pda'
id='zxg1d285'
to='[email protected]'
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='[email protected]'
id='zxg1d285'
to='[email protected]/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='[email protected]/pda'
id='lk5sd1v4'
to='[email protected]'
type='set'>
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
RCa0gyRlhzMFdEWHZKWXc9
</response>
</iq>
6. Room returns success
<iq from='[email protected]'
id='lk5sd1v4'
to='[email protected]/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='[email protected]/pda'
to='[email protected]/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='[email protected]/thirdwitch'
to='[email protected]/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 [email protected] for discussion there.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
