pam_krb5 with PKINIT from Heimdal and MIT

[Nicolas Williams]

On Fri, Oct 13, 2006 at 04:24:18PM -0400, Jeffrey Hutzelman wrote:
> On Friday, October 13, 2006 03:10:11 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> >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.

Definitely.  If no smartcard reader can be found, or no smartcard is
plugged in then PKINIT's result should be different from failure and
success (akin to PAM_IGNORE, as you suggest).

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

Right now we don't have any.

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

These, IMO, are part of the PA-ENC-TIMESTAMP pre-auth method.

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

I've not looked.  Does the patch that was submitted handle this?

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

Understood.  My point though is that the pre-auth method shouldn't
decide when krb5_get_init_creds() gives up, which is what I took your
suggestion to be.

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

That's OK -- we can cross this bridge when we come to it.  One way would
be to forbid combination and instead require "stacking" -- as long as
the framework is designed so pre-auth plug-ins have no side-effects then
this should work.  Or, add a preliminary step so that pre-auth combining
pre-auth methods can decide to go first and drive the processing of the
remainder of the PADATA by framework reentrance.

Nico
--