[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On expiration times and API.

From: Mats Erik Andersson
Subject: On expiration times and API.
Date: Sat, 20 Apr 2013 00:04:25 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Dear all,

let me make a proposal for extending the API,
based on three facts:

  * The utility 'kinit' of Solaris', using a variant
    of MIT Kerberos, is per default producing a
    TGT-REQ with fields

      req-body.endtime = 2037-12-31 00:00:00
      req-body.rtime = 2037-12-31 00:00:00

    unless overriden by '-l lifetime' and
    '-r renewable_life'.

  * In 'src/kdc.c', function asreq1(), the client
    request is supposed to be adapted to local
    policy regarding TGT expiry and renewal limit.
    This is outlined in the comments, but is not
    implemented in practice.

  * 'src/kdc.c' has no access to "lib/internal.h",
    whence 'shishid' has no possibility to read
    neither 'handle.ticketlife' nor 'handle.renewlife'.

To implement the indicated expiry policy I imagine
four new API calls:

  time_t shishi_endctime_realm (Shishi *handle, char *realm)
  time_t shishi_renewctime_realm (Shishi *handle, char *realm)
  time_t shishi_endctime_hint (Shishi *handle, Shishi_tkts_hint *hint)
  time_t shishi_renewctime_hint (Shishi *handle, Shishi_tkts_hint *hint)

Better functions? Previously implemented alternatives?

The configuration items


would state the default, server specific timing, while the new items


could cover realm specific limits. A further detail requires
scrutiny: Which upper limit is suitable for absolute upper
limit for expiry time? I am inclined to use

  'now' + 4 * 'default ticket life interval'

where the factor four is open for discussion.

Best regards,
  Mats E A

reply via email to

[Prev in Thread] Current Thread [Next in Thread]