[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have



On Mar 31, 2008, at 10:06 PM, Frank Ellermann wrote:


Kurt Zeilenga wrote:


The group has determined that DIGEST-MD5 (RFC2831) is not suitable
for progression on the Standards Track due to interoperability,
internationalization, and security concerns.



What I18N concerns ?


For one, lack of a specified character data normalization algorithm and
character encoding for passwords.


The only security concern I've heard of is the lack of channel
bindings, did I miss something important ?


Prone to downgrade attack.
Before I respond to your per-quality comments, I note that the short list of desired qualities is not intended to impart any requirements upon the deliverable. The list is certainly not inclusive of all the desired qualities. I did purposely try to list some qualities which can be consider opposed to each other.
In talking with Pasi, he suggested we keep this list short of key qualities. 


Use of well understood and broadly-implemented algorithms (e.g.,
HMAC, SHA1),






Not everybody likes SHA1, and those who like SHA1 are supposed to
like SHA2 better.
SHA1 is only listed an example of a well-understood and broadly- implemented 
algorithm.




Algorithm agility


That's a SASL feature, one side offers what it can do, the other
side picks what it supports and considers as best.  ITYM hash
agility, the mechanism must allow to be cloned for another hash.
No additional negotiation "within" the new mechanism.
There has also been talk of why it might be desirable to provide agility within the mechanism. 




Negotiated key hardening iteration count,


When H(x) is not "hard enough", then H(H(x)) shuffling the bits
again using the same H is not necessarily "harder".  It might
be interesting to look at H(x||count) or RMX if the PBKDF2 idea
turns out to only burn cycles, instead of being really "harder".


Just another desirable (to some) quality.





Downgrade attack protection,


I'm not sure what you have in mind.  When one side offers SASL
mechanisms A, B, and C, the other side can only pick, or say
"not good enough" - especially if it knows that there used to
be a better D when not talking to an attacker.


I listed this specifically because DIGEST-MD5 feature negotiation
is prone to downgrade attacks.





Channel Binding,


Unfortunately I'm not sure what this means.  Is this about
A <- TLS -> M <- TLS -> B, when A and B happily use SASL PLAIN
and don't know that they really talk "via" an attacker M ?  Do
channel bindings imply to use TLS ?
This means that it would be desirable for the mechanism to be capable of securely binding the ends points of a lower-level security channel, such as provided by TLS, to the end points of the mechanism exchange. 





Additionally, the WG will deliver a document summarizing its
DIGEST-MD5 concerns and requesting RFC 2831 be moved to
Historic status.


What will the WG do with standards having a normative reference
to RFC 2831 ?
Nothing. The WG is not in the business of updating SASL profiles for application profiles. 


-- Kurt