On 9/17/2014 11:32 AM, Wang Weijun wrote: > > 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. One of my motivation for a better design is the getServiceCreds() and the Exchanger.getResult() methods in the current webrev, which is more like a internal logic of krb5 key exchange.
For the new design, no need to define the Exchanger.getResult() and getServiceCreds() any more. Correspondingly, these function might be able to implemented internally in the service provider. > Also it seems we still need to define an extended HandshakeMessage which is > similar to KerberosClientKeyExchange that contains getPeerPrincipal() and > getLocalPrincipal(). I think it could the function of the new ExternalCipherSuiteProvider. > 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 to hide the details of KRB5 in SunJSSE as if we want to move the implementation details to Krb5. If we do it later, it is likely we need to reorg most the of code in this update, I would prefer we do it now. If I did not miss something, the new design should be more simple and straightforward. Xuelei > 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....@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 >>> >> >
