Simon Josefsson wrote:
John C Klensin <john-ietf@xxxxxxx> writes:
[...]
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.
I share Kurt's concern that this opens up for several classes of
implementations that may not interoperate well.
+1.
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).
Something along those lines may work, but I think there are serious
risks to get the details wrong with a quick fix like that here. If
someone has time to study your question that would be useful input
nonetheless.
Pending something more baked than SASLprep and Net-UTF-8-in-SASL, I
continue to believe that "MUST UTF-8 and SHOULD SASLprep" is a
reasonable compromise.
+1.
Finally, I strongly believe that deferring publication of SCRAM
significantly to address this issue in a more thorough way does more
harm than good.
I agree.
The state-of-the-art SASL mechanism today either
transfer passwords to servers without hashing them first, or they use
MD5 for the hash, and neither is acceptable. If we don't publish SCRAM,
the SASL framework will be unusable for new protocols.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf