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

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Mon Mar 29 20:09:56 UTC 2004

Also, this has been covered by my new JEP:


For whatever reason it doesn't have a number yet.  Peter has been slow to 
process it.


On Monday 29 March 2004 11:26 am, Deb Agarwal wrote:
> 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.

More information about the Standards mailing list