FWIW there are some well-respected people in the kerberos community who believe that rfc 2712 (I assume that is what these cipher suites are) should be deprecated in favor of some more modern alternative. I do not believe these suites see very wide use, although it’s probably not zero.
On Oct 20, 2014, at 5:21 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > Hi Xuelei > > Long time no discussion on this one. > > Updated webrev at http://cr.openjdk.java.net/~weijun/8038089/webrev.05/. Not > exactly the same as your suggestion and not final. Just want to ask you take > a look. > > 1. There are still 2 classes. ClientKeyExchange is for that hashshake > messgae, and ClientKeyExchangeService is to introduce new service not in the > base module. > > 2. I've tried my best to not mention KRB5 anymore inside the base module, but > CipherSuite is an exception: > > a. Shall we change KeyExchange from enum to a normal class. Otherwise it > cannot be subclassed so there is no way to add new exchange in a service. > > b. We should also move all add(KRB5...) lines into the service. > > 3. Which is the first class loaded in JSSE? Is it JsseJce? I'd like to load > the services and introduce new KeyExchange and CIpherSuite there. > > Thanks > Max > > > On Sep 22, 2014, at 12:06, Xuelei Fan <xuelei....@oracle.com> wrote: >> >> >> My idea about the new service looks like: >> -------------------- >> public interface ClientKeyExchange { >> // Get the peer principal of this client key exchange >> public Principal getPeerPrincipal(); >> >> // Get the local principal of this client key exchange >> public Principal getLocalPrincipal(); >> >> // Create a new client key exchange message >> // >> // Should be called in client side. >> public HandshakeMessage createClientKeyExchange(String hostname, >> AccessControlContext acc, int protocolVerson, >> SecureRandom rand) throws IOException; >> >> // Parse a client key exchange message >> // >> // Should be called in server side. >> public HandshakeMessage parseClientKeyExchange(int protocolVerson, >> int clientRequestedVersion, SecureRandom rand, >> byte[] encodedTicket, byte[] encrypted, >> AccessControlContext acc) throws IOException; >> >> // Negotiate the pre-master secret of this client key exchange. >> public SecretKey clientKeyExchange() throws IOException; >> } >> -------------------- >> >> Still need a few methods in order to support session resumption. The >> initialization method may depend on the service loading approach. For >> example, if it is defined as SPI, we can call it via algorithm name >> ("KRB5"); if it is defined to be load with ServiceLoader, may need to >> define a new sub-class for KRB5. >> >> In TLS handshaking, the usage of the methods may look like: >> ----------------------- >> Client Server >> krb5-ciphers ---ClientHelloRequst--> Support Krb5? >> initialize Krb5 ClientKeyExchange >> <----- ServerHello ---- >> <---ServerHelloDone---- >> initialize Krb5 ClientKeyExchange >> create krb5 ClientKeyExchange message >> ---ClientKeyExchange--> parse ClientKeyExchange msg >> get the pre-master secret >> negotiate the shared secret >> ---changeCipherSpec---> >> -------Finished-------> get the pre-master secret >> negotiate the shared secret >> <---changeCipherSpec--- >> <-------Finished------- >> ... >> ----------------------- >> >> >> Thanks, >> Xuelei >> >> On 9/17/2014 1:58 PM, Xuelei Fan wrote: >>> On 9/17/2014 1:49 PM, Wang Weijun wrote: >>>>> I would prefer we do it now. If I did not miss something, the new design >>>>> should be more simple >>>>> and straightforward. >>>> >>>> Maybe, but I am not sure since this would surely touch more TLS side >>>> codes. If you want to be totally separated, we also need to move the >>>> ciphersuites definitions outside CipherSuite.java. The TLS side can >>>> iterate through all providers to add them back and create something like a >>>> Map<keyExchangeAlg, KeyExchangeService>. Then we could use this map in all >>>> "switch (keyExchange)" blocks. >>>> >>>> Do you think it's easier to make these changes based on the current codes? >>>> Or based on my modified codes? >>>> >>>> Can you describe the KeyExchangeService interface you are thinking about? >>>> Currently I have to define a two-level interface -- >>>> ExternalCipherSuiteProvider and ExternalCipherSuiteProvider.Exchanger -- >>>> to model the service and the exchange instance. >>>> >>> OK, I will wrap up my ideas of the KeyExchangeService. But it may take a >>> few more days. Wish I could get it ready by next Monday. >>> >>> Thanks, >>> Xuelei >>> >> > Personal email. hbh...@oxy.edu
