[standards-jig] Refreshing the Thread: EDigest
mass at akuma.org
Thu May 29 03:45:35 UTC 2003
I discussed this with Diz and after lots of productive arguing we came
to a compromise: I'll support adding a standard jabber:iq:auth mapping
of a SASL mechanism to JEP-0078. This way we cannot be perceived as a
standards body of 'circumventing' the XMPP and IETF processes, and won't
be adding new functionality to the jabber:iq:auth protocol which goes
beyond the XMPP core and im internet-drafts. We decided to to work on
registering an "EDIGEST" SASL mechanism to the IANA, only to quickly
realize that what we were proposing is remarkably similar to another
existing SASL mechanism, DIGEST-MD5. The only real differences are that
they use a 'realm' where we use a random value, and they use a different
So basically we decided that my arguments were almost completely mute.
We should just document the mechanism for a user to register an edigest
with JEP-0077, and add a note to JEP-0078 explaining that edigest stuff
is added only to bring equivalent DIGEST-MD5 functionality for things
which do not support SASL, without requiring additional algorithms like
MD5. Of course, the edigest and the DIGEST-MD5 password stores will not
be compatible, but because the value supplied in the register request
and stored is a SHA1 digest rather than a MD5 one.
David Waite wrote:
> Richard Dobson wrote:
>> Edigest seems fine to me now, its just an extra option for those that
>> it, my only real beef was with the suggestion of depresiating standard
>> digest in favour of this, but as that is not going to be done now it all
>> seems fine to me.
> I've decided I'm very much opposed to this being within a
> standards-track JEP.
> From the XMPP charter:
> "A major goal of the working group will be to extend the current XMPP
> protocols to provide finished support for RFC 2779-compliant security
> mechanisms, including authentication, privacy, access control and
> end-to-end as well as hop-by-hop message security."
> The JSF supported the IETF effort ot perform security enhancements,
> but now we are saying in this forum that the mechanisms proposed
> aren't good enough, without even bringing this to their attention.
> jabber:iq:auth should only be for providing compatibility with
> pre-XMPP clients. Any 'enhancements' from this point forward should be
> done as new SASL mechanisms. If SASL is too hard for non-desktop
> clients to support, we need to bring this to the XMPP working group
> _now_. By my measurements though, the solid differences between the
> two is requiring Base64 rather than lowercase hexadecimal encoding,
> and MD5 instead of SHA1. (to support both the MD5 DIGEST and
> PLAINTEXT SASL mechs)
> So either we are enhancing security outside the XMPP effort and the
> IETF (which seems horribly wrong to me both technically and
> politically), or we are making a major change which does not enhance
> security (which is just dumb).
> If someone wants to make this informational, I'm all for it. From my
> cursory glance, it does not expose any new security problems, but I am
> not a security export.However, unless someone manages to bring
> arguments to my attention which haven't been in the previous barrage
> of email on the subject, I'm very much a solid -1 on a standards-track
> JEP 78 containing this. If a SASL mechanism for edigest is proposed,
> I'm fine with it going into JEP 77, since the IETF has no in-band
> registration standards.
> -David Waite
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards