--On Tuesday, September 15, 2009 10:55 +0200 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf