Re: gnome-keyring Obtaining a TGT without unrestricted access to password.
- From: David Woodhouse <dwmw2 infradead org>
- To: Nico Williams <nico cryptonector com>
- Cc: "Roland C. Dowdeswell" <elric imrryr org>, Guido G?nther <agx sigxcpu org>, Russ Allbery <rra stanford edu>, krbdev mit edu, gnome-keyring-list gnome org, stefw collabora co uk
- Subject: Re: gnome-keyring Obtaining a TGT without unrestricted access to password.
- Date: Thu, 16 Jun 2011 17:21:45 +0100
On Thu, 2011-06-16 at 11:07 -0500, Nico Williams wrote:
> > How does one square away the storing of a passwd in memory against
> > this existing prevalent use case? Other than simply transitioning
> > to OTP in order to defeat it?
>
> You either ignore this problem or you use OTP or PKINIT with
> non-extractable private keys stored in smartcards.
Or perhaps you don't consider it a problem at all, since it is the
predominant mode of operation of Windows clients.
I appreciate the KDC-admin viewpoint being presented, and I'm certainly
not suggesting that you should accept this kind of caching behaviour on
your well-run networks.
But most people running a Kerberos server probably don't even know
they're doing it.
What I'm trying to achieve here is *optional* client behaviour which is
acceptable on a "typical" Windows network, both from the security (for
the admin) and the usability (for the user) point of view.
What I need to do, since I cannot *force* the admin to change policies
for the benefit of the Linux clients, is fit in with the Windows model.
Which as far as I can tell is to remember your password (or maybe just
the str2key result) when you log in, and then use it to automatically
obtain a TGT for you when you need it. And then ask you to provide a new
password if it finds that your password on the network has changed.
I understand that there are issues with that model, but it is a
commonly-accepted model that I think we need to be able to support
*somehow*.
--
dwmw2
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]