[standards-jig] JEP 34 (SASL)
jeremie at jabber.org
Fri Aug 23 16:21:42 UTC 2002
> Ok, after an involved set of discussions this afternoon, let me take another
> crack at this. I still like the IQ's.
Why? I don't see any technical reason as to why it would be better to be
inside an IQ, and know of a few why it's better to not be, particularly
the fact that this is authenticating the stream, for more than just the
jabber:client, jabber:server, or any other stream namespace(s).
The ability to publish and determine the support for SASL in the opening
of the stream and as a seperate namespace is important, particularly for
S2S, which with it buried in an IQ it would have to have the implicit
behaviour of "if it's an iq, and if there's no to or from attributes, then
check the namespace" instead of just throwing everything out unless it's
in one of the stream namespaces (as well as having to possibly watch for
and define the behaviour of an attempted sasl iq after any alternative
trust mechanism like dialback or a handshake/key-exchange).
The jabber packets (iq/message/presence) are all "routeable" for the most
part and associated with some known identity, particularly for s2s or
component connections, and the only exceptions being c2s auth/reg. I see
this as an opportunity to clean up and enforce that concept, and putting
sasl inside an iq would only blur it. The sasl exchanges aren't
routable in the JID sense and are valueable primarily to the stream
processing software for authentication of any (c2s/s2s/service) stream,
hence the stream level namespace.
> I understand the desire to have the authentication mechanism be able to
> support multiple credentials for the same stream.
It's just a possibility, not necessarily a desire, or at least that
feature isn't the goal/intent.
> I think that opens a very large can of worms on the current protocol
It doesn't change the current protocol in any way, nor does making use of
that possibility even change any aspect of the protocol after using sasl,
it's simply the use of one of possibly many authorized identities to
create a session.
> and with the current implementations.
Heh, huh? First, obviously, this has nothing to do with current
implementations, and secondly, it would only need be supported if the
authentication back-end supported herirachial groupings instead of a
traditional flat one-to-one account system (any current implementation
just adding sasl support would obviously be the latter and not able to
More information about the Standards