[standards-jig] Advanced authentication

Iain Shigeoka iainshigeoka at yahoo.com
Tue Apr 16 17:29:07 UTC 2002

On 4/15/02 6:39 PM, "Robert Norris" <rob at cataclysm.cx> wrote:

> First, it should be noted that AAF is not simply a replacement for the
> current authentication system, which is only really used during client
> (c2s) authentication. It is intended to be allow for authentication
> between any two Jabber entity, not just for authentication of a client
> to a session manager.

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

> Section 4 of RFC 2222 outlines requirements for SASL profiles. I've gone
> through each point of section 4 below:
> 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?

> 2. This is covered by AAF, by means of the initial set to request a
>  mechanism. The only difference is that the mechanism identifiers are
>  different so that they are better suited to XML (ie using a namespace
>  to identify).

BEEP (www.beepcore.org) does this with XML too.

> 3. This is covered by AAF, as much as the various aspects can be used by
>  Jabber. The only thing left out is a description of how the
>  challenges and responses are encoded, since this we already have a
>  rich encoding system, the XML itself. This is better left to the
>  actual authentication mechanism descriptions to define.
> 4. The "negotiated security layer" (ie the packet stream after
>  authentication completes) starts after the server entity sends the
>  last result packet of the authentication dialogue. This is defined by
>  the authentication mechanisms themselves, because they may want to
>  send some data back with the final result.
> 5. This is completely dependent on the function of the server entity,
>  and so isn't applicable.
> 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


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

More information about the Standards mailing list