Re: The usability of service ticket lifetimes

On 8/21/2012 2:49 PM, Jeffrey Hutzelman wrote:
> On Tue, 2012-08-21 at 13:21 -0400, Jeffrey Altman wrote:

> Furthermore, this violates the expectations of _users_ who, when they
> are aware of expiration at all, expect it to happen a fixed amount of
> time after they log in or otherwise obtain tickets, rather than based on
> when they first talked to a particular service on a particular day.

Most ticket managers such as Network Identity Manager, the Microsoft
Windows LSA, and any site that is making use of k5start (or similar
tools) works very hard to ensure that _users_ are completely unaware of
expiration.  The goal is to make the acquisition and use of Kerberos
tickets invisible to the user.  The only time a user should be aware of
the inability to renew is when

 (a) the renew_till lifetime has expired (if the platform enforces that)

 (b) if a policy change prevents the further renewal of the TGT
     (or user account in the case of Windows)

The Kerberos community has years of experience with enforcement of
expiration times on application protocols such as those protected by
GSS-API and the conclusion has been that expiration enforcement on
connections is a bad idea because of the usability problems that are caused.

In my opinion a more secure solution is one that permits the ticket
lifetime to be shorter and the renewable lifetime to be longer providing
the realm administrator a shorter period of time between when policy or
account adjustments are made and when they take effect.

Jeffrey Altman

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQM/IqAAoJENxm1CNJffh4neUH/iDBptjp8OtfrWQhgvUAiYCO
sznz/GPVPfge/aL1wycoT7zOTpuISWT7SXXv5GynoMu4c3arNsSdREff+MTYDmGI
HieNALlipb/ynis1vSW1appJJjoje1K+w6VUmCLmsy1nmpFQES/qXYHnnwk3T60e
9KFDGrdwF2TFYqOQbJ0DgIXL8FI+pU9mQsB8ewmG97fj6qebHiPTJkgGH00WxYFr
JAC7SBKh77yJVNIHkj3s7GUBxNTPo+6KLU9jBHfF0OhhJTxSpR4mCy3l9aS5T3iW
6HVUf6akA8735xeQ1IRwLfhKCZWJRFL69tcaqwQYZ884DS5yCy94M+34HKVo07w=
=oCLv
-----END PGP SIGNATURE-----