Hi Max,
The former approach for KDF would be the correct one. If this isn't a
derivation algorithm that has use outside our Kerberos implementation
then I'm not sure it's worth making it a general KDF implementation
because of its specificity. But I have no strong feelings either way.
--Jamil
On 12/19/2017 4:04 PM, Weijun Wang wrote:
On Dec 20, 2017, at 12:02 AM, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
- can you verify if the new proposed KDF API could be used for the
key-derivation parts in the future?
I'll try.
I took a quick look at the dr() method and I'm pretty sure this can fit into
the KDF API as it currently sits. I'd like to read that section of the RFC
just to be sure, but it looks pretty straightforward. Out of curiosity does
this KDF get used anywhere other than Kerberos?
I don't think so. You can see it is defined inside the Kerberos RFC.
There are 2 key derivations inside Kerberos. You can see them inside the test
[1]:
1. From (passphrase,salt,(optional) iteration count) to a basekey, lines 53, 56.
2. From (basekey, usage, type) to an application key, line 165. Here type can
be one of checksum, encryption or integrity, and usage can be an arbitrary
integer (For example, 1 for issuing a key, 2 for send a message).
It looks the KDF API can be called this way:
KDC kdf = KDF.getInstance("Kerberos5/base");
kdf.init(passphraseAsKey, (salt+count), List.of(empty));
Key baseKey = kdf.deriveKey();
KDC kdf2 = KDF.getInstance("Kerberos5/app");
kdf2.init(baseKey, null, List.of(usage+type));
Key appKey = kdf2.deriveKey();
and either kdf2.init() should be run again and again for different usage+type,
or create kdf2 each time.
Or, if there is a deriveKey(DerivationParameterSpec) method, it can be simpler
KDC kdf = KDF.getInstance("Kerberos5");
kdf.init(passphraseAsKey, (salt+count));
Key appKey = kdf2.deriveKey(usage+type);
Thanks
Max
[1]
http://cr.openjdk.java.net/~weijun/8014628/webrev.00/test/jdk/sun/security/krb5/etype/KerberosAesSha2.java.html
