Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

[Weijun Wang <[e-mail]>]

> On Aug 4, 2017, at 8:40 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
>> 4. And a clarification text "When neither of the methods is called, the implementation should choose a default provider for each mechanism it supports" to the introduction of addProviderAtFront() and addProviderAtEnd(), at the end of S 6.1.
> 
> I'm not entirely sure that this addresses Ekr's concern.  Laying it out (hopefully)
> more clearly, suppose that I have a java standard library that provides GSSAPI
> support, and supports the krb5 and ntlm mechanisms.  It's clear that my
> application code could supply an alternate provider for the krb5 mech and
> have that used preferentially.  But could my application code also supply
> a provider for, say, the IAKERB mech via addProviderAtFront, and have that used?

I think this is already covered in https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-04#page-34:

> 3) The application wants to use the locally configured providers as
>       far as possible, but if support is missing for one or more
>       mechanisms, then it wants to fall back on its own provider.

Here, support for the IAKERB mech "is missing", and user provides "its own provider". Of course in this case, calling addProviderAtFront or addProviderAtEnd makes no difference.

Thanks
Max