Proposal to export gssapi context

[Nicolas Williams]

On Tue, Mar 09, 2004 at 06:00:42PM -0500, Kevin Coffman wrote:
> Brought to krbdev...
> 
> The kernel implementation of rpcsec_gss used for NFSv4 requires context
> information be negotiated in user-land and then passed down for use in the
> kernel.  gss_export_context() exports the context as an opaque object which
> cannot be used for this purpose.  We are proposing three new APIs.  One is
> to restrict the encryption types negotiated in user-land to the set that the
> kernel can use.  The other two are to export context information into a
> usable structure, and then free that structure.
> 
> Comments, suggestions, welcome.

I've several comments:

 - With the Kerberos V mechanism you can control what enctypes are to be
   used by controlling what enctypes the nfs/* service principals have.

   Ergo you don't need krb5_gss_set_allowable_enctypes().

   Just limit your nfs principals' enctypes.

 - Your krb5_gss_set_allowable_enctypes() proposal is
   mechanism-specific, and not necessary to boot (see previous point).

 - The GSS-API should have had a way to specify what QoPs are desired at
   context init time.  It doesn't.  Help us fix this at the 60th IETF :)

 - The GSS-API should have had a decent way to find out what QoPs are
   supported by a given context.  It doesn't.  Help us fix this at the
   60th IETF :)

 - It would be nice to have a standard specification of the Kerberos V
   mechanism's exported context token format.  We don't.  Now that we've
   had the last revision we hope to ever have to the Kerberos mechanism
   we can go ahead and think about this.

   To begin with I'd want to specify it as an IETF document, and then
   I'd want to use ASN.1 as the notation.

Cheers,

Nico
--