[standards-jig] JEP 34 (SASL)

Craig Kaes ckaes at jabber.com
Wed Aug 21 18:03:39 UTC 2002

> I don't really follow why it is necessary to rewrite an encoded value at
> any point. Who is it that needs to unencode the node response, append
> the domain, and reencode it? Why do they need to do that?

Because I misunderstood "realm", which would suffice for this, methinks. 
  The problem is one of how to handle authentication in a virtual 
hosting environment.  This problem goes away if sasl "realm" and stream 
"to" are the same.  Ignore my third issue -- I was trying to reinvent 
the wheel.

I also had it pointed out to me that in the initial response in example 
3, the client is handing back user and password, so that pretty much 
renders much of what I said so much jibberish.  It does raise a 
different issue, though.  How do client connection manager writers 
ensure that the user given to SASL in the response is the same user that 
later sets resource and establishes a session in example 10?  What 
prevents me from sending:

     <sasl:auth mechanism='plain'>
         base64(craigk, mypassword, ...)

and then upon recieving <sasl:success/> sending:

     <iq type='set'>
         <query xmlns='jabber:iq:auth'>

Perhaps some sort of token can be passed back in the final challenge 
that allows me to validate the username they log in with?  Perhaps we 
can slap a "to" on all the sasl:responses and the jabber protocol sasl 
stuff validates that "to" and "userid" are the same?  Ideas?


More information about the Standards mailing list