Skip Menu |
 

To: krb5-bugs@mit.edu
Date: Thu, 1 Jul 2004 17:38:59 -0400 (EDT)
From: hartmans@mit.edu (Sam Hartman)
Subject: Don't expire contexts when tickets expire


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.
Date: Fri, 02 Jul 2004 10:59:30 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:


Sam Hartman via RT wrote:
Show quoted text
>
> 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.

It may not be consistent, but it is the pratical thing to do.
This should be one of the issues for KITTEN.


I ran into a similiar problem with using Globus with gssklog. The gssklog
uses gss_inquire_context to get the lifetime of the context to determing
the lifetime of the AFS token to issue if no other lifetime is given
this is the only way to test the credentials of the peer. The Globus code
was not testing the credentials correctly. It has since been fixed.



Show quoted text
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Date: Fri, 2 Jul 2004 11:21:12 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: rt-comment@krbdev.mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:
On Fri, Jul 02, 2004 at 10:59:30AM -0500, Douglas E. Engert wrote:
Show quoted text
>
>
> 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.
>
> It may not be consistent, but it is the pratical thing to do.
> This should be one of the issues for KITTEN.

I disagree. You both know that. :/

Nico
--
Date: Fri, 02 Jul 2004 13:51:28 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Cc: rt-comment@krbdev.mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:


Nicolas Williams wrote:
Show quoted text
>
> On Fri, Jul 02, 2004 at 10:59:30AM -0500, Douglas E. Engert wrote:
> >
> >
> > 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.
> >
> > It may not be consistent, but it is the pratical thing to do.
> > This should be one of the issues for KITTEN.
>
> I disagree. You both know that. :/

Well the capability needs to be there, its just that GSS does not
know how to do both. A user could do equivelent functions, by using
GSS to securly exchange a private key, that the client and server could use
indefinitlyoutside of GSS. So what can't GSS be used to do the same thing?





Show quoted text
>
> Nico
> --

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
To: rt@krbdev.mit.edu, krb5-prs@MIT.EDU
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
From: Sam Hartman <hartmans@mit.edu>
Date: Mon, 05 Jul 2004 18:47:57 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Douglas" == Douglas E Engert <deengert@anl.gov> writes:

Show quoted text
Douglas> Sam Hartman via RT wrote:
Show quoted text
>> 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.

Show quoted text
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

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

* Treat the lifetime as advisory and never expire contexts. This
allows for best application design but may be inconsistent with the
spec.
Date: Tue, 6 Jul 2004 03:34:23 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: rt@krbdev.mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.7KiB
On Mon, Jul 05, 2004 at 06:47:57PM -0400, Sam Hartman wrote:
Show quoted text
> >>>>> "Douglas" == Douglas E Engert <deengert@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.

Show quoted text
> * 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.

Show quoted text
> * 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
--
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 06 Jul 2004 13:45:56 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
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.


If you don't come up with a good solution it probably will not be
optional at least in the first cut.
Date: Tue, 6 Jul 2004 23:37:09 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
On Tue, Jul 06, 2004 at 01:46:02PM -0400, Sam Hartman via RT wrote:
Show quoted text
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@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.

You can't have that default. Deployed GSS applications rely on the
current default behaviour (expiring), thus we can't change it.

Show quoted text
> If you don't come up with a good solution it probably will not be
> optional at least in the first cut.

You are proposing the change, not I, thus the onus of working out a
proposal that wouldn't break existing applications is on you.

That said, I won't mind helping to design this extension.

Nico
--
Date: Wed, 07 Jul 2004 07:28:15 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt-comment@krbdev.mit.edu
Cc: hartmans@mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.9KiB


Nicolas Williams via RT wrote:
Show quoted text
>
> On Tue, Jul 06, 2004 at 01:46:02PM -0400, Sam Hartman via RT wrote:
> > >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@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.
>
> You can't have that default. Deployed GSS applications rely on the
> current default behaviour (expiring), thus we can't change it.


Not so. You have made the assumptions that the lifetime of a connection
is somehow tied to the lifetime of the credentials. But this is an
mechanisum specifice decision. So for Kerberos unless it is documented
in some Kerberos GSS standard that says this is so, it is undefined.
(I am on vacation, so will let you check if this is documented.)
So an implementation of a mech could chose to set the lifetime of the
conection it anything it wanted.

Show quoted text
>
> > If you don't come up with a good solution it probably will not be
> > optional at least in the first cut.
>
> You are proposing the change, not I, thus the onus of working out a
> proposal that wouldn't break existing applications is on you.
>
> That said, I won't mind helping to design this extension.
>
> Nico
> --
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 07 Jul 2004 13:35:02 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Show quoted text
>>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Nicolas> On Tue, Jul 06, 2004 at 01:46:02PM -0400, Sam Hartman via
Nicolas> RT wrote:
Show quoted text
>> >>>>> "Nicolas" == Nicolas Williams via RT
>> <rt-comment@krbdev.mit.edu> writes:
>>
Show quoted text
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).
Show quoted text
>> 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.

Show quoted text
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.

--Sam
Date: Mon, 12 Jul 2004 11:51:03 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2620] Don't expire contexts when tickets expire
RT-Send-Cc:
On Wed, Jul 07, 2004 at 01:35:05PM -0400, Sam Hartman via RT wrote:
Show quoted text
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@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@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
--