question about wanted_enctypes in krb5_gss_init_sec_context()

[Sam Hartman]

>>>>> "Will" == Will Fiveash <william.fiveash at sun.com> writes:

    Will> So, if I read you correctly, you are saying that it's
    Will> possible that the Kerberos protocol could support an enctype
    Will> that would be incompatible with GSS when Kerberos is used as
    Will> a mech?  

I'm actually saying it is currently true on our mainline code that we
support enctypes for Kerberos we do not support for GSS.  It has been
true in the past for released code and is reasonably likely to be true
again in the future.


    Will> Does the issue involve the quality of protection
    Will> values?  If so, I'm confused because I notice that in RFC
    Will> 1964, the only confidentiality QOP value is
    Will> GSS_KRB5_CONF_C_QOP_DES but the wanted_enctypes[] in MIT
    Will> 1.2.5 lists ENCTYPE_DES3_CBC_SHA1 as one of the session key
    Will> enctypes that a GSS client can request.

It's not so much that it involves QOP as everyone ignores that.  It
involves whether theree is a specification of how to use particular
keys with GSSAPI.  You are correct that RFC 1964 only specifies single
DES.  We also implemented a 3DES GSSAPI mechanism which is not
documented anywhere.  (There is documentation of a different mechanism
that differs from ours only in implementation bugs somewhere).  We
believe Heimdal and the MIT implementation share this 3DES mechanism.

There is documentation of an RC4 based mechanism in a Microsoft draft.
We have implemented that on our mainline.  The It seems to work with
Microsoft, although there are a few operations that must be tested
before release.


There is limited ongoing work on an AES GSSAPI mechanism.

If all of this leads you to the conclusion that RFC 1964 really has no
business talking about specific encription types and that it should
have used abstract messages like krb_priv or something like that, we
completely agree with you.