Nicolas Williams wrote: > > > IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we > have a [consolidation-private] pam_get_user() function, which IMO should > also be Public. (b) was a good thing, and so was (c), but (c) is > getting upset by modules that can prompt for PINs, or which can derive > PAM_USER from smartcards and/or biometrics.
PLEASE keep in mind that a PIN may be entered via a smartcard reader, and will never be seen via the host. So a prompt for a PIN may not have any input, just instructions. So one has to stop thinking about PAM prompting. See in the PKINIT code and PKCS#11 CKF_PROTECTED_AUTHENTICATION_PATH in pkinit_crypto_openssl.c But even here it looks like it does not write the prompt as instructions, but if it is requesting the PIN via the prompter. (But I need to get a reader with a pin pad to test this out.) > > Solving the multi-layer "negotiation" and other framework-level issues > is out of scope for this case though. I think Will's proposal will work > well enough for now. > >> The really problem is with the PAM framework. It does not give the user any >> choice as to how the user would like to try authenticaiton. It should be >> asking as the first prompt (a list or menu) like to use a smartcard for >> local or PKINIT login, local password Kerberos password, OTP password, >> (or whatever else is available maybe fingerprint of face recognition?) >> Pam would then route to the appropriate modules, rather then starting >> a sequence of optional/required modules that may treat this as a failed >> login attempt,which can lead to locked accounts. >> >> At least pam_authtok_get should have a prompt option to tell the user what >> to do next. > > I agree with your comment about the framework being the problem. The > framework doesn't deal well with the two-layer negotiation problem, and > it doesn't deal at all with asynchrony (e.g., plugin a smartcard and > have the current user/password prompt go away or change into a PIN > prompt). > > I'm waiting for a code review from Gary to complete PSARC/2005/275. One > possible way to solve the multi-layer negotiation issue would be to have > pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from > PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth > sheme being tried. Another way might be to have prompt= parameter to pam_authtok_get, set by the sysadmin. > >>> OpenSolaris >>> pam_krb5 must follow this module currently as it relies on it for the >>> password. This is the reason I'm suggesting that if pam_krb5 is stacked >>> above pam_authtok_get it would assume it should try PKINT only. Given >>> this I don't seen the need for another config parameter like try_pkinit. >> You might be able able to drop the try_pkinit but only if the some other >> method is available to tell the differenrce between a smartcard and some >> other crypto device supported below pkcs#11. > > We've talked about this as well, and I think that too is out of scope > here. But briefly, IMO there should be a way to select tokens for > C_Login() in a way that takes PAM context (e.g., PAM_TTY) into > consideration, so that only tokens that could be associated with a seat > are used. Yes that is an issue on other OSes too. > But we don't need that urgently because for SunRay the seat > is already taken into account via other methods, and for VTs we don't > care very much about this. > > Nico -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
