[standards-jig] Advanced authentication

Robert Norris rob at cataclysm.cx
Tue Apr 16 23:13:30 UTC 2002

> Client-Client authentication is interesting.  What kind of security model
> are you thinking about?  If you can't trust the server at least as much as a
> client you communicate with through the server I can't see this as having
> that much value with the current Jabber setup.  Unless you encrypt packets
> separately and are negotiating authentication and perhaps exchanging keys
> with these other clients.  I have a hard time imagining how secure you can
> make it though if you can't trust the server...

What is the server? Is it jabberd? c2s? jsm?

I'm thinking of this scenario: some entity on the Jabber network (be it
a session manager, a transport, a c2s client) wants to offer a service.
But, it only wants to allow certain other entities to use it. So, it
requires remote entities to authenticate to it before they use it.

This could be the traditional case of a c2s client authenticating to a
session manager, but what about (say) a blogging component
authenticating to a pub/sub service? Or a c2s client authenticating to

> > 1. Jabber has two "services" in the IANA service registry, jabber-client
> >  and jabber-server. These are completely ambiguous in the context of
> >  component-component authentication, for example. And, even in the places
> >  where they might have relevance (ie connections to c2s/s2s via TCP),
> >  what purpose does their use actually serve?
> Each is playing different roles.  Jabber component protocols IMO are
> implementation specific and shouldn't be in the Jabber standard.  A clear
> server and client role is very normal isn't it?

That's not true. A component is a valid Jabber entity, and must speak a
standard protocol if it expects anything to talk to it. Every transport
does this, for example.

It is a client/server role insofar as a one entity initiates an
authentication to another, but the type of service that the "server"
entity provides could be anything. jabber-client and jabber-server are
for two specific cases, c2s clients communicating in the jabber:client
namespace, and servers talking via s2s.

> > The thing that occured to me while writing the above list is that SASL
> > is really suited to simple client/server-based services where a client
> > connects to a server via TCP, authenticates, does some work, and then
> > disconnects (ie SMTP/IMAP/HTTP/POP/LDAP/ACAP/whatever). It is not
> > suited to the kind of peer-to-peer communication that Jabber does most
> > of its work with.
> I'm not sure I'm understanding this correctly.  Jabber is client-server.  In
> fact, its strictly client-server.   Something like BEEP that uses SASL is
> peer-to-peer.  A challenge response protocol doesn't imply a client-server
> relationship.

BEEP is a transport layer, yes? (I admit, I don't have much experience
with it). AAF operates at a higher level than the Jabber transport (ie
the <stream:stream/> stuff). It is for authenticating individual
entities, any entities.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020417/f1ebaf99/attachment.sig>

More information about the Standards mailing list