pam_krb5 with PKINIT from Heimdal and MIT

[Nicolas Williams]

On Thu, Oct 12, 2006 at 05:31:41PM -0400, Jeffrey Hutzelman wrote:
> > 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.

Yes, but I don't think it should be the PKINIT pre-auth plug-in that
decides this!  Instead, the framework should be able to decide that if
some pre-auth (say, PKINIT) could get started then nothing else should
be tried after it.  Just as the framework should be able to impose a
local pre-auth preference order.

Also, perhaps the caller should get the option to specify such things.
pam_krb5 should want to use local policy (unless that policy allows the
user to select pre-auths through PAM conversations, as Doug suggests).
Whereas kinit should want to allow the user to override local policy.

> 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

I'm not sure about the second one.  Were you thinking of Sam's pre-auth
combination framework?  Or were you thinking of PA-PK-OCSP-RESPONSE?

One thing is certain: the framework needs to allow one plug-in (PKINIT)
to output multiple PADATAs because of the OCSP thing.

> - Nothing to do for this module; keep going
> - Module failed, abort the request

I think that should be "Module failed."  See above about when failure
should terminate authentication.

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

I would provide a function that a plug-in can call to request that other
pre-auth methods' PADATAs in the request/response be processed
immediately.  I.e., make parts of the framework reentrant.

This would allow for a pre-auth combination pre-auth that specifies
pre-auth order in its PADATA or through is pre-auth combination rules.

Nico
--