pam_krb5 with PKINIT from Heimdal and MIT
nalin at redhat.com
Thu Oct 12 19:57:54 EDT 2006
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.
> >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.
More information about the krbdev