[standards-jig] Advanced authentication
rob at cataclysm.cx
Sat Apr 20 12:59:40 UTC 2002
> > Are you saying that any entity connected directly to the network can be
> > considered a "server", while any entity that is not connected directly
> > (a user client) is a "client"?
> I'm saying that Jabber only has protocols that recognize a client or server.
> Things like the groupchat manager acts as a logical server on the network
> even though it is probably implemented as an integral component of some
> other server. If you're talking to something that is not is a client or
> server role, you aren't using Jabber...
Fair enough. I'm still not sure that these definitions of client and
server really correspond to the IANA jabber-client and jabber-server,
> >>> Transports will never be completely transparent to clients, because you
> >>> have to know their address so you can route to them.
> >> Is that true? I thought the server can maintain a map of addresses and
> >> clients using one set of addresses can be completely ignorant of how the
> >> messages are delivered to a particular address.
> > I'm not sure I understand this. What I meant, is that to talk to, say, a
> > user on AIM, I need to know that I need to send messages to
> > user at aim-t.host.
> > If there is some sort of mapping like this, its news to me.
> Oh yes. Actually, the gateway iq protocol pretty much does this. :)
Ahh, gateway .. yes, but you still need to know where the transport is.
> > Agreed, sort of. You mean that the protocols need to be in either the
> > jabber:client or the jabber:server namespaces. The problem is that
> > neither of these are defined, per se, and the line between them is very
> > fuzzy.
> :) Well, the documentation for them may be a bit fuzzy. :) But they
> actually are pretty clearly defined. Almost all Jabber protocols exist as
> both a c2s and s2s protocol. The main difference is that authentication
> differs for c2s and s2s, and that s2s allows multiplexing of user traffic,
> while c2s will only support packets sent from, or destined to the
> authenticated user account established during c2s authentication for that
> Although the protocols may be used s2s, c2s, or c2c, there is only servers
> and clients...
s2s "authentication" isn't, not exactly, because it relies on the DNS.
> > (Using AAF, it would be entirely possible to implement a Kerberos
> > authentication mechanism without too much trouble).
> This would actually be interesting to mention in your doc. I think something
> along these lines is a current hot button in IM security.
Perhaps I'll need to read more about Kerberos, and put together an auth
mehanism for it.
So, where do we go from here? I still don't have a problem with AAF as
it stands; I don't see any fundamental flaws in it. Should we be doing
SASL, even though it down essentially the same job, or just continue
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