[35829] in Kerberos
Re: Request to change MIT Kerberos behavior when principal is expired,
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Fri Mar 7 15:04:34 2014
Date: Fri, 7 Mar 2014 15:04:21 -0500 (EST)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOgGq9FEMmNBp_s_wfekKg6KByHeUEFFKgSZwcnsH6u94Q@mail.gmail.com>
Message-ID: <alpine.GSO.1.10.1403071459370.1213@multics.mit.edu>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
