[standards-jig] Refreshing the Thread: EDigest
matt at jivesoftware.com
Thu May 29 04:21:12 UTC 2003
I think that someone mentioned before that DIGEST-MD5 is a required
algorithm in SASL? Does that mean that XMPP clients/servers would need
to support it? With the JEP-78 edigest changes, does that mean clients
and servers have to support essentially the same mechanism but with two
different algorithms in order to be "compliant"?
I guess I agree with Evan that I don't see the point in adding more to
auth if we tell developers that supporting SASL is required unless it's
BTW, I checked and there are quite a few options for full cryptography
libraries in J2ME out there (MD5 and SHA1 included with encryption
algorithms). So, I guess I don't see what would be hard about SASL then?
I'm not tied to SASL in any particular way, it just seems like a good
idea to run with only a single route -- either a new auth protocol or SASL.
David Waite wrote:
> 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
> hashing algorithm.
> 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
> 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
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards