[standards-jig] JEP 34 (SASL)
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
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:
base64(craigk, mypassword, ...)
and then upon recieving <sasl:success/> sending:
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