pam_krb5 with PKINIT from Heimdal and MIT
Nicolas.Williams at sun.com
Fri Oct 13 16:10:11 EDT 2006
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.
More information about the krbdev