[standards-jig] JEP 34 (SASL)

Joe Hildebrand jhildebrand at jabber.com
Wed Aug 21 01:16:03 UTC 2002

(CC'd to the jabber-ietf list, since I think that group should join in
the fun.)

Craig and I were talking about this today.  This is an attempt to
summarize what we talked about.

Yes, you can de-base64 the challenges and responses, and figure out
the user name, but in actual practice, that means that the thing at
the edge (jpoll, ccm, jadc2s, etc.) needs to understand *way* too much
about SASL.  Yes, that may be where the initial implementation put the
SASL logic, but we want to put it somewhere else.  Also, for things
like PLAIN, you don't actually get user information in the challenges
and responses.

(As an aside, can we please have base64-decoded versions of the
example messages in the JEP, for those of us who aren't geeky enough
to have written their own base64 decoders just for the purpose of
reading this JEP?)

My proposal is that all the SASL packets have a to='myuser at myhost/foo'
attribute on them.  A nice side-effect of this approach is that
different users can continue to have different authentication
approaches.  And, the jabber:iq:auth namespace is not needed at the
end to set the resource, since we have all of the information we need
to set upa session when the authentication is finished.

While we're at it, is there some reason why all of the SASL elements
can't be in IQ's?

So, I'd propose this:

C: <iq to='myuser at myhost/foo' type='get' id='1'>
C:  <mechanisms xmnls='http://www.iana.org/assignments/sasl-mechanisms'>
C: </iq>

S: <iq from='myuser at myhost/foo' type='result' id='1'>
S:  <mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
S:   <mechanism>PLAIN</mechanism>
S:   <mechanism>DIGEST-MD5</mechanism>
S:   <mechanism>EXTERNAL</mechanism>
S:  </mechanisms>
S: </iq>

C: <iq to='myuser at myhost/foo' type='set' id='2'>
C:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'
C:         mechanism='PLAIN'/>
C: </iq>

S: <iq from='myuser at myhost/foo' type='set id='3'>
S:  <challenge xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
S: </iq>

(aside: the xml is wrong in example 3 in the JEP.)

C: <iq to='myuser at myhost/foo' type='result' id='3'>
C:  <result xmnls='http://www.iana.org/assignments/sasl-mechanisms'>cm9iAHNlY3JldA==</result>
C: </iq>

(aside: "cm9iAHNlY3JldA==" is the base64 of "rob secret")

S: <iq from='myuser at myhost/foo' type='result' id='2'>
S:  <auth xmnls='http://www.iana.org/assignments/sasl-mechanisms'/>
S: </iq>

(note: the id here is intentionally '2', to match the type='set' above.)

I don't think we need to extend the basic protocol to do this.  You
can still add something as a flag in the stream:stream, but it doesn't
really *have* to be a xmlns.  Even if it is, the xmlns inside the iq
should probably be something different, so that existing server
implementations will work ok.

Joe Hildebrand

Craig <ckaes at jabber.com> writes:

> 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
> you?)</sasl:challenge>
> 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.
> Thoughts?
> --C
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list