[16893] in Kerberos_V5_Development
Re: gnome-keyring Obtaining a TGT without unrestricted access to
daemon@ATHENA.MIT.EDU (David Woodhouse)
Thu Jun 16 11:03:37 2011
From: David Woodhouse <dwmw2@infradead.org>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Date: Thu, 16 Jun 2011 16:02:49 +0100
In-Reply-To: <20110616111215.GB12572@mournblade.imrryr.org>
Message-ID: <1308236570.3450.303.camel@i7.infradead.org>
Mime-Version: 1.0
Cc: Allbery <rra@stanford.edu>, russ@pch.MIT.EDU,
Guido G?nther <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 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 getsinvoked when we try to use a TGT which is expired/expiring. Thenkrb5-auth-dialog could ship with such a plugin, which will *try* sendingthe DBus message to krb5-auth-dialog if it's running.
The code in libkrb5 itself doesn't need to know the details. That's thepoint 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 iskrb5-auth-dialog which is responsible for keeping the credentials cacheup to date, and interacting with the user when new credentials arerequired. It *does* interact with the user for itself with a known,recognisable dialog, rather than through the application which is makingthe 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 thatpassword is already cached elsewhere in the system. And the secondproblem, noted in my digression, is that krb5-auth-dialog doesn'tactually kick in when an application is trying to use Kerberos, but theTGT 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 partsof the system, for other reasons. If we wanted to take the naïveapproach, we could just expose that password on demand tokrb5-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 itshould perform a *limited* set of operations with it (like handling NTLMchallenge/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 existingone no longer works. As long as that's done by a *single*, recognisablepart of the system, of course. We wouldn't want all the apps suddenlystarting to fall back to non-Kerberos authentication methods and eachasking 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 asyou set a wakeup timer to wake the laptop up from its slumber in themiddle of the night, connect to the VPN (without user interaction), andrenew the ticket. Otherwise it'll be dead and unrenewable every morning?
-- dwmw2
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
