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

Weijun Wang weijun.wang at oracle.com
Tue Dec 19 15:52:24 UTC 2017



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

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



More information about the security-dev mailing list