Re: pam_krb5 with PKINIT from Heimdal and MIT

["Douglas E. Engert" <deengert@anl.gov>]

Nicolas Williams wrote:
> On Thu, Oct 12, 2006 at 04:12:42PM -0400, Nalin Dahyabhai wrote:
> 
>>The libkrb5 side of things goes through the list of preauth types
>>suggested by the KDC, and the first preauth type for which it's able to
>>obtain data is deemed good enough to fire off a request to the KDC.
> 
> 
> In what order are the pre-auths attempted?
> 
> If we agree that PADATA should be considered to be unordered then a
> client-side pre-auth preference/precedence order seems necessary.


Good question. It also needs input from the user. For example they
may have a smart card, a OTP token and a password, all usable with
the same principal, (and may even need to use two of these for the
same authentication.)

So any preference or order may be imposed by the user or workstation.
The user may have forgotten his smartcard today, or the kiosk
will only use OTP or the ssh keyboard-interactive will not
allow the use of a smartcard over the network.

Since we have people from Sun, RedHat and Debian all on this e-mail
thread, can we look at PAM in general and with Kerberos from the user's
prospective?

The way PAM works today i.e. get a username and password
then call all the pam routines one at a time with the same password
will not work well with a pre-auth preference if they have to
guess at how the "password" is to be used. If the user guesses
wrong too many times, some auth service might disable their account,
or their smart card.

What would it take to have PAM prompt for the username, principal and
the user's preferred auth method all with the same pam_conv call?
This could then be used with krb5_get_init_creds_opt_set_...
(One of the choices could also be to not use Kerberos, so
the pam_krb5 would return IGNORE to let other PAM routines handle
the auth.

Then when the preauths need additional input, they use the
krb5_prompter to get the password, OTP, or pin. They can each
have their own prompt, telling the user what is requested,
including a OTP challenge if needed, or in the case where there
is a smartcard reader with a pin pad to enter the pin on the pad.

An additinal problem today  is the username is really the local
unix username, and there is no way to use a different Kerberos
principal.

So the sequence might be:

Application calls pam_start which may or may not have a username.
and may or may not have prompted for a "password" (Solaris 10
has an  pam_authtok_get.so that actually gets in the way of what I
am proposing.)

  pam_krb5 puts up a menu (or one at a time) with:

    "Principal or "no" for local login"  with grayed out
            default derived from username
      If the user types no, then don't use Kerberos.

     a new krb routine could be called to get the preauths
     available for this user or required for the user and passed
     back to PAM.

     If there is a choice to be made, then ask user (or see if
     smartcard is inserted. (

    "Would you like to use: Smartcard, OTP, password"
     User responds with 1, 2, 3 or some other way to select.

     krb5_get_init_creds_opt_set_... is called to specify the user
     preference. (Or  maybe this choice could be called from inside
     the libkrb5 after krb5_get_init_creds_password was called.)

     krb5_get_init_creds_password is called, with a prompter.
     the prompter gives the user specific instructions as
     what is needed, password, pin or OTP.


In any case, it time to look at pam and preauth together
from the user's prospective.



> 
> Nico

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444