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

[Edgecombe, Jason]

I don't see how anyone can object to rejecting requests for expired or deleted principals. I understand that the password changing aspect could be more controversial.

Could we at least add the "reject requests for expired/removed principals" part?

---------------------------------------------------------------------------
Jason Edgecombe | Linux and Solaris Administrator
UNC Charlotte | The William States Lee College of Engineering
9201 University City Blvd. | Charlotte, NC 28223-0001
Phone: 704-687-1943
jwedgeco at uncc.edu | http://engr.uncc.edu |  Facebook
---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person responsible for delivering it to the intended recipient, any disclosure, copying, distribution, or other use of any of the information in this transmission is strictly prohibited. If you have received this transmission in error, please notify me immediately by reply e-mail or by telephone at 704-687-1943.  Thank you.


-----Original Message-----
From: Benjamin Kaduk [mailto:kaduk at MIT.EDU] 
Sent: Friday, March 07, 2014 3:04 PM
To: Nico Williams
Cc: Edgecombe, Jason; kerberos at mit.edu
Subject: Re: Request to change MIT Kerberos behavior when principal is expired, deleted or password changed

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