[standards-jig] Small Footprint Clients and Authentication

Evan Prodromou evan at prodromou.san-francisco.ca.us
Thu May 29 18:51:00 UTC 2003


>>>>> "PS" == Peter Saint-Andre <stpeter at jabber.org> writes:

    PS> 1. There are no SASL-aware servers to test against.

Now, first off, I swear I'm not just being contrarian. ;-)

But isn't jabberd2 SASL-aware? I'm just glancing over the code, and
there's lots of SASL-specific stuff. Yeah, it's an alpha release, but
that shouldn't be a big problem for lab testing.

    PS> SASL-aware servers will not be widespread on the Jabber
    PS> network for some time to come.

On the other hand, edigest-aware servers are completely
non-existent. B-)

    PS> But we want to do compliance testing rather soon, and it's
    PS> unrealistic to expect clients to do only SASL authentication
    PS> when SASL-aware servers are not available (or widely
    PS> available).

A couple of points:

1) I don't think anyone wants clients to _only_ do SASL authentication
   any time in the next 2-3 years. But if SASL is the Way Of The
   Future, we should start preparing for that by ceasing enhancements
   of jabber:iq:auth.

2) The protocol schedule and requirements should drive compliance
   testing, not the other way around. It seems like short-term
   thinking to move the goalposts around to make compliance testing
   possible, when we'll all be saddled with the protocol changes
   needed to do that for years to come.

    PS> 2. The argument has been made to me that small-footprint
    PS> clients can do jabber:iq:auth but not SASL. I don't know
    PS> whether that is true or not.

I think that whoever made this assertion, if they're available, should
speak up and confirm it, or we should just drop it. It's really not
holding up under scrutiny.

    PS> 3. Both jabber:iq:auth and jabber:iq:register should be
    PS> reviewed every six months by the Jabber Council for possible
    PS> deprecation (please see Section 8 of JEP-0001 for details). I
    PS> think they cannot be deprecated now but should be deprecated
    PS> in the future.

Perhaps "nonpreferred" would be a better word than "deprecated".

    PS> 4. The addition of the "edigest" method is intended to move
    PS> the old jabber:iq:auth protocol closer to the level of
    PS> password security (in storage) provided by MD5.

If we're determined to fiddle with jabber:iq:auth, and the goal is to
provide a mechanism security-equivalent to RFC 2831, we should instead
define RFC 2831 in jabber:iq:auth.

This has the all the security advantages (ahem) of edigest, and
additionally provides a convenient upgrade path between current
jabber:iq:auth and SASL down the road. Clients will have the logic for
DIGEST-MD5 authentication, and can just shift around their output to
be in XMPP-SASL format rather than jabber:iq:auth format.

~ESP

-- 
Evan Prodromou
evan at prodromou.san-francisco.ca.us






More information about the Standards mailing list