Obtaining a TGT without unrestricted access to password.

[Simo Sorce]

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, it
already does all you ask for.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York