NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0574:  Update to FCS_SSH in ESM PPs

Publication Date
2021.01.29

Protection Profiles
PP_ESM_AC_V2.1, PP_ESM_ICM_V2.1, PP_ESM_PM_V2.1

Other References
FCS_SSH_EXT.1

Issue Description

The SFRs for SSH in the NIAP ESM PPs are outdated and do not describe current expectations with respect to these protocols.

Resolution

 

This TD is one of several to replace TD0541.

Section 5.3.5.1 and Appendix C.8.10 are replaced in ESM ICM and PM PPs, and Appendix C.5.10 is replaced in AC PP as follows.

FCS_SSH_EXT.1.1

The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254 and [selection: 4256, 4344, 5647, 5656, 6187, 6668, 8268, 8308, 8332, no other RFCs] as a [selection: client, server].

Application Note: The ST author selects which of the additional RFCs to which conformance is being claimed. An SSH product can implement additional RFCs, but only those listed in the selection can be claimed as conformant under common criteria. The RFC selections for this requirement need to be consistent with selections in other elements of this Protection Profile (e.g., cryptographic algorithms permitted). RFC 4253 indicates that certain cryptographic algorithms are "REQUIRED". This means that from the IETF's perspective the implementation must include support, not that the algorithms must be enabled for use. Ensuring that algorithms indicated as "REQUIRED" but not listed in later elements of this Protection Profile is out of scope for the assurance activity for this requirement.

The following mapping is provided as a guide to ST authors to ensure the appropriate RFC selections are made:

RFC 4256 – Select if keyboard-interactive authentication is available

RFC 4344 – Select if AES-128-CTR or AES-256-CTR modes are available

RFC 5647 – Select if AEAD_AES_128_GCM or AEAD_AES_256_GCM are available

RFC 5656 – Select if elliptical curve cryptography is available

RFC 6187 – Select if X.509 certificates are available for public key algorithms

RFC 6668 – Select if HMAC-SHA-2 algorithms are available

RFC 8268 – Select if FFC DH groups with SHA-2 are available

RFC 8308 Section 3.1 – Select if RFC 8332 is selected

RFC 8332 – Select if SHA-2 is available with ssh-rsa selection for public key algorithms

Assurance Activity

The evaluator will ensure that the selections indicated in the ST are consistent with selections in the dependent components.

Note for some Assurance Activities defined in the subsequent FCS_SSH_EXT elements, that the exact test configuration will depend on whether the TSF acts as an SSH client (and therefore proposes disallowed algorithms) or as an SSH server (and does not accept certain algorithms). The evaluator is expected to be able to configure the test environment appropriately and perform the testing based on the selection made in FCS_SSH_EXT.1.1.

 

FCS_SSH_EXT.1.2

The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, and [selection: password-based, no other method].

Assurance Activity

TSS

The evaluator will check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSH_EXT.1.5, and ensure that if password-based authentication methods have been selected in the ST then these are also described.

 

Guidance

If supported public-key authentication methods are configurable, the evaluator shall verify the guidance documentation includes instructions on configuring these. If the password-based authentication method can be enabled or disable via configuration setting, the evaluator shall verify this configuration is described in the guidance documentation.

Test

Test 1: The evaluator shall, for each public key algorithm supported, show that the TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities required to support this test shall be performed according to instructions in the guidance documentation.

Test 2: [Conditional on selection of ‘server’ in FCS_SSH_EXT.1.1] The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a new key pair for that algorithm without configuring the TOE to recognize/allow the public key for authentication. The evaluator shall attempt to establish a connection with the new key pair and demonstrate that authentication fails.

Test 3: [Conditional] Using the guidance documentation, the evaluator shall configure the TOE for password-based authentication and demonstrate successful authentication over SSH using a password as an authenticator. The evaluator shall then, re-attempt authentication entering an incorrect password, and demonstrate that the authentication fails.

FCS_SSH_EXT.1.3

The TSF shall ensure that, as described in RFC 4253, packets greater than [assignment: number of bytes] bytes in an SSH transport connection are dropped.

Application Note: RFC 4253 provides for the acceptance of “large packets” with the caveat that the packets should be of “reasonable length” or dropped. The assignment should be filled in by the ST author with the maximum packet size accepted, thus defining “reasonable length” for the TOE.

Assurance Activity

The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped.

FCS_SSH_EXT.1.4 

The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: aes128-ctr, aes256- ctr, [selection: aes128-cbc, aes256-cbc, AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other algorithms].

Application Note: RFC 5647 specifies the use of the AEAD_AES_128_GCM and AEAD_AES_256_GCM algorithms in SSH. As described in RFC 5647, AEAD_AES_128_GCM and AEAD_AES_256_GCM can only be chosen as encryption algorithms when the same algorithm is being used as the MAC algorithm. If AES-GCM is selected, there should be corresponding FCS_COP entries in the ST.

Assurance Activity

TSS

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component.

Guidance

The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements).

Test

Test 1: The evaluator shall establish an SSH connection using each of the encryption algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

Test 2: The evaluator shall run a test such that only the 3des-cbc encryption algorithm is configured and no other encryption algorithms. The evaluator shall attempt to establish an SSH connection and observe that the connection is rejected.

FCS_SSH_EXT.1.5

The TSF shall ensure that the SSH transport implementation uses [selection: ssh-rsa, ecdsa-sha2- nistp256] and [selection: ecdsa-sha2-nistp384, x509v3- ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp384, no other public key algorithms] as its public key algorithm(s) and rejects all other public key algorithms.

Application Note: Implementations that select only ssh-rsa will not achieve the 112-bit security strength in the digital signature generation for SSH authentication as is recommended in NIST SP 800-131A. Future versions of this document may remove ssh-rsa as a selection.

Assurance Activity

TSS

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component.

Guidance

The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements).

Test

Test 1: The evaluator shall establish an SSH connection using each of the public key algorithms specified by the requirement to authenticate. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

Test 2: The evaluator shall attempt to establish an SSH connection where only the ssh-dsa public key algorithm is configured and no other public key algorithms, and observe that the connection is rejected.

FCS_SSH_EXT.1.6

The TSF shall ensure that the SSH transport implementation uses [selection: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512] and [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other MAC algorithms] as its data integrity MAC algorithm(s) and rejects all other MAC algorithm(s).

Application Note: RFC 5647 specifies the use of the AEAD_AES_128_GCM and AEAD_AES_256_GCM algorithms in SSH. As described in RFC 5647, AEAD_AES_128_GCM and AEAD_AES_256_GCM can only be chosen as MAC algorithms when the same algorithm is being used as the encryption algorithm. RFC 6668 specifies the use of the sha2 algorithms in SSH.

Assurance Activity

TSS

The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component.

Guidance

The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed).

Test

Test 1: The evaluator shall establish a SSH connection using each of the integrity algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

Test 2: The evaluator shall attempt to establish an SSH connection, using the TSF, where only the “none” MAC algorithm is configured, and observe that the attempt fails.

Test 3: The evaluator shall attempt to establish an SSH connection, using the TSF, where only the hmac-md5 MAC algorithm is configured and observe that the attempt fails.

FCS_SSH_EXT.1.7

The TSF shall ensure that [selection: diffiehellman-group14-sha1, ecdh-sha2-nistp256] and [selection: diffie-hellman-group14-sha256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, no other methods] are the only allowed key exchange methods used for the SSH protocol.

Assurance Activity

TSS

The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component.

Guidance

If key exchange methods are configurable, the evaluator shall check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections to the TOE.

Test

Test 1: The evaluator shall configure an SSH connection to permit all allowed key exchange methods. The evaluator will attempt to establish an SSH connection with the TOE using each allowed key exchange method and observe that each attempt succeeds.

Test 2: The evaluator shall attempt to establish an SSH connection, using the TSF, where the SSH client only allows the diffiehellman-group1-sha1 key exchange and the SSH server is configured according to the algorithms allowed in the SFR. The evaluator shall observe that the attempt fails.

 

FCS_SSH_EXT.1.8

The TSF shall ensure that the SSH connection be rekeyed after [selection: no more than 2 ^28 packets have been transmitted, no more than 1 Gigabyte of data has been transmitted, no more than 1 hour] using that key.

Assurance Activity

 

TSS

The evaluator shall check the TSS to ensure that if the TOE enforces connection rekey or termination limits lower than the maximum values that these lower limits are identified.

In cases where hardware limitation will prevent reaching data transfer threshold in less than one hour, the evaluator shall check the TSS to ensure it contains:
 a. An argument describing this hardware-based limitation and
 b. Identification of the hardware components that form the basis of such argument. For example, if specific Ethernet Controller or Wi-Fi radio chip is the root cause of such limitation, these subsystems shall be identified.

 

Guidance

The evaluator shall check the guidance documentation to ensure that if the connection rekey or termination limits are configurable, it contains instructions to the administrator on how to configure the relevant connection rekey or termination limits for the TOE.

Test

The test harness needs to be configured so that its connection rekey or termination limits are greater than the limits supported by the TOE -- it is expected that the test harness should not be initiating the connection rekey or termination.

Test 1.  Establish an SSH connection.  Wait until the identified connection rekey limit is met.  Observed that a connection rekey or termination is initiated.  This may require traffic to periodically be sent, or connection keep alive to be set, to ensure that the connection is not closed due to an idle timeout.

 

Justification

Updating these SFRs brings them in line with current standards and adds stronger, more commonly used algorithms.

 
 
Site Map              Contact Us              Home