RFC 3962 and DK(tkey, "kerberos") function

[Tom Yu]

"kerberos at noopy.org" <kerberos at noopy.org> writes:

> Hello,
>
> I've been working on generating AES keys for a keytab.  I've been
> following RFC 3962 and 3961 and have gotten as far as implementing a
> PBKDF2 function in C# per RFC 2898.  Following this high-level
> representation of AES 128
> (http://msdn.microsoft.com/en-us/library/dd304065%28PROT.10%29.aspx)
> my results are correct thus far.  I am having a heck of a time
> implementing a DK() function in C# however.
>
> I implemented PBKDF2(...) with C#'s Rfc2898DeriveBytes class and what
> I don't quite understand is how "kerberos" is hashed against the
> intermediate key generated by Rfc2898DeriveBytes to generate my AES
> 128, 256, etc key.  It looks like "kerberos" has to be folded (maybe
> n-folded) somehow so that I can use it as my IV, but I am not quite
> sure I'm on the right track.  I've been comparing my results with
> ktpass.exe (when I create a keytab w/an itercount of 4096 and type of
> AES128-SHA1) to what I'm generating but no dice.
>
> Can someone shed some light on this?

The IV is also known as the "cipher state" for CBC ciphers, and each
cryptosystem specification includes a default initial cipher state.
For "simplified profile" (e.g. DES3 and AES) cryptosystems, this is
all-bits-zero.

The DK function uses n-fold to expand the well-known constant
"kerberos" to a full cipher block length and then uses a temporary key
to encrypt that block.  It does not use the n-folded constant as an
IV.  In the case of AES, the temporary key is the output of PBKDF2.