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