Re: [sasl] I-D Action:draft-ietf-sasl-scram-08.txt

[Nicolas Williams <[e-mail]>]

On Fri, Oct 02, 2009 at 09:54:24PM +0200, Simon Josefsson wrote:
> This version seems fine in general, but re SASLprep on password it says:
> 
>   o Normalize(str): Apply a Unicode normalization algorithm to a UTF-8
>     [RFC3629] encoded "str". The resulting string is also in UTF-8.
>     Implementations SHOULD use the SASLPrep profile [RFC4013] of the
>     "stringprep" algorithm [RFC3454] as the normalization algorithm.
> 
> That text does not resolve whether Normalize() should be invoked with
> unassigned code points permitted or not.  There were different
> suggestions on what clients and servers should do in earlier
> discussions, so I believe the text has to be explicit on what clients
> and servers needs to do.
> 
> I don't care strongly, but my preference is to disallow unassigned code
> points everywhere where a string is hashed.  Allowing unassigned code
> points introduce uncertainty in the algorithm, and I find that to rarely
> be useful in practice.  My experience is that allowing unassigned code
> points is useful when the string is transferred to the other side for
> comparison, but when the string is hashed that is no longer the case.  I
> am aware that others have different preferences.

Here we must treat passwords as storage strings.  SASLprep doesn't
distinguish between query and stored strings, but it does reference
Stringprep, which does.  And Stringprep has this to say about stored
strings: "[s]tored strings using the profile MUST NOT contain any
unassigned code points".

New text:

   o  Normalize(str): Apply a Unicode normalization algorithm to a UTF-8
      [RFC3629] encoded "str".  The resulting string is also in UTF-8.
      Implementations SHOULD use the SASLPrep profile [RFC4013] of the
      "stringprep" algorithm [RFC3454] as the normalization algorithm.
----> Note that, for SCRAM, passwords are "stored strings", which means
----> that unassigned codepoints in SCRAM passwords are prohibited (see
----> RFC3454, section 7).

Nico
--