[standards-jig] Advanced authentication

Robert Norris 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
   to identify).

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

It's a protocol extension. It has nothing to do with any single
implementation of the server. Besides, does anyone really know what JNG
is?

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

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.

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/20020416/88bdf7b6/attachment.sig>


More information about the Standards mailing list