renewable in krb5.conf

Greg Hudson ghudson at
Thu Mar 15 15:50:43 CET 2018

On 03/15/2018 08:02 AM, Harald Barth wrote:>> You also need to specify
>>    renewable = true
> I think this only makes a difference for the MIT library. My tests
> suggest that. Correct?

>From a look at the Heimdal and MIT krb5 code, it doesn't appear to me
that either library does anything with a "renewable" krb5.conf variable.
 Both libraries appear to set the renewable KDC option when renew_till
is non-zero.

> "I want renewable
> and just give me the default from the KDC" like with the --renewable
> command line flag.

This option doesn't appear to really request the KDC maximum; it sets a
renewable lifetime of six months (kuser/kinit.c:556).

Jeff Altman wrote:
> As far as I am concerned the client should always request the maximum
> supported "lifetime" and "renew_lifetime" in order to permit the KDC
> settings to take precedence.
> Unfortunately, KDC implementation choices mean that there is no well
> defined value for maximum lifetime and renew_lifetime.  180 days appears
> to be safe enough.

[Mostly out of curiosity:]

>From a protocol perspective, "till" isn't optional in the ASN.1
encoding, but sending 19700101000000Z (the encoding of POSIX timestamp
0) requests the KDC maximum.  "rtime" is optional, but RFC 4120 states
that it will be set when the renewable option is requested, and there is
no defined value for requesting the KDC maximum.

MIT krb5's KDC appears to respect an rtime of 19700101000000Z as being
the KDC maximum (going back to 1.0).  Heimdal's KDC appears to behave
similarly (although if the rtime field is omitted from the KDC-REQ-BODY
encoding, Heimdal will ignore the renewable option).  I don't have any
visibility into the Windows KDC and [MS-KILE] doesn't say anything
specific, so perhaps there lies the KDC implementation choice Jeff
refers to.

>From a client perspective, both libraries appear to make it difficult to
set a request till or rtime of 19700101000000Z, so changes would be
needed to make it possible to configure clients to behave as Jeff
suggests.  Of course you can just request a very long lifetime and
renewable lifetime.

More information about the Heimdal-discuss mailing list