[standards-jig] Advanced authentication

Robert Norris 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,
though.

> >>> 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
> session.
> 
> 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
refining AAF?

Rob.

-- 
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/20020420/713388f3/attachment.sig>


More information about the Standards mailing list