Re: pam_krb5 with PKINIT from Heimdal and MIT

[Jeffrey Hutzelman <jhutz@cmu.edu>]

On Thursday, October 12, 2006 04:12:42 PM -0400 Nalin Dahyabhai 
<nalin@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.

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.

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.

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.

In addition, while today there is no requirement that preauth data be 
generated or processed in a particular order, it is plausible that new 
preauth types will be introduced in the future which have dependencies that 
require them to be processed in a particular order.  If this happens, then 
for a pluggable preauth mechanism to be useful, there will have to be some 
defined way of controlling the order in which padata is processed.  It may 
be beneficial to define such a mechanism sooner rather than later.

-- Jeff