[Standards] Loopback Authentication
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
> 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:
// create unix domain socket in blocking mode
// do exchange
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