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

[Sean Mullan]

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

* AesSha2DkCrypto.java

- why does stringToKey(char[] password, String salt, byte[] s2kparams) 
swallow exceptions but stringToKey(char[] secret, byte[] salt, byte[] 
params) does not?

- can you verify if the new proposed KDF API could be used for the 
key-derivation parts in the future?

--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
>>
>