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

[Nicolas Williams via RT]

On Wed, Jul 07, 2004 at 01:35:05PM -0400, Sam Hartman via RT wrote:
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment at krbdev.mit.edu> writes:
> 
>     Nicolas> On Tue, Jul 06, 2004 at 01:46:02PM -0400, Sam Hartman via
>     Nicolas> RT wrote:
>     >> >>>>> "Nicolas" == Nicolas Williams via RT
>     >> <rt-comment at krbdev.mit.edu> writes:
>     >> 
>     Nicolas> Summary: Find a way to make context non-expiration
>     Nicolas> optional.  I don't think you will find a way to do so
>     Nicolas> safely with the Kerberos V mechanism as it stands
>     Nicolas> (rfc1964 and CFX).
>     >>  On the principle of those who care about a feature should
>     >> figure out how to make it work, I'm interested in hearing
>     >> suggestions from you on how to make this feature be optional.
>     >> I believe I require that the default behavior be non-expiring
>     >> contexts because I believe that creates a more usable
>     >> experience.
> 
>     Nicolas> You can't have that default.  Deployed GSS applications
>     Nicolas> rely on the current default behaviour (expiring), thus we
>     Nicolas> can't change it.
> 
> 
> What will it break?  Also, even if it does break some things, I think
> you need to show that it breaks more than it unbreaks.

Well, to begin with, MIT krb5's AUTH_GSSAPI (and, presumably, the
upcoming RPCSEC_GSS code in MIT krb5) makes reference to
GSS_S_CONTEXT_EXPIRED.

So does Solaris' RPCSEC_GSS code.

More: neither the MIT AUTH_GSSAPI code nor the Solaris RPCSEC_GSS
actually do any application-level context expiration so far as I can
see.  It may take modifying the mechanism as you propose to test this
thesis, but I'm quite sure of it.

I suspect that if you make this change from mandatory-by-default to
advisory-by-default context expiration kadmin session lifetime will no
longer be bounded by ticket lifetimes.  Some will no doubt consider this
to be a problem.

Sure, you can probably fix kadmin/kadmind to perform context expiration
at the application level, but then this would prove that the proposed
change is a backwards-incompatible change in an interface that others
might have expected to be very stable against such changes.

I recommend that advisory context expiration be made an option, that you
pursue this at your convenience, but, also, that you specify the option
as an extension or clarification to the GSS-API at the IETF KITTEN WG.

Making context expiration optionally be advisory is easy for initiators
since GSS_Init_sec_context() has an input parameter which provides for
doing so and since RFCs 2743 and 2744 explicitly specify ways to request
a default lifetime, indefinite lifetime and exact lifetimes (in
seconds).

For acceptors this is harder since GSS_Accept_sec_context() does not
have an input parameter for requesting a specific context lifetime.  For
me the reasonable solution here would be either, or both of: a) use the
acceptor credential lifetime_req/rec to specify the lifetime of contexts
accepted thereby and/or b) specify an extension to the GSS-API for
setting context lifetime.

Cheers,

Nico
--