Proposal to export gssapi context

[Nicolas Williams]

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.

Anyways, I again point out the pain of the lame GSS-API treatment of
QoP, but I digress.

Cheers,

Nico
--