TD0694's modifications to FCS_SSH_EXT.1.3 test 2 do not account for every way the packet_length field can be viewed. Additionally, audit requirements are inconsistent in the PP.

TD0694 is archived and replaced with the following:

PKG_SSH_V1.0, FCS_SSH_EXT.1.3, Test 2, steps b and c are updated as follows, with underlines denoting additions and strikethroughs denoting deletions:

b. Next the evaluator shall craft a packet that is one byte slightly larger than the maximum size specified in this component and send it through the established SSH connection to the TOE. The packet should not be greater than the maximum packet size + 16 bytes. If the packet is larger, the evaluator shall justify the need to send a larger packet.

c. The Eevaluator shall verify that the packet was dropped by the TOE. The method of verification will vary by the TOE. Examples_include by reviewing the TOE audit log for a dropped packet audit or observing the TOE terminates the connection.

OpenSSH examines the packet_length field to determine whether the packet is a large packet or not. This differs slightly from RFC 4253 in that this length does not include the MAC or the packet_length field itself; however, TSS is allowed to define how “large packets” are detected.

When using a CBC or CTR cipher with a non-ETM MAC algorithm, the 4 byte packet_length field must be encrypted; however, it is not counted in the packet_length value. The encrypted data must be a multiple of the block size, so packet_length is always 16 * X - 4 (i.e., never a multiple of 8).

Also, when multiple MACs are supported, the total packet length is variable (e.g., HMAC-SHA-512 would create a total packet length 32 bytes longer than HMAC-SHA-256 for packets with identical packet_lengths).

Test 2c requires the TOE to audit a dropped packet; however, this is inconsistent with Section 3.1 that does not specify any required auditable events.