RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5

[Jamil Nimeh]

On 12/19/2017 07:52 AM, Weijun Wang wrote:
>
>> On Dec 19, 2017, at 10:05 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> This looks good. Just a few comments:
>>
>> - please add a release note subtask and open a separate docs issue to document the new etypes
>> - does this need a CSR? I would think it does because it is adding support for a new RFC and etypes
> Will do.
>
>> * AesSha2DkCrypto.java
>>
>> - why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow exceptions but stringToKey(char[] secret, byte[] salt, byte[] params) does not?
> I simply copy the behavior of the same methods for other etypes. Looks like the later is always private and called by the former. The former is called by EncryptionKey::acquireSecretKey and this method was designed to accept a null value instead of handle an exception.
>
>> - 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?
>
> Thanks
> Max
>
>> --Sean
>>
>> On 11/1/17 8:38 PM, Weijun Wang wrote:
>>> Ping again.
>>>> On Sep 18, 2017, at 5:15 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>
>>>> Hi All
>>>>
>>>> Please take a review at
>>>>
>>>>    http://cr.openjdk.java.net/~weijun/8014628/webrev.00/
>>>>
>>>> Most changes are just duplicating existing classes/methods/fields on AES-SHA1 etypes. One day we might do some refactoring to simplify this.
>>>>
>>>> Real changes:
>>>>
>>>> - AesSha2DkCrypto.java:
>>>>
>>>> 1. A new dr() method, explained in https://tools.ietf.org/html/rfc8009#section-3
>>>>
>>>> 2. etype name used in stringToKey(), explained in https://tools.ietf.org/html/rfc8009#section-4
>>>>
>>>> 3. A separate deriveKey() method. Not only it reduces duplicated codes, but it is also used in KerberosAesSha2.java the test.
>>>>
>>>> - Config.java:
>>>>
>>>> Previous AES-SHA1 etypes now have aliases aes128-sha1 and aes256-sha1.
>>>>
>>>> - EType.java:
>>>>
>>>> The default enctypes set now includes the new aes-sha2 etypes, but aes-sha1 etypes are more preferred. This is also what MIT krb5 is doing.
>>>>
>>>> - KerberosAesSha2.java
>>>>
>>>> Test vectors in https://tools.ietf.org/html/rfc8009#appendix-A.
>>>>
>>>> Thanks
>>>> Max
>>>>