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 [email protected] | 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:[email protected]] Sent: Friday, March 07, 2014 3:04 PM To: Nico Williams Cc: Edgecombe, Jason; [email protected] 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
