[Standards-JIG] Client-Client authentication with x509 certificates

Deb Agarwal DAAgarwal at lbl.gov
Mon Mar 29 19:26:14 UTC 2004


Ian,

Have you looked at the End-to-end draft in the XMPP working group?
  End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)

We here at LBNL are also looking at using grid certs for Jabber.
We see an issue with the assumption that you can have a cert
with your jabber id in it.  How are you planning on doing the
cert to Jabber id mapping?

Deb

Ian Stokes-Rees wrote:

> [meta-comment: this may not be the right list to post this on.  Please 
> let me know if XMPPWG is a better one]
> 
> I been working with jabber for about 6 months now, and am finally 
> getting in to the security side of things.  We are already using a very 
> well developed x509 infrastructure for grid computing, and we would like 
> to make use of Jabber for communication between services, "grid jobs", 
> and users.
> 
> I have now read both the IETF drafts, and many of the Jabber JEPs, but I 
> think I have missed something.  I see how, in principal, a client can 
> authenticate to a server using TLS and XMPP (I would love to see details 
> on how this is configured for a jabberd2 server, however), and then 
> start an encrypted, authenticated session.  This is mutual 
> authentication, not just plain vanilla SSL with *only* self signed 
> server certificate.  So far, this sounds good.  The problem is that most 
> users, I think, don't care about authenticating to the server, so much 
> as they care authenticating with the other jabber users (or software 
> "agents" or "clients" authenticating to other "agents" or "clients")
> 
> The current system, so far as I can tell, only provides two things:
> 
> 1) For the client, a fair degree of certainty that it is talking to the 
> intended jabber server;
> 2) For the server, a fair degree of certainty that it is talking to the 
> claimed user/client JID.
> 
> This is fine so long as all the server cares about is authenticating the 
> clients which connect to it (which is probably the case), *and* that all 
> the client cares about is authenticating the server which it connects to 
> (which is probably *not* the case).  The client really cares about 
> sending and receiving <message> <presence> and <iq> stanzas from other 
> clients.  The fact that they come via a server is a technical detail.  I 
> believe the client wants (and needs) to receive cryptographically signed 
> <message>, <presence>, and <iq> stanzas so it can verify they have come 
> from the indicated sender.  Without this there can be no guarantee that 
> the server has not been compromised, or that some rogue server is 
> fabricating messages and sending them via a s2s connection.
> 
> I think it is necessary to introduce a mechanism to sign stanzas and 
> deal with key distribution between clients so that client A and client B 
> can share their public keys auto-magically.  A system to map JIDs to CAs 
> (a sort of signing policy system) may also be valuable, but, at first 
> thought, probably not possible.  Maybe just some way to fetch an x509 
> Distinguished Name which matches a JID, so client B, on receiving a 
> signed message from client A, can figure out which public key to use to 
> check the signing.
> 
> The Globus projects x509 proxy certificate system *may* work here, 
> provided jabber users are happy to temporarily give the server their 
> identity to use.
> 
> If I have misunderstood this, please let me know!  I would be 
> particularly interested in being pointed at an JEPs or other 
> documentation regarding security and Jabber.
> 
> Ian.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deb Agarwal                          e-mail:DAAgarwal at lbl.gov
MS50B-2239                           phone :(510)486-7078
Lawrence Berkeley National Lab       URL: http://www-itg.lbl.gov/~deba
Berkeley, CA 94720
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




More information about the Standards mailing list