On 8038089: TLS optional support for Kerberos cipher suites needs to be re-examine

[Weijun Wang]

On 8/6/2014 20:55, Xuelei Fan wrote:
> Weijun,
>
> Where the krb5 impl will be packaged into in the future?

In the java.jgss module.

>  Still the
> SunProvider but in a new jar file?  I was wondering whether we can use
> the provider service approach that we used to define other security
> components implementations.  I'm not quite confident with the security
> of the use of ServiceLoader.load().

You mean define a new provider service like "MessageDigest" and 
"Cipher", I think that's a heavier version of ServiceLoader. Also this 
interface is now quite premature and only used internal.

By security, are you afraid of someone providing his own implementation 
and shadow the JDK one? I'll do some investigation.

--Max

>
> Xuelei
>
>
> On 8/4/2014 9:48 AM, Wang Weijun wrote:
>> Hi Xuelei
>>
>> Are you OK with the code change? The updated webrev is now at
>>
>>    http://cr.openjdk.java.net/~weijun/8038089/webrev.02/
>>
>> Comparing to the last version. there are some comment changes and emptying refs.allowed. The only major change is that the ServiecLoader now uses system class loader.
>>
>> Thanks
>> Max
>>
>> On Jul 21, 2014, at 16:22, Wang Weijun <weijun.wang at oracle.com> wrote:
>>
>>> Please review the updated webrev at
>>>
>>>   http://cr.openjdk.java.net/~weijun/8038089/webrev.01
>>>
>>> Some comment changes. Some arguments rearrangement between classes.
>>>
>>> The interface is still in sun.security.ssl. It will be easy to move it to somewhere else later. When module is introduced, we may need to export the interface from java.base to java.security.jgss.
>>>
>>> Thanks
>>> Max
>>>
>>> On Jul 17, 2014, at 12:35, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>>> On 7/16/2014 4:41 PM, Wang Weijun wrote:
>>>>> Hi Xuelei
>>>>>
>>>>> A *primitive* version of webrev available at
>>>>>
>>>>>   http://cr.openjdk.java.net/~weijun/8038089/webrev.00
>>>>>
>>>>> Please confirm this is the way you like it.
>>>>>
>>>> I have not read too much about the details of the update.  But looks
>>>> like it is in the right way.
>>>>
>>>>> ExternalCipherSuite is the service interface and Krb5CipherSuite implements it. It's a modification of the old Krb5Proxy but I've moved as many as Kerberos-related codes to the implementation side so it has less methods now.
>>>>>
>>>>> Most likely we will define this new interface in a public package.
>>>>>
>>>> If krb5 is the only external implementation of TLS cipher suites, I
>>>> think, we may want to try the best not to define public interface if
>>>> possible.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> I didn't touch any core SSL classes except for ClientHandshaker and ServerHandShaker. If you think there are other places too closely connected with kerberos, please let me know.
>>>>>
>>>>> Ideally, those
>>>>>
>>>>> case K_KRB5: case K_KRB5_EXPORT:
>>>>>    Krb5Helper.doXXX(...):
>>>>>
>>>>> should be something like
>>>>>
>>>>> default:
>>>>>    getExternalHelper(keyExchange).doXXX(...)
>>>>>
>>>>> but I guess we won't do that unless we know there will be a second implementation.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>