Fwd: Man page description of kinit -R

[Brett Randall]

> On 9/3/2014 8:41 PM, Brett Randall wrote:
>> Hi,
>>
>> krb5-1.10.1 here.
>>
>> My local man page for kinit (as well as
>> http://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kinit.html
>> ) has the following description of the kinit -R option:
>>
>> -R: requests renewal of the ticket-granting ticket. Note that an
>> expired ticket cannot be renewed, even if the ticket is still within
>> its renewable life.
>>
>> Does the comment "an expired ticket cannot be renewed" remain true,
>> and if so, can someone help me understand "expired" in this context?
>> If I have a ticket which has an "Expires" date-time (as reported by
>> klist) which is in the past, but a "renew until" date which is in the
>> future, I can successfully renew the ticket using kinit -R.  I see
>> this as renewal of an expired, but renewable and
>> within-renewable-period ticket.
>
> Your understanding is correct.   What KDC is renewing such a ticket?
>

MIT krb5, KDC machine reports:

# krb5-config --version
Kerberos 5 release 1.10.3

To be clear on my test, my realm in kdc.conf contains:

  max_life = 1d
  max_renewable_life = 7d

I create a short-life, renewable ticket, then use klist -s to check
before/after it has expired.  Then kinit -R is able to renew the
ticket.

$ kinit -l 30s -r 30m myprinc
Password for myprinc at MY.COM:
<enter password>
$ klist -s
$ echo $?
0
<wait 30 seconds>
$ klist -s
$ echo $?
1
<expired>
<plain klist shows ticket with expiry date-time in the past>
$ kinit -R
$ klist -s
$ echo $?
0
<plain klist shows ticket with updated expiry date-time>

The behaviour seems reasonable enough to me, but it is contra to that
man page comment.

Also I have read one piece of client code that behaves like this is
standard behaviour - it waits until the TGT expires, then renews it.

>> Is that expected, and is the above comment now a doc-bug?
>
> It is not expected and would be a KDC side bug.
>
>
>