[standards-jig] Advanced authentication

Jeremie jeremie at jabber.org
Mon May 6 15:15:56 CDT 2002


Although there may not have been much activity on this thread yet, it is
definately a very important one with interesting arguments on both sides.

I just had the opportunity to really dig into SASL last week as a result
of some ongoing IETF discussions, and learning that no matter what we at a
minimum need to provide a Jabber profile for SASL.

As a result of reading everything, and trying to simplify SASL to the bare
minimum XML-ish binding, I can completly understand Rob's desire for a
Jabber friendly scheme since there are some aspects of SASL that don't
pair well with XML itself (but are still doable of course).

I suggest that everyone interested at least read RFC 2222, even just the
first parts, it's pretty short and easy (in comparison to other RFCs).
I've started writing down my thoughts and simple XML namespace here:

	http://home.jeremie.com/sasl.txt

You can see visually from that doc the reasons why our "own" native way of
doing the same thing would be much nicer, and how Rob's AAF could easily
carry the above SASL namespace as one of the alternative options, but just
as easily a single SASL namespace could be used to carry any
new/alternative mechanisms as well, so neither really offers fundamentally
different functionality.

Anyway, there is the other question of how to use SASL.  It's easy to just
throw it into it's own IQ, or alternatively make it something that is
extended to work in the legacy jabber:iq:auth framework.  There is one
other alternative, and it's one I've been considering in more depth as a
fully "unifying" possibility.  

A SASL namespace could be used at the stream layer to auth the stream
itself, outside of the realm of the Jabber traffic (much like dialback):

<stream:stream xmlns="jabber:client" xmlns:sasl="http://...sasl">
<sasl:sasl status="..."/>
...

This is unifying in that it can be used by S2S and the internal component
connections supported by the servers, as well as by clients. Also, for C2S
connections it could be used in a way that compliments the existing
iq:auth instead of replacing it, where you would use SASL to authorize the
client stream, and the iq:auth would associate the resource.

Just some additional thoughts and discussion :)

Jer





More information about the Standards-JIG mailing list