pam_krb5 with PKINIT from Heimdal and MIT
jhutz at cmu.edu
Fri Oct 13 16:24:18 EDT 2006
On Friday, October 13, 2006 03:10:11 PM -0500 Nicolas Williams
<Nicolas.Williams at sun.com> wrote:
> 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!
Neither do I, necessarily. The question of whether to use the PKINIT
plugin and whether its success is required is something that needs to be
answered by a combination of configuration and the caller, possibly on a
case-by-case basis. For example, kinit might have a switch indicating that
PKINIT should be used (or, more generally, that a certain PA mechanism
should or should not be used), with the default controlled by something in
> Also, perhaps the caller should get the option to specify such things.
Right. The correct behavior is not to try using PKINIT all the time just
because the plugin is installed.
>> - 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?
This situtation could result from some kind of combination, or from a
plugin that provides or processes PA-DATA but isn't a "preauthentication
mechanism". A good example of this on the receive side is the handlers for
PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, and PA-ETYPE-INFO2.
> One thing is certain: the framework needs to allow one plug-in (PKINIT)
> to output multiple PADATAs because of the OCSP thing.
Yes; there's no question of that.
>> - 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.
Well, I meant the "nothing to do" case to be the equivalent of a PAM module
returning PAM_IGNORE - it's the module telling you it's not relevant to the
situation at hand.
> 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.
Hm. That's an interesting approach, though it only works if the type that
knows about the dependency is processed first.
More information about the krbdev