TD0732: FCS_SSHS_EXT.1.3 Test 2 Update
Publication Date
2023.05.19
Protection Profiles
PKG_SSH_V1.0
Other References
FCS_SSH_EXT.1.3
Issue Description
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.
Resolution
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 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. Justification
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. |