question about wanted_enctypes in krb5_gss_init_sec_context()
william.fiveash at sun.com
Thu Jun 20 17:13:00 EDT 2002
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 18.104.22.168.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
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.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev