[16887] in Kerberos_V5_Development
Re: Obtaining a TGT without unrestricted access to password.
daemon@ATHENA.MIT.EDU (Simo Sorce)
Thu Jun 16 08:16:14 2011
From: Simo Sorce <simo@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <1308186302.3450.200.camel@i7.infradead.org>
Date: Thu, 16 Jun 2011 08:15:51 -0400
Message-ID: <1308226551.3182.88.camel@willson.li.ssimo.org>
Mime-Version: 1.0
Cc: Guido =?ISO-8859-1?Q?G=FCnther?= <agx@sigxcpu.org>, stefw@collabora.co.uk,
krbdev@mit.edu, gnome-keyring-list@gnome.org
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, 2011-06-16 at 02:04 +0100, David Woodhouse wrote:> I'm trying to implement automatic renewal of Kerberos tickets during the> lifetime of a user's session.> > The user's password is learned at login time and stored within the> gnome-keyring dæmon.> > We also have krb5-auth-dialog running in the background, which will> prompt the user for a password when the TGT needs to be renewed.> > You'd think it would be simple to make the latter use the password> that's been stored by the former... I wish it were so.> > The problem is that we don't want the keyring process to actually give> *out* the password. It's happy to perform operations for us *using* the> password, but not just to *give* it to us.> > I have three ideas, and I'm not sure how viable any of them are. I'd> very much appreciate some pointers...> > > My first approach was to look at using plugins. For example, we'd have a> preauth plugin to handle KRB5_PADATA_ENC_TIMESTAMP which would farm it> off to gnome-keyring to perform the actual operation. But that seems to> have failed at the first hurdle because in krb5_do_preauth() we> unconditionally try the built-in handlers *first*, before trying the> modules. And if those match the patype and fail, the module doesn't even> get a look in.> > > My second thought was that perhaps the keyring could be asked for the> result of str2key on the password. That's not the actual *password*, at> least. But I suspect that even that is still too sensitive to be handing> it out?> > > The third thought is that I could call krb5int_get_init_creds() with a> get_as_key function that returns a "special" key, where the actual> methods on it are just PKCS#11 calls to the keyring to do the job.> It's complicated by the fact that the method pointers aren't in the> krb5_keyblock but are actually looked up at invocation time with> find_enctype(). But there may be a way to make this work, perhaps?> > > Any better ideas, or suggestions for which option to pursue?
If you are on a Linux distribution I suggest you look into sssd, italready does all you ask for.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
