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

["Roland C. Dowdeswell" <elric imrryr org>]

On Thu, Jun 16, 2011 at 11:11:25AM +0100, David Woodhouse wrote:
>

> 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!
> 
> We fixed this in Evolution a while back; checking for the
> KRB5KRB_AP_ERR_TKT_EXPIRED or KRB5KDC_ERR_NEVER_VALID errors and poking
> krb5-auth-dialog manually:
> http://git.gnome.org/browse/evolution-data-server/commit/?id=6c6dfcc9
> 
> But that only solves the problem for Evolution, and not for any other
> clients. It would be nice if perhaps we could hook into libkrb5 itself,
> so we can do that 'poke' in *one* place, rather than having to modify
> all the clients. Is that feasible?

Just a few random thoughts on the topics...

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.  libkrb5 can't just assume that X11 is in use and if the user
is using a TTY then it's not possible to simply write characters
to stdout or /dev/tty and hope that this does not destroy the screen
layout of curses using applications.  Even if you assume X11, you
do not really want to force all applications that link against
libkrb5 to have to link against the X11 libraries as well.  You
would also need to make decisions about what toolkits you need to
use, this in many environments would lead to versioning difficulties,
etc.  So, at the very least, you would have to setup a new Kerberos
API which would pass in various prompter functions as so on...

It is not good practice to expose your passwd to random applications
and it is not a good idea to train the user to enter their passwd
into random differently constructed dialog boxes as this also trains
the user to be susceptible to phishing attacks.  And so, passwd
entry boxes, IMO, should be presented by a tightly controlled set
of applications and have a completely uniform UI.  Granted, this
would be a ``perfect world'' solution.  Given the technology at
hand, compromises may need to be made.

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.

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---and one of the main
reasons that TGTs were invented in the first place.  Although, it
is certainly more convenient to store the user's passwd in memory
in many cases, it violates many assumptions that are made by various
Kerberos tools, i.e. kpasswd which has the assumption that knowledge
of the passwd indicates that the user is actually part of the
interaction.

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.  A well setup
system using renewable credentials could keep credentials valid
for much longer than that.

When using small disconnected devices such as phones and the like,
one should note that it is quite difficult to con users into entering
anything that resembles a passwd with enough complexity on the
rather limited input interfaces that these devices typically have.
It is likely better to assert that the device belongs to an individual
user and allow the device to authenticate itself to the network
via either a keytab or pkinit and trust that the screen unlock
mechanism is protection enough (after reviewing its lockout policies,
etc.).  In this case, you'd likely want to assign the devices a
separate Kerberos principal and manage your authorisation data
appropriately such that the device does not have full access but
rather only access to a subset of the presented services.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/