[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]

Ian Paterson ian.paterson at clientside.co.uk
Wed Sep 12 12:53:37 UTC 2007


Peter Saint-Andre wrote:
> Ian Paterson wrote:
>   
>> In real life servers will always be compromised (especially in cases
>> where the attacker is the service provider). So SASL PLAIN still
>> contains a serious vulnerability that is easily fixed in those cases
>> where DIGEST-MD5 is a practical option.
>>     
>
> Except that DIGEST-MD5 is effectively being deprecated by the IETF. Thus
> the interest in SCRAM, YAP, and their ilk.
>   

With all due respect to the experts at the IETF, I feel (as a 
non-expert) that they are trying to depricate DIGEST-MD5 before it has a 
suitable replacement (i.e. another one that protects users' passwords 
from a compromised server). I strongly agree we should recommend/require 
SCRAM and/or YAP as soon as they are baked. But is that likely to happen 
before 3920bis is puiblished?

I agree that if we start recommending SASL PLAIN in addition to 
DIGEST-MD5 now, *and if we continue to do so in the future*, then we can 
ensure that current implementations will still be compatible with future 
implementations that have removed support for DIGEST-MD5.

However I don't understand why we are considering recommending weakening 
the security of XMPP servers in the short and medium term by not 
requiring any of DIGEST-MD5 or SCRAM or YAP. Are XMPP implementors 
experiencing interoperability issues with DIGEST-MD5? If so can't we fix 
them with a Best Practices XEP - as we did with SASL ANONYMOUS and SASL 
EXTERNAL? Which of the 7 problems with DIGEST-MD5 mentioned in [1] make 
DIGEST-MD5 less secure for XMPP authentication than SASL PLAIN?

- Ian

[1] 
http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt




More information about the Standards mailing list