question about wanted_enctypes in krb5_gss_init_sec_context()

[Will Fiveash]

On Thu, Jun 20, 2002 at 02:35:54PM -0400, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <william.fiveash at sun.com> writes:
> 
>     Will> I've noticed in the 1.51.2.8.2.4 version of
>     Will> init_sec_context.c (MIT 1.2.5) that the function
>     Will> krb5_gss_init_sec_context() uses the intersection of
>     Will> wanted_enctypes and the default_tgs_enctypes as the list of
>     Will> enctypes that a GSS client will request for the session key.
>     Will> I'm wondering if the code to find the intersection is really
>     Will> necessary.  Can't the default_tgs_enctypes be used for the
>     Will> list of requested session key enctypes by GSS clients?  If
>     Will> so, then the wanted_enctypes[] array could go away which
>     Will> would be a good thing.
> 
> In 1.2.5 probably so.  On the mainline, no.  We do not support GSS
> with the export grade RC4 as an example.
> 
> In general, because of the way RFC 1964 is written, we cannot
> guarantee that we have a way to use arbitrary session key types with
> GSSAPI.

So, if I read you correctly, you are saying that it's possible that
the Kerberos protocol could support an enctype that would be
incompatible with GSS when Kerberos is used as a mech?  Does the issue
involve the quality of protection values?  If so, I'm confused because
I notice that in RFC 1964, the only confidentiality QOP value is
GSS_KRB5_CONF_C_QOP_DES but the wanted_enctypes[] in MIT 1.2.5 lists
ENCTYPE_DES3_CBC_SHA1 as one of the session key enctypes that a GSS
client can request.

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)