pam_krb5 with PKINIT from Heimdal and MIT
jhutz at cmu.edu
Fri Oct 13 17:36:56 EDT 2006
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.
>> >> - 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.
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).
> 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
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.
More information about the krbdev