[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Simon Josefsson
Subject: Re: PAM vs GSSAPI?
Date: Thu, 22 Mar 2007 08:55:27 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux)

Russ Allbery <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>> Ah, right.  I recalled some GSS-API extensions for initial acquisition,
>> but I guess they were never implemented widely.  It might have been a
>> better approach, though.  But maybe there are other things that pam_krb5
>> do which isn't possible to do via GSS-API?
> Basically, what pam_krb5 has to do is:
>  * Acquire initial credentials.  This is normally done using a password
>    but may instead be done using a smartcard and PKINIT.  This requires
>    dealing with a Kerberos prompting function and passing the prompts back
>    to the user, since the Kerberos library may be doing other things at
>    the same time (like forcing the user to change an expired password).
>  * Verify that the initial credentials are valid by obtaining a service
>    ticket for a local key and then checking that service ticket against
>    the local key.  This prevents KDC spoofing.
>  * Store the initial credentials into a ticket cache and chown that ticket
>    cache to the user.  (Due to the way that OpenSSH works, it also has to
>    be able to store them in a temporary file and read them back out
>    later.)
>  * Verify that the user is permitted to log on to this account by calling
>    krb5_kuserok, which checks the Kerberos principal against the local
>    account name, a .k5login if any, and against any principal to local
>    account name mappings as configured in krb5.conf.
>  * Obtain password changing credentials (different than the TGT since
>    password changing credentials are marked DISALLOW_TGT_BASED).
>  * Change the user's password.
> As near as I can tell, GSS-API doesn't provide facilities to do any of
> those operations.

Thanks for the summary!  Sounds like pam_gssapi is not a feasible idea


reply via email to

[Prev in Thread] Current Thread [Next in Thread]