Re: [PATCH 10/22] gss_krb5: Add upcall info indicating supported kerberos enctypes

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Thu, 2010-04-15 at 09:17 -0400, Kevin Coffman wrote: 
> On Thu, Apr 15, 2010 at 7:34 AM, Steve Dickson <SteveD@redhat.com> wrote:
> > On 04/14/2010 02:30 PM, Kevin Coffman wrote:
> >>> diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
> >>> index 8b612e7..d96d824 100644
> >>> --- a/net/sunrpc/auth_gss/gss_krb5_mech.c
> >>> +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
> >>> @@ -552,6 +552,7 @@ static struct gss_api_mech gss_kerberos_mech = {
> >>>        .gm_ops         = &gss_kerberos_ops,
> >>>        .gm_pf_num      = ARRAY_SIZE(gss_kerberos_pfs),
> >>>        .gm_pfs         = gss_kerberos_pfs,
> >>> +       .gm_upcall_enctypes = "enctypes=1,2,3 ",
> >>>  };
> >>
> >> Hi Trond,
> >> This list should be in preference order.  It doesn't matter much with
> >> this one, but the preferred order for DES is usually "3,1,2".
> >>
> >> When adding 3DES, the list should be "16,3,1,2"
> >> When adding AES, it should be "18,17,16,3,1,2"
> >> When adding RC4, it should be "18,17,16,23,3,1,2"
> > Ok... I went back and took a second look at this... The first
> > thing I did was put the gm_upcall_enctypes list back in
> > preference order. I had no idea there was actually a theory
> > behind the order...
> >
> > Side Note: It appears the ordering really does not matter
> > because the KDC is the one that decides (via the TGS-REP) which
> > enctype will be used and (I've been told) the KDC will always
> > pick the highest enctype possible.
> >
> > Now the reason root was not getting its context was
> > basically because of the following error (which I missed)
> >    ERROR: prepare_krb5_rfc_cfx_buffer: not implemented
> >
> > Which was introduced by the third nfs-utils patch
> > (Add support for non-DES encryption types)
> > I'm currently investigating what that means...
> >
> > So, Trond its up to you if you want to put that
> > list back in preference order, it will not matter
> > to the user space code...
> >
> > steved.
> >
> >
> 
> I still contend that the order we send matters.  This is from MIT
> 1.6.3 KDC code:
> 
> /*
>  * This function returns the keytype which should be selected for the
>  * session key.  It is based on the ordered list which the user
>  * requested, and what the KDC and the application server can support.
>  */
> krb5_enctype
> select_session_keytype(krb5_context context, krb5_db_entry *server,
>                        int nktypes, krb5_enctype *ktype)

OK. I will revert the ordering changes.