[standards-jig] Refreshing the Thread: EDigest

Matt Tucker matt at jivesoftware.com
Thu May 29 04:21:12 UTC 2003


David,

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 
"impossible".

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.

Regards,
Matt

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 
>>> want
>>> 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
>> http://mailman.jabber.org/listinfo/standards-jig
> 
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig




More information about the Standards mailing list