On Fri, Feb 20, 2015 at 03:51:17PM +0100, Jakub Hrozek wrote:
On Wed, Feb 18, 2015 at 12:55:48PM +0100, Sumit Bose wrote:
Thank you, very nice design. I fixed some typos in the page in revisions
11 to 13, I hope I didn't change the meaning anywhere. I also have some
questions, see inline.
> ==== Offline-authentication ====
> Assuming a user with 2FA enabled which log into a desktop session which
> currently does not have a connection to the central authentication
> server. If the two factors are entered into a single prompt the
> resulting string can only be processed by the central authentication
> server and a loss of connection will make authentication and login
> impossible. Even the SSSD offline-authentication feature won't help
> because SSSD will only store a hash of the password used for the last
> successful authentication and compare it with the hash of the current
> password. Since the combined password will change at every login the
> current combined password cannot be validated against any previously
> used password.
> If the two factors are entered separately SSSD can save a hash of the
> first factor can can compare the hashes for the first factor when
> offline to allow at least access to the local machine. It has to be
> noted that the even if krb5_store_password_if_offline is set to true
> SSSD will not try to get a TGT when going online again because in the
> general case the second factor (OTP) might be already invalid.
Is this always the case? IIRC Nathaniel mentioned that you might be able
to request a TGT that will include a flag that indicates the TGT was
obtained with a single factor only..and then the service would decide if
a single factor is enough.
But perhaps that was a future development of Kerberos?
yes, if this is available we might want to add support for this. But it
might be a bit irritating to the user that e.g. after going online he is
able to access some services but with limited rights?
> Both use-cases mentioned above might only be working if the first factor
> (long-term password) is sufficiently long. A 4-digit PIN used by some
> OTP systems is not secure enough to be uses as a password for a keyring
> or to allow local access.
> ==== Handling the two authentication factors ====
> Both the wire protocol between pam_ssd and the pam responder and SSSD
> internally with the sss_auth_token struct handle the credentials as a
> blob with a length and a type. Currently the blob contains either the
> password or is NULL in case of no password (there is a special usage
> where it contains a Kerberos credential cache identification).
> Adding the two authentication factor to those structure can be achieve
> without modifying them by using a new type for 2FA and creating a blob
> which starts with two 32bit unsigned integer value containing the size
> of the first and second authentication factor respectively followed by
> the first factor and finally the second factor.
> uint32_t | uint32_t | uint8_t | uint8_t
What do these numbers mean? Do they say that with the
first factor, all 6 chars are the payload and with the
second factor only the first 5 chars are useful?
ah sorry, this is a typo the '5' should be a '6' as well. This example
should just illustrate that since we already have length fields the
strings in the wire format may contain a trailing \0 or not. It's up to
the decoding routines to make proper strings out of it.
> 0x06 | 0x06 | abcdef | 12345\0
> As shown the first and second factor may or may not include a trailing
> \0 in the blob. But calls which decompose the blob into its component
> must assure that that there is a trailing \0 if strings are expected.
> With this scheme only packaging and un-packaging the two factors has to
> be added to existing or new calls but all other internal handling like
> sending the data from the responder to the backends can be left
> Backends which should handle 2FA must be made aware of the new
> authentication token type.
> ==== The pre-authentication request ====
> The pre-authentication request will follow the same path as the
> authentication request with an empty password and with type
> SSS_PAM_PREAUTH instead of SSS_PAM_AUTHENTICATE. It is up to the backend
> if and how this request will be handled. Currently only the IPA auth
> provider will support the pre-auth request in the sense that it can send
> different results base on the expected authentication type (1FA, 2FA)
> back to the client. Since the IPA provider will basically use the
> generic krb5 auth provider the krb5 auth provider will support the
> pre-auth request as well.
> The IPA provider will send a back a PAM response of the type
> SSS_PAM_OTP_INFO in case of 2FA with optional token_id, vendor name and
> challenge so that pam_sss can give additional hints to the user and a
> unsigned 32bit integer value indication the type of the optional data.
> This indicator will make it more easy to add more data in future or just
> indicate that the user uses 2FA but the backend is offline.
> If 2FA is not enable for the user or errors occur just a PAM_SUCCESS
> will be returned. In this case pam_sss will just ask for a single
> If the backend is offline the PAM responder will tell the client that
> only the first factor is needed for local authentication with the help
> of a special SSS_PAM_OTP_INFO message. To achieve this the type of the
> hashed authentication token in the cache must be saved.
Here the types would be denoting either a 1FA password or a 2FA first
yes, basically it would be the authtok_type.
> Additionally the
> length of the second factor should be saved in the cache to allow
> splitting a combined password which might be entered by the user
> accidentally or via services where special prompting might not be
> available like e.g. ssh.
I'm curious about the splitting. Can you learn what the factors are if
the service doesn't offer the smart prompting? (For instance, if OTP
users only ever logged in with SSH)
no, in this case we always do 1FA from the SSSD point of view as we do
Also, shall we only support splitting where the OTP is in the form of
"$first_factor$second_factor" or do some OTP devices use the other way
I'm not aware of any, but if there are any I hope we might be able to
detect them e.g. with the help of the vendor field and act accordingly.
But this would be an enhancement for an upcoming release like
Finally, does pam_sss (or sssd) know if the prompting is actually available
or does sssd always attempt its prompting and it's up to the service
what it displays?
pam_sss only has the pam_conversation callback, we cannot tell what the
service does with it.
> If the second factor varies in size this scheme
> will fail but saving the length of the first factor will make an offline
> attack against the hashed password much easier.
Do we care about offline attach given that we have
I meant 'offline attack' in the sense that you have physical access to
the hard disk and can read the hash.
> Since the pre-auth request is an additional round-trip from pam_sss to
> the KDC and back it might delay the logon process a bit. To avoid this
> in environments where only 1FA is used and option the pam_sss,
> ''disable_preauth'', can disable the pre_auth request completely.
> Additionally I would suggest a more dynamic solution where is pre-auth
> request is only send if a special file, e.g.
> /var/lib/sssd/pubconf/do_pam_preauth, exits. The IPA provider can create
> this file at startup if 2FA is supported.
Yes, I think the SSSD default should be 'no preauth', because otherwise
all plain krb5 or plain LDAP auths might be slowed down and I suspect
using OTPs will not be the default for some time.
I like the file idea, can we for instance query the server for some indicator
that OTPs are used during the subdomains request and then create the file?
> ==== Special use of the first factor (long term password) ====
> ===== Cached password hash for offline-authentication =====
> If authentication was successful, the ''cache_credentials'' option
> set to ''true'' and the first factor has at least
> ''[#minimal_password_length minimal_password_length]'' SSSD will
> hashed version of the first factor to the user's cache entry as it is
> done for the 1FA password.
> ===== PAM =====
> If authentication is successful and the ''forward_pass'' option is
> for pam_sss the first factor will be saved in the PAM_AUTHTOK item so
> that other modules in the PAM stack can use it. '''QUESTION: shall
> we(authconfig) add forward_pass by default? Currently is it not.'''
I think it would be quite useful, especially for the gnome keyring case,
but we need to do this change anyway when we start supporting the local
> === Configuration changes ===
> ==== pam_sss ====
> New options:
> - ''disable_preauth'' will unconditionally disable the
> pre-authentication request
> - ''use_2fa'' will always ask for two authentication factor, might
> only useful for testing
Sounds useful for testing, but I would recommend to not document an
internal-only option. (Speaking from experience of seeing sbus_timeout
and similar options in sssd.conf files coming from users..)
> ==== sssd.conf ====
> New option:
> - [=#minimal_password_length] ''minimal_password_length'' will let
> pam responder only safe a hash of the password if it has a minimal
> length. Additionally it might indicate to pam_sss to remove passwords
> from the PAM environment which are shorter. '''Question: We can limit
> this option to the first factor of a 2FA authentication. Although it
> might be useful for 1FA passwords as well it might introduce a
> regression to existing installations.'''
I don't see how it could be useful for 1FA, I would prefer to not change
the 1FA case.
> ==== Changing the first factor ====
> It is already possible to change the long-term password (first factor),
> the current scheme will not be changed here.
During password change, will only the "old password" prompt accept both
factors or also the "new password" prompts? I'm mostly wondering about
the ssh case where we don't always control the prompt.
no, for password changes ssh will use pam_conversation (at least when
UsePAM is set). Only for PasswordAuthentication the user does not see
sssd-devel mailing list