pam_krb5 with PKINIT from Heimdal and MIT

[Jeffrey Hutzelman]

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


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

-- Jeff