pam_krb5 with PKINIT from Heimdal and MIT

[Nicolas Williams]

On Fri, Oct 13, 2006 at 09:52:02AM -0500, Douglas E. Engert wrote:
> Nicolas Williams wrote:
> >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.

The host can detect that there's a smartcard plugged in somewhere.  If
the smartcard requires a PIN number and the user does not type it in
correctly pam_krb5 can fail immediately.  If the user forget their PIN
and wants to try again w/o PKINIT then they can remove the smartcard and
try again.

The host cannot tell whether the user has an OTP or a password.

The KDC really should not indicate that password and OTP pre-auth are
both OK -- presumably the admins will have added OTP pre-auth because
they believe it is more secure (but see the threads on OTP pre-auth in
KRB-WG).

So, in practice, I believe it should be possible for pam_krb5 to impose
a local pre-auth preference that works for all users with no more than
two interactive pre-auth methods being attempted.  Heck, it should be
possible for us to define a globally default pre-auth precedence that
works for all users, given the pre-auths that we have or have seen
proposed.  E.g.,

1) PKINIT
2) SRP
3) strong OTP/challenge-response
4) strengthened PA-ENC-TIMESTAMP [*]
5) PA-ENC-TIMESTAMP
6) weak OTP/challenge-response

[*]  DCE RFC26, combination with PKINIT w/ anon client, channel bindings
     to TLS with server certs only, etc...

> 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?

Yes.

In a worst case scenario, where the KDC offers multiple pre-auth methods
that all require interaction and none of which can be inferred to be
preferred by the user without additional interaction, then pam_krb5
could: a) prompt the user for their preference, then proceed, or b) run
through each pre-auth in local preference order sequence.

Now, look at my proposal for a global pre-auth precedence.  In the
absolute worst case the user will be prompted for 1-3 passwords and two
OTPs.  But in practice the worst case would be prompting for one
password and one OTP, during migrations.

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

The "password" or "authentication token" (PAM terminology, you know)
will have to be prompted for separately for password-based and OTP
pre-auths.

> 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?

PAM supports that.

> 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?  PAM modules can prompt for a principal name if they like.

> 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.)

Yup.  But you could get rid of pam_authtok_get if you like.

Nico
--