[standards-jig] Advanced authentication
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