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