pam_krb5 with PKINIT from Heimdal and MIT

[Nicolas Williams]

On Fri, Oct 13, 2006 at 05:36:56PM -0400, Jeffrey Hutzelman wrote:
> On Friday, October 13, 2006 03:46:36 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> >These, IMO, are part of the PA-ENC-TIMESTAMP pre-auth method.
> 
> They are not.  They provide information about parameters to the 
> string-to-key operation, which transcends any particular preauth method. 
> They may be necessary for any use of passwords as long-term keys.

I am not so sure.

> >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.
> 
> Well, no, but I expect in most cases that failure of a module will cause 
> the operation to be aborted; that is, you want to treat the module as 
> "required" rather than "sufficient" (really, there's a lot of similarity to 
> PAM here, as long as one doesn't take it too far).

I meant "give up" as in "not try another AS exchange" not as in
"continue processing PADATA for this exchange."

> >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.
> 
> That's true; I can see there are ways to extend the preauth plugin 
> framework in the future to allow more complicated scenarios without making 
> assumptions about the protocol or breaking backward compatibility with 
> older plugins.  As long as that property is satisfied, there's probably not 
> a problem.

And for that I think all we need is to make sure that plug-ins don't
have side effects, that their inputs and outputs are well defined, and
that the framework keeps whatever inter-pre-auth state must be kept
(which today should be "none").

> Given that it will probably be a release or two before this interface 
> becomes public [NB: I do not work or speak for MIT], there's probably some 
> time to work out the kinks.

I imagine so.

Nico
--