RFR 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine
Wang Weijun
weijun.wang at oracle.com
Wed Sep 17 03:32:58 UTC 2014
Certainly it will be better to make the interface more generalized. But there are ExternalCipherSuiteProvider methods like getServiceCreds() and isRelated() and I don't know how they will be used for other key exchange services. Also it seems we still need to define an extended HandshakeMessage which is similar to KerberosClientKeyExchange that contains getPeerPrincipal() and getLocalPrincipal(). In this sense, it is more likely we rename KerberosClientKeyExchange to a better name instead of moving it out of SSL.
Do you wish to do these inside this bug or a new one? I prefer the latter when we decide to support (or at least prototype) one of those other key exchange services.
--Max
On Sep 17, 2014, at 10:27, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> I'm OK with the doPrivileged-with-permission mode.
>
> Generally speaking, we only need to define the authentication part of a
> cipher suite for KRB5 implementation. I was wondering, can we simplify
> the code more as follow:
> 1. define an private external authentication interface, which:
> a. generate key exchange message;
> b. read key exchange message;
> c. generate pre-master secret.
>
> 2. This interface can be implemented for key exchange/authentication as
> KRB5 (RFC 2712), SRP (RFC 5054), PSK (RFC 4279), etc.
>
> For this fix, we probably want to:
> 1. move KerberosClientKeyExchange.java to krb5 model.
> 2. update ExternalCipherSuiteProvider (rename to KeyExchangeService?) to
> support HandshakeMessage parser and generation, and the generation of
> pre-master secret.
> 3. don't need Krb5Helper any more, call the new interface directly.
>
> After the update, the SunJSSE provider would only known the algorithm
> name of the KRB5 key exchange.
>
> What do you think?
>
> Thanks,
> Xuelei
>
> On 9/16/2014 9:31 AM, Wang Weijun wrote:
>> Hi Xuelei
>>
>> Please review the latest code change at
>>
>> http://cr.openjdk.java.net/~weijun/8038089/webrev.04/
>>
>> Compared with webrev.03, only the way the provider is loaded is changed, which is the static block on lines 50-71 of Krb5Helper.java.
>>
>> Thanks
>> Max
>>
>
More information about the security-dev
mailing list