>> Do you want to file a simple enhancement request (CCC)? > > Why CCC? This is all internal. > Yes, it is optional. I think, now it can accept unbound principal in server side, it is an enhancement. It would be nice to have the community and SQE know the improvement.
>> >> . 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? The exception message will be confusing if the check is done in line 208 and 213. I like to show principal mismatch message when using bound principals. Xuelei >> >> >> 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 >>
