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

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> Ian Paterson wrote:
>> Kevin Smith wrote:
>>> On 11 Sep 2007, at 17:20, Ian Paterson wrote:
>>>> Even where TLS is available, SASL PLAIN requires server operators to
>>>> keep copies of all users' passwords. This is a serious (and often
>>>> unnecessary) security weakness.
>>> I'm not sure that's true; the server could hash the password still,
>>> both in storage and at the end of the wire. It doesn't help against a
>>> compromised server that's still accepting connections, but the
>>> passwords don't need to be stored plaintext afaics.
>> Yes, sorry everyone who corrected me. That was my silly error (lack of
>> sleep).
>>
>> 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.

Kurt Zeilenga pointed me to the following text in RFC 4513:

B.2.1.  Section 4 ("Required security mechanisms")

   - The name/password authentication mechanism (see Section B.2.5
     below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
     LDAP's mandatory-to-implement password-based authentication
     mechanism.  Implementations are encouraged to continue supporting
     SASL DIGEST-MD5 [DIGEST-MD5].

Presumably we could have similar text in rfc3920bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070911/53cd0831/attachment.bin