Understanding the cluster security services private/public key-based mechanisms

Cluster security services provides two security mechanisms for authentication and authorization.

Both the HBA and HBA2 mechanisms employ private/public key pairs for authentication. An unique private/public key pairing is associated with each node in the cluster. These keys are used to encrypt and decipher data. Data encrypted with a particular private key can be deciphered only by the corresponding public key, and data encrypted with the public key can be deciphered only by the corresponding private key.

When the cluster security services are installed on a node, a private key for that node is created and a public key is then derived from the private key. The private key remains on the node in a protected file that only the root user can access. The public key is provided to the other nodes within the cluster by the cluster management applications and is stored on the node in a file that is readable by all users. A node's private/public key pair is considered synonymous with a node's identity and is not expected to change over time. However, if a node's private key does need to be changed, see Changing a node's private/public key pair for instructions on how to do this.

At the time that the private/public key pair is created, cluster security services also creates a trusted host list for the node. The trusted host list associates host identities—host names and IP addresses—with their corresponding public key values. This association is stored in a file and used by the ctcas subsystem to create and validate identity-based credentials for the HBA and HBA2 MPMs. This association is also used by RSCT during cluster setup to create and verify signatures for messages passed between RSCT subcomponents.

The initial trusted host list file created by the installation process associates a node's public key value with all active host names and IP addresses associated with all configured and active AF_INET and AF_INET6 adapters for that node. If no network interfaces are configured and active at the time, then the installation process does not create a trusted host list; instead, the ctcas subsystem will create the file when it runs for the first time.

A node can only verify credentials from an HBA or HBA2 MPM client if the client's node is listed along with its associated public key in the receiving node's trusted host list. If a client node's host name or IP address does not appear in this list or if the public key value recorded in this list is not correct, then the client cannot be authenticated. When a public key for a cluster node is provided to a node, the public key is recorded along with the cluster node's host name and IP address values in the trusted host list.

For message signature verification to function and for HBA and HBA2 credential verification to succeed, the public keys and their host associations must be distributed throughout the cluster. When configuring a cluster of nodes (either as a management domain or as an RSCT peer domain using configuration resource manager commands), the necessary public key exchanges will, by default, be carried out by configuration resource manager utilities. If the network is relatively secure against identity and address spoofing, you can use these utilities; otherwise, transfer the keys manual to prevent the inclusion of nodes that may be attempting to masquerade as known nodes. Carefully consider whether the network's security is sufficient to prevent address and identity spoofing. If you do not think the network is secure enough, see Guarding against address and identify spoofing when transferring public keys. If you are not sure whether your network is secure enough, consult with a trained network security specialist to find out if you are at risk.

Table 1 lists the default locations for a node's private key, public key, and trusted host list.