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

[David Woodhouse]

On Thu, 2011-06-16 at 12:12 +0100, Roland C. Dowdeswell wrote:
> Just a few random thoughts on the topics...

Thanks!

> It's not really feasible to put these hooks directly into libkrb5,
> because libkrb5 does not have any knowledge of what UI is being
> used. 

That's easy enough to handle; you just provide a plugin API which gets
invoked when we try to use a TGT which is expired/expiring. Then
krb5-auth-dialog could ship with such a plugin, which will *try* sending
the DBus message to krb5-auth-dialog if it's running.

The code in libkrb5 itself doesn't need to know the details. That's the
point of a plugin API, surely?

> These requirements suggest that a daemon (such as KCM in Heimdal)
> should manage the credentials cache and this daemon should be
> responsible for interacting with the user when new credentials are
> required.  This daemon could thus be separately configured to
> interact with the user using a potentially out of band channel from
> that of the application which requires the new credentials.

Absolutely. That is *exactly* what we're trying to achieve. It is
krb5-auth-dialog which is responsible for keeping the credentials cache
up to date, and interacting with the user when new credentials are
required. It *does* interact with the user for itself with a known,
recognisable dialog, rather than through the application which is making
the connection.

There are two problems with krb5-auth-dialog that I would need to solve.
The original one that it keeps asking for the password, when that
password is already cached elsewhere in the system. And the second
problem, noted in my digression, is that krb5-auth-dialog doesn't
actually kick in when an application is trying to use Kerberos, but the
TGT has expired.

> On the topic of storing passwds in memory...  It should be remembered
> when considering storing passwds in memory that this violates one
> of the key design principles behind Kerberos

Nevertheless, the password is *already* stored in memory in other parts
of the system, for other reasons. If we wanted to take the naïve
approach, we could just expose that password on demand to
krb5-auth-dialog, and let krb5-auth-dialog use it. But we don't *want*
to be handing the password out like candy; the keyring which holds it
should perform a *limited* set of operations with it (like handling NTLM
challenge/response requests), rather than just giving it out.

> Also, keep in mind that many shops have a 90 day passwd rotation
> policy which effectively means that a passwd that is entered on
> the keyboard is only valid for an average of 45 days.

It's perfectly acceptable to prompt for a new password if the existing
one no longer works. As long as that's done by a *single*, recognisable
part of the system, of course. We wouldn't want all the apps suddenly
starting to fall back to non-Kerberos authentication methods and each
asking for the password for themselves.

> A well setup system using renewable credentials could keep credentials
> valid for much longer than that.

Am I missing something here? The Windows default is a 10-hour ticket,
renewable for 10 days. So you might manage 10 days at most, as long as
you set a wakeup timer to wake the laptop up from its slumber in the
middle of the night, connect to the VPN (without user interaction), and
renew the ticket. Otherwise it'll be dead and unrenewable every morning?

-- 
dwmw2