Subject: Re: [Ietf-krb-wg] New Version Notification - draft-ietf-krb-wg-otp-preauth-20.txt

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Oct 2011 13:38:58 -0400

We believe that this new version should resolve the discuss comments.
Stephen, even if it does resolve all the comments, please hold off on
approving it for at least a week to give the WG time to comment on the
changes.

I believe that Sean was copied on all the discussion regarding his
comments.

With regard to Unicode strings here's what we've done.

1) we've removed any case-insensitive comparisons.

2) Where possible we've recommended that string comparison happen on the
KDC. We've recommended that for now we use saslprep because we have it,
although because much of the comparison is happening on the KDC, we can
upgrade that in the future. It's a SHOULD not a MUSt for all the same
reasons sasl plain is a SHOULD saslprep. You may have some backend
system that really needs (or already does) something else.

3) One class of strings that requires client handling is the vendor and
service strings. Sometimes they are just display strings. However in the
case of connected token matching they are identifiers. In this case, the
identifier is supplied to the KDC and to the token by the token
vendor. We believe transporting strings without modification and doing
octet-level matching will cover almost all cases. Since the strings are
hard-coded in tokens and supplied to the KDC by the same people
supplying the tokens, that seems reasonable. Clients are permitted to
perform more liberal (more likely to match) comparisons than octet-level
match; they could do case insensitive comparisons if desired. We don't
think there will be security issues with this, but we don't think it's
required for interoperability, so it's a MAY.

4) There's one class of strings where we had a hard choice. Clients need
to prepare a password-like quantity (a PIN possibly combined with an OTP
value) for hashing. We chose saslprep because we have it. Here, the
Unicode 3.2 issue is real although probably not as bad as with
passwords. We probably will want to come back and update this. We've
promised to consider saslprep compatibility, but if we break
compatibility with some uncommon strings that probably isn't the end of
the world. In other words we'll take saslprep now and expect to move to
whatever the IETF gets to for hashed applications of strings in a
Unicode version independent manner.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg