Key derivation with non-ASCII characters

[Sam Hartman]

>>>>> "Frank" == Frank Taylor <FrankSTaylor at gmail.com> writes:

    >> Careful here.  The crypto document does require the use of
    >> UTF-8 encoding.  However, in the updated specification (as in
    >> RFC1510), these strings are actually restricted to 7-bit
    >> US-ASCII.  Implementations which use non-ASCII characters (and
    >> most do) violate RFC1510.

    Frank> I stand corrected. Indeed the UTF-8 mention is the in the
    Frank> crypto draft. What status does this now have given that it
    Frank> has just expired?  The Kerberos clarification doc
    Frank> references the crypto draft for the definition of the
    Frank> string_to_key function (and its expected input).

The crypto draft has been approved for publication as an RFC by the
IESG.    That's one of the cases that will prevent a draft from
 expiring even if it gets past its expiration date.  It is currently
 in the RFC editor queue.



    >> Sam has explained what the existing
    >> (pre-kerberos-clarifications) Microsoft implemenetation will
    >> actually do -- it will expect you to encode all strings as
    >> UTF-8, and does not perform any normalization.

    Frank> So, given that I can use UTF-8 password/salt I should get
    Frank> the right values for MS AD... unfortunately I still don't
    Frank> get the right key.

I think this concerns us greatly.  A lot of assumptions we've been
making in the Kerberos working group depend on understanding what
vendors have done.

Could you look at the salt that is being used?  The easiest way to do
that is to try sending an AS request and see what you get back in the
etype-info structure?

--Sam