Re: gnome-keyring Obtaining a TGT without unrestricted access to password.

[Greg Hudson <ghudson MIT EDU>]

In general, I think the path of least resistance will be one of the
ideas suggested by others: (1) invoke krb5_get_init_creds from a
subprocess which knows the password, (2) use sssd, or (3) follow site
policy and use renewable credentials.

But, to answer some specific questions:

On Wed, 2011-06-15 at 21:04 -0400, David Woodhouse wrote:
> 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.

The preauth plugin interface is intended to allow out-of-tree code to
implement a new preauth system with a new protocol spec, not to alter
the information gathering of existing preauth systems.  I don't think
this is the right layer.  (Also, the preauth plugin interface isn't
public yet and will likely undergo significant changes when it becomes
public in 1.10.)

> 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?

To answer some follow-up questions about this: string-to-key operations
are intended to be non-reversible.  I wouldn't be as confident about the
irreversibility of string-to-key for DES and DES3 enctypes as I would
for other enctypes.  string-to-key for modern enctypes (AES) is also
intended to be slow enough to present a mild impediment to dictionary
attacks.  String-to-key is a function of the password and a salt which
is usually a combination of the principal name and realm, although the
KDC can override that.

So at least in the ideal, if you hand out the string-to-key'd password,
that's a free pass to use it for Kerberos for that principal as long as
the password is valid, but not necessarily a free pass to use it for any
other Kerberos principal or other protocol using the same password.  Of
course it's a great piece of information to have for an offline
dictionary attack.

> 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?

What you describe is conceptually similar to the case where someone
wants to invoke krb5int_get_init_creds_keytab() with the key stored in a
PKCS11 token which will perform crypto operations but won't give up the
key.  This is not currently a supported scenario for MIT krb5, except
perhaps in the Solaris Kerberos fork.  We recently introduced the opaque
type krb5_key as a first step to supporting that kind of thing, but
there is still significant work to do before it would become a
possibility, on both sides of the crypto interface.

> It's the same for authentication. The user shouldn't have to
> *manually* check whether their TGT is still valid and get a new one
> before running the mailer. If the mail program discovers that the TGT
> has expired, it should just go poke krb5-auth-dialog to get you a new
> one!

There is support for something like this on Windows and OSX for GSSAPI
apps.  I don't think we're conceptually opposed to having something
similar on Unix platforms, using some kind of IPC to delegate the actual
prompting to another process.