pam_krb5 with PKINIT from Heimdal and MIT

[Jeffrey Hutzelman]

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


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.

-- Jeff