pam_krb5 with PKINIT from Heimdal and MIT

[Nalin Dahyabhai]

On Thu, Oct 12, 2006 at 05:31:41PM -0400, Jeffrey Hutzelman wrote:
> On Thursday, October 12, 2006 04:12:42 PM -0400 Nalin Dahyabhai 
> <nalin at redhat.com> wrote:
> 
> >> o The thinking is if the user puts in a smart card, try and use it.
> >>   If no card is present use passwords as before. If they put in a card
> >>   and it fails, don't fall back to password, make them take the card
> >>   out first.
> >
> >The libkrb5 side of things goes through the list of preauth types
> >suggested by the KDC, and the first preauth type for which it's able to
> >obtain data is deemed good enough to fire off a request to the KDC.
[snip]
> >The end-result is what you describe above.
> 
> Not really.  If there is a smartcard present, and the user types the wrong 
> PIN, then the authentication should fail immediately, without sending any 
> message to the KDC and without prompting for a password.

I think we read "it fails" differently there, but I get your meaning.

We still use krb5_get_init_creds_password() for both the pkinit and
non-pkinit case, and the application can't directly control which
preauth type libkrb5 will attempt to use, so I'm not sure how I feel
about failing immediately on a bad PIN.

> More generally, a preauth module needs to be able to return any of several 
> results such as
> 
> - OK, stop processing preauth and send the request to the KDC
> - OK, include this data but keep processing preauth
> - Nothing to do for this module; keep going
> - Module failed, abort the request
> 
> ... and possibly others.

The library distinguishes between preauth systems which produce data for
the KDC (PA_REAL) and those which process data from the KDC for use by
PA_REAL systems (PA_INFO).  PA_REAL is the first case you listed, and
PA_INFO covers the second and third.  Right now there's no facility for
that last one.

HTH,

Nalin