Specifications

Security Target Version 1.0 9/29/2014
70
The supporting cryptographic functions are included to support the HTTPS/TLS (RFCs 2818 TLS 1.0 (RFC 2246),
TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246), SSHv2 (RFCs 4251, 4252, 4253, and 4254), and IPsec (RFC 4303)
secure communication protocol.
The following cipher suites are implemented by the TOE:
• TLS_RSA_WITH_AES_128_CBC_SHA,
• TLS_RSA_WITH_AES_256_CBC_SHA,
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA;
• TLS_RSA_WITH_AES_128_CBC_SHA256,
• TLS_RSA_WITH_AES_256_CBC_ SHA256,
• TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256,
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
The TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1 or HMAC-
SHA-1-96, and RSA (with diffie-hellman-group14-sha1 for the key exchange method). In the FIPS mode of
operation, the cipher parameters have been hardcoded to use only the Common Criteria evaluated configuration and
are not configurable by the administrator.
SSHv2 connections are rekeyed prior to reaching 2
28
packets; the authentication timeout period is 30 seconds
allowing clients to retry only 3 times, password based authentication can be configured; and packets are limited to
32,768 bytes. Note that the TOE manages a packet counter for each SSH session so that it can initiate a new key
exchange when the 2
28
packet limit is reached. Whenever the timeout period or authentication retry limit is reached,
the TOE closes the applicable TCP connection and releases the SSH session resources. As SSH packets are being
received, the TOE uses a buffer to build all packet information. Once complete, the packet is checked to ensure it
can be appropriately decrypted. However, if it is not complete when the buffer becomes full (32,768 bytes) the
packet will be dropped.
The TOE includes an implementation of IPsec in accordance with RFC 4303 for security. The primary
cryptographic algorithms used by the TOE include AES-CBC-128 and AES-CBC-256 (as specified by RFC 3602)
and AES-GCM-128 and AES-GCM-256 (as specified by RFC 4106) along with IKEv1 as defined in RFCs 2407,
2408, 2409, and RFC 4109 and IKE2 as defined in RFCs 5996 and 4307. Note that the TOE supports both main and
aggressive modes, though aggressive mode is disabled in CC/FIPS mode as indicated above. Furthermore,
"confidentiality only" ESP mode is disabled by default.
IKEv1 and IKEv2 SA lifetime and volume limits can be configured via a CLI function by an authorized
administrator and, in the case of IKEv1, can be limited to 24 hours for phase 1 and 8 hours for phase 2 and also to as
little as 2.5 MB of traffic for phase 2. The IKEv1 and IKEv2 protocols implemented by the TOE include DH Groups
2 (1024-bit MODP), 14 (2048-bit MODP), 19 (256-bit ECC), and 20 (384-bit ECC) and utilize RSA (aka rDSA) or
ECDSA peer authentication. In the IKEv1 phase 1 and phase 2 and IKEv2 IKE_SA and IKE_CHILD exchanges, the
TOE and peer will agree on the best DH group both can support. When the TOE initiates IKE negotiation, the DH
group is sent in order according to the peer’s configuration. When the TOE receives an IKE proposal, it will select
the first match and the negotiation will fail if there is no match. The TOE does not execute any checks to ensure the
strength of the negotiated symmetric algorithm in the IKEv1Phase 2SA or IKEv2 CHILD_SA is less than or equal
of the strength of the IKEv1 Phase 1 SA or IKEv2 IKE_SA. As such, it is the responsibility of the Administrator to
properly configure quick mode 1+2 for algorithms.
Additionally, pre-shared keys used for IPsec can be constructed of essentially any alphabetic character (upper and
lower case), numerals, and special characters (e.g., “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”) and can be
anywhere from 1 to 64 bytesin length (e.g., 22 characters). The TOE requires suitable keys to be entered by an
authorized administrator using a Web GUI or CLI function.
The Cryptographic support function is designed to satisfy the following security functional requirements: