[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pam_krb5 with PKINIT from Heimdal and MIT

On Fri, Oct 06, 2006 at 11:44:15AM -0500, Douglas E. Engert wrote:
So while waiting for the pam_krb5-2.4 source to show up on
http://www.eyrie.org, I am attaching the Heimdal pkinit mods for
pam-krb5-2.3 as a point of discussion. I would hope the MIT
and CITI people would comment on their pkinit API.

The pkinit support is hooked in through a preauthentication abstraction
interface.  The only thing libkrb5 is aware of on its side is that
there's a module which can supply data for, and process data provided
by, a KDC for preauthentication type 16 (or 17, or 15).

The same interface could be used to implement other preauthentication
types (that's the intention anyway), but at the moment I think attention
is focused on making sure that it's sufficient to interface with pkinit

 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.

If a pkinit module is called first, and it supplies data, then the
client uses that, skipping the password prompt.  If the KDC rejects the
pkinit request, the client will give up unless the KDC's error response
includes e-data which might be used to try adjust the request.

If the KDC's error included e-data, the modules get a crack at it, and
if one of them provides different data, the library will re-send the
request with the new padata.

The end-result is what you describe above.