Code review request: 8005523: Unbound krb5 for TLS

[Weijun Wang]

On 4/15/13 11:05 AM, Xuelei Fan wrote:
>>> ... 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, ...)

Good.

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

Why CCC? This is all internal.

>
> . 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.

If the returned serverKeys is empty (it won't be null), line 208 will 
return a null and line 213 will throw the IOE. Is that enough?
>
>
> Is it possible to add a new test for the unbound krb5 in TLS?

It's already there. Note the "principal=*" in the updated SSL.java test. 
Maybe I can provide 2 test cases, one bound, one unbound.

Thanks
Max

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