Security/Icehouse/Keystone

This page documents security related details for the Keystone project in the OpenStack Icehouse release.

Implemented Crypto
Keystone doesn't have an home-brewed encryption implementations, everything is used from Python Standard libraries or third party libraries.

Libraries

 * oauthlib (uses hashlib)
 * OpenSSL
 * PassLib
 * PyCrypto
 * Python hashlib
 * python-ldap (ultimately uses GnuTLS, NSS, or OpenSSL depending on the platform)
 * Requests (for keystoneclient HTTPS usage - need to investigate underlying crypto usage)
 * uses stdlib - https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/connection.py

Keys/Certificates

 * PKI signing key - Protected via filesystem ownership/permissions.
 * SSL/TLS key - Protected via filesystem ownership/permissions.

Passwords

 * SSL/TLS must be enabled in Keystone to prevent clients from sending passwords over the network in clear-text.
 * Passwords are truncated to a maximum length prior to hashing
 * Configurable via CONF.identity.max_password_length (default=4096)
 * SQL Identity
 * Password hashes are stored in SQL database.
 * SSL/TLS can be used to protect the connection to the database.
 * LDAP Identity
 * SSL/TLS must be used for connections to LDAP to prevent Keystone from sending passwords over the network in clear-text.

Tokens

 * Signed tokens are stored in their entirety in one of the following backends:
 * KVS
 * Memcached
 * Ephemeral storage.
 * Able to use AES encryption and sha384 signing.
 * SQL (default)
 * Persistent storage.
 * SSL/TLS can be used to protect the connection to the database.
 * Expired tokens are not automatically removed from the backend. The "keystone-manage token_flush" command should be used to periodically remove expired tokens (via cron).

Potential Improvements

 * Eliminate LDAP user password hashing. This code should be unnecessary, as passwords supplied by clients should only be used to perform LDAP bind operations and never stored locally in any form.
 * Allow all hashing schemes to be configurable where not restricted by compatibility requirements (such as S3 and EC2)
 * The use of md5 for token hashing is the biggest concern, as it's use is discouraged (or disallowed in the case of FIPS). Changes are in progress to make this configurable in Juno.  The default should be sha256 if possible.
 * Allow support for LDAP SASL bind methods(such as DIGEST-MD5 and GSSAPI).
 * Allow other forms of external authentication to avoid using passwords (Kerberos, SAML).