Configuring security compliance mode

Edit online

When RSCT is installed on a node, its security mode is set to none by default. The default mode does not impose any restrictions for host-based authentication (HBA) mechanism or key types that are configured for RSCT. A node or cluster can be migrated to be compliant with the National Institute of Standards and Technology (NIST) SP800-131a compliance.

RSCT compliance mode

To use the nist_sp800_131a NIST compliance mode for any service that uses security mechanisms for authentication and secure communication, the service must use minimum key strengths. The following key types provided by RSCT comply with the NIST compliance:

Asymmetric key types

rsa2048_sha256
rsa2048_sha512
rsa3072_sha256
rsa3072_sha512
rsa4096_sha256
rsa4096_sha512

Symmetric key types

aes128_sha256
aes128_sha512
aes256_sha256
aes256_sha512

Note: After the node is made complaint with the nist_sp800_131a NIST compliance mode, the cluster security services can authenticate sessions only from the nodes that are using symmetric or asymmetric keys, which are compliant with the compliance specification.

Migrating RSCT to the nist_sp800_131a compliance mode depends on the operational scope of RSCT.

Enabling a security mode in stand-alone node

A stand-alone node that is not a member of a management or peer domain can be migrated to operate under the nist_sp800_131a mode by running the chsecmode command.

Enabling a security mode in management domain

Domains that are managed by a Hardware Management Console (HMC) or IBM Flex Systems Manager (FSM) can be migrated to the NIST-compliant mode when the management control point (MCP) is migrated. All communications between RSCT running on MCP and RSCT running on the logical partition (LPAR) comply with the NIST SP800-131a specification when the enablement is initiated from the HMC. To enable this security mode on the HMC, run the following command and then restart the HMC if HMC is not restarted by the following command:

chhmc -c security -s modify --mode nist_sp800_131a

This command drives the necessary compliance in RSCT that is running on the HMC and all the LPARs contained in the management domain at a particular time. Also, the NIST compliance mode is enabled on the LPARs that automatically join the management domain.

start of change However, if the LPAR is running virtual HMC (vHMC) software, the compliance state of the LPAR is not influenced by the physical HMC that is managing the vHMC. Use the chhmc command to enable NIST mode on vHMC. end of change

Notes:

Before you enable NIST compliance on the HMC, install RSCT 3.2.0.0 on all the LPARs. The management domain then continues to use communications according to the security guidelines mentioned in the NIST SP800-131a specification.
If any of the LPARs do not have the required RSCT levels installed, the RSCT that is running on the HMC stops communicating with the LPAR. It can impact certain operations that can be performed on the LPAR from the HMC.
If an LPAR is participating in a peer domain with other LPARs and if you enable the NIST compliance mode on the HMC, the HMC drives the NIST compliance mode on the peer domain if all the nodes have the latest RSCT levels installed and the active version is 3.2.0.0.
If an LPAR is participating in a peer domain, ensure that all peer domain members are in online state before initiating NIST compliance mode on the HMC. If HMC compliance is changed when some of the peer domain members are in offline state, and subsequent online operation fails on those nodes, run the preprpnode command again on all the nodes before you bring the nodes online.
If an LPAR is participating in a peer domain, and peer domain members are managed by two or more independent HMCs, ensure that the same compliance mode is set on all HMCs to avoid disruption to the management domain.

Management domains that are managed by multiple MCPs

If an LPAR is managed by more than one HMC or FSM, the NIST compliance mode can be applied only when one of HMCs is migrated to the NIST compliance mode. The MCP might not be able to communicate with the other MCPs or LPARs until the nodes are migrated to the NIST compliance mode.

If the MCPs are configured as a peer domain, complete the following steps to enable the NIST compliance mode:

Migrate MCP peer domain by using the NIST-compliance private or public keys and symmetric keys by running the following command:
```
> runact -c IBM.PeerDomain ChangeSecurityMode CSSKType="rsa2048_sha256" HBAType="aes256_sha256"
```
Enable the NIST compliance mode on HMC or FSM.

Enabling a security mode in a peer domain consisting of stand-alone nodes

A stand-alone peer domain can be created to operate in the nist_sp800_131a mode, or migrated to be compliant by running an action while the domain is online.

Enabling a security mode in a peer domain consisting of LPARs managed by an HMC or FSM

Peer domains that consist of LPARs under the management domain of an HMC or FSM are automatically migrated to be nist_sp800_131a compliant when the management domain is migrated to the NIST compliance mode, and the peer domain has a quorum of members.

Therefore, it is recommended that the NIST compliance mode be enabled on the HMC or FSM when all LPARs defined in the peer domain are online in the peer domain.

You can enable a security mode on all LPARs defined in the peer domain if:

Any LPARs were offline in the peer domain when the NIST compliance mode was enabled on the HMC or FSM.
The LPARs are defined in peer domain that is managed by multiple or different HMCs or FSMs. You must perform the steps after the NIST compliance mode has been enabled on all MCPs.
A peer domain is offline when the NIST compliance mode is enabled on the HMCs or FSMs that are managing its members.

You must perform the following steps before you bring any offline LPARs online in the peer domain or before you start a domain that was offline when the NIST compliance mode was enabled:

Run the lssecmode command to verify the security compliance mode on each LPAR. If the security compliance mode on the LPAR is none, run the following command:
```
chsecmode -c nist_sp800_131a
```
Run the preprpnode command on each LPAR, specifying all nodes defined in the peer domain.
You can now start the offline peer domain. You can also bring any LPARs online that were not online in the running peer domain.

Creating a peer domain

The RSCT installed on a node, which is migrated to a compliance mode, can communicate with other nodes that are not configured to the same compliance mode, provided both of the nodes are using compliant key types. For example, a peer domain can be created consisting of nodes that are configured with the nist_sp800_131a mode and nodes that are not configured with the nist_sp800_131a mode, while all the members of the domain are using key types that are compliant with the compliance specification. The mkrpdomain command provides the -C option to specify the compliance mode of the domain that is created. If the -k option is also used to specify the cluster key type, it must be set to the CSSKTYPE_NONE value to disable peer messaging security, or to a key type that is compliant with the requested security mode.

Consider the following prerequisites for creating a domain that enforces nist_sp800_131a compliance on all members:

All nodes must be installed with RSCT version 3.2.0.0, or later.
Each mode must be migrated to the nist_sp800_131a compliance mode or be configured to use compliant public or private keys before the preprpnode and the mkrpdomain operations are run.

If the mkrpdomain command with the -C nist_sp800_131a option is run for a domain consisting of nodes that meet the required conditions, the nodes that are using compliant keys but not migrated to the nist_sp800_131a mode are migrated during domain creation. The security mode of the domain is set to the nist_sp800_131a mode. Any nodes that are added after domain creation must be migrated to the same compliance mode.

If the mkrpdomain command is run for the same set of nodes without the -C option, or with the value none, the nodes that did not have the nist_sp800_131a mode are not migrated automatically. If the domain security mode is set to none, the nodes are added to the domain irrespective of the node's compliance mode.

The compliance mode of a domain can be queried by running the following command:

> lsrsrc -c IBM.RSCTParameters SecurityMode
Resource Persistent Attributes for RSCTParameters
resource 1:
	SecurityMode = "none"

The SecurityMode attribute of the peer domain ensures the domain members are using key types for RSCT communication that are compliant with the mode value. However, the nodes in the domain are not required to configure their compliance mode to the same value. For example, a peer domain that has the nist_sp800_131a SecurityMode attribute might have members that do not have nist_sp800_131a mode enabled as reported by the lssecmode command, provided that they are configured to use a HBA compliant key type.

Adding peer nodes

Consider the following prerequisites for adding nodes to a peer domain that is operating with the nist_sp800_131a compliance mode:

The node is installed with RSCT version 3.2.0.0, or later.
The node is migrated to the nist_sp800_131a compliance mode, or is configured to use public or private keys that are compliant with the compliance specification.

When a node, which uses compliant keys that are not enabled with the nist_sp800_131a compliance mode, is added to a domain operating in the nist_sp800_131a mode, it is migrated automatically. The -M option can be specified to the addrpnode command to prevent the node from being migrated by failing the operation.

Migrating a peer domain

A peer domain that is not configured to enforce a security compliance specification has a security mode of value none. This setting allows any supported HBA and CSSK key types to be configured within the cluster, provided the RSCT code level of each node supports the key types. A cluster can be migrated to a compliance mode by running the ChangeSecurityMode IBM.PeerDomain resource class action. The RSCT must be operating within the same compliance specification or compatible specification on all members for a peer domain that is configured to a compliance specification.

Consider the following prerequisites for migrating a cluster to the nist_sp800_131a mode:

All nodes are installed with RSCT version 3.2.0.0, or later.
The domain has a quorum of members.

To migrate a domain to the nist_sp800_131a mode, run the following command:

> runact -c IBM.PeerDomain ChangeSecurityMode Mode="nist_sp800_131a" CSSKType="type" HBAType="type"

The Mode, CSSK_TYPE, and HBA_METHOD fields are optional and default to compliant key types for the requested mode. If the fields are specified, the key types must be compliant for the mode. The CSSK_TYPE field might also be specified as CSSKTYPE_None to disable RSCT secure peer messaging.

Nodes, which are offline when a peer domain is migrated to the nist_sp800_131a compliance mode, cannot rejoin the domain if they are not configured to use a compliant HBA key type. Before bringing the nodes online to a migrated domain, run the chsecmode command on each offline node to enable the nist_sp800_131a compliance mode, or change their HBA keys to a nist_sp800_131a compliant key type, and then run the preprpnode command to distribute the public keys.

If individual nodes are defined in an offline peer domain and are migrated to the nist_sp800_131a compliance mode, run the preprpnode command to exchange public keys before starting the domain.

Disabling a security compliance mode

After a node is migrated to the nist_sp800_131a mode, it cannot be changed to the non-compliant mode without reconfiguring RSCT. If the node is a member of a management or peer domain, you must remove the node from the cluster and reconfigure the node to change the compliance mode from the nist_sp800_131a mode.