Proposal to export gssapi context

[Kevin Coffman]

> On Tue, Mar 09, 2004 at 09:00:10PM -0500, Ben Cox wrote:
> > On Mar 9, 2004, at 7:22 PM, Sam Hartman wrote:
> > >>>>>>"Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> > >
> > >    Nicolas> I've several comments:
> > >
> > >    Nicolas>  - With the Kerberos V mechanism you can control what
> > >    Nicolas> enctypes are to be used by controlling what enctypes the
> > >    Nicolas> nfs/* service principals have.
> > >
> > >This only works on the server side.
> > >
> > >I need to control it on the client as well.
> > >
> > >There are multiple implementations out there;)
> > 
> > I want to amplify Sam's comment here: if you have some clients that can 
> > do 3DES for RPCSEC_GSS you want to allow your nfs/* service principals 
> > to have 3DES keys.  If you can't limit it on the client side as Kevin 
> > proposed, then other clients whose user-mode libraries have 3DES 
> > support but whose kernel NFS client code doesn't support it, you're in 
> > a spot of difficulty.
> 
> Yes, I got this.
> 
> Of course, on such clients one can limit the set of enctypes one will
> accept for ticket session keys.  Basically, one must have consistent
> enctype support throughout accross all applications that share a given
> Kerberos V credential.  This applies to initiators, and it applies to
> acceptors.  It's a simple rule.

We have an additional constraint of which enctypes are supported by
the kernel.