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

Re: Security



On Aug 26, 2008, at 11:40 AM, Simon Josefsson wrote:



Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> writes:


On Aug 13, 2008, at 9:18 AM, Simon Josefsson wrote:
Your approach would send the message that we recommend users to prefer 
PLAIN+TLS over CRAM-MD5+TLS.


The problem as I see it is that the draft doesn't make it clear that
we're recommending CRAM-MD5+TLS.  The one recommendation statement
isn't enough.

Most implementors and deployers and users of PLAIN understand PLAIN's
weaknesses without even reading RFC 4616. Reading RFC 4616 reinforces 
what folks already understand.  But even so, RFC 4616 reiterates the
recommendation in the Abstract and Introduction, provides examples
showing use with TLS, and then reinforces its recommendations by
clearly stated security considerations.  RFC 4616 also places
requirements on IETF protocols that state PLAIN is an applicable
authentication mechanisms that the protocol specification MUST mandate 
implementation of strong data security services.

Implementors, deployers and users of CRAM-MD5 appear not to well
understand CRAM-MD5's weaknesses and hence are more apt to ignore the
recommendation, especially one buried on page 5 of the specification.
The CRAM-MD5 specification places no mandate on IETF protocols that
state CRAM-MD5 is an applicable authentication mechanism.
All of the above appear to be fixable by changing the CRAM-MD5 document. 
Right?
Yes. But I have a hard time assuming that the changes will actually happen. 


A more interesting discussion seems to be: Assuming the document
recommends CRAM-MD5+TLS sufficiently well (similar to the wording in the 
PLAIN document), would such a document be acceptable to put on the
Standards Track and with the applicability of COMMON?
I'm personally think the I-D has other issues (such as interop) would are not yet adequately addressed. I do think it's possibly that the I- D could be revised such to address all of its known issues, but I'm concerned that this might be viewed as being too disruptive. 


If that is not the WG consensus, it would be clearer to abandon the
current CRAM-MD5 specification and produce a "Moving CRAM-MD5 to
Historic" document.


Seems like an approach worth considering...


However, I believe CRAM-MD5+TLS, with warnings about channel binding
vulnerabilities, is valuable to have on the standards track until there 
is other solutions that we can recommend instead (i.e., GS2+SCRAM).
Alternatively, publish the "CRAM-MD5 to Historic" document simultaneously as the GS2+SCRAM document. 

I suspect the alternative is likely easier to gain consensus for....

-- Kurt