From 1ef8b1e5f47ce2b8acc646941248757de5dce109 Mon Sep 17 00:00:00 2001 From: RichardKalinec Date: Thu, 5 Dec 2019 16:41:28 +0100 Subject: [PATCH] doc/designs: Add a design page for application-specific passwords This design page describes a new enhancement: application-specific passwords and permissions management for them. Users will be able to have additional passwords besides the primary one, and set permissions for them specifying what systems and services will each application-specific password have access to. Application-specific passwords will also be usable with other authentication mechanisms incorporating passwords, namely otp, radius and hardened. They will also be supported by ipa-kdb for Kerberos authentication. https://pagure.io/freeipa/issue/4510 --- doc/designs/application-specific-passwords.md | 243 ++++++++++++++++++ 1 file changed, 243 insertions(+) create mode 100644 doc/designs/application-specific-passwords.md diff --git a/doc/designs/application-specific-passwords.md b/doc/designs/application-specific-passwords.md new file mode 100644 index 0000000000..da474f57ad --- /dev/null +++ b/doc/designs/application-specific-passwords.md @@ -0,0 +1,243 @@ +# Application-specific passwords + +**DESIGN STAGE** + +## Overview + +FreeIPA does not currently allow users to have more than one password. +Using a single password for the user's account carries potential risk and +inconvenience with it. If the password is compromised on only one of the devices +the user uses, the attacker gains full administrative access to the user's +account and all services associated with it. The user can then halt it only by +changing this single account's password and reconfiguring all systems and +applications using that password for authentication (even if only to one +particular service) to use the new one. + +This enhancement therefore brings support multiple passwords for a single user +and extends access control mechanisms to distinguish between various user's +passwords. Only allowing multiple passwords for a single user itself would, +if application-specific passwords are each used only on one device, increase +convenience in the case that the user can no longer trust a password used on +one of his devices. Namely, he can revoke or change only that password, without +needing to revoke or change his other passwords, including the primary password. +Access control extension would add significant security benefit to this - the +intruder's access to the user's account might be more or less limited +according to what permissions is the compromised password assigned. + +Resolves: https://pagure.io/freeipa/issue/4510 +How Google does it: https://support.google.com/accounts/answer/185833?hl=en + +## Use cases + +### Use with password-only authentication + +The user can set multiple passwords per account. Each password can be then used +for authenticating on only one device. Various passwords can as well be used to +authenticate to various services or their sets. These divisions can even be +combined, thus - in the most extreme case - having one password for +authenticating to one specific service on one particular device. Granularity of +such divisions will be fully up to user's discretion. + +### Use as a part of 2FA (OTP) + +The user could enter an application-specific password instead of the primary +one, and then an OTP, allowing application-specific passwords to be used as +a part of 2FA. Although 2FA reduces the risk of account hijacking, the benefits +of application-specific passwords still improve security in this case as well. + +### Use as a fallback mechanism when 2FA is activated, but the client + application does not support it + +The user would enter only an application-specific password, enabling to use 2FA +for account management as well as services that support it, while allowing +applications that do not support it to work. + +### Use as part of RADIUS and Hardened Password authentication mechanisms + +As both of these authentication mechanisms include sending a password for +authentication, they could also be used with application-specific passwords. +As pure RADIUS provides only weak protection of the sent password, it might +be even more desirable than in the case of traditional password authentication. + +## Design + +### Multiple passwords for a single user and related changes + +If the attribute for password in the user schema is not multi-valued, it must +be modified to be. The user management must be extended to facilitate multiple +passwords for a single user. This also includes password reset functionality - +the user will be able to specify what password to reset. The user account +status will display information for all its passwords. + +It is worth considering adding another attribute to the user schema, which will +hold labels for all application-specific passwords, so that these labels can be +displayed in the WebUI and used in the relevant commands in CLI, increasing +the usability of these new functionality. The user will not need to remember +that e.g. password no. 4 is for access to email on a smartphone. + +Other authentication mechanisms that also incorporate sending a password will +also support application-specific passwords - namely otp (2FA), radius (RADIUS) +and hardened (Hardened Password (by SPAKE or FAST)). 2FA will now allow to omit +the OTP step if the client application does not support it and use only an +application-specific password in such case. + +It is worth considering if: +* the user will set application-specific passwords as usual (having to fulfil + password policies in place), and/or +* they will be generated by FreeIPA (possibly only for one use, being an OTP). + It is usually done so by web services using application-specific passwords as + a fallback mechanism when 2FA is activated, but the client application does + not support it. + +### Permissions management for application-specific passwords + +The user will be able to configure permissions based on the password +used to log into the account: +* logging in using the primary password (or the master 2FA token) +would grant full access to the account, including configuring all +the other passwords as well as access to all services for which +that account is used, +* logging in with an application-specific password would allow +access only to a specified subset of systems and services that +password is allowed access to (for example, it could grant access +only to log in to the user's mail server). + +By default, the password will have no permissions assigned, being inactive in +practice, with the user then explicitly assigning permissions for it at his/her +discretion. This may range from access to only one particular service up to +either (TBD): +* access rights on par with his primary password, or +* access to all systems and services, but not to the account management. + +It would be better for this to be at least to some extent separate from the +general access control, as permissions for passwords will be set by the user, +while permissions for the whole account are often set by other people. As a part +of this, it may be desirable to implement an attribute determining whether +default and managed permissions apply for the given user's password, or not. + +There is another option: in theory, authentication indicators could be used for +access management for multiple passwords for a single user - it would then be +best to differentiate 'levels' of passwords. This might (depending on +implementation) facilitate less fine-grained access control for varius +passwords, but would probably be easier to implement. + +If needed, self-service ACIs and/or delegation ACIs will be extended as well +to support application-specific passwords. + +#### HBAC for application-specific passwords + +There are two options how to make HBAC distinguish between various passwords: +* Assign permissions for access to hosts as a part of the permissions management + for the user's passwords. HBAC would be extended to check these permissions. +* Extend HBAC rules to *(host, service, user, password id/password level)* + so that they will directly accommodate this functionality. The attribute + identifying a user's password or a password level: + * can either be an optional field or it can have a special wildcard value denoting + 'all user's passwords', + * will be administered by the user (in line with permissions management for + user's passwords in general). + +### ipa-kdb support for the aforementioned functionality + +The ipa-kdb daemon will be extended to support the aforementioned functionality +as well, so that it can be used with Kerberos, which plays a critical role in +FreeIPA, as all commands facilitating user management require not only relevant +permissions, but also an obtained Kerberos ticket. + +### SSSD support for the aforementioned functionality. + +SSSD will also be extended to support the aforementioned functionality. This +will be done by a closely related, but separate extension of SSSD. On the +side of FreeIPA, after SSSD is extended, interactions with SSSD using the new +functionality must be tested. + +## Implementation + +The extension must be backward compatible, that means not breaking any existing +functionality and passing all existing tests. + +As for changes to the data storage: +* As mentioned above, if the attribute for password in the user schema is not + multi-valued, it must be modified to be. +* The permissions for application-specific passwords or at least password levels + will be stored in a suitable location in the LDAP database. If the entire LDAP + database of FreeIPA or SSSD is already being backed up, there is no need for + change here, but if only select sections of it are backed up, then these + permissions should be included into backup as well. + +It is possible that the extension will neccessitate changes to some LDIF files +in install/share/. + +**New dependencies**: TBD, not expected for now + +## Feature management + +### UI + +TBD + +### CLI + +TBD + +## How to test + +TBD + +## Test Plan + +1. All existing tests must pass. This also ensures that the user can have only +one password. +2. Test (password policy-compliant) application-specific passwords and their + permissions management with 1FA: + 2.1 Add one application-specific password using WebUI and one using CLI. + 2.2 Check that the user is not able to log in using either of these new + passwords. + 2.3 Add some permissions for both application-specific passwords. This + includes both 'standard' permissions and HBAC rules. + 2.4 Check that using these application-specific passwords, it is possible to + authenticate to all and only those services and systems that they have + been permitted to in the previous step. + 2.5 Log in using the primary password. + 2.6 Check whether all user's passwords are listed in the WebUI or by using an + appropriate command in CLI. + 2.7 Change both application-specific passwords - the one created using WebUI + by using CLI, and vice versa. + 2.8 Repeat step 2.4 using the changed application-specific passwords. + 2.9 Remove both application-specific passwords - one by using WebUI, and the + other one by using CLI. + 2.10 Chceck that the user now only has the primary password. +3. Test whether the password policies in force for the given user automatically + apply for all of his passwords - i.e. they cannot be bypassed by setting + another password: + * Try to add an application-specific password that is in breach of the + password policy in place. This must fail. +4. Test application-specific passwords and their permissions management with + 2FA: + 4.1 Enable 2FA (authentication mechanism *otp*). + 4.2 Check that the user can still log in using only his password. + 4.3 Create a token for the user. + 4.4 Check that the user can no longer log in using only his password. + 4.5 Log in using the primary password and OTP. + 4.6 Repeat steps 2.1 - 2.10 with 2FA in place. + 4.7 Remove the token created in step 4.3 and disable 2FA. +5. Test application-specific passwords and their permissions management with + RADIUS (such that it uses a password for authentication) and Hardened + Password authentication mechanisms. For both of these authentication + mechanisms: + 5.1 Change the authentication mechanism to the tested one and perform any + necessary configuration. + 5.2 Check that the user can still log in using his primary password as a part + of the tested authentication mechanism. + 5.3 Repeat steps 2.1 - 2.10 with the tested authentication mechanism. + 5.4 Change the authentication mechanism back to the traditional password + authentication. +6. Test application-specific passwords and their permissions management with + Kerberos (ipa-kdb): + * Repeat steps 2.1 - 2.10, but instead of logging in by entering the password + directly, obtain a Kerberos ticket by entering the password into the + corresponding prompt and then log in using the obtained ticket. +7. Test interactions with SSSD using the new functionality. + * Repeat all procedures from points 1. - 6., but when testing logins other + than those into account management (i.e. FreeIPA server), perform them on + a client using SSSD configured against the testing FreeIPA server. \ No newline at end of file