7.1 Test Bed #1
7.1.4 Component Configuration Diagram – TESTBED #1
The following identifies each of the testbed devices including installed software if applicable:
CMS4400: N/A
EX3400: N/A
FX5400: N/A
NX7400: N/A
NX7500: N/A
NX2400: N/A
Management Workstation:
o 10.14.52.71: Large Putty, Firefox, Techtia OpenSSH, Wireshark o 10.2.4.75: Large Putty, Firefox, Techtia OpenSSH, Wireshark o 10.2.6.220: Large Putty, Firefox, Techtia OpenSSH, Wireshark o 10.2.4.198: Large Putty, Firefox, Techtia OpenSSH, Wireshark
AAA Server: OpenLDAP
Audit Server: SyslogD
Time Server: OpenNTP
Port Mirroring PC: Wireshark 7.2 Test bed #2
7.2.1 Physical Component Overview – TESTBED #2
Each of the devices and connections shown in the figure below are a physical connection. The following components were used in the testing of the TOE.
CMS4400
EX3400
FX5400
NX7400
NX7500
NX2400
Management Workstation
AAA Server
Audit Server
Time Server
Port Mirroring PC
7.2.2 Testbed Diagram – TESTBED #2
The following is a visual representation of the Testbed used to test the TOE:
7.2.3 Testbed Addressing – TESTBED #2
The following identifies the network addresses for the testbed components:
CMS4400: 12.12.12.5
EX3400: 12.12.12.6
FX5400: 12.12.12.7
NX7400: 12.12.12.8
Management Workstation: 12.12.12.9, 12.12.12.13, 12.12.12.17
AAA Server: 12.12.12.10
Audit Server: 12.12.12.11
Time Server: 12.12.12.12
Port Mirroring PC: N/A
7.2.4 Component Configuration Diagram – TESTBED #2
The following identifies each of the testbed devices including installed software if applicable:
CMS4400: N/A
EX5400: N/A
FX3400: N/A
NX7400: N/A
Management Workstation: Large Putty, Firefox, Techtia OpenSSH, OpenSSL, Wireshark
AAA Server: OpenLDAP
Audit Server: SyslogD
Time Server: OpenNTP
Port Mirroring PC: Wireshark
8 Audit Testing Summary
8.1.1 FAU_GEN.1 Test 1
Item Data/Description
Test ID FAU_GEN.1 Test 1
Objective The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in table 1 and administrative actions. This should include all instances of an event--for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be
generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST.
If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session.
For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.
Test Flow
(generic test steps)
1. Trigger each auditable event on the TOE.
2. Verify that each audit record is generated and contains the required information.
Results Each audit event was successfully generated by the TOE.
8.1.2 FAU_STG_EXT.1 Test 1 (not audit server)
Item Data/Description
Test ID FAU_STG_EXT.1 Test 1 (not audit server)
Objective The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.
Test Flow
(generic test steps)
1. Securely connect to the audit server via TLS.
2. Send audit data to the audit server from the TOE:
a. Triggered by performing nominal configuration changes.
3. Examine traffic to ensure it is encrypted within a TLS session and not plaintext.
Results TOE successfully communicated with the audit server over a TLS session.
8.2 Cryptographic Support Testing Summary 8.2.1 FCS_CKM.1.1 Test 1
The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above, depending on the selection performed by the ST author.
Evaluator Findings
The cryptographic module employed by the TOE has been through the key generation portion of the RSA2VS.
There have been no source code modifications to the cryptographic module.
8.2.1.1 CAVP Algorithm Certificate # Certificate # 1759
8.2.1.2 Verdict Pass
8.2.2 FCS_COP.1.1 (1) Test 1
The evaluator shall use tests appropriate to the modes selected in the above requirement from
"The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES
Validation system (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining Message Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" as a guide in testing the requirement above.
8.2.2.1 Evaluator Findings
The tester verified that multiple modes of operation were tested via the AESAVS.
8.2.2.2 CAVP Algorithm Certificate # Certificate # 3447
8.2.2.3 Verdict Pass
8.2.3 FCS_COP.1.1 (2) Test 1
The evaluator shall use the signature generation and signature verification portions of "The Digital Signature Algorithm Validation System” (DSAVS or DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System” (ECDSAVS or ECDSA2VS), and "The RSA Validation
System” (RSAVS) as a guide in testing the requirement above. The Validation System used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB 186-2 or FIPS PUB 186-3).
Evaluator Findings
The tester confirmed that the module was tested against both the signature generation and verification portions of the RSA2AVS and ECDSA2VS.
8.2.3.1 CAVP Algorithm Certificate # Certificate # RSA 1759, 1758; ECDSA: 696 8.2.3.2 Verdict
Pass
8.2.4 FCS_COP.1.1 (3) Test 1
The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the requirement above.
Evaluator Findings
The evaluator found that the module’s SHS implementation was tested against the SHAVS and that the testing encompassed what was found in the ST.
CAVP Algorithm Certificate # Certificate #2837, 2836
8.2.4.1 Verdict Pass
8.2.5 FCS_COP.1.1 (4) Test 1
The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)" as a guide in testing the requirement above.
Evaluator Findings
The evaluator found that the module’s HMAC implementation was tested against the HMACVS and that the testing encompassed what was found in the ST.
8.2.5.1 CAVP Algorithm Certificate # Certificate #2195
8.2.5.2 Verdict Pass
8.2.6 FCS_RBG_EXT.1.1 Test 1
Documentation shall be produced—and the evaluator shall perform the activities—in accordance with Annex D, Entropy Documentation and Assessment.
Evaluator Findings
See separately submitted Entropy Assessment Report (EAR) for details.
Verdict Pass
8.2.7 FCS_RBG_EXT.1.1 Test 2 (SP 800-90A DRBG) The evaluator shall perform 15 trials for the RBG implementation.
If the RBG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate.
If the RBG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate.
Evaluator Findings
The evaluator found that the module’s DRBG implementation was tested against the DRBGVS and that the testing encompassed what was found in the ST. This is equivalent to the testing described above.
8.2.7.1 CAVP Algorithm Certificate # Certificate #843
8.2.7.2 Verdict Pass
8.3 Identification and Authentication Testing Summary 8.3.1 FIA_PMG_EXT.1 Test 1
Item Data/Description
Test ID FIA_PMG_EXT.1 Test 1
Objective The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.
Test Flow
(generic test steps)
1. Select subsets of passwords to attempt to configure.
a. Subset should include maximum length b. Subset should include minimum length
c. Subset should include various passwords of allowable length
d. Subset should include less than minimum length (bad)
e. Subset should include more than maximum length (bad)
f. Each password should use various combinations of UPPERCASE, lowercase, numbers, and special characters
2. Attempt to create users with each of the good passwords.
Each should be possible.
3. Attempt to create users with each of the bad passwords.
Each should be denied
Results For each allowable password combination, the TOE allowed the password to be created. For each non-allowable password combination, the TOE rejected the password.
8.3.2 FIA_UIA_EXT.1 Test #1
Item Data/Description
Test ID FIA_UIA_EXT.1 Test #1
Objective The evaluator shall use the operational guidance to configure the appropriate credential supported for the login method. For that credential/login method, the evaluator shall show that providing correct I&A information results in the ability access the system, while providing incorrect information results in denial of access.
Test Flow
(generic test steps)
1. Configure the TOE as described in the user guide a. (including configuring a user).
2. Log into the TOE from each of the available interfaces, including, a. Local CLI
b. Remote CLI c. Remote GUI
3. Attempt to log into the TOE from each available interface using incorrect credentials.
Results For each login attempt created with allowed credentials, the TOE granted access. For each login attempt with bad credentials, the TOE rejected access. This was performed both over SSH, HTTPS, and at the local console.
8.3.3 FIA_UIA_EXT.1 Test #2
Item Data/Description
Test ID FIA_UIA_EXT.1 Test #2
Objective The evaluator shall configure the services allowed (if any) according to the operational guidance, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement.
Test Flow
(generic test steps)
1. If the TOE allows any services before login, configure the services.
In this case, the TOE does NOT allow any actions before authentication
2. Attempt to access other services prior to login at each interface.
Results The TOE prevented any service prior to authentication. There were no hidden services available.
8.3.4 FIA_UIA_EXT.1 Test #3
Item Data/Description
Test ID FIA_UIA_EXT.1 Test #3
Objective For local access, the evaluator shall determine what services are available to a local administrator prior to logging in, and make sure this list is consistent with the requirement.
Test Flow
(generic test steps)
1. If the TOE allows any services to the local user before login, configure the services.
• In this case, the TOE does NOT allow any actions before authentication
2. Attempt to gain access to other local services prior to login.
Results The TOE prevented any service prior to authentication. There were no hidden services available.
8.3.5 FIA_UAU.7 Test #1
Item Data/Description
Test ID FIA_UAU.7 Test #1
Objective The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information.
Test Flow
(generic test steps)
1. Attempt login at the local console with incorrect credentials.
2. Successfully login into the TOE at the local console.
3. Verify that in each case, no feedback was provided
Results The TOE provided NO feedback during the authentication process either at the local prompt or the remote prompt.
8.4 Protection of the TSF Testing Summary 8.4.1 FPT_STM.1 Test #1
Item Data/Description
Test ID FPT_STM.1 Test #1
Objective The evaluator uses the operational guide to set the time. The evaluator shall then use an available interface to observe that the time was set correctly.
Test Flow 1. Set the time of the TOE.
(generic test steps) 2. Verify the time on the TOE was updated.
Results The tester was able to successfully change the configured local time on the TOE.
8.4.2 FPT_STM.1 Test #2
Item Data/Description
Test ID FPT_STM.1 Test #2
Objective If the TOE supports the use of an NTP server; the evaluator shall use the operational guidance to configure the NTP client on the TOE, and set up a communication path with the NTP server. The
evaluator will observe that the NTP server has set the time to what is expected.
Test Flow
(generic test steps)
1. Configure the NTP services on the TOE (using user guide).
2. Use a TOE service that leverages the remote NTP.
a. The easiest is logging of an administrative action.
Results The tester was able to configure the TOE to use a time server. The TOE also successfully used the time server time.
8.4.3 FPT_TUD_EXT.1 Test #1
Item Data/Description
Test ID FPT_TUD_EXT.1 Test #1
Objective The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains a
legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE.
Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update.
Test Flow
(generic test steps)
1. Confirm the version of the TOE software through an administrative interface.
2. Perform a software update as described in the User Guidance.
3. Confirm the new version of TOE software through an administrative interface (similar to what was done previously).
4. Re-perform several of the previously performed assurance activities.
Results The TOE software was able to be updated.
8.4.4 FPT_TUD_EXT.1 Test #2
Item Data/Description
Test ID FPT_TUD_EXT.1 Test #2
Objective The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or
produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE rejects the update.
Test Flow
(generic test steps)
1. Confirm the version of the TOE software through an administrative interface.
Note: this must be the evaluated version of the TOE 2. Corrupt a software update for the TOE using a hex editor.
3. Attempt to update the TOE software using the corrupted image (this should fail).
Results The TOE was able to detect the bad software update and reject the update.
8.5 TOE Access Testing Summary 8.5.1 FTA_SSL_EXT.1 Test #1
Item Data/Description
Test ID FTA_SSL_EXT.1 Test #1
Objective The evaluator follows the operational guidance to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the
evaluator then ensures that re-authentication is needed when trying to unlock the session.
Test Flow
(generic test steps)
1. Configure a local time out period on administrative sessions.
2. Log onto the local administrative interface and let it set idle for the configured time period.
3. Verify that the session was terminated.
4. Repeat with different values for the time out period.
Results The TOE enforced the configured inactivity timeout period for each configured time.
8.5.2 FTA_SSL.3 Test #1
Item Data/Description
Test ID FTA_SSL.3 Test #1
Objective The evaluator follows the operational guidance to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a
remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period.
Test Flow
(generic test steps)
1. Configure a remote time out period on administrative sessions.
2. Log onto the remote administrative interface (SSH CLI, HTTPS) and let it set idle for the configured time period.
3. Verify that the session was terminated.
4. Repeat with different values for the time out period.
Results The TOE enforced the configured inactivity timeout period for each configured time.
8.5.3 FTA_SSL.4 Test #1
Item Data/Description
Test ID FTA_SSL.4 Test #1
Objective The evaluator initiates an interactive local session with the TOE. The evaluator then follows the operational guidance to exit or log off the session and observes that the session has been terminated.
Test Flow
(generic test steps)
1. Log onto the TOE through a local administrative interface (CLI).
2. Using the instructions provided by the user guide log off.
Results The tester was able to successfully login to the TOE and then log out of the TOE at the local interface.
8.5.4 FTA_SSL.4 Test #2
Item Data/Description
Test ID FTA_SSL.4 Test #2
Objective The evaluator initiates an interactive remote session with the TOE.
The evaluator then follows the operational guidance to exit or log off the session and observes that the session has been terminated Test Flow
(generic test steps)
1. Log onto the TOE through a remote administrative interface (SSH CLI, HTTPS).
2. Using the instructions provided by the user guide log off.
Results The tester was able to successfully login to the TOE and then log out of the TOE over SSH/HTTPS.
8.5.5 FTA_TAB.1 Test #1
Item Data/Description
Test ID FTA_TAB.1 Test #1
Objective The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent
warning message is displayed in each instance.
Test Flow
(generic test steps)
1. Configure the TOE to display a warning message using the procedures described in the user guide.
a. Note: there are different warning messages for local, HTTPS, and SSH access.
2. Start an administrative session at the local CLI.
3. Verify that the login banner was presented.
4. Start an administrative session at the remote SSH CLI.
5. Verify that the SSH banner was presented.
6. Start an administrative session at the remote HTTPS GUI 7. Verify that the HTTPS GUI banner was presented
Results The tester was able to configure multiple login banners dependent upon the interface being used.
8.6 Trusted Path/Channels Testing Summary 8.6.1 FTP_ITC.1 Test #1
Item Data/Description
Test ID FTP_ITC.1 Test #1
Objective The evaluators shall ensure that communications using each
protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the
operational guidance and ensuring that communication is successful.
For each protocol that the TOE can initiate as defined in the
requirement, the evaluator shall follow the operational guidance to ensure that in fact the communication channel can be initiated from the TOE.
The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext.
Test Flow
(generic test steps)
1. Configure the TOE to connect securely to an audit server via TLS.
2. Establish a connection to the audit server and send audit records (note this test is similar to the test in FAU_STG_EXT.1).
3. Repeat for each type of device supporting secure communication, including,
a. AAA server b. Audit server
Results The TOE was able to use secure communications for audit servers and AAA servers. All traffic for each communication is sent over the secure TLS channel.
8.6.2 FTP_ITC.1 Test #2
Item Data/Description
Test ID FTP_ITC.1 Test #2
Objective The evaluators shall, for each protocol associated with each
authorized IT entity tested during test 1, the connection is physically interrupted. The evaluator shall ensure that when physical
connectivity is restored, communications are appropriately protected
Test Flow
(generic test steps)
1. Securely connect the TOE to the audit server using TLS.
2. Disconnect the audit server from network (breaking the connection)
3. Reconnect the audit server to the network 4. Send more data to the audit server
5. Verify that when the connection was reestablished it was secure 4. Repeat for each type of device supporting secure
communication, including, a. AAA server
Results The TOE resumed TLS protected communications with each remote IT device after the tester restored network connectivity.
Results The TOE resumed TLS protected communications with each remote IT device after the tester restored network connectivity.