pam_krb5 with PKINIT from Heimdal and MIT

[Jeffrey Hutzelman]

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.
>
> 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