Request to change MIT Kerberos behavior when principal is expired, deleted or password changed

[Benjamin Kaduk]

On Thu, 6 Mar 2014, Nico Williams wrote:

> It'd be trivial to reject requests using tickets predating the last
> password change.

I wonder whether we would want this behavior to be behind a knob of some 
form.  ("Maybe some people rely on the current behavior.")  I was having a 
discussion off-list recently with someone who wanted the ability to give 
out a long-lived, but restricted, TGT, and be able to revoke it with a 
password change.  The "restricted" part would definitely need some form of 
protocol extension, and we were talking about adding a piece of authdata 
to the ticket that indicated what client kvno was used to perform the 
authentication (instead of checking the time of last password change and 
the time of issue).  This could allow for clients to opt-in to 
revocability, while still giving the KDC the option of always inserting 
such authdata.

The authdata proposal would need to be standardized, of course, which is a 
barrier that just checking the time of password change in the KDB does not 
have.

-Ben