Subject: set-passwd v2 and I18n, take three

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Jul 2004 17:08:57 -0500

Sam and I met today for about two and a half hours on this topic.

We have reached an agreement and a more complete understanding of
Kerberos V extensions and I18N issues than we had had before.  And it is
clear that our collective treatment of these issues had been incomplete.

I do not at this moment have time to give a full report however, so you
will have to wait until tomorrow for it, but fear not, for I have notes.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 30 Jul 2004 19:25:36 -0500

> will have to wait until tomorrow for it, but fear not, for I have notes.

And here, then, is the report.  
********************************************************************************

We started by looking at details and kept backing off to look at the
bigger picture.  I'll do the reverse here.

The big picture is:

 - While we want a Kerberos V extensions-only world, we need a migration
   strategy, including support for dual mode pre-extensions/extensions
   deployments.

This entails a sort of hypocratic oath for Kerberos V extensions and
pre-extensions uses of non-IA5String characters in protocol elements:

 - Principal and realm names, and passwords, with non-IA5String
   characters should, in dual-mode deployments, continue to work such as
   they did, for pre-extensions implementations, as well as they used to
   prior to the advent of extensions.

   In other words: don't break what used to work.

   (Of course, such strings do not interop too well pre-extensions, but
   to the extent that they do they should continue to.)

 - Getting to a pure-extensions world effectively means eventually
   changing all old non-IA5String names, passwords and salts and, during
   the transition, possibly having multiple valid forms of the same.

Rounding out the big picture we note that we don't merely have a
"just-send-8" problem, we also have a "just-use-8" problem:

 - Principal and realm names are just-sent-8, pre-clarifications.
 - Passwords are just-used-8, pre-clarifications.
 - Salts are both, just-sent-8 and just-used-8, pre-clarifications.

 - The distinction between between just-send-8 and just-use-8 is that in
   the case of the former just-8 strings are sent on the wire, whereas
   in the latter peers must agree on the just-8 strings a priori, or
   fail.

   Passwords are only sent on the wire when setting new ones, else they
   are fed to string2key() and failure to agree means failure to
   authenticate.

   Salts are just-sent-8 on the wire in ETYPE-INFO/ETYPE-INFO2, but are
   also optimistically just-used-8 with string2key() in initial AS
   requests.

Now for the details.

Prior to Kerberos V extensions and set-password v2 the KDC didn't know
and didn't have to know about the encoding of new passwords -- it just
fed them to string2key and went on its merry way.  (I'm glossing over
password quality policies, many implementations of which simply assumed
the KDC's locale when examining new passwords.)  As long as users used
the same locales (or platforms) consistently this sufficed.

Extensions and set-passwd v2 change this IF and only IF we want new
non-ASCII passwords set on Kerberos V extensions-enabled realms to work
with any/some clarifications implementations.

New non-ASCII passwords set by extensions/set-passwd v2 clients won't
work with just-use-8 pre-extensions clients, not unless we take steps to
help the KDC massage such new passwords into the expected just-use-8
form they would have taken prior to extensions.  This is so in part
because we want to use UTF-8 only on the wire, but also partly because
extensions/set-passwd v2 clients won't necessarily be representative of
pre-extensions clients/locales also used by the same users during the
migration.

That is, if the KDC knows nothing about the encodings to be used on
pre-extensions clients for new extensions non-ASCII passwords, then the
KDC can't possibly ensure that the principal's long-term key as known by
the KDC will match the string2key output on pre-extensions legacy
systems because the KDC will have no way to produce expected just-use-8
versions of new passwords given nice, normalized UTF-8, not without some
hints.

So, IF we want new non-ASCII, extensions passwords to work with any,
some, or all pre-extensions clients then the KDC must have information
about such clients' preferred encodings -- a set of encodings.

Such information can be set, on the KDC, administratively in a
per-realm, per-principal and/or per-client fashion.  Set-password v2
clients can also provide some of this information, through the language
tags for the user, and even the encoding of the client's current locale
(or user's locale preferences).

Now, just how many encodings should extensions KDCs support for new
non-ASCII passwords to be usefully interoperable with pre-extensions
clients?  And what does this entail?

The answer to the first question is that the upper bound is the number
of known, used encodings plus one for unnormalized Unicode; in most
cases this may be just a handful.  Let's call this number 'N'.

What this entails is that the KDC must try up to N+1 PA-ENC-TIMESTAMP
validations per-pre-extensions AS-REQ!  It can either store up to N+1
versions of the long-term key in its KDB, or it can store the password
and perform up to N string2key() ops per-pre-extensions AS-REQ.  This is
because of the just-use-8 nature of passwords.

You can see that reducing N is highly desirable.

Also, in the case of pre-extensions AS-REQs w/o pre-authentication the
KDC simply cannot ensure that it picks the right longterm key.

Sam's point, prior to yesterday had been that N can be expected to be
very small per-realm, mine was that in the case of large, global
organizations N could be quite large, say, 16-20.  AES string2key() x 16
takes a lot of time.  AES key size x 16 takes a lot of space.  Thus I
argued that information from set-password v2 clients about users' locale
preferences could be used to reduce N to 1 or 2.

One last detail.  The solution we propose is that extensions KDCs that
care need to support N password encodings, as described above, but these
encodings will be obtained by converting the UTF-8 provided by
set-password v2 clients, which means we're making this assumption: that
the set-password v2 passwords can be converted to the other encodings as
they would have been produced by pre-extensions clients.  This
assumption need not always hold, for example, if the other encodings are
encodings of Unicode other than UTF-8, or if the are unnormalized UTF-8
(as in Windows 2000).  To compensate for this we can have just-use-8
strings sent (where they are sent) as display strings -- that is,
unnormalized; this applies to passwords in the set-password v2 protocol
and to salts in extensions' ETYPE-INFO2.

So, we settled on the following:

 - Salts and other string2key character string-type parameters should be
   sent unnormalized on the wire (that is, salts are display strings on
   the wire) but only new salts that can be SASLprep'ed to storage
   strings should be allowed.

 - The same applies to passwords in the set-password v2 protocol.

 - Set-password v2 clients should have an option to send information
   about users' preferred or current locale to the server.  Locales
   consist, mostly, of a language tag and an encoding tag; the
   set-password v2 protocol already has a way to send language
   preference information to the server -- adding an encoding preference
   won't be hard.

   Such information can be used by KDCs that wish to support new
   non-ASCII passwords on pre-extensions clients by helping to limit the
   number of legacy encodings of the password, and therefore, the number
   of versions of a user's longterm keys, that the KDC should support.

 - Extensions KDCs need not actually do anything to support use of new
   non-ASCII passwords on pre-extensions clients, and perhaps the
   document should not describe the strategy described above, but for
   those implementors who do want to provide such support, the way to do
   it is described above.

Cheers,

Nico
--