Re: Security

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> writes:

> 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.

Sure, but if CRAM-MD5 is used with TLS, the initial statement above is
misleading: there is nothing in the security considerations of CRAM-MD5
that explains how CRAM-MD5 under TLS fails to provide adequate
protection.

> 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.

I suspect people read different things into the first statement here.  I
suggest to change it to:

  CRAM-MD5 used without TLS is no longer considered to provide adequate
  protection.

Otherwise it is unclear whether 'CRAM-MD5' refers to the actual
HMAC-mechanism used by CRAM-MD5 (then the sentence is true) or whether
it refers to CRAM-MD5 used under TLS (then the sentence is false).

>> 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.

Agreed.  Note that PLAIN merely says that TLS SHOULD be used.  I believe
a SHOULD is sufficient, especially considering the good explanation of
the problems that leads to recommending TLS in the CRAM-MD5 document.

>> 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.

Nor have I, but I don't believe MUST is required.  PLAIN contains:

   By default, implementations SHOULD advertise and make use of the
   PLAIN mechanism only when adequate data security services are in
   place.

It continues with:

   Specifications for IETF protocols that indicate that this
   mechanism is an applicable authentication mechanism MUST mandate that
   implementations support an strong data security service, such as TLS.

That places restrictions on specifications, not implementations, which
is somewhat weird, but CRAM-MD5 could do the same.  That is what I
propose to do.

>> 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.

SHOULD has worked fine for PLAIN, so I disagree.

/Simon