[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pam_krb5 with PKINIT from Heimdal and MIT
Nicolas Williams wrote:
> 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.
And that is what the pam_krb5-2.4 mods with the Heimdal pkinit does.
The krb5_get_init_creds_opt_set_pkinit calls PKCS11 and queuies for
reader and tokens in the reader, and returns no readers or no smartards.
>
> 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).
Keep you options open here there may be pre-auths in the future that
require both. It could also be which OTP to use: SecureID, Cryptocard...
There moght be a conversion going on....
>
> 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.
I know.
Its a hint to those verdors like *Sun* to do this in *your* pam_krb5.
>
>
>>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.
Hint, again...
>
>
>>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.
Another hint, to you to get Sun to look at your pam stack and
pam_krb5.
>
> Nico
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444