[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Security
On 12 Aug 2008, at 2:51 AM, Simon Josefsson wrote:
Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> writes:
On 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:
| CRAM-MD5 is no longer considered to provide adequate protection.
I believe the WG consensus supports the inclusion of this statement
in
the I-D, as well as the detailed consideration text that follows it.
That's not the case, as it depends on the circumstances where
CRAM-MD5 is used. E.g. over TLS it could be fine (ignoring the
issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
is certainly better than APOP (as stated in 2195) or "LOGIN".
I believe Frank has a point here: CRAM-MD5 under TLS with server
authentication does not have any of the security problems mentioned in
section 5, at least as far as I can tell from a quick read of the -10
document.
Which is why there is a recommendation that TLS be used.
Given the mechanism can be used without TLS, detailing considerations
for use without TLS seems quite appropriate. It's also appropriate to
discuss considerations for use with TLS.
It is my belief that WG consensus is that the current text is adequate
in both of these areas. I encourage anyone who thinks the current
text can be approved upon offer alternative text for the WG to consider.
CRAM-MD5 does have interoperability problems in that it historically
doesn't require use of UTF-8 and SASLPrep. However, support for
SASLPrep in PLAIN was added in a later revision of PLAIN. The same
could be done for UTF-8 and SASLprep in CRAM-MD5 too, which would
remove
that interoperability problems.
Right, one could MUST Unicode, MUST SASLprep, MUST-UTF-8. To date, I
simply haven't seen significant WG support for changing the SHOULDs to
MUSTs.
Summarizing, we could do for CRAM-MD5 what we did for PLAIN (require
TLS
and require UTF-8 + SASLprep).
Because of CRAM-MD5 use of cryptographic functions, CRAM-MD5 requires
more than what PLAIN requires. PLAIN could get away with a server-
side SHOULD as it presumed the server knows what it might otherwise be
able to do to ensure proper function. With CRAM-MD5, the client
traditionally has had to rely on a priori knowledge of the character
sets/encoding/normalization to ensure proper function, and that means
that one cannot independently produce an interoperable
implementation. If one desires independently developed
interoperability, then providing a precise definition of the character
encoding and normalization procedures is a necessary (as MUSTed by RFC
4422). Such MUSTs would likely cause disruption.
I have no seen adequate support for MUSTs here.
None of the arguments made in the
document would still stand against that construct (I think). What is
puzzling is that the document already appear to strongly suggest use
of
TLS and UTF-8 and SASLprep, so I think we have already solved the
security and interoperability problem inherent in the old CRAM-MD5
specification.
I don't believe the SHOULDs are adequate to ensure independently
developed interoperability.
/Simon