Deploying FIPS Mode

FIPS Mode can only be configured when other certain configuration preconditions have been met. These preconditions are required to provide a suitable environment for using a FIPS 140-3 cryptographic module for processing traffic.

Therefore in preparation for enabling FIPS Mode, the following configuration elements should be inspected and updated accordingly.

As per the guidance in SP 800-52r1, only SSL versions TLS 1.0 and later are suitable for operating in an environment using a FIPS 140-3 cryptographic module.

Therefore, to enable FIPS Mode, ensure your Virtual Traffic Manager configuration has SSLv3 disabled by setting ssl!support_ssl3 to "No" on the System > Global Settings > SSL Configuration page. Additionally, ensure that your virtual servers and pool do not override the global SSL setting on an individual basis (using the ssl_support_ssl3 settings on the Virtual Server > Edit > SSL Decryption and Pool > Edit > SSL Encryption pages).

ATTENTION If your SSL virtual server clients and pool nodes do not support TLS 1.0 or later, they will no longer be able to connect using SSL.

The FIPS 140-3 requirements provide a list of approved cryptographic methods that a FIPS 140-3 cryptographic module may include. Methods that are not approved are not permitted in the cryptographic module.

Some SSL/TLS cipher suites include cryptographic methods that are not approved by FIPS 140-3, common examples include the RC4 stream cipher and the MD5 digest algorithm. So that all TLS cryptography can be performed using the FIPS 140-3 cryptographic module when in FIPS Mode, the list of cipher suites that can be configured for use with the Virtual Traffic Manager is reduced to the following set:

Additionally, for TLSv1.3:

ATTENTION This will have an impact on interoperability with SSL virtual server clients and pool nodes, if they do not support any of the FIPS 140-3 compatible cipher suites then they will no longer be able to connect via SSL.

TrafficScript provides access to a number of cryptographic operations for rules executed in the Virtual Traffic Manager. When operating in FIPS Mode, these operations will be provided by the FIPS 140-3 cryptographic module.

For TrafficScript functions that use cryptographic methods not approved for FIPS 140-3 cryptographic modules, those functions will not execute successfully when operating in FIPS Mode. It is recommended that you migrate any uses of the TrafficScript functions listed below to an alternative cryptographic digest implementation that is approved for FIPS 140-3 cryptographic modules.

The TrafficScript functions that will produce an error when used in FIPS Mode are those that use the MD5 algorithm:

Public Key Infrastructure certificates and keys are cryptographic assets that need to be considered as part of a FIPS 140-3 deployment.

Although not directly considered in the FIPS 140-3 document, SP 800-131A covers a set of requirements for acceptable strength of keys used in cryptographic operations. These requirements are generally enforced by a FIPS 140-3 cryptographic module, and so must be considered prior to enabling FIPS Mode. For a more formal discussion about what "key strength" actually is (in this context), see the SP 800-51 Part 1 publication referred to in the FIPS 140-3 section above.

Beyond the strength of a key represented by a certificate, a certificate itself contains a cryptographic signature to enable validation that the certificate is the same as that validated by the issuer.

The algorithms used to create and validate the cryptographic signature must be approved for use in a FIPS 140-3 cryptographic module when in FIPS Mode. In FIPS Mode only those certificates whose signature digest uses the FIPS-approved SHA-1, SHA256, SHA384 and SHA512 algorithms can be used.

Prior to enabling FIPS Mode, the Virtual Traffic Manager SSL catalog (found at Catalogs > SSL) should be audited for:

If you attempt to enable FIPS Mode in this way, validation errors will highlight any certificates in the current configuration that will prevent the operation from succeeding.

Alternatively, you can use the command-line "cert" tool included in your Virtual Traffic Manager installation to evaluate individual certificates. For example, to inspect the SSL Server Certificate 'example' certificate file, use the following command:

Once these "weak assets" have been identified, you should evaluate their purpose in your Virtual Traffic Manager deployment to determine whether they are actually required, and if they are what other systems/services need to be changed/updated/deprecated to successfully move your Virtual Traffic Manager deployment towards having FIPS Mode enabled. These "weak assets" must be removed before FIPS Mode can be enabled.

ATTENTION Removing certificates and private keys may have an impact on connectivity with your Virtual Traffic Manager deployment. For example, SSL clients may be required to present a certificate signed by a "weak" CA, or the Virtual Traffic Manager itself may be required to provide a specific certificate when connecting by SSL to nodes in a pool. In these example cases, removing the "weak assets" will prevent clients, and the Virtual Traffic Manager, from creating SSL connections.

In addition to the above, you should consider your deployment where the Virtual Traffic Manager is in operation.

When operating in FIPS Mode, the Virtual Traffic Manager will reject requests to process cryptographic "weak assets" regardless of whether they are from the local configuration or received from remote systems.

ATTENTION If you are expecting virtual server clients to present certificates when connecting to the Virtual Traffic Manager by SSL, or the Virtual Traffic Manager is connecting to pool nodes by SSL, you should ensure the certificates presented by virtual server clients and pool nodes are suitable for operations in FIPS Mode.

When operating with chains of certificates, all the certificates in the chain must not be "weak" in order for that certificate chain to be successfully used by the Virtual Traffic Manager in FIPS Mode.

Some cipher suites make use of the Diffie-Hellman Key Exchange algorithm. SP 800-131A covers a set of requirements for acceptable strength of keys, which is also applicable for the Diffie-Hellman algorithm.

The size of the modulus in the domain parameters for finite field Diffie-Hellman key agreement used by the Virtual Traffic Manager can be configured with the ssl!diffie_hellman_modulus_size configuration key (from the “SSL Configuration” section of the System > Global Settings page).

The validity of a FIPS 140-3 cryptographic module is defined by the testing performed by an accredited testing laboratory. Testing for a software cryptographic module is performed on a specific hardware/operating system platform (operational environment). When a FIPS 140-3 cryptographic module is used in an operational environment where it has been validated, that module can be considered FIPS 140-3 validated.

The details about the operational environments in which the RCSM has been validated can be found in its listing on the NIST Web site.

While testing has been performed on a limited number of operational environments (and thus the RCSM used in those environments have explicit FIPS 140-3 validity), it is understood that a validated FIPS 140-3 cryptographic module (Level 1) may retain its validity when operating in an environment where it has not been explicitly validated (for FIPS 140-3).

The Implementation Guidance for FIPS 140-3 (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf) covers this case under section G.5. This covers the "porting" rules that a vendor (Riverbed in the case of the RCSM) or a user, for example, an administrator for a Virtual Traffic Manager installation, should conform to in order to retain FIPS 140-3 validity on a platform that has not been explicitly listed as validated. Note that NIST (specifically CVMP) remains the overall arbitrator of whether a FIPS 140-3 cryptographic module is and is not considered valid.

ATTENTION If you are concerned about whether or not the Virtual Traffic Manager will retain the FIPS 140-3 validity of the RCSM in your installation, please contact your support provider.

The RCSM has only been tested for validation on versions of the Linux Operating System. Support and validation for non-Linux systems is not available.

Providing you have followed the preceding instructions for preparing your Virtual Traffic Manager deployment, you can enable FIPS Mode by accessing the System > Global Settings page of the Admin UI and setting the fips!enabled configuration key to “Yes”.

Setting the fips!enabled key in your configuration is not sufficient to have the Virtual Traffic Manager operate fully in FIPS Mode; a restart of each Virtual Traffic Manager instance in the cluster is required.

ATTENTION Restarting the Virtual Traffic Manager disconnects any active connections. For high availability deployments, Ivanti recommends that you schedule this operation to minimize the interruption to your services. For further information, see the Virtual Traffic Manager: Installation and Getting Started Guide applicable to your product variant.

When using the Admin UI or SOAP-based Control API after enabling FIPS Mode, the Virtual Traffic Manager will perform a validation of your configuration to ensure various criteria for FIPS Mode.

Any aspect of the configuration that is in conflict with FIPS Mode will generate an error. If you see such an error, please refer to the Preparation section above with respect to the error you observe.

When operating in FIPS Mode, each Virtual Traffic Manager in a cluster will report whether it is successfully operating in FIPS Mode in the event log. A message such as the following can be seen:

If there is an error when trying to enable FIPS Mode, the Virtual Traffic Manager will report this in the event log. In the Virtual Traffic Manager component where FIPS Mode failed, cryptographic operations (and services that utilize those operations) will be disabled within that component.

As an example, consider a Virtual Traffic Manager with two HTTP virtual servers, one with SSL decryption and one without. If FIPS Mode fails to successfully initialize, the SSL decrypting virtual server will be disabled and no traffic will be processed, the other virtual server will operate normally.

ATTENTION Even if a Virtual Traffic Manager is successfully started with FIPS Mode in operation, it is possible, although rare, that during operation the requirements for FIPS 140-3 will cease to be met. In these cases, the same behavior as encountered during an initialization failure can be expected: the failing Virtual Traffic Manager will report an error, and cryptographic operations will no longer be available where FIPS Mode has failed.