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 \_][ [email protected], +1 303 497-1844 \________________________________________ ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
