Obtaining a TGT without unrestricted access to password.

[Guido Günther]

Hi David,
On Thu, Jun 16, 2011 at 10:21:28AM +0100, David Woodhouse wrote:
> On Thu, 2011-06-16 at 08:44 +0200, Guido Günther wrote:
> > I'm not sure if this is what David wants to achieve but if so couldn't
> > we just move the auth part of krb5-auth-dialog into gkr keeping the
> > notification parts and plugins of krb5-auth-dialog separate? We could
> > then use krb5_get_init_creds_password with our own prompter and use
> > the password if available. 
> 
> That is our backup plan, but I share Stef's reticence. We really do want
> gnome-keyring to stick to what it does best, and not start getting
> involved in remote network operations.
> 
> I certainly don't think we'd ever actually do it *in* the gnome-keyring
> process. As well-trusted as libkrb5 may be, we just don't want *any*
> network code running in the gkr process. Instead, we'd give the password
> (or preprocessed password-as-key) out to a separate process. It would
> probably be best to do that by spawning a helper that we *know* will
> just do what it's supposed to be doing, rather than handing it out on
> demand to some existing process that asks for it, and having to invent
> some trust model to give us confidence in that.
> 
> But really, we don't want to be doing that at all. We *really* want to
> use gkr *only* for the crypto operations using the password, invoked
> from the appropriate places in libkrb5.

How does this integrate with PKINIT and FAST? The reason
krb5-auth-dialog relies krb5_get_init_creds_* is that the Kerberos
library handles asking for the right authentication (Password or e.g.
smartcard PIN) at the moment.
Cheers,
 -- Guido