NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0631:  NIT Technical Decision for Clarification of public key authentication for SSH Server

Publication Date
2022.03.21

Protection Profiles
CPP_ND_V2.2E

Other References
ND SDv2.2, FCS_SSHS_EXT.1, FMT_SMF.1

Issue Description

The NIT has issued a Technical Decision for clarification of public key authentication for SSH Server.

Resolution

NDcPP v2.2e, FCS_SSHS_EXT.1 shall be modified as follows:

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

Application Note 98

The intent of this element is to specify user authentication mechanism(s) that the TOE acting as an SSH server accepts from connecting SSH clients. The TOE is required to implement the capability to validate presented authentication keys. When SSH Server is used as part of FTP_TRP.1/Admin, it is expected the TOE is capable of verifying each presented key against a database of trusted user identities as specified by FMT_SMF.1. While no specific public key algorithms are mandatory to support, the use of public key algorithms must be consistent with signature verification as specified in FCS_COP.1/SigGen.

If the TOE implements password-based authentication, the option ‘password-based’ must be selected. If the TOE can only authenticate itself with a public key, the option ‘no other method’ must be chosen.

FCS_SSHS_EXT.1.5 Application Note 101 shall be prepended with:

Application Note 101

The intent of this element is to specify public-key server authentication mechanism(s) that the TOE implements. The TOE is required to implement the capability to generate its own host authentication key(s) in accordance with FCS_CKM.1 as specified by FMT_SMF.1 via “Ability to manage the cryptographic keys”.

The TOE is required to implement the capability to verify the host’s public key as described in RFC 4251 Section 4.1.

If x509v3-ssh-rsa…

ND SD v2.2, FCS_SSHS_EXT.1.2 TSS shall be modified as follows:

The evaluator shall check to ensure that the TSS contains a list of supported public key algorithms that are accepted for client authentication and that this list is consistent with signature verification algorithms selected in FCS_COP.1/SigGen (e.g., accepting EC keys requires corresponding Elliptic Curve Digital Signature algorithm claims).

The evaluator shall confirm that the TSS includes the description of how the TOE establishes a user identity when an SSH client presents a public key or X.509v3 certificate. For example, the TOE could verify that the SSH client’s presented public key matches one that is stored within the SSH server’s authorized_keys file.

If password-based authentication method has been selected in the FCS_SSHS_EXT.1.2, then the evaluator shall confirm its role in the authentication process is described in the TSS.

ND SD v2.2, FCS_SSHS_EXT.1.2 Tests shall be modified as follows:

Test objective: The purpose of these tests is to verify server supports each claimed client authentication method.

Test 1: For each supported client public-key authentication algorithm, the evaluator shall configure a remote client to present a public key corresponding to that authentication method (e.g., 2048-bit RSA key when using ssh-rsa public key). The evaluator shall establish sufficient separate SSH connections with an appropriately configured remote non-TOE SSH client to demonstrate the use of all applicable public key algorithms. It is sufficient to observe the successful completion of the SSH Authentication Protocol to satisfy the intent of this test.

Test 2: The evaluator shall choose one client public key authentication algorithm supported by the TOE. The evaluator shall generate a new client key pair for that supported algorithm without configuring the TOE to recognize the associated public key for authentication. The evaluator shall use an SSH client to attempt to connect to the TOE with the new key pair and demonstrate that authentication fails.

Test 3: [Conditional] If password-based authentication method has been selected in the FCS_SSHS_EXT.1.2, the evaluator shall configure the TOE to accept password-based authentication and demonstrate that user authentication succeeds when the correct password is provided by the connecting SSH client.

Test 4: [Conditional] If password-based authentication method has been selected in the FCS_SSHS_EXT.1.2, the evaluator shall configure the TOE to accept password-based authentication and demonstrate that user authentication fails when the incorrect password is provided by the connecting SSH client.

ND SD v2.2, FCS_SSHS_EXT.1.5 TSS shall be modified as follows:

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the SSH server’s host public key algorithms supported are specified and that they are identical to those listed for this component.

ND SD v2.2, FCS_SSHS_EXT.1.5 Test shall be modified as follows:

Test objective: This test case is meant to validate that the TOE server will support host public keys of the claimed algorithm types.

Test 1: The evaluator shall configure (only if required by the TOE) the TOE to use each of the claimed host public key algorithms. The evaluator will then use an SSH client to confirm that the client can authenticate the TOE server public key using the claimed algorithm. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

Has effectively been moved to FCS_SSHS_EXT.1.2.

Test objective: This negative test case is meant to validate that the TOE server does not support host public key algorithms that are not claimed.

Test 2: The evaluator shall configure a non-TOE SSH client to only allow it to authenticate an SSH server host public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the non-TOE SSH client to the TOE SSH server and observe that the connection is rejected.

NDcPP v2.2e, FMT_SMF.1 ‘Specification of Management Functions’ shall be appended as follows:

FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:

     …

     [selection:

               …

                     o Ability to manage the trusted public keys database;

                     o No other capabilities].

Application Note 24

If the TOE offers ability for a remote authorized IT entities or authorized remote Administrators to connect via an interface secured with SSH, then the ST author must select the option “Ability to manage the trusted public keys database” to account for management of public key authentication. It is acceptable for this management function to be implemented as part of general TOE user management functionality or as a standalone management function.

For further information, please see NIT Interpretation at:  https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/NITDecisionRFI202113A.pdf

Justification

See Issue Description.

 
 
Site Map              Contact Us              Home