[Standards] Loopback Authentication
justin-keyword-jabber.093179 at affinix.com
Fri Feb 2 00:45:45 UTC 2007
On Thursday 01 February 2007 1:13 am, you wrote:
> On Thu Feb 1 02:48:13 2007, Justin Karneges wrote:
> > Unfortunately, there is no clean cross-platform solution for this
> > kind of thing. Depending on how many platforms we'd want loopback
> > authentication to work on, we could end up with 3 or 4 mechanisms.
> > Do we want to make a handful of new SASL mechanisms? (putting
> > loopback auth on the level of SASL)
> No, I think you and Ralph are correct in saying you want to re-use
> SASL EXTERNAL.
> Note that a much more portable way of doing it (albeit one that need
> a bit more client support) is to run the XMPP stream over a UNIX
> domain socket, since there's a handful of API calls on most UNIX
> platforms which allow you to extract the calling UID. I know it works
> on BSD and Linux systems.
> Windows is, as ever, a bit of a challenge, but I believe that named
> pipes have a similar ability.
Yes, a specialized pipe may be a good solution. However, I'm not sure if I
would want to run the entire c2s session over a special pipe. What about
using the pipe just to establish trust?
One idea I've thought about is having the XMPP session still take place over
TCP, but the client and server could complete something oob-ish to establish
trust. The file idea I brought up earlier is a very crude example of an oob
method. The unix domain socket is a lot better. On Windows I was told that
it may be possible to look up PIDs and send events (such as WM_DATACOPY)
between processes (just to give an example of a possibly good solution that
doesn't involve a pipe).
My question now is where do we draw the line between SASL EXTERNAL and a new
SASL mechanism? Ralph says that EXTERNAL should be used only if no
additional exchange of information is required. However, I don't know if
that's really the deciding factor. After all, TLS requires an exchange of
information, and is still deemed suitable for SASL EXTERNAL. But then maybe
it is a special case.
If I were going the unix domain socket route, my gut would be to add a new
item to <stream:features> containing the socket path. The client could then
connect to the domain socket, handshake (send SCM_CREDENTIALS and the XMPP
stream id), and close the domain socket. At this point, the server now knows
who the client is, and so the client proceeds with SASL EXTERNAL over the
More information about the Standards