[16880] in Kerberos_V5_Development
Obtaining a TGT without unrestricted access to password.
daemon@ATHENA.MIT.EDU (David Woodhouse)
Wed Jun 15 21:05:14 2011
From: David Woodhouse <dwmw2@infradead.org>
To: krbdev@mit.edu
Date: Thu, 16 Jun 2011 02:04:59 +0100
Message-ID: <1308186302.3450.200.camel@i7.infradead.org>
Mime-Version: 1.0
Cc: Guido =?ISO-8859-1?Q?G=FCnther?= <agx@sigxcpu.org>, stefw@collabora.co.uk,
gnome-keyring-list@gnome.org
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
I'm trying to implement automatic renewal of Kerberos tickets during thelifetime of a user's session.
The user's password is learned at login time and stored within thegnome-keyring dæmon.
We also have krb5-auth-dialog running in the background, which willprompt 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 passwordthat'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* thepassword, but not just to *give* it to us.
I have three ideas, and I'm not sure how viable any of them are. I'dvery much appreciate some pointers...
My first approach was to look at using plugins. For example, we'd have apreauth plugin to handle KRB5_PADATA_ENC_TIMESTAMP which would farm itoff to gnome-keyring to perform the actual operation. But that seems tohave failed at the first hurdle because in krb5_do_preauth() weunconditionally try the built-in handlers *first*, before trying themodules. And if those match the patype and fail, the module doesn't evenget a look in.
My second thought was that perhaps the keyring could be asked for theresult of str2key on the password. That's not the actual *password*, atleast. But I suspect that even that is still too sensitive to be handingit out?
The third thought is that I could call krb5int_get_init_creds() with aget_as_key function that returns a "special" key, where the actualmethods 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 thekrb5_keyblock but are actually looked up at invocation time withfind_enctype(). But there may be a way to make this work, perhaps?
Any better ideas, or suggestions for which option to pursue?
-- dwmw2
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
