[16889] in Kerberos_V5_Development
Re: Obtaining a TGT without unrestricted access to password.
daemon@ATHENA.MIT.EDU (Russ Allbery)
Thu Jun 16 09:56:24 2011
From: Russ Allbery <rra@stanford.edu>
To: Stef Walter <stefw@collabora.co.uk>
In-Reply-To: <4DF9B6CF.6040104@collabora.co.uk> (Stef Walter's message of
"Thu, 16 Jun 2011 08:54:55 +0100")
Date: Thu, 16 Jun 2011 06:56:14 -0700
Message-ID: <871uyt283l.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: =?utf-8?Q?G=C3=BCnther?= <agx@sigxcpu.org>,
David Woodhouse <dwmw2@infradead.org>, gnome-keyring-list@gnome.org,
krbdev@mit.edu, guido@pch.MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Stef Walter <stefw@collabora.co.uk> writes:
> On 06/16/2011 02:28 AM, Russ Allbery wrote:
>> Why don't you just obtain renewable tickets and renew them instead of
>> storing the password in memory?
> That sounds interesting. Do you have pointers to how this works? I'm not
> that familiar with Kerberos, so please bear with me :)
The result of a Kerberos authentication is a Kerberos
ticket-granting-ticket, which has a lifetime and a renewable lifetime. As
long as you do so within the lifetime window, you can perform another
authentication to the KDC using the ticket-granting-ticket, without the
password, and ask for a renewed ticket, which will hand you back a new
ticket with a longer lifetime, but with a renewable lifetime that still
expires at the same time as the first one.
In other words, renewing the ticket-granting-ticket can be done without
knowledge of the password and is just like reusing the password, except:
1. The total length of time that a person can renew their credentials
without demonstrating knowledge of the key is under the control of the
local site KDC administrator, where you probably want it to be.
2. The local site KDC administrator can intervene if necessary and cause
the KDC to refuse to renew tickets for that user (if, for example,
there's some reason to believe the renewable ticket was compromised).
So it's generally superior to storing the user's password in memory in
every respect except when the user intentionally wants to not follow site
policy as expressed in the renewable ticket lifetime. (Unfortunately,
that last case is common, in part because a lot of sites don't realize
they *have* set a policy.)
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
