--On Tuesday, September 15, 2009 10:55 +0200 Simon Josefsson
<simon@xxxxxxxxxxxxx> wrote:
>...
> 2) This is a technical issue.
>
> SCRAM does not say anything about the encoding used for the
> password (e.g., Latin-1, UTF-8) or whether SASLprep should be
> applied to the string or not. I believe this violates this
> requirement in RFC 4422:
>
> In order to avoid interoperability problems due to differing
> normalizations, when a mechanism calls for character data
> (other than the authorization identity string) to be used
> as input to a cryptographic and/or comparison function, the
> specification MUST detail precisely how and where (client
> or server) the character data is to be prepared, including
> all normalizations, for input into the function to ensure
> proper operation.
>
> For simple user names and/or passwords in authentication
> credentials, SASLprep [RFC4013] (a profile of the
> StringPrep [RFC3454] preparation algorithm), SHOULD be
> specified as the preparation algorithm.
>
> For highest interoperability the document could do MUST use
> UTF-8 and MUST use SASLprep. I understand that some people
> will not implement SASLprep, and I agree with them that there
> are valid reasons for not implementing SASLprep (such as it
> being based on obsolete Unicode versions), so I would be
> equally happy with MUST use UTF-8 and SHOULD use SASLprep. I
> don't think the requirement on SASLprep can be relaxed further
> without breaking the requirements in RFC 4422. Personally, in
> the long term I would prefer to deprecate SASLprep in favor of
> Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I
> believe "SHOULD use SASLprep" in SCRAM is a reasonable
> trade-off considering these factors.
For whatever it is worth, I agree with this analysis. I'm not
sure that RFC 5198 is an adequate substitute for SASLprep, but
it is far better than unrestricted UTF-8 (which, IMO, we should
no longer be recommending in any protocol that requires
comparison of strings).
Because of the unrestricted UTF-8 problem, and without taking a
position on deprecating SASLprep, my inclination would be to
strengthen Simon's proposed requirement a bit to "MUST use UTF-8
and SHOULD use SASLprep or at least Net-UTF-8" or its
equivalent.
Alternately, I believe that any string that would successfully
come out of SASLprep would conform to Net-UTF-8, i.e., that the
set of valid SASLprep strings is a proper subset of the set of
valid Net-UTF-8 strings. If that were true -- and someone with
significant Unicode normalization and SASLprep
knowledge/experience would need to verify it-- then "MUST use
Net-UTF-8 [RFC 5198] and SHOULD use SASLprep" would be an even
better formulation (perhaps with a note about that subset
relationship).
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf