[16902] in Kerberos_V5_Development
Re: gnome-keyring Obtaining a TGT without unrestricted access to
daemon@ATHENA.MIT.EDU (David Woodhouse)
Thu Jun 16 12:22:18 2011
From: David Woodhouse <dwmw2@infradead.org>
To: Nico Williams <nico@cryptonector.com>
Date: Thu, 16 Jun 2011 17:21:45 +0100
In-Reply-To: <BANLkTinNN_=jx3dOYG=9rVCXaNB5O=gFGA@mail.gmail.com>
Message-ID: <1308241307.3450.319.camel@i7.infradead.org>
Mime-Version: 1.0
Cc: Russ Allbery <rra@stanford.edu>, Guido G?nther <agx@sigxcpu.org>,
stefw@collabora.co.uk, krbdev@mit.edu, gnome-keyring-list@gnome.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
