[Standards] Loopback Authentication

Matthias Wimmer m at tthias.eu
Thu Feb 1 10:06:58 UTC 2007


Hi Justin!

Justin Karneges schrieb:
> An an example, in Linux, it is possible to inspect /proc/net/tcp to determine 
> the uid of a given TCP connection.  The XMPP server could look up a peer 
> address/port in this table.  The client could then authenticate with SASL 
> EXTERNAL, since the server already knows who it is.  This is just a rough 
> example, I don't know if it is foolproof, but you get the idea.  Another idea 
> may be for the client to drop a file in /var, and the server can check the 
> file ownership to validate the client.  Some mechanisms may require more 
> steps than others, or require attributes to be exchanged over XMPP.

Putting files in /var does not seem to be a good idea, normal users 
typically will not have write access there. Also it seems to be a very 
hacky way.

I'd much prefere that a server would check the uid of the other 
connection endpoints if it connects from a trusted host (where localhost 
might be one of, but on a managed network it might also be the complete 
site).

> 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) 

It is all one (already defined) SASL mechanism: EXTERNAL. We also did 
not need to define EXTERNAL for authentication using certificates, we 
just wrote an informational XEP to help people implementing the existing 
standard (RFC 4422, Appendix A).

This is also not platform dependent, but already cross-platform: if the 
server knows who originated the connection and can associate a Jabber ID 
with this person, it can offer the EXTERNAL mechnism.
The platform dependent part is just how a server finds out the identity 
of the connecting client, but that's not part of the specification, but 
an implementation detail. And implementations are typcially platform 
dependent.


Matthias


-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070201/18a937d5/attachment.bin>


More information about the Standards mailing list