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:22 -0400, Trond Myklebust wrote: 
> 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.

Done and pushed out