bug?: erroneous start time for max renewable life check

[Richard Johnson]

I've found a misbehavior and what looks like a bug in clients behavior under
MIT Kerberos 1.4 (IBM import to AIX), 1.7 (in CentOS), and 1.8.1 (MIT release
built AIX).  The problem is not exposed on clients using Heimdal Kerberos
1.2.1 or 1.3.2.

I encountered this while setting up principals for long-running jobs that need
to intermittently write their output to storage servers as they work.  Our
KDCs are OpenBSD 4.5, 4.6 and 4.7 with Heimdal Kerberos.  Our clients are a
mix of systems using MIT Kerberos and Heimdal Kerberos.

The misbehavior:

When a TGT with the Renewable flag set is used to obtain an ftp or host ticket
on an MIT Kerberos client, that ftp or host service ticket also has the
Renewable flag set.  I call this misbehavior as it seems nonsensical.  If an
ftp or host service ticket is expired, a new one will be obtained; there's no
need to make them renewable.

The likely bug:

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.

This can result in the max renewable lifetime of the ftp, host, or other
service ticket already having expired at the time the ticket is requested.

In practice, long-running jobs are unable to obtain the host or ftp ticket
after a week, meaning they can't store results during the majority of their
run.  The error encountered is "Requested effective lifetime is negative or
too short on krb5_mk_req call".

Why one week?  While the job's principal and resulting TGT typically has a
maximum lifetime of 3+ days, and a maximum renewable lifetime of multiple
months, the host and ftp principals have the standard maximum lifetime of 1
day and maximum renewable lifetime of 1 week.

A workaround:

I don't have one yet.  The quick answer would be to find a way to stop MIT
Kerberos clients from requesting renewable ftp, host, and other service
tickets when the TGT has the Renewable flag set.  That way, we'll neatly dodge
problems caused by service tickets that arrive with their max renewable
lifetime erroneously exceeded, or that erroneously run out of renwable
lifetime after being obtained.

I have so far been unable to find config options or lifetime setting hacks
that will turn off or break inheritance of the Renewable flag. Suggestions
greatly appreciated.

A fix:

I don't have one yet.  Not inheriting the TGT auth time when ftp, host or
other service tickets are created, but instead using the creation time of the
service ticket, would do the job as long as the eventually expired service
tickets are replaced normally.  Alternatively, not treating the erroneous time
calculation as a fatal problem, but instead as an expired service ticket which
should be replaced with a non-renewable one, would solve the problem. 
Suggestions about which would make more sense greatly appreciated.


Richard

-- 
/\            Richard Johnson
  \           security administrator, UCAR
   \_][       rjohnson at ucar.edu, +1 303 497-1844
       \________________________________________