Code review request: 8005523: Unbound krb5 for TLS

[Xuelei Fan]

>> ... Especially, I make Handshaker public and pass it
>> to KerberosClientKeyExchangeImpl so that its context can be used to
>> check permissions. Is this necessary? I mean, is the context any
>> different from the one inside KerberosClientKeyExchangeImpl?
The access control context is reserved for KRB5/JAAS especially. It is
used to force to use the context that generate the socket, rather than
the context of Krb5 (Note that Krb5Proxy in Krb5Helper is an static
final instance).

I would suggest to pass AccessControlContext instead of Handshaker
parameter if you only need the context.  As the one for client side, for
example:
KerberosClientKeyExchange.init(init(String serverName, boolean
isLoopback, AccessControlContext acc, ...)

Do you want to file a simple enhancement request (CCC)?

. KerberosClientKeyExchangeImpl.java
------------------------------------
Do you want to check the return value to make sure it is non-null or
empty? Otherwise, it is possible to run into NPE when using the serverKeys.

188  KerberosKey[] serverKeys = AccessController.doPrivileged(

An IOException will be thrown if the principal is not matched. I think
we need to reserve the behavior.


Is it possible to add a new test for the unbound krb5 in TLS?

Thanks,
Xuelei

On 4/1/2013 9:16 PM, Weijun Wang wrote:
> Ping again.
> 
> On 3/14/13 4:42 PM, Weijun Wang wrote:
>> Hi Xuelei
>>
>> You might know that krb5 now supports unbound acceptor, which means if
>> you set "principal=*" in an acceptor's JAAS login config file, it can
>> serve as any service. The acceptor would read initiator's request, find
>> out what the intended service name is, and then find a key for it from
>> its keytab file.
>>
>> Currently TLS's krb5 ciphersuites must know the service principal at the
>> beginning, it uses the info to read keys and then wait for incoming
>> requests. This must be changed if it also want to be "unbound".
>>
>> I have a primitive patch here
>>
>>     http://cr.openjdk.java.net/~weijun/8005523/webrev.00
>>
>> You can see it gets a ServiceCreds instead of KerberosKey at the
>> beginning. This ServiceCreds encapsulates keytabs and JAAS settings, and
>> it can be used to find keys for any service name later.
>>
>> The fix is quite ugly. Especially, I make Handshaker public and pass it
>> to KerberosClientKeyExchangeImpl so that its context can be used to
>> check permissions. Is this necessary? I mean, is the context any
>> different from the one inside KerberosClientKeyExchangeImpl?
>>
>> Thanks
>> Max