preserve original starttime on renewed TGTs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

preserve original starttime on renewed TGTs

Frank Cusack-5
When running 'kinit -R', the KDC resets the starttime on the returned
TGT to "now".  I'd like to modify my KDC to preserve the original
starttime instead.  That could make a renewed TGT appear to have longer
than the normal maximum configured lifetime, but it seems like a fairly
trivial non-problem.  As opposed to a postdated ticket, this would be
now be a predated ticket.

This change would violate RFC 4120 par 3.3.3:

  If the new ticket is to be a renewal, then the endtime above is
  replaced by ... the starttime for the new ticket plus the life
  (endtime-starttime) of the old ticket.

That is, the endtime would no longer be the starttime of the new
ticket plus the life of the old ticket.

But I don't see how it'd be a problem in practice.  Note that the new
ticket would still have the correct lifetime.

Further renewals (ie, of the renewed ticket) would again violate this
section in that the KDC would not know the original ticket's lifetime
(it's no longer preserved in the renewed TGT presented to the KDC), so
it'd have to choose the lifetime based on the configured maximum
ticket lifetime.  For most uses, where people/applications don't request
renewable tickets with shorter than maximum lifetimes, I submit that
this is not a problem.

Anyone think I am wrong and this violation of RFC 4120 3.3.3 would be a
problem? Or any other issues with this plan?

If I made it a configurable KDC option, would MIT be likely to accept
the patch?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

Simo Sorce
On Fri, 19 Nov 2010 13:21:34 -0800
Frank Cusack <[hidden email]> wrote:

> When running 'kinit -R', the KDC resets the starttime on the returned
> TGT to "now".  I'd like to modify my KDC to preserve the original
> starttime instead.  That could make a renewed TGT appear to have
> longer than the normal maximum configured lifetime, but it seems like
> a fairly trivial non-problem.  As opposed to a postdated ticket, this
> would be now be a predated ticket.

Hi Frank,
I am curious to understand why you want to do that.
What class of use cases does it solve?

Simo.

--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

Nicolas Williams-2
On Fri, Nov 19, 2010 at 04:43:42PM -0500, Simo Sorce wrote:

> On Fri, 19 Nov 2010 13:21:34 -0800
> Frank Cusack <[hidden email]> wrote:
>
> > When running 'kinit -R', the KDC resets the starttime on the returned
> > TGT to "now".  I'd like to modify my KDC to preserve the original
> > starttime instead.  That could make a renewed TGT appear to have
> > longer than the normal maximum configured lifetime, but it seems like
> > a fairly trivial non-problem.  As opposed to a postdated ticket, this
> > would be now be a predated ticket.
>
> Hi Frank,
> I am curious to understand why you want to do that.
> What class of use cases does it solve?

My guess: it helps deal with servers whose clocks are a little bit
behind (but still within skew).

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

Nicolas Williams-2
In reply to this post by Frank Cusack-5
On Fri, Nov 19, 2010 at 01:21:34PM -0800, Frank Cusack wrote:

> This change would violate RFC 4120 par 3.3.3:
>
>   If the new ticket is to be a renewal, then the endtime above is
>   replaced by ... the starttime for the new ticket plus the life
>   (endtime-starttime) of the old ticket.
>
> That is, the endtime would no longer be the starttime of the new
> ticket plus the life of the old ticket.
>
> But I don't see how it'd be a problem in practice.  Note that the new
> ticket would still have the correct lifetime.

Clients could be checking that the KDC is doing what the RFC says, so, I
don't think that'd be OK.  However, the KDC could lie in the
EncKDCRepPart and put the original starttime in the actual Ticket.  I
might not mind that, but:

> Further renewals (ie, of the renewed ticket) would again violate this
> section in that the KDC would not know the original ticket's lifetime
> (it's no longer preserved in the renewed TGT presented to the KDC), so
> it'd have to choose the lifetime based on the configured maximum
> ticket lifetime.  For most uses, where people/applications don't request
> renewable tickets with shorter than maximum lifetimes, I submit that
> this is not a problem.

This could be a problem.  I'm not sure yet.  I suppose the KDC can
always include a KDC-ISSUED authorization-data element documenting the
original ticket lifetime.

But...  what's the motivation?  Slow clocks on servers?

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

Jeffrey Altman-2
In reply to this post by Nicolas Williams-2
On 11/19/2010 5:01 PM, Nicolas Williams wrote:

> On Fri, Nov 19, 2010 at 04:43:42PM -0500, Simo Sorce wrote:
>> On Fri, 19 Nov 2010 13:21:34 -0800
>> Frank Cusack <[hidden email]> wrote:
>>
>>> When running 'kinit -R', the KDC resets the starttime on the returned
>>> TGT to "now".  I'd like to modify my KDC to preserve the original
>>> starttime instead.  That could make a renewed TGT appear to have
>>> longer than the normal maximum configured lifetime, but it seems like
>>> a fairly trivial non-problem.  As opposed to a postdated ticket, this
>>> would be now be a predated ticket.
>>
>> Hi Frank,
>> I am curious to understand why you want to do that.
>> What class of use cases does it solve?
>
> My guess: it helps deal with servers whose clocks are a little bit
> behind (but still within skew).
I'm going to put my money on KCA issued short-lived certificates.  The
certs are frequently issued with a period of validity from starttime to
max renew lifetime.

Jeffrey Altman


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (498 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

Frank Cusack-5
In reply to this post by Simo Sorce
On 11/19/10 4:43 PM -0500 Simo Sorce wrote:

> On Fri, 19 Nov 2010 13:21:34 -0800
> Frank Cusack <[hidden email]> wrote:
>
>> When running 'kinit -R', the KDC resets the starttime on the returned
>> TGT to "now".  I'd like to modify my KDC to preserve the original
>> starttime instead.  That could make a renewed TGT appear to have
>> longer than the normal maximum configured lifetime, but it seems like
>> a fairly trivial non-problem.  As opposed to a postdated ticket, this
>> would be now be a predated ticket.
>
> Hi Frank,
> I am curious to understand why you want to do that.
> What class of use cases does it solve?

I would like an application to be able to determine the last time the
user actually authenticated and make a decision based on that.  With
renewable TGTs you can't determine how long ago the user actually
interactively authenticated.

It'd be a burden (both for the user, and administratively) to require
special purpose user/foo principals (which could have a short lifetime
and no renewability) for said applications.

I can go into more detail if that isn't sufficient, but I think it is
enough to understand the problem?  Nice guesses by others, though.

Wait a second.  I see this already exists, it's the authtime field.
And RFC 4120 describes exactly this usage.  I guess I missed it since
klist doesn't show it.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: preserve original starttime on renewed TGTs

hartmans
>>>>> "Frank" == Frank Cusack <[hidden email]> writes:

    Frank> On 11/19/10 4:43 PM -0500 Simo Sorce wrote:
    >> On Fri, 19 Nov 2010 13:21:34 -0800
    >> Frank Cusack <[hidden email]> wrote:
    >>
    >>> When running 'kinit -R', the KDC resets the starttime on the
    >>> returned TGT to "now".  I'd like to modify my KDC to preserve
    >>> the original starttime instead.  That could make a renewed TGT
    >>> appear to have longer than the normal maximum configured
    >>> lifetime, but it seems like a fairly trivial non-problem.  As
    >>> opposed to a postdated ticket, this would be now be a predated
    >>> ticket.
    >>
    >> Hi Frank, I am curious to understand why you want to do that.
    >> What class of use cases does it solve?

    Frank> I would like an application to be able to determine the last
    Frank> time the user actually authenticated and make a decision
    Frank> based on that.  With renewable TGTs you can't determine how
    Frank> long ago the user actually interactively authenticated.

Doesn't the authtime field already serve this purpose?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev