[standards-jig] Advanced authentication

Iain Shigeoka iainshigeoka at yahoo.com
Fri Apr 19 16:50:34 UTC 2002

On 4/18/02 4:03 PM, "Robert Norris" <rob at cataclysm.cx> wrote:

>>> Agreed, but there will still be discrete entities attached to the
>>> network.
>> Right.  But they must play either a server or client role.  If they don't
>> play one of those roles, they are part of some other client or server entity
>> (you couldn't separate them and have them function separately on the Jabber
>> network).
> 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...

>>> 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.  :)

>>> I'm not talking about how jabberd handles things internally. Entities
>>> attached to the network must communicate in a defined way, otherwise,
>>> what's the point? It doesn't matter what type of entity they are, or
>>> where they are in the network (remember, the network spans multiple
>>> "servers" (routers)) - they should perform tasks in a standard way.
>> Right.  But that's only defined in Jabber for c2s and s2s communication.
>> There is nothing else.  So the protocols must be c2s or s2s...
> 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...

> (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.


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

More information about the Standards mailing list