[Standards] Loopback Authentication

[Justin Karneges]

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 
XMPP stream.

-Justin