pkinit preauth plugin issue

Nicolas Williams Nicolas.Williams at sun.com
Tue Feb 16 12:29:09 EST 2010


On Tue, Feb 16, 2010 at 11:46:15AM -0500, Jeffrey Hutzelman wrote:
> However, Doug and Nico bring up an interesting point.  There are other 
> kinds of inputs besides traditional passwords and PINs, such as OTPs and 
> responses for challenge-response mechanisms.  Some of these don't require 
> as much careful separation as we'd like to see for PINs, but some will, and 
> in any case, the user and sometimes the calling application need to know 
> what is being asked for.  Perhaps the right solution here, at least in the 
> long term, is a general API rather than a PKINIT-specific one.

I think there are two krb5 API specific changes to make: a) provide a
way to pass passwords, PINs, OTPs, and challenge responses to individual
and maybe even all pre-auth methods (PA-ENC-TIMESTAMP can use a PIN too,
if a long-term symmetric key is stored on a token) and distinguish among
them, b) provide additional information in prompts about the type of
entry being prompted for.

(a) is useful when the application has one or more such items a priori
(e.g., in the case of SSHv2 "password" userauth there's a password).

(b) is useful when the application does not have all such items that may
be required by pre-auth methods but needs to allow for re-use of such
items (PAM is probably the only such application).

I suspect that the gic prompt types facility was added for the benefit
of applications that don't directly interact with users, but rather
which bridge MIT krb5's prompter interface to other prompters (again,
PAM is probably the main example).  So there is precedent for (b).

Nico
-- 



More information about the krbdev mailing list