Proposal to export gssapi context

[Martin Rex]

Nicolas Williams wrote:
> 
> 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.

GSS-API is an **abstraction**.
What you're trying to do is extremely implementation specific and
requires profound meta-knowledge above GSS-API in order to be useful.

What you're looking for is a mechanism-specific extension.
(even if someone implements the same extensions for two or three
 mechanisms it is still mechanism-specific).

> 
> 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).

Going with a mechanism-specific extension is the correct way to proceed.

> 
>  - 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 :)


While such a functionality might sound "useful", I actually can not
think of any kind of portable use.  What makes one QOP special and
an application prefer it over another?  Sounds to me like this requires
profound meta-knowledge about the specific mechanism implementation
on the side of the application.  But what about new QOPs with the
next version of the gssapi mechanism? How does an application learn
the meaning of those (without requiring changes to the application)?

The availability of QOPs is a local matter.  It may be configurable
somewhere or a mechanism may provide a mechanism-specific API extension
or both.


> 
>  - 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 :)

As above, this is primarily a mechanism-specific issue since it requires
meta-knowledge to choose a particular QOP over another.

Remember that there are *very* few gssapi mechanisms that actually implement
QOP negotiation.  Usually the initiator selects a specific set of
algorithms and the acceptor either supports it an security context
establishment and protected message exchange succeeds or fails.

When the selection (or in case that a mechanism supports it the
preference list for a QOP negotiation) is configurable in a mechanism
specific fashion independent of the calling application, then any
administrator-supplid configuration will work even for all those
portable gss-api based application that don't have any metaknowledge
and don't play games with funny APIs.


> 
>  - 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.

WAIT A MINUTE!

Don't touch the current scope and definition of gss_export_context().

What you're looking for is extremely mechanism-specific anyway, so
you should be using a mechanism-specific API extension for that.
Don't expect all vendors to implement any such proposal.  I wouldn't
count on Microsoft to do it.



-Martin