FIPS Mode

The primary feature associated with activating FIPS Mode is that it enables the use of a FIPS 140-3 Cryptographic Module when processing traffic. In general, the FIPS Mode feature in the Virtual Traffic Manager is to help an organization towards FIPS compliance.

Additionally, various configurations/operations of the Virtual Traffic Manager are restricted when FIPS Mode is configured, for two reasons:

1.To ensure inputs to the cryptographic module are within the validated range for FIPS 140-3.

2.To ensure that operations that are mutually exclusive with the requirements for FIPS 140-3 cannot be enabled. An example of a restricted operation is SSL 3.0 (only TLS 1.0 and onward are compatible with FIPS 140-3).

FIPS 140-3

FIPS 140-3 is the second revision of the FIPS 140 series publication, published by the National Institute of Standards and Technology (NIST). This is described in detail at the following location: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

This document describes the security requirements for cryptographic modules. There are 4 security levels to the FIPS 140-4 requirements, ranging from 1 - 4. It is generally understood that software-only security modules are only capable of achieving the lowest security level (1); higher security levels have requirements, such as tamper protection, that can only be achieved in a physical product. In general these requirements relate to processes involving cryptographic operations.

In addition, several other NIST "Special Publications" should be considered:

•"Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations" SP 800-52r1 (http://dx.doi.org/10.6028/NIST.SP.800-52r1)

•"Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths" SP 800-131A (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf):

•For considerations of what constitutes "key strength" SP 800-51 Part 1 (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf).

The Virtual Traffic Manager does not implement all recommendations made in this document.

FIPS 140-3 and the Virtual Traffic Manager

The FIPS 140-3 cryptographic module used in Linux variants of the Virtual Traffic Manager is the Riverbed® Cryptographic Security Module (RCSM) (certificate number 2099). Details about the FIPS 140-3 validity of this module can be found at the NIST CMVP page, at: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search#2099

When FIPS Mode is enabled, upon start-up of the Virtual Traffic Manager the RCSM will be loaded and initialized. Any failure during initialization (e.g. Power On Self Tests) will be reported as a fatal error - all cryptographic operations in the Virtual Traffic Manager FIPS boundary will be disabled (for example, SSL decrypting virtual servers and SSL encrypting pools).

The Virtual Traffic Manager FIPS boundary

The Virtual Traffic Manager uses cryptography in a number of features, the primary example being for SSL/TLS. However, not all of these cryptographic uses are included within the designated Virtual Traffic Manager FIPS boundary shown below:

This boundary is most simply defined as:

1.All the cryptographic operations performed for the processing of traffic.

2.All cryptographic interactions with cryptographic objects used when processing traffic.

When FIPS Mode is in operation:

Item (1) covers primarily TLS; all data that is processed by the Virtual Traffic Manager in terms of virtual servers and pools will use the FIPS 140-3 cryptographic module for all cryptography. This includes subordinate operations in TLS such as OCSP requests.

Item (2) considers the manipulation of cryptographic objects stored as part of a Virtual Traffic Manager configuration, the primary example being PKI certificates and private keys. Any cryptographic interaction with these objects will be performed with the FIPS 140-3 cryptographic module.

All "control-plane" cryptography is not included within the Virtual Traffic Manager FIPS boundary. To clarify, the following, non exhaustive, list of functionality is not within the Virtual Traffic Manager FIPS boundary:

•Virtual Traffic Manager SNMP interaction

•The Virtual Traffic Manager SOAP API

•The Virtual Traffic Manager REST API

•The Virtual Traffic Manager Admin UI

•SSH access to a Virtual Traffic Manager Appliance

The importance of (2) in the boundary is that in the case of, for example, the SOAP or Admin UI; although the cryptography used for the transport is not using a FIPS 140-3 cryptographic module, any operations requested that might manipulate cryptographic objects for use within the Virtual Traffic Manager FIPS boundary will be performed with a FIPS 140-3 cryptographic module.

When considering whether FIPS Mode is suitable for your deployment requirements, you should ensure that you consider whether the Virtual Traffic Manager FIPS boundary provides sufficient functional coverage.

TLS as an exception

As mentioned above, the general definition of the Virtual Traffic Manager FIPS boundary is that all cryptographic operations performed within that boundary are done using a FIPS 140-3 cryptographic module.

There is an exception to this, where MD5 is required as part of the TLS 1.0 handshake protocol. Without MD5, it would be impossible to inter-operate with TLS clients requiring only the latest version of TLS. This case is covered by a discussion in the "Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations" document referenced above, whereby this specific use of MD5 in these very specific parts of the TLS handshake protocol are deemed safe. Refer to this document for further technical details.

As such the Virtual Traffic Manager SSL implementation uses an MD5 algorithm from another cryptographic implementation for these specific cases alone, disregarding that MD5 is generally not available from a FIPS 140-3 cryptographic module.

Equally, there are other uses of the MD5 algorithm within the Virtual Traffic Manager FIPS boundary, however these have been identified as unrelated to cryptographic or security purposes (i.e. the MD5 algorithm is used as a hash function, rather than as a cryptographic digest).