[standards-jig] Advanced authentication
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
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
Size: 232 bytes
Desc: not available
More information about the Standards