[Standards] Loopback Authentication
dave at cridland.net
Fri Feb 2 09:40:41 UTC 2007
On Fri Feb 2 00:45:45 2007, Justin Karneges wrote:
> 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).
Well, what the server uses to get an externally derived
authentication identifier is entirely up to it. EXTERNAL gets
advertised when the server has one or more authorization identifiers
that it's established out-of-band WRT SASL.
I think running XMPP over a UNIX socket is perfectly valid. If you
want to do things remotely, then you need a method for validating the
client properly, and given the kinds of use-cases you've mentioned,
I'd have thought a TLS certificate or other strong auth method is the
thing to use here.
FWIW, my little ACAP server can do exactly the same thing, running
ACAP over UNIX domain sockets. It'll even do TLS or compression over
them, which is fantastically pointless, but more trouble than it was
worth to disable them.
> 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.
No, it's out of band for SASL and XMPP. Basically, if the server
knows who the client can act as without any SASL exchange, it says so
by advertising EXTERNAL.
I appreciate that TLS gets turned on inside the application protocol,
but the protocol itself is unaware that anything more interesting
than a layer insertion has taken place. That layer might be able to
identify the remote client via some means, but the key feature is
that the server ends up with one or more authzids it trusts the
client to use without further authentication.
> 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.
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.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards