pkinit preauth plugin issue

Jeffrey Hutzelman jhutz at
Mon Feb 15 16:15:51 EST 2010

--On Monday, February 15, 2010 02:58:07 PM -0600 Nicolas Williams 
<Nicolas.Williams at> wrote:

> On Mon, Feb 15, 2010 at 03:49:04PM -0500, Jeffrey Hutzelman wrote:
>> A nice theory, but using PAM_AUTHTOK for both passwords and PINs is
>> asking  for trouble.  Unfortunately, the original PAM API design just
>> isn't quite  flexible enough for this case.
> I tend to agree.  I've been thinking that we could patch this up by
> adding a PAM item to indicate what type of "token" the PAM_AUTHTOK value
> is.  Such an item would default to "PAM_AUTHTOK is a password" and would
> get reset every time PAM_AUTHTOK is set.
> Would it be preferable to have separate items for "password" and "PIN"
> (and "OTP", "response to challenge", ...)?
> Also, note that knowing that some string is a PIN is not enough: you
> need to know which token (ugh; here I mean smartcard) the PIN is for.
> Assuming there's only one token [for the current seat] works, but that
> seems like a lousy assumption.

If we were designing a new interface, I think I'd prefer to be able to 
store multiple types of responses and manage them separately, so that one 
could sensibly mix invocations of modules that want to use different types. 
Ideally, the response-type would be extensible, so that rather than having 
to invent a new PAM item (which has to be understood by the framework) each 
time a new response type comes along, we just pick a new response-type 

I suppose this could be done with PAM data, rather than items; modules 
which use the same response type could simply agree on PAM data naming. 
However, that locks the application out of being able to pre-provide a 
response.  I suppose that's not a big deal for PAM_AUTHTOK et al.

But now we're getting a bit far afield of pam_krb5...

More information about the krbdev mailing list