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
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?
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?
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
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)
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
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?
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
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 is
set to ''true'' and the first factor has at least
''[#minimal_password_length minimal_password_length]'' SSSD will saved a
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 given
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 ====
- ''disable_preauth'' will unconditionally disable the
- ''use_2fa'' will always ask for two authentication factor, might be
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 ====
- [=#minimal_password_length] ''minimal_password_length'' will let the
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.