Currently, the SSH EP does not support TOEs that only implement the "@openssh.com" variant of GCM.

FCS_SSHC_EXT.1.3 is modified as follows (using underlines to indicate additions):

FCS_SSHC_EXT.1.3 The SSH software 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, aes128- gcm@openssh.com, aes256-gcm@openssh.com, 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.

RFC 5647 only applies to the RFC compliant implementation of GCM. A TOE that only implements the “@openssh.com” variant of GCM should not select 5647-compliant algorithms in FCS_SSHC_EXT.1.1. aes*-gcm@openssh.com is specified in Section 1.6 of the OpenSSH Protocol Specification (https://cvsweb.openbsd.org/cgi-  bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.31).

FCS_SSHC_EXT.1.5 is modified as follows (using underlines to indicate additions):

FCS_SSHC_EXT.1.5  The SSH client 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, implicit, no other MAC algorithms] as its 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.
The SFRs for cryptographic operations, encryption and hashing, are inherited from the base PP.

The ST author selects “implicit” when, and only when, aes*-gcm@openssh.com is selected as an encryption algorithm. When aes*-gcm@openssh.com is negotiated as the encryption algorithm, the MAC algorithm field is ignored and GCM is implicitly used as the MAC. “implicit” is not an SSH algorithm identifier and will not be seen on the wire; however, the negotiated MAC might be decoded as “implicit”.

Assurance Activity

The evaluator will check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. The evaluator will 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 1: The evaluator will establish a SSH connection using each of the integrity algorithms, except "implicit", 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 will configure an SSH server to only allow the “none” MAC algorithm. The evaluator will attempt to connect from the TOE to the SSH server and observe that the attempt fails.

Note: To ensure the proposed MAC algorithm is used, the evaluator shall ensure a non-aes*- gcm@openssh.com encryption algorithm is negotiated while performing this test.

• Test 3: The evaluator will configure an SSH server to only allow the hmac- md5 MAC algorithm. The evaluator will attempt to connect from the TOE to the SSH server and observe that the attempt fails.

FCS_SSHS_EXT.1.3 is modified as follows (using underlines to indicate additions):

FCS_SSHS_EXT.1.3 The SSH server 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, aes128- gcm@openssh.com, aes256-gcm@openssh.com, 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.

RFC 5647 only applies to the RFC compliant implementation of GCM. A TOE that only implements the “@openssh.com” variant of GCM should not select 5647-compliant algorithms in FCS_SSHS_EXT.1.1. aes*-gcm@openssh.com is specified in Section 1.6 of the OpenSSH Protocol Specification (https://cvsweb.openbsd.org/cgi-  bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.31).

FCS_SSHS_EXT.1.5 is modified as follows (using underlines to indicate additions):

FCS_SSHS_EXT.1.5  The SSH server 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, implicit, no other MAC algorithms] as its 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.
The SFRs for cryptographic operations, encryption and hashing, are inherited from the base PP.

The ST author selects “implicit” when, and only when, aes*-gcm@openssh.com is selected as an encryption algorithm. When aes*-gcm@openssh.com is negotiated as the encryption algorithm, the MAC algorithm field is ignored and GCM is implicitly used as the MAC. “implicit” is not an SSH algorithm identifier and will not be seen on the wire; however, the negotiated MAC might be decoded as “implicit”.

Assurance Activity

The evaluator will check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. The evaluator will 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 1: Using an appropriately configured client, the evaluator will establish a SSH connection using each of the integrity algorithms, except "implicit", 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 will configure an SSH client to only allow the “none” MAC algorithm. Using this client, the evaluator will attempt to connect to the TOE and observe that the attempt fails.

Note: To ensure the proposed MAC algorithm is used, the evaluator shall ensure a non-aes*- gcm@openssh.com encryption algorithm is negotiated while performing this test.

• Test 3: The evaluator will configure an SSH client to only allow the hmac- md5 MAC algorithm. using this client, the evaluator will attempt to connect to the TOE and observe that the attempt fails

The key exchange defined for AES GCM defined in Section 5.1 of RFC 5467 is ambiguous regarding how the encryption and MAC algorithm should be negotiated. To resolve this ambiguity, a de facto standard has emerged whereby if AES GCM is negotiated as the encryption algorithm by use of aes*- gcm@openssh.com, the MAC field is ignored. (https://cvsweb.openbsd.org/cgi- bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.31 section 1.6). The necessary modifications are specified in TD0337 for the NDcPP.