[Standards] Loopback Authentication

[Dave Cridland]

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 
connection.

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade