[standards-jig] Advanced authentication
rob at cataclysm.cx
Tue Apr 16 01:39:24 UTC 2002
> I think if it is possible, a SASL profile is a better solution than anything
> "jabber native". When it comes to security, people like to work with well
> known solutions if possible. IMO, anything that is not SASL should really
> demonstrate advantages several times more compelling than SASL in order to
> justify itself or provide reasons why it is impractical to do so.
Perhaps, but if it does the job in essentially the same way, but is
modified from "pure" SASL to better fit the Jabber protocols better, does
that make it of less value?
> I think it would really strengthen your proposal if you went into more
> details why you think we should use AAF rather than a SASL profile. In
> particular, if you could expand the following sentence from the document:
> > It cannot technically be called a Jabber SASL profile, because it does not
> > conform to section 4 of RFC 2222.
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.
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?
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
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 didn't realise this when first putting AAF together, and now I've
realised it, I'm even more convinced that SASL is not suitable for the
same jobs that AAF handles. I'll probably end up removing the comparison
to SASL from the proposal.
> I think it would also be nice to discuss whether this is a retrofit to the
> existing Jabber system, or proposal for Jabber Next Generation (JNG) or
It's a protocol extension. It has nothing to do with any single
implementation of the server. Besides, does anyone really know what JNG
It would take considerable effort to replace client authentication with
AAF anytime soon, because we do not have a defined namespace for session
management. Currently, jabber:iq:auth overloads authentication and
session information (ie the <resource/> tag) in the same packet.
Also, at least for jabberd, it would require a serious overhaul of the
way that c2s communicates with the session manager. I beleive temas has
done some work in this area in the past, but there's still a long way to
It could, however, be used right now for general authentication between
two entities (eg two components, a user client and a service, etc).
I'm not interested in cobbling together something over the top of the
existing flaws, but rather producing something that is "correct" and
will continue to work long into the future. I am quite aware that are
dependencies that need to be met before AAF could ever replace simple
authentication (most notable session management).
These are the reasons I haven't yet submitted AAF to the council.
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