Code review request: 8005523: Unbound krb5 for TLS
Weijun Wang
weijun.wang at oracle.com
Wed Apr 17 01:39:09 UTC 2013
Webrev updated:
http://cr.openjdk.java.net/~weijun/8005523/webrev.02/
Changes since webrev.01:
1. Add a isRelated() Krb5Helper method to find out if a Subject can
provide creds for a service principal.
2. Server check permission at initialization if bound
3. Only check permission again at clientkeyexchange if unbound
Thanks
Max
On 4/16/13 8:48 PM, Weijun Wang wrote:
>
>
> On 4/16/13 8:18 PM, Xuelei Fan wrote:
>> On 4/16/2013 5:44 PM, Weijun Wang wrote:
>>>>
>>>> I am not sure how to do that. Can I just skip this check and whenever
>>>> subject != null always set resumingSession to true? This is not very
>>>> correct but is it possible to detect the mismatch later and "resume"
>>>> the
>>>> full negotiation?
>>>>
>> No, it is dangerous. The server has to make the right decision while
>> parsing ClientHello.
>>
>> Can you design a new Krb5Helper method to match the principals and
>> implement it in krb5/Krb5ProxyImpl.java. If it is a bound krb5, need to
>> match exactly; otherwise, the matching is performed per the request of
>> unbound krb5.
>
> I'll try.
>
>>
>> For unbound krb5, what's the return value of KerberosKey.getPrincipal()?
>
> Unbound krb5 has no KerberosKey, it only has KeyTab, and KeyTab.isBound
> is false.
>
> -Max
>
>> Is it a "*"? If it is always a "*", we also can check it in
>> ServerHandshake.java. I'm afraid it is not reliable so you won't
>> consider it.
>>
>>>
>>> It seems the purpose of this check is that, if it fails, you can be sure
>>> that kerberos is not loaded so the full negotiation will try to find a
>>> RSA ciphersuite. Is that right?
>>>
>> It depends. The check is also can be used to prevent abused session
>> resuming. The following full negotiation acts like a new handshaking, so
>> the Kerberos cipher suite may be used again.
>>
>>> I cannot call kerberos-specific codes in SSL because of module
>>> independence.
>>>
>> krb5/Krb5ProxyImpl.java? See above.
>>
>> Xuelei
>>
More information about the security-dev
mailing list