Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Jul 2002 16:32:15 +0200

This leads to having words like "Masse" and "Maße" treated as the same
user identity or password, I'm not sure that is a good idea.

I also note that the use of Unicode NFKC normalization in the
specification makes it incompatible with all existing CRAM-MD5
implementations I've looked at.

"Kurt D. Zeilenga" <[email-masked]> writes:

> It might be appropriate for 2222bis to provide a SASL
> string profile(s) [draft-hoffman-stringprep] for
> authentication identities, authorization identities,
> and passwords which mechanisms can reference as needed.
>
> Kurt
>
>
> At 07:28 AM 2002-06-23, Simon Josefsson wrote:
>
>>Lyndon Nerenberg <[email-masked]> writes:
>>
>>> This version was pushed to replace the about-to-expire -01 draft;
>>> there are no changes to the content from the -01 version.
>>>
>>> I haven't received any comments since the publication of -01,
>>> therefore I plan to submit this for last call a few days after the
>>> upcoming IETF meeting ends.
>>
>>I have two comments regarding the use of Unicode NFKC normalization:
>>
>>1) It can be made more clear that using other normalization tables
>>   than the one referenced may result in interoperability problems:
>>
>>--- draft-nerenberg-sasl-crammd5-02.txt.orig    Mon Jun 17 20:01:40 2002
>>+++ draft-nerenberg-sasl-crammd5-02.txt Sun Jun 23 16:21:13 2002
>>@@ -87,7 +87,11 @@
>>      The user name and shared secret MUST be represented in the Unicode
>>      character set [UNICODE], and MUST be normalised using the Unicode
>>      Normalisation Form KC [NFKC]. The resulting values MUST be encoded
>>-     as UTF-8 [UTF8].
>>+     as UTF-8 [UTF8].  An application MUST NOT use newer normalization
>>+     tables even when such are available because it is not possible to
>>+     know if the other protocol entity also utilizes these newer tables.
>>+     This includes any Unicode normalization erratas that may be issued
>>+     in the future.
>> 
>> 
>> 3.1.  Formal Syntax
>>
>>2) Update CRAM-MD5 to use Unicode 3.2. According to
>>   http://www.imc.org/idn/mail-archive/msg06650.html there was one
>>   backwards incompatible change in the NFKC normalization tables
>>   between 3.1 and 3.2, it could be good to use the latest version to
>>   support that character properly.
>>
>>--- draft-nerenberg-sasl-crammd5-02.txt.orig    Mon Jun 17 20:01:40 2002
>>+++ draft-nerenberg-sasl-crammd5-02.txt Sun Jun 23 16:04:43 2002
>>@@ -200,8 +200,8 @@
>>      [NFKC]
>>           Davis, M., M. Durst, "Unicode Standard Annex #15: Unicode Nor-
>>           malisation Forms", An integral part of The Unicode Standard,
>>-          Version 3.1.1 (http://www.uni-
>>-          code.org/reports/tr15/tr15-21.html).
>>+          Version 3.2.0 (http://www.uni-
>>+          code.org/reports/tr15/tr15-22.html).
>> 
>> 
>>      [SASL]
>>@@ -210,12 +210,11 @@
>> 
>> 
>>      [UNICODE]
>>-          The Unicode Consortium, "The Unicode Standard, Version 3.1.1",
>>+          The Unicode Consortium, "The Unicode Standard, Version 3.2.0",
>>           defined by: The Unicode Standard, Version 3.0 (Reading, MA,
>>           Addison-Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
>>-          Unicode Standard Annex #27: Unicode 3.1 (http://www.uni-
>>-          code.org/reports/tr27/) and the Unicode 3.1.1 Update Notice
>>-          (http://www.unicode.org/versions/ Unicode3.1.1.html).
>>+          Unicode Standard Annex #28: Unicode 3.2 (http://www.uni-
>>+          code.org/reports/tr28/tr28-3.html).
>> 
>> 
>>      [UTF8]
>>
>>Perhaps one also can discuss the problem of using different
>>transcoding tables to convert from legacy character sets to Unicode in
>>clients and servers, since such tables aren't standardized, but
>>hopefully that is mostly academic.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Jul 2002 21:57:42 -0700

>user identity or password, I'm not sure that is a good idea.

IMO, It's better than having them treated as being different...
(considering that the user may switch to input devices
not capable of generating the ß.

Anyways, we have a significant interoperability problem with
different implementations comparing identities and passwords
differently.  We must explicitly define how this is to be done
for each mechanism.  My suggestion is that we define a SASL
string profile which mechanisms should utilize.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 12:21:38 +0200

> not capable of generating the ß.

ß is a special case, most non-ASCII characters are not normalized into
ASCII characters in stringprep.  E.g., å is not.

> string profile which mechanisms should utilize.

I guess it is the way most protocol are heading, so perhaps it is a
good idea.  Wouldn't this prohibit binary authentication/authorization
identities and passwords though?  I remember some discussions earlier
if identities and passwords were supposed to be binary clean or not.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jul 2002 04:48:59 -0600

> implementations I've looked at.

Can you tell more about these implementations? How do they send non-ASCII
usernames and/or passwords?

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 13:01:32 +0200

> usernames and/or passwords?

They encode them using the local character set, it seems.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jul 2002 06:05:29 -0600

> They encode them using the local character set, it seems.

...and as CRAM-MD5 didn't specify a charset, they don't (and will not)
interoperate anyway.
So this is not an issue. (Note, that this is not an argument for NFKC in
particular).

Regards,
Alexey Melnikov

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Jul 2002 16:32:15 +0200

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Jul 2002 21:57:42 -0700

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 12:21:38 +0200

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jul 2002 04:48:59 -0600

Regards,
Alexey Melnikov

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 13:01:32 +0200

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jul 2002 06:05:29 -0600

Regards,
Alexey Melnikov