Re: Security

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx> writes:

> Simon Josefsson writes:
>> Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> writes:
>>>> SHOULD has worked fine for PLAIN, so I disagree.
>>>
>>> It works fine because of PLAIN's design.  The party, the server, is
>>> preparing both the presented and stored strings.   In CRAM-MD5, two
>>> parties need to agree on the preparation on what preparation to use
>>> for things to work properly.
>>
>> Ah, I understand your objection now.
>>
>> Given that RFC 2195 appears to be ASCII only, I don't see a problem with
>> extending it to UTF-8 in a revised version and mandate that using a
>> SHOULD or MUST though.
>
> It doesn't say the password is ASCII, only that the digest being
> sent is.  Authentication breaks if the password is UTF-8, one
> protocol peer SASLpreps it, and the other does not.
>
> OTOH it also breaks if the password is Latin-1, one peer translates to
> UTF-8, and the other does not.  "MUST use UTF8/SASLprep" in practice
> implies "client and whoever creates server secret MUST know which
> character encoding is in use, so it can translate to UTF-8 if needed".
> Simple solutions to that would be to reject 8-bit input or make it the
> user's problem and expect UTF-8 input, of course.

True.  However, I think it is reasonable to assume that RFC 2195
intended for passwords to be ASCII only.  We can fix this lack of detail
with new text that says MUST UTF-8+SASLprep before hashing in 2195bis.
This is a problem that can be fixed when revising a standard, it doesn't
necessarily mean the standard is broken without any chance of rescuing
it.

/Simon