[Standards] Loopback Authentication

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Feb 7 20:21:27 UTC 2007

On Friday 02 February 2007 1:40 am, Dave Cridland wrote:
> On Fri Feb  2 00:45:45 2007, Justin Karneges wrote:
> > 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.
> Well, you have to tie in the TCP session with the UNIX session
> strongly, otherwise some pretty trivial break-ins are caused. For a
> start, you'd need something similar to dialback, using a
> cryptographically random code transmitted to the client, probably
> under encryption, which is then used as a shared secret over the UNIX
> connection.
> To put it another way, I won't let you borrow my tin opener, you'll
> get worms all over it.

Sure, I was just trying to use a simple example.

> I think your gut instinct is wrong here - I think you can just run
> over UNIX domain sockets. Note that the client doesn't have to send
> SCM_CREDENTIALS, the server can just retrieve them, so it's really no
> different to TCP for the client.

The reason I'd like to retain TCP here is because implementations already 
target TCP.  The difficulty in swapping TCP out for a OS named pipe/socket 
really depends on the implementation.  On one hand it might be a simple 
initialization change (for a unix app using OS sockets directly).  On another 
hand it might require a transport rewrite (for a unix app using an inflexible 
TCP wrapper library, or for a windows app).

Going OOB leads to a simpler abstraction.  Again, this is just a simple 
example :), but in C you could have a completely self-contained function:

  int try_local_auth()
    // create unix domain socket in blocking mode
    // do exchange
    // close
    return 1 on success, 0 for any other reason

Okay, so the content of this function might be unix-specific and ugly, but its 
interface is very non-threatening.  How hard would it be to then insert this 
function inside of an existing client?  This just seems a lot more practical 
to me than changing out the entire transport layer.


More information about the Standards mailing list