Key derivation with non-ASCII characters
hartmans at MIT.EDU
Fri Sep 3 14:29:57 EDT 2004
>>>>> "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
More information about the Kerberos