ETSI GS NFV-SEC 002 V1.1.1 (2015-08)

Network Functions Virtualisation (NFV); NFV Security; Cataloguing security features in management software

DGS/NFV-SEC002

General Information

• Status: Published
• Publication Date: 16-Aug-2015
• Technical Committee: NFV SEC - Security
• Current Stage: 12 - Completion
• Due Date: 10-Sep-2015
• Completion Date: 17-Aug-2015

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
NFV Security;
Cataloguing security features in management software

2 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)

Reference
DGS/NFV-SEC002
Keywords
NFV, open source, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Introduction . 8
5 Identity and access management . 9
5.1 General . 9
5.2 PKI tokens . 10
5.2.0 General . 10
5.2.1 PKI set-up . 10
5.2.2 Token generation . 10
5.2.3 Token verification . 11
5.2.4 Token indexing . 11
5.3 UUID tokens . 12
5.4 Trusts . 12
5.5 Token storage . 13
5.6 Token Transport . 14
5.7 Identity federation . 14
5.8 Identity API Access Control . 15
5.9 Password Hashing . 15
5.10 Time Synchronization . 15
6 Communication Security . 15
7 Stored data security . 16
7.1 Block Storage Encryption . 16
7.2 Logical Volume Sanitization . 17
8 Firewalling, zoning, and topology hiding. 17
8.1 Security group . 17
8.2 Anti-spoofing . 18
8.3 Network Address Translation . 18
8.4 Network isolation . 19
8.5 Firewall-as-a-service . 19
9 Availability . 19
10 Logging and monitoring . 20
10.1 Logging . 20
10.2 Event notification . 21
11 Compute isolation . 22
12 Guidance on the use of OpenStack in NFV. 23
13 Recommended OpenStack enhancements in support of NFV. 24
ETSI
4 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
Annex A (informative): Authors & contributors . 25
Annex B (informative): Bibliography . 26
History . 27

ETSI
5 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
1 Scope
The present document gives a survey of the security features in the open source management software relevant to NFV,
in particular OpenStack™ [i.1] as the first case study. It addresses the OpenStack modules that provide security services
(such as authentication, authorization, confidentiality protection, integrity protection, and logging) together with the full
graphs of their respective dependencies down to the ones that implement cryptographic protocols and algorithms. It also
identifies a set of recommendations on the use of and enhancements to OpenStack as pertinent to NFV.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] OpenStack.
NOTE: http://www.openstack.org/.
[i.2] United States Computer Emergency Readiness Team.
NOTE: http://www.us-cert.gov/.
[i.3] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.4] ETSI GS NFV-SEC 001: "Network Functions Virtualisation (NFV); NFV Security; Problem
Statement".
[i.5] ETSI GS NFV 004: "Network Functions Virtualisation (NFV); Virtualisation Requirements".
[i.6] ETSI GS NFV-MAN 001: "Network Functions Virtualisation (NFV); Management and
Orchestration", (work in progress).
[i.7] Memcached.
NOTE: http://memcached.org/.
ETSI
7 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
[i.8] OpenID Connect.
NOTE: http://openid.net/connect/.
[i.9] IETF Application Bridging for Federated Access Beyond web (ABFAB) Working Group.
NOTE: http://tools.ietf.org/wg/abfab/charters.
[i.10] IETF RFC 5905 (June 2010): "Network Time Protocol Version 4: Protocol and Algorithms
Specification".
NOTE: https://tools.ietf.org/html/rfc5905.
[i.11] IEEE 1588-2008 (July 2008): "IEEE Standard for a Precision Clock Synchronization for
Networked Measurement and Control Systems".
[i.12] The OpenStack Security Guide.
NOTE: http://docs.openstack.org/sec/.
[i.13] Trusted Computing Group: Storage Work Group Storage Security Subsystem Class: Opal.
NOTE:   http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class
_opal.
[i.14] IETF RFC 3164: "The BSD syslog Protocol".
[i.15] IETF RFC 5424: "The Syslog Protocol".
[i.16] IETF RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
[i.17] FIPS PUB 186-4: "Digital signature Standard".
[i.18] DMTF: "Cloud Auditing Data Federation (CADF)".
NOTE: Available at: http://www.dmtf.org/standards/cadf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [i.3] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in [i.3] and the following apply:
AMQP Advanced Message Queuing Protocol
AH Authentication Header
API Application Program Interface
ARP Address Resolution Protocol
CADF Cloud Auditing Data Federation
CMS Cryptographic Message Syntax
DHCP Dynamic Host Configuration Protocol
DMTF Distributed Management Task Force
ESP Encapsulating Security Payload
GRE Generic Route Encapsulation
HMAC Hashed Message Authentication Code
HTTP HyperText Transfer Protocol
IKE Internet Key Exchange
IP Internet Protocol
JSON JavaScript Object Notation
KVS Key Value Stores
ETSI
8 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
LDAP Lightweight Directory Access Protocol
LUKS Linux Unified Key Setup
MAC Media Access Control
MAC/IP Media Access Control / Internet Protocol
NSS Network Security Services
NTP Network Time Protocol
PEM Privacy Enhanced Mail
PKI Public Key Infrastructure
PTP Precision Time Protocol
RPC Remote Procedure Call
SAML Security Assertion Mark-up Language
SASL Simple Authentication and Security Layer
SED Self Encrypting Drive
SQL Structured Query Language
SR-IOV Single Root Input Output Virtualization
SSH Secure SHell
SSL Secure Socket Layer
TCP Transfer Control Protocol
URI Uniform Resource Identifier
UUID Universally Unique IDentifier
VLAN Virtual LAN
VM Virtual Machine
VNC Virtual Network Computing
VPN Virtual Private Network
VXLAN Virtual eXtensible Local Area Network
WSGI Web Server Gateway Interface
4 Introduction
Building on open source software can help advance certain goals of NFV, such as accelerated time-to-market and
improved interoperability. To do so effectively calls for having a knowledge base of the security features and
cryptographic algorithms supported in each relevant code base. In particular, NFV applications are subject to privacy
and security regulations. The knowledge base helps shed light on how to best apply the pertinent software and on
enhancements necessary to meet the NFV security needs. It is also useful for other reasons. Chief among them are:
• export control of cryptographic software;
• compliance with procurement processes;
• follow-up on alerts from US-CERT [i.2] and other similar organizations; and
• determination of the relevant elements for security analytics.
Such a knowledge base is of particular importance in the area of management and orchestration, which plays a critical
role in NFV security.
The present document addresses OpenStack, a widely adopted cloud operating system, as the first case study. It aims to
cover all applicable aspects of information and network security, including:
• Identity and access management
• Communication security
• Stored data security
• Firewalling, zoning, and topology hiding
• Availability
ETSI
9 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
• Logging and monitoring
• Compute isolation
NOTE: OpenStack™ is a set of open source tools for building and managing cloud-computing software platforms
for public and privvate clouds.
It consists of a group of interrelated projects that control pools of processing, storage, and networking
resources throughout a data center e.g. Neutron, Nova, Keystone, Barbican, Swift, Glance, Trove, Cinder,
etc.
The present document describes the OpenStack modules that provide security services (e.g. authentication,
authorization, confidentiality protection and integrity protection) together with their respective dependencies on
cryptographic protocols and algorithms. It also makes a set of recommendations on the use of and enhancements to
OpenStack as pertinent to NFV. The case study takes into account the issues identified in ETSI GS NFV-SEC 001 [i.4]
and the related requirements specified in ETSI GS NFV 004 [i.5] and ETSI GS NFV-MAN 001 [i.6].
5 Identity and access management
5.1 General
Keystone is the component in OpenStack that provides centralized authentication and authorization. It is used by all
OpenStack components for API access control. Hence, at a high level, a user is authenticated by Keystone first before
gaining access to any other service (Keystone may employ an external authentication system). Upon successful
authentication, the user is given a temporary token. From this point on, to get a service, the user includes the token in
the service request. The user can receive the service if and only if the token is validated and if the user has the proper
roles.
Keystone is organized as a set of internal services, including the identity service, token service, and catalog service. The
identity service handles user authentication and user-data validation. The following constructs are basic to the service:
• User, which may be a person or a process using an OpenStack service.
• Project (or tenant), which owns a set of OpenStack resources. A project shall be assigned a domain.
• Group, which is a set of users. A group shall be assigned a domain. A user may be assigned one or multiple
groups.
• Domain, which is a set of users, groups, and projects.
• Role, which specifies a set of rights and privileges. Roles can be granted at either the domain or project level.
A group may be assigned one or multiple roles on a domain. A user may be assigned one or multiple roles on a
project or domain. An example role is admin. A user shall have a role assigned to have access to a resource.
The identity service supports basic management of user data (e.g. create, read, update and delete). It also has the
flexibility to use a pluggable authentication or authorization module through a backend. Common backends include
Lightweight Directory Access Protocol (LDAP) servers, SQL databases and Key Value Stores (KVS). Keystone uses an
SQL backend by default.
The identity service is accessible through a REST API. The corresponding API endpoint is, in fact, the entry point to all
services. An endpoint is a network-accessible address in the form of a Uniform Resource Identifier (URI). The identity
service may support a separate endpoint for administrative purposes. It goes without saying that the transport of all API
access transactions needs to be protected. In general, access control is based on configurable policy stored in a JSON
file. Other components in OpenStack can further customize the policy according to their respective service contexts.
Keystone supports an SQL policy backend.
The token service deals with token management and validation. It relies on a database to store tokens and the associated
data, including the token revocation list (or token revocation events) and per-token information (e.g. lifespan and
scope). The scope of a token is determined by a combination of projects (or domains) and roles associated with the user.
An unscoped token does not include a specified role. Such a token may be issued during the initial authentication of the
user, who can then use the token to discover accessible projects and then exchange it for a scoped token.
ETSI
10 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
As the basis for service access, tokens shall be protected from forgery, and from unauthorized access and alteration in
transit and at rest. The token service also provides protection in this regard. Several types of tokens are supported,
including Public Key Infrastructure (PKI) and Universally Unique IDentifier (UUID). The token type in use as well as
other specifics (e.g. token lifespan) is configurable. The default token type is UUID. Depending on the token type, it
may be useful to cache tokens to enhance performance. OpenStack services can be configured to this end. When used,
token caches need to be protected and expiration times need to be set appropriately. Custom token types are also
possible through external modules.
The catalogue service manages a registry of all OpenStack services. It allows a user to discover the entitled services and
the corresponding endpoints. Services can be organized in terms of regions, while endpoints classified as public,
internal or administrative. It is also possible to have tenant-specific endpoints. Keystone supports an SQL catalogue
backend.
5.2 PKI tokens
5.2.0 General
A PKI token is a Cryptographic Message Syntax (CMS) string, essentially data that are digitally signed and base64
encoded. The specifics of the data signed are context-dependent. They may include information on, for example, the
user, tenant, role, trust, timestamp and entitled services. One characteristic of such a token is its long length. It is
possible that a PKI token is too long to fit into either a header or URI. To reduce the token size, Keystone supports
compression through zlib. Still the size of a compressed PKI token is much larger than that of a UUID token.
PKI tokens are verifiable by any API endpoints as long as they have access to Keystone's signing certificate, the
information for verifying the signing certificate (i.e. the certificate chain and certificate revocation list), and the token
revocation list (or revocation event records). Keystone provides an API for retrieval of relevant signing certificates.
Decentralized token validation reduces the chance of Keystone becoming a bottleneck. For this reason, PKI had been
the default token type since the Grizzly release. Nevertheless, it has been changed back to UUID in the Juno release
based on deployment experience. The concerns are largely due to the large size of PKI tokens.
5.2.1 PKI set-up
Keystone provides the utility for generating the signing key, the corresponding certificate and the certificate chain that
are required for token generation and management. The required material may be externally generated and imported.
Either way, it is stored in separate files in the Privacy Enhanced Mail (PEM) format in the directories as specified in the
Keystone configuration file (i.e. keystone.conf). Keystone does not support encryption of private key files but relies
on the access control mechanisms of the underlying operating system to protect such files.
The Keystone utility for generating signing keys and certificates is the command keystone-manage pki_setup,
which is based on OpenSSL. The key size and certificate lifespan are configurable through keystone.conf. The
signature algorithm in use is RSA-SHA256. RSA is hardcoded in keystone/common/openssl.py and SHA256 in
keystoneclient/common/cms.py.
5.2.2 Token generation
Table 1
openssl cms -sign -signer
Cryptographic
/etc/keystone/ssl/certs/signing_cert.pem -inkey
module used
/etc/keystone/ssl/private/signing_key.pem -
outform PEM -nosmimecap -nodetach -nocerts –
noattr –md –sha256
Signature algorithm default RSA-SHA1 (with key-size = 2048)
Configurability configurable through the signing certificate and key as part of PKI
setup
Invoking module
keystone/common/cms.py/cms_sign_text() or
keystoneclient/common/cms.py/cms_sign_text()

The token lifespan is configurable through keystone.conf. The default is one hour.
ETSI
11 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
5.2.3 Token verification
A PKI token is valid if satisfying at least the following criteria:
• It has not expired.
• It had not been revoked.
• The signing certificate and token signature are valid. (The certificate chain is valid and no certificates have
been revoked.)
Table 2
openssl cms -verify -certifle
Cryptographic
/etc/keystone/ssl/certs/signing_cert.pem –CAfile
module used
/etc/keystone/ssl/certs/ca.pem -inform PEM -
nosmimecap -nodetach -nocerts -noattr
Signature algorithm default RSA-SHA1 (with key-size = 2048)
Configurability configurable through the signing certificate and key as part of PKI
setup
Invoking module
keystone/common/cms.py/cms_verify() or
keystoneclient/common/cms.py/cms_verify()

5.2.4 Token indexing
To reference PKI tokens, their hash values are used. The hash algorithm is configurable.
Table 3
hashlib.py
Cryptographic
module used
Hash algorithm default MD5 (expected to change to SHA256)
Configurability
The hash algorithm is configurable via hash_algorithms in
keystone.conf.
Invoking module keystone/common/cms.py/cms_hash_token() or
keystoneclient/common/cms.py/cms_hash_token()

ETSI
12 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
5.3 UUID tokens
UUID tokens are randomly generated strings that are verifiable by Keystone only. The use of such tokens necessitates a
persistent storage backend. A UUID token is valid if there is a non-expired matching token in the backend.
Table 4
Cryptographic uuid.uuid4().hex (from uuid.py)
module used
Random number
/dev/urandom or a pseudo-random number generator
generation
Configurability Platform-dependent
Invoking module keystone.token.providers.uuid.py
NOTE 1: uuid.uuid4() makes use of the available UUID library from the platform (e.g.
libuuid on Linux). If both uuid_generate_rand() and
uuid_generate_time()are available, the former is the first choice.
uuid_generate_rand()builds on /dev/urandom, while
uuid_generate_time() is based on the local current time, the MAC
address (if available), and a pseudo-random number. If no UUID library is
available, uuid.uuid4() constructs UUIDs based on /dev/urandom
directly. If /dev/urandom is unavailable, it constructs UUIDs based on the
pseudo-random number generators implemented in random.py, which are not
deemed cryptographically secure.
NOTE 2: /dev/urandom is not as strong as /dev/random. The latter will return bits
only if there is sufficient entropy in the input. This is known as blocking. In
contrast, the former is non-blocking.
NOTE 3: Pseudo-random number generation should be NIST FIPS-186-4
[i.17] compliant.
5.4 Trusts
Keystone further supports delegation through the construct of trust, which is not cryptographically based. The construct
is particularly relevant to services (e.g. Heat) involving deferred operations. In these cases, tokens alone are insufficient;
they are short lived.
A trust is between two parties: the trustor and trustee. Only the trustor can create a trust, which represents the trustor's
consent to let the trustee act on the trustor's behalf. The trustee has exclusive use of the trust. To carry out a delegated
task, the trustee uses a somewhat special token that reflects its delegated role. The special token is known as a trust
token, which is just a normal token with additional trust-related information. The trustee (after being authenticated)
obtains a trust token from Keystone by presenting a trust. For example, a Heat service user gets a token from Keystone
based on a trust with Alice for accessing Nova and uses the token to create a new instance of Alice's stack on her behalf
in response to an auto-scaling or a reporting event.
A trust has a limited scope. In other words, only a sub-set of the trustor's privileges is delegated to the trustee. The
delegated set of privileges is a combination of a project and a list of roles associated with the trustor. In Heat, the
heat_stack_owner. This is configurable through heat.conf. A token derived from a trust will have
default role is
the same scope as the trust.
Trusts are immutable once created. To update a trust relationship, the trustor deletes the old trust and creates a new one.
Upon deletion of the old token, any tokens derived from it are revoked. If the trustor loses any delegated privileges, the
trust becomes invalid.
A trust may have a limited lifetime. If the expiration time is not specified, the trust is valid until it is explicitly revoked.
The default is infinite lifetime and it is hardcoded.
A trust may be constrained in terms of the number of times that it can be used for getting a token. The default is no cap
and it is hardcoded.
ETSI
13 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
A trust may allow "impersonation" so that the trustee appears as the trustor to services validating a trust token.
(Impersonation as meant in OpenStack is a misnomer, given that it refers to authorized use of an identity.)
Impersonation is enabled by default. This is configurable through keystone.conf. Note that a trust token carries a
trust object containing all the related information, including the impersonation flag. So an impersonator is known in
effect. When impersonation is enabled, logs need to capture the information necessary for auditing and non-repudiation
purposes.
Delegation may be recursive so that the original trustee further delegates another trustee, becoming a trustor as a result.
This is controlled by the flag allow_redelegation, which is disabled by default. In the case of recursive delegation,
the trust construct further includes an attribute for specifying the depth of delegation, or the length of the re-delegation
chain. A re-delegation depth of the value zero means that further delegation is impossible. The depth of re-delegation is
configurable through keystone.conf. Recursive delegation is applicable to VM lifecycle management (as
implemented in Solum).
By default, the authentication method for deferred operations is set to passwords instead of trusts. This requires storage
of passwords in yet another backend, which adds complications. This is configurable through heat.conf.
The default backend for trusts is SQL. This is configurable through keystone.conf. The database keeps track of,
among other things, the expiration time, deletion time and remaining quota of each trust. Trusts, as designed, do not
employ any cryptographic measures, and are vulnerable to forgery and tampering. Proper controls needs to be in place
to protect the trust information and support auditing and non-repudiation.
Trusts can be queried at the identity API endpoint. The access control policy is configurable through a Keystone policy
file (typically policy.json). For obvious reasons, only a trustor or trustee may issue queries. The related policy
should be set accordingly.
A trust is identified by a UUID, which is generated the same way as for an UUID token.
5.5 Token storage
Keystone supports the following back-ends for token storage in addition to the default SQLite database in some
ditstributions:
• SQL database (default).
The storage is persistent. Expired tokens are not automatically removed from the backend. To purge such
tokens, the keystone-manage token_flush command can be used. Protection of the tokens in the
database is implementation-dependent.
• Key Value Store (KVS).
The base implementation keeps tokens in memory. It is primarily for testing support.
• memcached [i.7].
This is a key-value store in support of caching. The storage is in-memory, distributed, and ephemeral. Expired
tokens are removed automatically. Cached tokens may be protected through HMAC or HMAC together with
encryption. This is configurable through keystone.conf or the configuration file of another OpenStack
component (e.g. heat.conf).
ETSI
14 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
Table 5
Cryptographic
Crypto.hash and Crypto.Cipher in the Python
module used
Cryptography Toolkit (pycrypto)
Digest algorithm SHA384
Encryption algorithm AES (with 128-bit keys)
Key derivation HMAC-based
Configurability Limited.
• The digest and encryption algorithms are hard-coded.
• The HMAC and encryption keys are derived from a
configurable secret key (memcache_secret_key) in a
configuration file, such as heat.conf.
• The HMAC key size is hard-coded to 128 bits.
• The encryption key size is hard-coded to 128 bits.
keystoneclient.middleware.memcache_crypt.py
Invoking module
NOTE 1: Secret key protection relies on the access control mechanisms of the underlying
platform.
NOTE 2: memcached supports Simple Authentication and Security Layer (SASL) as an
option but the default is no authentication.

5.6 Token Transport
Keystone supports secure transport of tokens through SSL/TLS, although SSL/TLS is disabled by default. SSL/TLS
connections can be effected between Keystone and its user as well as between Keystone and its backend. The
information required for SSL/TLS operations is provisioned in the files as specified in keystone.conf.
Table 6
Cryptographic OpenSSL library (the SSL/TLS-specific part)
module used
Cipher suite Negotiated during the handshake
Configurability
• The list of candidate cipher suites is configurable through
openssl.cnf (that is part of the underlying platform) and
openssl.conf (that is part of OpenStack).
• Client authentication based on certificates is configurable
through keystone.conf.
keystoneclient.session.Session()
Invoking module
NOTE: Keystone may run as part of an HTTP server. In this case, a different SSL/TLS
library may be used as dictated by the HTTP server.

5.7 Identity federation
Through identity federation Keystone can outsource identity management to an external provider known as an identity
provider. The assumption here is that the identity provider is trusted. It is, thus, straightforward for an operator to reuse
its existing identity management system in a monolithic NFV deployment scenario. There is no need for provisioning
existing users in Keystone. In the common nomenclature of identify federation, the user is called the principal and
Keystone the relying party.
The involvement of a third party to vouch for the authenticity of the user results in a new authentication workflow.
When receiving an authentication request, Keystone, instead of handling the request itself, redirects it to the identity
provider (typically through the user agent). Upon receiving the redirected request, the identity provider performs the
steps to authenticate the user, and then redirects the result as an attestation to Keystone (through the user agent). If the
user is attested authentic, Keystone generates an un-scoped token, based on which the user can find out the accessible
projects and obtain another token with a proper scope. Tokens generated for a federated user are distinguishable. They
carry information related to federation, such as the name of the identity provider, the identity federation protocol, and
the associated groups.
Keystone has the flexibility to support multiple identity federation protocols, such as the Security Assertion Mark-up
Language (SAML) 2.0, OpenID Connect [i.8], Kerberos, and Application Bridging for Federated Access Beyond web
(ABFAB) [i.9]. Support for SAML 2.0 is already available. Its use is configurable through keystone.conf
(i.e. adding saml2 to the list of authentication methods). Support for other protocols is in the works.
ETSI
15 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
Keystone supports management of identity providers, including creation, deletion, update, and discovery. An identity
provider may not manage users in terms of the same attributes as Keystone. So attribute mapping is necessary. To this
end, Keystone supports management of attribute mapping on a protocol basis for each identity provider. Mapping is
done through a set of rules. Each rule maps a local attribute in Keystone to a remote attribute in the identity provider.
Typically a federated user is mapped to a group in Keystone and given the roles associated with the group. The default
backend for identity providers and mappings is SQL.
Identity federation is also applicable to token verification across two different OpenStack clouds. As a result, a token
generated by one cloud can be used to access another cloud. Such Keystone federation is under development. Again,
trust between the two OpenStack clouds is assumed and it is established through a separate process.
5.8 Identity API Access Control
API access control in Keystone is policy-based. To a certain degree, policy is configurable through a JSON file; what
gets enforced (or coded) is not always consistent. In the policy file, a set of rudimentary rules can be specified for each
call in the identity API. A rule prescribes a required role (e.g. admin) or a required matching condition for an attribute
(e.g. user_id) of the token and another parameter (e.g. trust.trustor_user_id) passed in the request. If a rule is
expected but undefined, the default rule that requires the admin role applies. The name and location of the JSON file is
configurable through keystone.conf. The default name is policy.json.
Each OpenStack module has its own policy file. There is no inbuilt mechanism for consistency across OpenStack in
terms of policy definition, decision, and enforcement. In general, protection of policy files is critical. There shall be
strict access control and audit trails.
5.9 Password Hashing
Keystone provides native support for password management, including password hashing.
Table 7
passlib.hash.sha512_crypt.encrypt()
Cryptographic
module used
Hashing algorithm hard coded (SHA512)
Configurability The number of rounds of SHA-512 to use in generation of the salt
is configurable via CONF.crypt_strength (default=40000) in
keystone.conf.
Invoking module passlib.hash.sha512_crypt.encrypt()
NOTE: In Passlib, the default number of rounds is 100 000.

5.10 Time Synchronization
Given that token expiration is a component of Identity and Access Management, time synchronization among the
servers making up an OpenStack cloud is critical. Time synchronization is not provided by OpenStack, and shall be
configured through the underlying operating system services, such as the Network Time Protocol (NTP) [i.10] or the
Precision Time Protocol (PTP) [i.11]. The time service shall also be securely configured to prevent servers from being
attacked in a way to cause an expired token from being considered still valid.
6 Communication Security
Communication security in an OpenStack-based infrastructure can be effected through means such as TLS, the Secure
Shell (SSH) protocol, and VPNaaS.
TLS supports confidentiality and integrity of communication over TCP, and authentication of communicating peers. For
TCP-based services in OpenStack, the use of TLS can be controlled through configuration (e.g. through the use_ssl
flag in a service configuration file). But TLS is not necessarily required by default where it is applicable, such as access
to Glance, Neutron and Virtual Network Computing (VNC) connections. OpenStack further allows TLS connections to
be set up when certificates cannot be verified. This may be controlled by the api_insecure or insecure flag,
which is disabled by default. The OpenStack proper supports TLS through the OpenSSL library, which is configurable
to forbid its predecessor SSL and the cipher suites that are known to be vulnerable.
ETSI
16 ETSI GS NFV-SEC 002 V1.1.1 (2015-08)
The security functions supported by SSH are similar to those by TLS. A key difference is that SSH does not require
certificate-based authentication for servers. SSH is typically used for remote login and command execution. In the
OpenStack proper, the following controls are available for SSH:
• Injection of SSH key pairs to guest virtual machines for access by tenants [i.10]. This can be done by the
metadata service or by the hypervisor. In the latter case, the inject_key flag provides the control and it is
disabled by default. Note that the specific SSH software in use is application dependent.
• Host key checking upon first connection to a storage backend. Certain drivers in Cinder (the block storage
service) support issuing commands for execution on a storage backend through SSH. The
strict_ssh_host_key_policy flag controls whether an SSH client is to trust the public key of a newly
encountered SSH server. It is disabled by default. If it is enabled, Cinder will allow connection to a backend
only if the first host key presented is specified in the ssh_hosts_key_file file. Cinder supports an SSH
client based on the Paramiko library.
VPNaaS is part of Neutron, which provides the networking service in OpenStack. To date, VPNaaS supports site-to-site
IPsec tunnels. Standard transform protocols (i.e. ESP and AH) and modes (i.e. tunnel and transport) are supported. The
defaults are hardcoded to ESP and tunnel. The supported authentication algorithm is SHA-1; and encryption algorithms
are 3DES, AES-128, AES-192 and AES-256 (with the default hardcoded to AES-128). These are also applicable to the
Internet Key Exchange (IKE) protocol. For key exchange specifically, the supported phase 1 operation is limited to
Main Mode (which is reasonable) and the supported authentication method is limited to pre-shared secrets stored in
files. In addition, the supported Diffie-Hellman Groups are limited to 2 (1 024-bit modulus), 5 (1 536-bit modulus), and
14 (2 048
...