a suggestion for improving pkinit preauth plugin token choosing
will.fiveash at oracle.com
Wed May 12 13:38:02 EDT 2010
On Wed, May 12, 2010 at 10:13:10AM -0700, Henry B. Hotz wrote:
> On May 12, 2010, at 8:50 AM, Nicolas Williams wrote:
> > On Wed, May 12, 2010 at 08:56:39AM -0400, Sam Hartman wrote:
> >> I actually agree with henry that "please insert a token," should be out
> >> of scope for preauth plugins.
> >> My rationale is that the current prompter interface is kind of weak when
> >> it interacts with GUIs etc, and the more we can avoid using it, the
> >> better.
> > That rationale applies even more so to PAM than to the gic prompter. At
> > least the gic prompter tells you what kind of thing it's prompting for,
> > whereas PAM has no such concept. Yet we can't apply the same rationale
> > to PAM and say "sorry, no please insert a token prompt, you have to
> > figure out all by yourself that the reason you can't login is that you
> > haven't plugged your smartcard in".
> Why is everyone so afraid to let an attempt "fail"? Maybe it's not
> your first choice, but why is it so bad?
> If it "fails" then you can return a meaningful error message that
> tells the user how to do it over so it works. You can say "I couldn't
> find any smart cards.", or "I found the following credentials and I
> don't know which one to use. Please remove the extras and try
> again.", or "Please call extension HELP.", or even "Please call
> security to have yourself arrested because you are a dangerous
> terrorist." ;-)
Remember that in a PAM auth stack the pam_krb5 module does not display
error messages. It can log them but that doesn't help the user. So if
the call to krb5_get_init_creds_password() returns an error, pam_krb5
logs the cause and returns a PAM error to the auth stack. And depending
on the auth stack config, the user may be presented with a password
prompt when they really should be doing PKINIT. Something needs to tell
the user to insert their smart card.
> You can tell the user absolutely anything you want that might be
> helpful, and you don't have any pre-existing constraints from a design
> that didn't anticipate your specific situation.
Note my new work e-mail address: will.fiveash at oracle.com
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/
More information about the krbdev