[krbdev.mit.edu #2620] Don't expire contexts when tickets expire

[Nicolas Williams via RT]

On Mon, Jul 05, 2004 at 06:47:57PM -0400, Sam Hartman wrote:
> >>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
> 
>     Douglas> Sam Hartman via RT wrote:
>     >>  we have agreed to a customer requirement that context
>     >> expiration not happen when ticket expiration happens.
>     >> 
>     >> The tricky part here is to figure out what gss_inquire_context
>     >> should return.  I'd really rather make the lifetime advisory
>     >> but I'm not sure that is consistent with the spec.
> 
>     Douglas> It may not be consistent, but it is the pratical thing to
>     Douglas> do.  This should be one of the issues for KITTEN.
> 
> It's an issue for kitten already.
> 
> Clearly something in this space needs to be done.  Options are:
> 
> * Have krb5 credentials claim they have indefinite lifetime at the
>    gssapi layer; clearly consistent with the spec

This might cause an application not to re-acquire credentials when it
should, leaving it with de-facto-but-not-de-jure expired credentials.  I
don't think this is too serious, but it isn't good.

I need to think about this more.  One question is how to make this
behaviour optional; the credentials acquisition functions have an input
parameter, time_req, for specifying the application's required lifetime
for the credentials.  Perhaps the value "(OM_uint32) -1" would do for
requesting, and indicating, infinite lifetimes.

Of course, this works for initiators, but what about acceptors?

GSS_Accept_sec_context() has no time_req parameter, so use of
GSS_C_NO_CREDENTIAL, at minimum, is out.  But worse is the fact that
without retrofitting existing mechanisms (i.e., the Kerberos V mech)
there is no way to negotiate the use of infinite lifetime contexts.

For the Kerberos V mechanism we could add a new req_flags flag, but
those are non-critical for the mech, which has no way to indicate
acquiescence/rejection.  Oof.

> * Have krb5 credentials claim their correct lifetime and have gss
>   contexts claim indefinite lifetime; also probably consistent with
>   the spec.

Contexts that don't have any expiration, advisory or otherwise, are
problematic for stateless GSS applications, such as NFSv2/3 w/
RPCSEC_GSS -- when are contexts to be deleted?

This strongly implies that context non-expiration MUST be optional --
see above.

> * Treat the lifetime as advisory and never expire contexts.  This
>   allows for best application design but may be inconsistent with the
>   spec.

I strongly object to the third option you list.  That would cause
applications which rely on mandatory context expiration for re-keying
and the like to not behave as intended.

Above all do no harm.

Summary:  Find a way to make context non-expiration optional.  I don't
	  think you will find a way to do so safely with the Kerberos V
	  mechanism as it stands (rfc1964 and CFX).

Nico
--