bug?: erroneous start time for max renewable life check

[Greg Hudson]

On Mon, 2010-05-17 at 19:37 -0400, Richard Johnson wrote:
> I've found a misbehavior and what looks like a bug in clients behavior under
[...]

Hi, sorry it's taken several weeks to look into this.  I believe you
have one fundamental misunderstanding about your situation, and it comes
here:

> When the ftp or host ticket is renewable, under all MIT releases I've tried,
> the maximum renewable lifetime is erroneously calculated from the inherited
> auth time of the TGT, not from the creation time of the the ftp or host
> ticket.

All of this logic is performed within the Heimdal KDC, not within the
MIT client code.  The error you are seeing (which corresponds to the
KDC_ERR_NEVER_VALID protocol code) also originates from the Heimdal KDC,
not the client library.  MIT code never generates this error.

When MIT client code requests a service ticket using a renewable TGT, it
typically requests a renewable service ticket with an rtime field of 0.
The zero rtime value is nonsensical from an RFC 4120 perspective, but
that is not relevant to your problem, as both MIT and Heimdal KDCs
interpret an rtime of 0 as "infinity" or "the maximum possible renewable
end time."

I think the most practical fix for your problem is to make the Heimdal
KDC more forgiving--it should not squash the validity end time of the
ticket simply because it calculated a lower maximum renewable end time.
If I were a Heimdal developer, I'd propose removing this line from
krb5tgs.c:

        et.endtime = min(et.endtime, *et.renew_till);

I'm certainly happy to change the MIT krb5 client code to not request
renewable service tickets, and I'll bring that up on the krbdev list.
But it's much easier to change your KDC than to change your OS-native
client code on every client.