[standards-jig] JEP 34 (SASL)

Craig ckaes at jabber.com
Tue Aug 20 17:37:25 UTC 2002

I've got a couple issues with the SASL jep.

Issue one (from section 2.2):
1)  Client says, "<stream:stream..." (translated, "I like SASL.")
2)  Server says, "<stream:stream...><sasl:mech...." (translated, "Me 
too!  I support these methods."
3)  Client says, "<sasl:auth mech='PLAIN'>base64(foo)..." (translated, 
"I like plaintext, my password is "foo").

Now in the doc, the Server says, "<sasl:success>" but I'm wondering how 
it did this without knowing the jid of the user trying to authenticate.

One way to attack this problem would be:

1)  Same.
2)  Server says, "<stream:stream...><sasl:challenge>base64(Who are 
3)  Client says, "<sasl:response>base64(bubba708)</sasl:response>"
4   Server says, "<sasl:challenge>base64(PLAIN,DIGEST)</sasl:challenge>....
5)  Client does step 3 from before.

It should be obvious why having the user id might be desirable for 
authentication.  Why would it be desirable to have it before methods are 
given?  Because I have top-secret clearance and must use Kerberos but 
you are just a plain ol' office worker and plaintext is fine for you. 
The server ensures that I auth using a method appropriate for my clearance.

Issue two:

We are not required to use base64 encoding of everything.  Is there a 
reason that this was chosen other than that IMAP did it?  Is this so 
that we can support Kerberos in the future?  It makes it difficult to 
test in the present.

Issue three:

This is a minor point raised by step 3 in the second sequence above 
(<sasl:response>base64(bubba708)</sasl:response) and that is whether we 
want to send bubba708 at foo.org or just bubba708 like we do today.  This 
becomes a bit of an issue with respect to base64 encoding in that for 
authentication to happen correctly, we'd have to snag the host out of 
the stream header (we do this today), unencode the response to get 
"bubba708" (don't do today), glue it onto the "foo.org" (we do this 
today), and re-encode the whole mess (don't do today) before handing off 
to the sasl libs.



More information about the Standards mailing list