assurance activity report (ndcpp10) for brocade ... · pdf file3.2 guidance documents (agd)...

Document: AAR-VID-10797 © 2017 Gossamer Security Solutions, Inc. All rights reserved.

www.GossamerSec.com

Assurance Activity Report

(NDcPP10) for Brocade Communications Systems, Inc.

Directors and Switches using Fabric OS v8.1.0

Version 0.3

06/22/2017

Prepared by: Gossamer Security Solutions

Accredited Security Testing Laboratory – Common Criteria Testing Catonsville, MD 21228

Prepared for: National Information Assurance Partnership

Common Criteria Evaluation and Validation Scheme

Version 0.3, 06/22/2017

GSS CCT Assurance Activity Report of 81 © 2017 Gossamer Security Solutions, Inc. Document: AAR-VID-10797 All rights reserved.

REVISION HISTORY

Revision Date Authors Summary

Version 0.1 04/20/2017 Haley Sykes

Initial draft

0.2 06/05/2017 Gossamer Updated to reflect validation comments

The TOE Evaluation was Sponsored by: Brocade Communications Systems, Inc. 130 Holger Way San Jose, CA 95134

Evaluation Personnel:

Cornelius Haley

Katie Sykes Common Criteria Versions:

Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September 2012

Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012

Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012

Common Evaluation Methodology Versions:

Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012

Version 0.3, 06/22/2017


TABLE OF CONTENTS

1 Introduction ........................................................................................................................................................... 6

1.1 Test Platform Equivalency ............................................................................................................................ 6

1.2 CAVP Certificate Justification ....................................................................................................................... 7

1.3 References.................................................................................................................................................... 8

2 Protection Profile SFR Assurance Activities ......................................................................................................... 10

2.1 Security audit (FAU) ................................................................................................................................... 10

2.1.1 Audit Data Generation (FAU_GEN.1) .................................................................................................... 10

2.1.2 User identity association (FAU_GEN.2) ................................................................................................. 17

2.1.3 Protected audit trail storage (FAU_STG.1) ............................................................................................ 17

2.1.4 Protected Audit Event Storage (FAU_STG_EXT.1) ................................................................................ 18

2.2 Cryptographic support (FCS) ...................................................................................................................... 21

2.2.1 Cryptographic Key Generation (FCS_CKM.1) ........................................................................................ 21

2.2.2 Cryptographic Key Establishment (FCS_CKM.2) ................................................................................... 22

2.2.3 Cryptographic Key Destruction (FCS_CKM.4) ....................................................................................... 23

2.2.4 Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(1)) ...................................... 24

2.2.5 Cryptographic Operation (Signature Generation and Verification) (FCS_COP.1(2)) ............................. 24

2.2.6 Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) ................................................................. 25

2.2.7 Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) ...................................................... 26

2.2.8 HTTPS Protocol (FCS_HTTPS_EXT.1) ..................................................................................................... 26

2.2.9 Random Bit Generation (FCS_RBG_EXT.1)............................................................................................ 28

2.2.10 SSH Server Protocol (FCS_SSHS_EXT.1) ............................................................................................ 29

2.2.11 TLS Client Protocol with authentication (FCS_TLSC_EXT.2).............................................................. 35

2.2.12 TLS Server Protocol (FCS_TLSS_EXT.1) ............................................................................................. 42

2.3 Identification and authentication (FIA) ...................................................................................................... 46

2.3.1 Password Management (FIA_PMG_EXT.1) ........................................................................................... 46

2.3.2 Protected Authentication Feedback (FIA_UAU.7) ................................................................................ 47

2.3.3 Password-based Authentication Mechanism (FIA_UAU_EXT.2) ........................................................... 47

2.3.4 User Identification and Authentication (FIA_UIA_EXT.1) ..................................................................... 48

Version 0.3, 06/22/2017


2.3.5 X.509 Certificate Validation (FIA_X509_EXT.1) ..................................................................................... 50

2.3.6 X.509 Certificate Authentication (FIA_X509_EXT.2) ............................................................................. 53

2.3.7 X.509 Certificate Requests (FIA_X509_EXT.3)....................................................................................... 54

2.4 Security management (FMT) ...................................................................................................................... 55

2.4.1 Management of security functions behavior - Trusted Update (FMT_MOF.1(1)) ................................ 55

2.4.2 Management of security functions behavior - Audit (FMT_MOF.1(3)) ................................................ 56

2.4.3 Management of security functions behavior - Audit (FMT_MOF.1(4)) ................................................ 57

2.4.4 Management of TSF Data (FMT_MTD.1(1)) .......................................................................................... 57

2.4.5 Management of TSF data - Admin Actions (FMT_MTD.1(2)) ................................................................ 58

2.4.6 Specification of Management Functions (FMT_SMF.1) ........................................................................ 59

2.4.7 Restrictions on Security Roles (FMT_SMR.2) ........................................................................................ 60

2.5 Protection of the TSF (FPT) ........................................................................................................................ 61

2.5.1 Protection of Administrator Passwords (FPT_APW_EXT.1) .................................................................. 61

2.5.2 Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) ...................................... 62

2.5.3 Reliable Time Stamps (FPT_STM.1)....................................................................................................... 62

2.5.4 TSF testing (FPT_TST_EXT.1) ................................................................................................................. 63

2.5.5 Trusted update (FPT_TUD_EXT.1) ......................................................................................................... 65

2.6 TOE access (FTA) ........................................................................................................................................ 69

2.6.1 TSF-initiated Termination (FTA_SSL.3) .................................................................................................. 69

2.6.2 User-initiated Termination (FTA_SSL.4) ................................................................................................ 69

2.6.3 TSF-initiated Session Locking (FTA_SSL_EXT.1) ..................................................................................... 70

2.6.4 Default TOE Access Banners (FTA_TAB.1) ............................................................................................. 71

2.7 Trusted path/channels (FTP) ...................................................................................................................... 71

2.7.1 Inter-TSF trusted channel (FTP_ITC.1) .................................................................................................. 71

2.7.2 Trusted Path (FTP_TRP.1) ..................................................................................................................... 73

3 Protection Profile SAR Assurance Activities ........................................................................................................ 76

3.1 Development (ADV) ................................................................................................................................... 76

3.1.1 Basic functional specification (ADV_FSP.1) ........................................................................................... 76

3.2 Guidance documents (AGD) ....................................................................................................................... 77

3.2.1 Operational user guidance (AGD_OPE.1).............................................................................................. 77

Version 0.3, 06/22/2017


3.2.2 Preparative procedures (AGD_PRE.1) ................................................................................................... 78

3.3 Life-cycle support (ALC) .............................................................................................................................. 79

3.3.1 Labelling of the TOE (ALC_CMC.1) ........................................................................................................ 79

3.3.2 TOE CM coverage (ALC_CMS.1) ............................................................................................................ 79

3.4 Security Target (ASE) .................................................................................................................................. 80

3.4.1 Security Target (ASE_TSS.1) .................................................................................................................. 80

3.5 Tests (ATE) .................................................................................................................................................. 80

3.5.1 Independent testing - conformance (ATE_IND.1) ................................................................................. 80

3.6 Vulnerability assessment (AVA) ................................................................................................................. 81

3.6.1 Vulnerability survey (AVA_VAN.1) ........................................................................................................ 81

Version 0.3, 06/22/2017


1 INTRODUCTION

This document presents evaluations results of the Brocade Fabric OS NDcPP10 evaluation. This document contains

a description of the assurance activities and associated results as performed by the evaluators.

1.1 TEST PLATFORM EQUIVALENCY

This section presents the test environment and explains why the test subset was adequate to address all product

installations.

The TOE was tested both at Brocade’s SQA facility in Denver Colorado, and at Gossamer’s test facility in Catonsville

Maryland. Initial testing was performed at Brocade, with follow up testing completed at Gossamer. Each Device

Under Test (DUT) was configured according to the step-by-step instructions in [CC-Guide].

Figure 1 Test Setup

TOE Platforms:

Brocade 620 SAN (T1022 processor)

Brocade 6520 SAN (MPC8548 processor)

The evaluators ran all SSHS and TLSS tests on both the G6520 and G620 DUT and observed identical results. The

remainder of the tests were executed primarily on the G620.

All models identified in the Security Target run the same FOS version 8.1.0b software and utilize the same features

in equivalent Power Architecture instruction sets. The evaluators loaded the same image onto the G620 and the

G6520 Brocade SAN devices. The same configuration instructions were used on both of the DUT. Since

Version 0.3, 06/22/2017


the same software is installed on all the platforms,

all security functions provided by the TOE are implemented in software,

all hardware platforms support an equivalent hardware architecture/instruction sets, and

the TOE operates only in 32-bit mode (even on 64-bit processors);

the evaluation team concluded, that testing of TOE software across two platforms was sufficient. The evaluator

perform every test on at least one platform, and sampled some tests on both platforms. The sampling was

performed to ensure that the assertion that platforms were equivalent was valid. TOE security behavior is the

same on all the switches for each of the SFRs defined by the NDcPP v1.0. These SFRs are instantiated by the same

version of the TOE software and in the same way on every platform.

1.2 CAVP CERTIFICATE JUSTIFICATION

The following table provides a mapping between the models and the processors. This mapping can be used to

reference the CAVP certificates referenced in the next table. All models run the same Brocade Fabric OS (FOS)

firmware, version 8.1.0b, which includes the Brocade FIPS crypto Library.

Table 1-1 Processor Mapping

Model Processor

DCX 8510-4 MPC8548

DCX 8510-8 MPC8548

Brocade 6510 PPC440EPX

Brocade 6520 MPC8548

Brocade 7840 P3041

X6-4 P4080

X6-8 P4080

Brocade G620 T1022

The following functions have been CAVP tested in accordance with the identified standards.

Table 1-2 TOE CAVP Certificates

Functions Requirement

Cert

MPC8548 PPC440EPX T1022 P4080 P3041

Encryption/Decryption

AES CBC (128 and

256 bits) FCS_COP.1(1) 4247 4246 4244 4243 4242

Cryptographic signature services

Version 0.3, 06/22/2017


Functions Requirement

Cert

MPC8548 PPC440EPX T1022 P4080 P3041

RSA Digital Signature

Algorithm (rDSA)

(modulus 2048)

FCS_COP.1(2) 2292 2291 2290 2289 2288

ECDSA Digital

Signature Algorithm

(P-256, P-384)

FCS_COP.1(2) 987 986 984 983 982

Cryptographic hashing

SHA-1/256/512

(digest sizes 160, 256,

and 512 bits)

FCS_COP.1(3) 3484 3483 3481 3480 3479

Keyed-hash message authentication

HMAC-SHA-1,

HMAC_SHA2-256,

HMAC-SHA2-512

(digest sizes 160, 256,

and 512 bits)

FCS_COP.1(4) 2785 2784 2782 2781 2780

Random bit generation

RNG with sw based

noise sources

FCS_RBG_EX

T.1

1326 1325 1323 1322 1321

Key Generation

RSA Key Generation FCS_CKM.1 2292 2291 2290 2289 2288

ECDSA Key

Generation FCS_CKM.1 987 986 984 983 982

DSA Key Generation FCS_CKM.1 1137 1136 1134 1133 1132

Key Establishment

ECC FFC CVL FCS_CKM.2 999 996 993 990 987

Key Derivation Functions

TLS and SSH 1000 997 994 991 988

1.3 REFERENCES

Version 0.3, 06/22/2017


The following documentation included material used to satisfy the Guidance assurance activities.

[ST] Brocade Communications Systems, Inc. Directors and Switches 8.1.0 using Fabric OS v8.1

(NDcPP10) Security Target, Version 0.3, 06/05/2017.

[CC-Guide] Configuration Guide Fabric OS Common Criteria Supporting Fabric OS 8.1.0b, June 7, 2017.

Other Documentation References:

[NDcPP10] collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015.

Version 0.3, 06/22/2017


2 PROTECTION PROFILE SFR ASSURANCE ACTIVITIES

This section of the AAR identifies each of the assurance activities included in the claimed Protection Profile and

describes the findings in each case.

2.1 SECURITY AUDIT (FAU)

2.1.1 AUDIT DATA GENERATION (FAU_GEN.1)

2.1.1.1 FAU_GEN.1.1

TSS Assurance Activities: None Defined

Guidance Assurance Activities: None Defined

Testing Assurance Activities: None Defined

2.1.1.2 FAU_GEN.1.2




Component TSS Assurance Activities: None Defined

Component Guidance Assurance Activities: The evaluator shall check the guidance documentation and ensure

that it lists all of the auditable events and provides a format for audit records. Each audit record format type must

be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit

event type mandated by the cPP is described and that the description of the fields contains the information

required in FAU_GEN1.2, and the additional information specified in the table of audit events.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of the

cPP. The evaluator shall examine the guidance documentation and make a determination of which administrative

commands, including subcommands, scripts, and configuration files, are related to the configuration (including

enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements

specified in the cPP. The evaluator shall document the methodology or approach taken while determining which

actions in the administrative guide are security relevant with respect to the cPP. The evaluator may perform this

Version 0.3, 06/22/2017


activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies

the requirements related to it.

The [CC-Guide] includes a chapter identifying audit messages generated by the TOE. This chapter does include all

audit events identified in [ST].

Table 2-1 shows the required audit events.

Table 2-1 Collected Audit Events

Requirement

Auditable Events Additional Content

FCS_HTTPS_EXT.1 Failure to establish an HTTPS session.

Reason for failure

HTTPS sessions will fail to be established either based upon login failures (see FIA_UAU_EXT.1 audits) or TLS errors (see FCS_TLSS_EXT.1 audits).

FCS_SSHS_EXT.1 Failure to establish an

SSH session

Reason for failure

The following audit message indicates that an SSH session failed to get established because of cipher mismatch. Similar messages are generated for the following: – Key exchange mismatch – Key algorithm mismatch – MAC mismatch – Host key mismatch 63 AUDIT, 2017/03/20-18:14:00 (UTC), [SEC-3076], INFO, SECURITY, NONE/NONE/NONE/None/CLI,

None/sw0/FID 128, , Event: SSH, Status: failed, Info: SSH Session establishment failed. Reason:

no matching cipher found, IP Addr: 10.70.12.112 FCS_TLSC_EXT.2 Failure to establish an TLS

Session Reason for failure

The following audit message indicates that a TLS handshake failed because of wrong version number for the TLS protocol. Similar messages are generated for the following: – Wrong ciphers – Wrong CA certificate – Server key length less than 2048 84 AUDIT, 2017/03/20-18:33:13 (UTC), [SEC-3077], INFO, SECURITY, root/root/NONE/console/CLI, ad_0/sw0/FID 128, , Event: TLS SESSION, TLS handshake failed, Info: Wrong Protocol version number.

FCS_TLSS_EXT.1 Failure to establish an TLS Session

Reason for failure

The following audit message indicates that a TLS handshake failed because of wrong version number for the TLS protocol. Similar messages are generated for the following: – Wrong ciphers – Wrong CA certificate – Server key length less than 2048 84 AUDIT, 2017/03/20-18:33:13 (UTC), [SEC-3077], INFO, SECURITY, root/root/NONE/console/CLI,

ad_0/sw0/FID 128, , Event: TLS SESSION, TLS handshake failed, Info: Wrong Protocol version

number.

Version 0.3, 06/22/2017


FIA_UIA_EXT.1 All use of the identification and authentication mechanism.

Provided user identity, origin of the attempt (e.g., IP address).

Failed CLI Login Bad Password Failed CLI Login Bad UserID The following audit message indicates that a login attempt failed at SSH (bad username). A similar message is generated for failures due to bad passwords. [SEC-3021], INFO, SECURITY, JBond007/admin/kali-2dot0.englab.brocade.com/ssh/CLI,

ad_0/pizzabox12/FID 3, , Event: login, Status: failed, Info: Failed login attempt via REMOTE, IP

Addr: kali-2dot0.englab.brocade.com.

Successful CLI Login The following audit message indicates that a login attempt with SSH succeeded. [SEC-3020], INFO, SECURITY, root/root/trapazoid.englab.brocade.com/ssh/CLI, ad_0/pizzabox12/FID

3, 8.1.0b_rc1_bld16, , , , , , , Event: login, Status: success, Info: Successful login attempt

via REMOTE, IP Addr: trapazoid.englab.brocade.com.

Failed Web UI Login Bad Password The following audit message indicates that a login attempt via Webtools failed (bad password). A similar message is generated for failures due to bad username. [SEC-3021], INFO, SECURITY, admin/admin/10.38.38.152/https/WebTools, ad_255/pizzabox12/FID 3, ,

Event: login, Status: failed, Info: Failed login attempt via HTTP, IP Addr: 10.38.38.152

Failed Web UI Login Bad UserID The following audit message indicates that a login attempt via Webtools failed (bad user). [SEC-3021], INFO, SECURITY, JBond007/admin/10.38.38.152/https/WebTools, ad_255/pizzabox12/FID 3,

,Event: login, Status: failed, Info: Failed login attempt via HTTP, IP Addr: 10.38.38.152. Successful Web UI Login The following audit message indicates a successful login attempt via Webtools. [SEC-3020], INFO, SECURITY, admin/admin/10.38.38.152/https/WebTools, ad_0/pizzabox12/FID 3, ,

Event: login, Status: success, Info: Successful login attempt via HTTP, IP Addr: 10.38.38.152.

FIA_UAU_EXT.2 All use of the identification and authentication mechanism.

Origin of the attempt (e.g., IP address).

See FIA_UIA_EXT.1 audits above

FIA_X509_EXT.1 Unsuccessful attempt to validate a certificate

Reason for failure

The following audit message indicates that certificate validation failed because the local issuer certificate was unavailable. Similar messages are generated for the following: – Key usage – Extended key usage – Self-signed certificates – Login with importing CA certificate – CN mismatch – Others NOTE OpenSSL errors are presented in the information section as-is.

Version 0.3, 06/22/2017


94 AUDIT, 2017/03/20-18:37:04 (UTC), [SEC-3081], INFO, SECURITY, swadmin/admin/10.252.200.228/ssh/CLI, ad_0/sw0/FID 128, , Event: TLS SESSION, Certificate Validation failed, Info: Reason = unable to get local issuer certificate.

FMT_MOF.1(1)/

TrustedUpdate

Any attempt to initiate a manual update

None.

See audit for FPT_TUD_EXT.1

FMT_MTD.1 All management activities of TSF data.

None.

See Table 2-2 Collected Admin Action Audits

FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure)

No additional information.

Audit for Initiation of an update The following audit messages indicate that a firmware download was initiated and completed successfully. [SULB-1001], 41547, WWN 10:00:50:eb:1a:48:1d:82 | CHASSIS, WARNING, Brocade7840, Firmwaredownload

command has started. (From v8.1.0b_rc1_bld07 To v8.1.0_cc_27mar).

[SULB-1044], 41549, WWN 10:00:50:eb:1a:48:1d:82 | CHASSIS, INFO, Brocade7840, Firmwaredownload to

secondary partition has completed successfully.

[SULB-1002], 41612, WWN 10:00:50:eb:1a:48:1d:82 | CHASSIS, INFO, Brocade7840, Firmwaredownload

command has completed successfully.

Result of the update attempt The following audit message indicates that a firmware download has failed. 2016/11/08-16:22:09, [SULB-1011], 621, CHASSIS, INFO, Brocade7840, Firmwaredownload command

failed.

Failed to download RPM package. Please check if the firmware image is accessible.

FPT_STM.1 Changes to the time. The old and new values for the time.

Origin of the attempt to change time for success and failure (e.g., IP address).

TS-1009: The audit message indicates that the time was updated using the date CLI; for example, Apr 1 10:10:01 Brocade300AD raslogd: 2013/04/01-10:10:01, [TS-1009], 90, WWN 10:00:00:05:1e:74:84:73 | FID 128, INFO, Brocade300AD, Date changed by user.

TS-1010: The audit message indicates that the time was updated from an NTP server; for example, 2015/01/22-11:16:21, [TS-1010], 29, FID 128, INFO, sw0, NTP Server Time Update from 2015/01/22-11:16:19.920251 to 2015/01/22-11:16:21.983630

FTA_SSL_EXT.1 Any attempts at

unlocking of an

interactive session.

None.

Unlock Using CLI via Console Unlock Using CLI via SSH The following audit message indicates that a login attempt with SSH succeeded. [SEC-3020], INFO, SECURITY, root/root/trapazoid.englab.brocade.com/ssh/CLI, ad_0/pizzabox12/FID

3, 8.1.0b_rc1_bld16, , , , , , , Event: login, Status: success, Info: Successful login attempt

via REMOTE, IP Addr: trapazoid.englab.brocade.com.

Version 0.3, 06/22/2017


Unlock Using Web UI The following audit message indicates a successful login attempt via Webtools. [SEC-3020], INFO, SECURITY, admin/admin/10.38.38.152/https/WebTools, ad_0/pizzabox12/FID 3, ,

Event: login, Status: success, Info: Successful login attempt via HTTP, IP Addr: 10.38.38.152.

FTA_SSL.3 The termination of a

remote session by the

session locking

mechanism.

None.

Termination using CLI at Console Termination Using CLI via SSH The following audit message indicates that a logout attempt with SSH succeeded. [SEC-3022], INFO, SECURITY, admin/admin/trapazoid.englab.brocade.com/ssh/CLI, ad_0/pizzabox12/FID

3, 8.1.0b_rc1_bld16, , , , , , , Event: logout, Status: success, Info: Successful logout by user

[admin].

Termination Using Web UI The following audit message indicates that a successful logout has occurred. [SEC-3022], INFO, SECURITY, admin/admin/kali-2dot0.englab.brocade.com/ssh/CLI,

ad_0/pizzabox12/FID 3, , Event: logout, Status: success, Info: Successful logout by user [admin]. FTA_SSL.4 The termination of an

interactive session.

None.

Termination using CLI at Console Termination Using CLI via SSH The following audit message indicates that a logout attempt with SSH succeeded. [SEC-3022], INFO, SECURITY, admin/admin/trapazoid.englab.brocade.com/ssh/CLI, ad_0/pizzabox12/FID

3, 8.1.0b_rc1_bld16, , , , , , , Event: logout, Status: success, Info: Successful logout by user

[admin].

Termination Using Web UI The following audit message indicates that a successful logout has occurred. [SEC-3022], INFO, SECURITY, admin/admin/kali-2dot0.englab.brocade.com/ssh/CLI,

ad_0/pizzabox12/FID 3, , Event: logout, Status: success, Info: Successful logout by user [admin]. FTP_ITC.1 Initiation of the trusted

channel.

Termination of the

trusted channel. Failure of the trusted

channel functions.

Identification of the initiator and target of failed

trusted channels establishment attempt

Establishing a Syslog Connection The following audit message indicates that a TLS handshake has been initiated. [SEC-3078], INFO, SECURITY, NONE/root/NONE/None/CLI, ad_0/pizzabox12/FID 3, , Event: TLS SESSION,

TLS handshake, Info: Establishing TLS connection. Host=10.38.38.152.

Terminating a Syslog Connection The following audit message indicates that a TLS session has been terminated. [SEC-3078], INFO, SECURITY, NONE/root/NONE/None/CLI, ad_0/pizzabox12/FID 3, , Event: TLS SESSION,

TLS handshake, Info: Terminating TLS connection. Host=10.38.38.152.

Version 0.3, 06/22/2017


Failure of a Syslog Connection See TLSC and X509 audits for failures associated with the failure of a syslog connection.

FTP_TRP.1 Initiation of the trusted

channel.

Termination of the

trusted channel. Failures of the trusted

path functions.

Identification of the claimed user identity.

Using CLI via SSH The following audit message indicates that a login attempt with SSH succeeded. [SEC-3020], INFO, SECURITY, root/root/trapazoid.englab.brocade.com/ssh/CLI, ad_0/pizzabox12/FID 3, 8.1.0b_rc1_bld16, , , , , , , Event: login, Status: success, Info: Successful login attempt via REMOTE, IP Addr: trapazoid.englab.brocade.com. Using Web UI The following audit message indicates a successful login attempt via Webtools. [SEC-3020], INFO, SECURITY, admin/admin/10.38.38.152/https/WebTools, ad_0/pizzabox12/FID 3, , Event: login, Status: success, Info: Successful login attempt via HTTP, IP Addr: 10.38.38.152.

Table 2-2 Collected Admin Action Audits

FMT_MTD.1

Admin Actions are shown

below

All management activities of TSF data.

None.

Configure Secure Connection with Audit Server

Change to disable use of external syslog server RAS-2007: The audit message indicates that a syslog server IP address has been removed; for example, Feb 5 21:27:43 10.38.37.150 raslogd: AUDIT, 2015/02/05-21:27:43 (GMT), [RAS-2007], INFO, SECURITY, admin/ admin/NONE/console/CLI, ad_0/Brocade300/CHASSIS, 7.3.0a1, , , , , , , Syslog server IP address 10.38.37.40 removed.

Change to host identified as the external syslog server RAS-2006: The audit message indicates that a syslog server IP address has been added; for example, Feb 5 21:27:05 10.38.37.150 raslogd: AUDIT, 2015/02/05-21:27:04 (GMT), [RAS-2006], INFO, SECURITY, admin/ admin/NONE/console/CLI, ad_0/Brocade300/CHASSIS, 7.3.0a1, , , , , , , Syslog server IP address 10.38.37.40 added.

User Management AUDIT, 2017/05/03-17:40:13 (GMT), [SEC-3027], INFO, SECURITY, admin/admin/10.38.243.4/https/

WebTools, ad_0/7840-3-security/FID 128, 8.1.0b, , , , , , , Event: userconfig, Status: success,

Info: User account [testuser] [ LFs changed: (null): 128 switchadmin:]. AUDIT, 2017/05/03-17:41:07 (GMT), [SEC-3028], INFO, SECURITY, admin/admin/10.38.243.4/https/

WebTools, ad_0/7840-3-security/FID 128, 8.1.0b, , , , , , , Event: userconfig, Status: success,

Info: User account [testuser] deleted.

Version 0.3, 06/22/2017


[SEC-1197], 10622, WWN 10:00:c4:f5:7c:00:6d:00 | FID 128, INFO, chewy, Changed account newadmin.

AUDIT, 2017/05/02-16:41:21 (GMT), [SEC-3024], INFO, SECURITY, admin/admin/10.38.38.152/https/Web

Tools, ad_0/chewy/FID 128, 8.1.0b, , , , , , , Event: passwd, Status: success, Info: User account

[newadmin], password changed.

Change Password [SEC-1197], 10622, WWN 10:00:c4:f5:7c:00:6d:00 | FID 128, INFO, chewy, Changed account newadmin.

AUDIT, 2017/05/02-16:41:21 (GMT), [SEC-3024], INFO, SECURITY, admin/admin/10.38.38.152/https/Web

Tools, ad_0/chewy/FID 128, 8.1.0b, , , , , , , Event: passwd, Status: success, Info: User account

[newadmin], password changed.

Configure Time Synchronization TS-1010: The audit message indicates that the time was updated from an NTP server; for example, 2015/01/22-11:16:21, [TS-1010], 29, FID 128, INFO, sw0, NTP Server Time Update from

2015/01/22-11:16:19.920251 to 2015/01/22-11:16:21.983630

Component Testing Assurance Activities: 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 the table of audit events and

administrative actions listed above. 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. Logging of all

activities related to trusted update should be tested in detail and with utmost diligence. When verifying the test

results, the evaluator shall ensure the audit records generated during testing match the format specified in the

guidance documentation, and that the fields in each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms

directly.

The evaluator created a list of the required audit events. The evaluator then collected the audit event when

running the other security functional tests described by the protection profiles. For example, the required event

for FPT_STM.1 is Changes to Time. The evaluator collected these audit records when modifying the clock using

administrative commands and NTP. The evaluator then recorded these audit events in the proprietary Detailed

Test Report (DTR). The security management events are handled in a similar manner. When the administrator

was required to set a value for testing, the audit record associated with the administrator action was collected and

recorded in the DTR.

Version 0.3, 06/22/2017


2.1.2 USER IDENTITY ASSOCIATION (FAU_GEN.2)

2.1.2.1 FAU_GEN.2.1





Component Guidance Assurance Activities: None Defined

Component Testing Assurance Activities: This activity should be accomplished in conjunction with the testing of

FAU_GEN.1.1.

See the test results for FAU_GEN.1.1.

2.1.3 PROTECTED AUDIT TRAIL STORAGE (FAU_STG.1)

2.1.3.1 FAU_STG.1.1




2.1.3.2 FAU_STG.1.2




Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure it describes the amount of

audit data that are stored locally and how these records are protected against unauthorized modification or

Version 0.3, 06/22/2017


deletion. The evaluator shall ensure that the TSS describes the conditions that must be met for authorized deletion

of audit records.

Section 6.1 of [ST] indicates that the TOE maintains a local audit log buffer that retains the last 1024 messages

persistently, overwriting the oldest events as necessary, and is only accessible by TOE administrators after logging

in. This section also states that the TOE protects the audit trail from modification and deletion by not allowing

direct access to the audit log files.

Component Guidance Assurance Activities: The evaluator shall examine the guidance documentation to

determine that it describes any configuration required for protection of the locally stored audit data against

unauthorized modification or deletion.

The [ST] indicates that the audit trail is protected from modification by virtue of the fact that administrators are

the only users of the system, and the CLI does not allow direct access to the audit log files. Thus only

authenticated administrators and utilize the CLI commands provided, and those commands only allow clearing of

the audit trail, not modification of individual records.

Component Testing Assurance Activities: The evaluator shall perform the following tests:

Test 1: The evaluator shall access the audit trail as an unauthorized administrator and attempt to modify and

delete the audit records. The evaluator shall verify that these attempts fail.

Test 2: The evaluator shall access the audit trail as an authorized administrator and attempt to delete the audit

records. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records

authorized for deletion are deleted.

The evaluator logged in as a default user with no admin permissions and then attempted to view the audit records.

Permission was denied.

The evaluator logged into the TOE as administrator and attempted to view locally stored audit records. The audit

records were displayed. The evaluator then attempted to clear the audit trail and observed that a message was

returned indicating that the “Audit Log Cleared”. Viewing the audit records confirmed the deletion of audit

records.

2.1.4 PROTECTED AUDIT EVENT STORAGE (FAU_STG_EXT.1)

2.1.4.1 FAU_STG_EXT.1.1



Version 0.3, 06/22/2017



2.1.4.2 FAU_STG_EXT.1.2




2.1.4.3 FAU_STG_EXT.1.3




Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure it describes the means by

which the audit data are transferred to the external audit server, and how the trusted channel is provided.

The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what

happens when the local audit data store is full; and how these records are protected against unauthorized access.

If the TOE complies with FAU_STG_EXT.2 the evaluator shall verify that the numbers provided by the TOE

according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3.

The evaluator shall examine the TSS to ensure that it details the behavior of the TOE when the storage space for

audit data is full. When the option 'overwrite previous audit record' is selected this description should include an

outline of the rule for overwriting audit data. If 'other actions' are chosen such as sending the new audit data to an

external IT entity, then the related behavior of the TOE shall also be detailed in the TSS.

Section 6.1 of the ST states that the TOE sends audit records to a configured syslog server in the environment. The

environment is relied upon to provide interfaces to read from the audit trail. The TOE generates a complete audit

record which is packaged into a syslog protocol message. A network connection is established with the syslog

server and the audit record is sent.

Section 6.1 of [ST] indicates that the TOE maintains a local audit log buffer that retains the last 1024 messages

persistently, overwriting the oldest events as necessary, and is only accessible by TOE administrators after logging

in. This section also states that the TOE protects the audit trail from modification and deletion by not allowing

direct access to the audit log files.

Version 0.3, 06/22/2017


Component Guidance Assurance Activities: The evaluator shall also examine the guidance documentation to

ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements

on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration

of the TOE needed to communicate with the audit server.

The evaluator shall also examine the guidance documentation to determine that it describes the relationship

between the local audit data and the audit data that are sent to the audit log server. For example, when an audit

event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a

buffer and 'cleared' periodically by sending the data to the audit server.

The evaluator shall also ensure that the guidance documentation describes all possible configuration options for

FAU_STG_EXT.1.3 and the resulting behavior of the TOE for each possible configuration. The description of

possible configuration options and resulting behavior shall correspond to those described in the TSS.

The [CC-Guide] contains a section entitled “Configuring the Fabric OS switch for Common Criteria”. This section includes instructions to configure TLS protection for audit connections to an external audit server. The [CC-Guide] indicates that the syslog server must support TLSv1.2. The [CC-Guide] contains a description of the processing of the audit data within the TOE, and indicates that audit records are sent to the external server as soon as they are generated.

Component Testing Assurance Activities: Testing of the trusted channel mechanism for audit will be performed as

specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall

perform the following additional test for this requirement:

a) Test 1: 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.

The evaluator shall perform operations that generate audit data and verify that this data is stored locally. The

evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies

that the TOE complies with the behavior defined in FAU_STG_EXT.1.3. Depending on the configuration this means

that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and

then verifies that

a) The audit data remains unchanged with every new auditable event that should be tracked but that the audit

data is recorded again after the local storage for audit data is cleared (for the option 'drop new audit data' in

FAU_STG_EXT.1.3).

b) The existing audit data is overwritten with every new auditable event that should be tracked according to the

specified rule (for the option 'overwrite previous audit records' in FAU_STG_EXT.1.3)

Version 0.3, 06/22/2017


c) The TOE behaves as specified (for the option 'other action' in FAU_STG_EXT.1.3).

The evaluator configured the system (per guidance) to securely transfer audit data. The evaluator then captured

network traffic between the TOE and the external audit server. The evaluator verified that the packet capture

showed the audit data was not cleartext on the network.

The evaluator also continued to generate audit data until the local storage space was exceeded. The evaluator

verified that when the local audit storage was filled to the maximum, the existing audit data was overwritten

based on the following rule: overwrite oldest records first.

2.2 CRYPTOGRAPHIC SUPPORT (FCS)

2.2.1 CRYPTOGRAPHIC KEY GENERATION (FCS_CKM.1)

2.2.1.1 FCS_CKM.1.1




Component TSS Assurance Activities: The evaluator shall ensure that the TSS identifies the key sizes supported by

the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies

the usage for each scheme.

Section 6.2 of the ST identifies the key sizes supported by the TOE for RSA, ECC and FFC schemes. It also describes

the key usage for each scheme. Table 7 in Section 6.2 lists the cryptographic functions and the associated

algorithms and key size. This includes the following:

Cryptographic Signature Services -- using RSA Digital Signature Algorithm with key size 2048 bit and ECDSA

Digital Signature Algorithm with NIST curves P-256 and P-384.

Key Generation – the TOE performs RSA, ECDSA and DSA Key generation

Key Establishment -- for elliptic curve and finite-field based key establishment, the TOE implements the

following sections of SP800-56A: 5.6 and all subsections. For RSA key establishment, the TOE implements

the following sections of SP 800-56B: 6 and all subsections.

These keys are used in cryptographic functions which support the SSHv2 and TLSv1.2 secure communication

protocols. The ECDSA cryptography is available only through SSHv2.

Version 0.3, 06/22/2017


Component Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the

administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses

defined in this PP.

The section entitled, “Configuring the Fabric OS switch for Common Criteria “ in [CC-Guide] provides a list of

configuration steps necessary to configure the TOE in Common criteria mode (i.e., a mode of operation meeting

requirements from [ST]). This section includes commands to configure crypto functions that must be configured in

order to meet requirements from the [ST].

Component Testing Assurance Activities: FIPS

The TOE has been CAVP tested. Refer to Section 1.2, “CAVP Certificate Justification” and specifically to Table 1-2

TOE CAVP Certificates.

2.2.2 CRYPTOGRAPHIC KEY ESTABLISHMENT (FCS_CKM.2)

2.2.2.1 FCS_CKM.2.1




Component TSS Assurance Activities: The evaluator shall ensure that the supported key establishment schemes

correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme,

the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

For SP800-56B Key Establishment Schemes: The evaluator shall verify that the TSS describes whether the TOE acts

as a sender, a recipient, or both for RSA-based key establishment schemes.

Section 6.2 of the ST identifies the cryptographic functions and algorithms supported by the TOE for RSA, ECC and

FFC schemes. It also describes the key usage for each scheme. Table 7 in Section 6.2 lists the cryptographic

functions and the associated algorithms and key size. This includes the following:

Key Establishment -- for elliptic curve and finite-field based key establishment, the TOE implements the

following sections of SP800-56A: 5.6 and all subsections. For RSA key establishment, the TOE implements

the following sections of SP 800-56B: 6 and all subsections.

These keys are used in cryptographic functions which support the SSHv2 and TLSv1.1 and 1.2 secure

communication protocols. The TOE acts as an initiator and responder for TLS and Responder for SSH.

Version 0.3, 06/22/2017


Component Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the

administrator how to configure the TOE to use the selected key establishment scheme(s).

The section entitled, “Configuring the Fabric OS switch for Common Criteria” in [CC-Guide] provides a list of


requirements from [ST]). This sections includes commands to configure The section entitled, “Configuring the

Fabric OS switch for Common Criteria” in [CC-Guide] provides a list of configuration steps necessary to configure

the TOE in Common criteria mode (i.e., a mode of operation meeting requirements from [ST]). This section

includes commands to configure crypto functions that must be configured in order to meet requirements from the

[ST].

omponent Testing Assurance Activities: FIPS



2.2.3 CRYPTOGRAPHIC KEY DESTRUCTION (FCS_CKM.4)

2.2.3.1 FCS_CKM.4.1




Component TSS Assurance Activities: The evaluator shall check to ensure the TSS lists each type of plaintext key

material and its origin and storage location.

The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system

power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel

per the protocol, etc.).

The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed

(cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different

types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS

describes the clearing procedure in terms of the memory in which the data are stored (for example, 'secret keys

stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent

storage device are cleared by overwriting three times with a random pattern that is changed before each write').

Version 0.3, 06/22/2017


Section 6.2 of the ST provides a list of the Critical Security Parameters and their storage location. It states that the

TOE is designed to zeroize secret and private keys when they are no longer required by the TOE. Zeroization

occurs as follows:

1. When deleted from FLASH, the previous value is overwritten once with zeroes

2. When added or changed in FLASH, any old value is overwritten completely with the new value

3. Zeroization of values in RAM is achieved by overwriting once with zeroes.


Component Testing Assurance Activities: None Defined

2.2.4 CRYPTOGRAPHIC OPERATION (AES DATA ENCRYPTION/DECRYPTION)

(FCS_COP.1(1))

2.2.4.1 FCS_COP.1(1).1









2.2.5 CRYPTOGRAPHIC OPERATION (SIGNATURE GENERATION AND VERIFICATION)

(FCS_COP.1(2))

Version 0.3, 06/22/2017


2.2.5.1 FCS_COP.1(2).1









2.2.6 CRYPTOGRAPHIC OPERATION (HASH ALGORITHM) (FCS_COP.1(3))

2.2.6.1 FCS_COP.1(3).1




Component TSS Assurance Activities: The evaluator shall check that the association of the hash function with

other TSF cryptographic functions (for example, the digital signature verification function) is documented in the

TSS.

Table 7 in Section 6.2 of the ST states that the TOE provides cryptographic hashing services using SHA-1, SHA-256

and SHA-512 and keyed-hash message authentication using HMAC-SHA-1, HMAC-SHA2-256 and HMAC-SHA2-512.

Section 6.2 of the ST states that the TOE supports TLSv1.1 and TLSv1.2 with AES in conjunction with SHA-1 and

SHA-256. The TOE supports SSHv2 with AES in conjunction with HMAC-SHA-1, HMAC-SHA2-256 and HMAC-SHA2-

512 and RSA and ECDH using the following key exchange methods: diffie-hellman-group14-sha1, ecdh-sha2-

nistp256 and ecdh-sha2-nistp384. The TOE also supports SSH_RSA and ecdsa-sha2-nistp256 for server

authentication.

Component Guidance Assurance Activities: The evaluator checks the AGD documents to determine that any

configuration that is required to configure the required hash sizes is present.

Version 0.3, 06/22/2017


The section entitled, “Configuring the Fabric OS switch for Common Criteria“ in [CC-Guide] provides a list of


requirements from [ST]). This section includes commands to configure hash sizes that must be configured in order

to meet requirements from the [ST].




2.2.7 CRYPTOGRAPHIC OPERATION (KEYED HASH ALGORITHM) (FCS_COP.1(4))

2.2.7.1 FCS_COP.1(4).1




Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it specifies the following

values used by the HMAC function: key length, hash function used, block size, and output MAC length used.

Table 7 in Section 6.2 of the ST indicates that the HMAC-SHA-1, HMAC-SHA2-256 and HMAC-SHA2-512 functions

are supported with digest sizes 160, 256 and 512 bits. The FCS_COP.1(4) requirement indicates that the

cryptographic key sizes are equal to the input block size.





2.2.8 HTTPS PROTOCOL (FCS_HTTPS_EXT.1)

2.2.8.1 FCS_HTTPS_EXT.1.1


Version 0.3, 06/22/2017









TSS Assurance Activities: The evaluator shall check that the TSS describes how peer authentication is implemented

when HTTPS protocol is used. (Per TD0125)

Section 6.3 of [ST] states that the TOE authenticates administrative users accessing the TOE the web interface

(HTTPS) in the same manner using its own password-based authentication mechanism.






Test 1: The evaluator shall attempt to establish an HTTPS connection with a web server, observe the traffic with a

packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

Other tests are performed in conjunction with the TLS evaluation activities.

Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator

shall perform the following test:

Test 2: If 'the peer presents a valid certificate during handshake' is selected in FCS_HTTPS_EXT.1.3, then certificate

validity shall be tested in accordance with testing performed for FIA_X509_EXT.1 if HTTPS is used for FTP_TRP.1 or

FTP_ITC.1. (TD0125 applied)

Version 0.3, 06/22/2017


Login via the TOE GUI is protected by HTTPS/TLS and was conducted during the FTP_TRP.1-t1 test case. Review of

the packet capture from FTP_TRP.1-t1, shows that traffic is protected by HTTPS/TLS. This packet capture also

shows that traffic is initiated by the TOE’s peer.

2.2.9 RANDOM BIT GENERATION (FCS_RBG_EXT.1)

2.2.9.1 FCS_RBG_EXT.1.1




2.2.9.2 FCS_RBG_EXT.1.2





Component Guidance Assurance Activities: Documentation shall be produced – and the evaluator shall perform

the activities – in accordance with Appendix D of [NDcPP].

The Entropy description is provided in a separate (non-ST) document that has been delivered to NIAP for approval.

Note that the entropy analysis has been accepted by NIAP/NSA.

Component Testing Assurance Activities: The evaluator shall perform 15 trials for the RNG implementation. If the

RNG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm

that the guidance documentation contains appropriate instructions for configuring the RNG functionality.

If the RNG 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. The evaluator verifies that the second

block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is

a count (0 â€“ 14). The next three are entropy input, nonce, and personalization string for the instantiate

operation. The next two are additional input and entropy input for the first call to generate. The final two are

additional input and entropy input for the second call to generate. These values are randomly generated. 'generate

one block of random bits' means to generate random bits with number of returned bits equal to the Output Block

Length (as defined in NIST SP800-90A).

Version 0.3, 06/22/2017


If the RNG 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. The evaluator verifies

that the second block of random bits is the expected value. The evaluator shall generate eight input values for

each trial. The first is a count (0 â€“ 14). The next three are entropy input, nonce, and personalization string for the

instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are

additional input and entropy input to the call to reseed. The final value is additional input to the second generate

call.

The following paragraphs contain more information on some of the input values to be generated/selected by the

evaluator.

Entropy input: the length of the entropy input value must equal the seed length.

Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length

is one-half the seed length.

Personalization string: The length of the personalization string must be <= seed length. If the implementation only

supports one personalization string length, then the same length can be used for both values. If more than one

string length is support, the evaluator shall use personalization strings of two different lengths. If the

implementation does not use a personalization string, no value needs to be supplied.

Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization

string lengths.



2.2.10 SSH SERVER PROTOCOL (FCS_SSHS_EXT.1)

2.2.10.1 FCS_SSHS_EXT.1.1





Version 0.3, 06/22/2017


TSS Assurance Activities: The evaluator shall check to ensure that the TSS contains a description of the public key

algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHS_EXT.1.5, and ensure

that password-based authentication methods are also allowed.

Section 6.2 of the ST indicates that the TOE implements SSHv2 which supports both public key and password based

authentication. The TSS also indicates that users can authenticate using either ssh-rsa or ecdsa-sha2-nistp256

public-key authentication.


Testing Assurance Activities: Test 1: The evaluator shall, for each public key algorithm supported, show that the

TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities

required to support this test shall be performed according to instructions in the guidance documentation.

Test 2: The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a

new key pair for that algorithm without configuring the TOE to recognize the 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: Using the guidance documentation, the evaluator shall configure the TOE to accept password-based

authentication, and demonstrate that a user can be successfully authenticated to the TOE over SSH using a

password as an authenticator.

Test 4: The evaluator shall use an SSH client, enter an incorrect password to attempt to authenticate to the TOE,

and demonstrate that the authentication fails.

Test 1 & 2: The evaluator created RSA and ECDSA public key pairs on a test host which would act as the SSH client

during the test. One public key was copied to the TOE while the second was not. The evaluator then attempted to

connect to the TOE using each public key and observed that only the key which was copied to the TOE would

successfully authenticate the user to the TOE.

Test 3: The evaluator performed a login via SSH was with the correct password and the connection was allowed.

Test 4: The evaluator performed a login via SSH was with the incorrect password and the connection was

disallowed.


TSS Assurance Activities: The evaluator shall check that the TSS describes how 'large packets' in terms of RFC 4253

are detected and handled.

Version 0.3, 06/22/2017


Section 6.2 of the ST states that as SSH packets are being received, the TOE uses a buffer to build all packet

information. Once complete, the packet is checked to ensure it can be appropriately decrypted. However, if it is

not complete when the buffer becomes full (256K bytes) the packet will be dropped.


Testing Assurance Activities: The evaluator shall demonstrate that if the TOE receives a packet larger than that

specified in this component, that packet is dropped.

The evaluator created and sent a packet to the TOE that was larger than the maximum packet size using a modified

PUTTY test tool. The evaluator observed that the TOE dropped the packet as expected.


TSS Assurance Activities: The evaluator shall check the description of the implementation of this protocol in the

TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as

well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those

listed for this component.

Section 6.2 of the ST states that the TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with

HMAC-SHA-1, HMAC-SHA2-256, and HMAC-SHA2-512 and RSA and ECDH using the following key exchange

methods:

diffie-hellman-group14-sha1,

ecdh-sha2-nistp256, and

ecdh-sha2-nistp384.

No optional characteristics are specified.

Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it

contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the

set of algorithms advertised by the TOE may have to be restricted to meet the requirements).



requirements from [ST]). This section includes a command (step 7 in [CC-Guide]) to configure the system for

crypto compliance to limit the cryptographic algorithms used by the TOE for TLS and SSH sessions to only those

allowed by the ST.

Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the encryption

algorithms 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.

Version 0.3, 06/22/2017


Test 2: The evaluator shall configure an SSH client to only allow the 3des-cbc encryption algorithm and no other

encryption algorithms. The evaluator shall attempt to establish an SSH connection from the SSH client to the TOE

and observe that the connection is rejected.

The evaluator configured the TOE for SSH using only the claimed encryption algorithms as described in the

guidance documentation. The evaluator attempted a connection with each valid algorithm and with 3DES. For

each test the evaluator confirmed the result of the attempted connection, and recorded the associated

wireshark/audit events generated. The connection using 3DES was rejected, but the connection attempts using

valid algorithms were successful.



TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as

well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those

listed for this component.



methods:



ecdh-sha2-nistp384.

The TOE also supports SSH_RSA and ecdsa-sha2-nistp256 for server authentication. No optional characteristics are specified.


contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the

set of algorithms advertised by the TOE may have to be restricted to meet the requirements).



requirements from [ST]). This section includes a command to configure crypto algorithms for TLS and SSH.

Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the public key

algorithms specified by the requirement to authenticate an SSH server to the TOE. 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 shall configure an SSH server to only allow the ssh-dsa public key algorithm and no other

public key algorithms. The evaluator shall attempt to establish an SSH connection from the TOE to the SSH server

and observe that the connection is rejected.

Version 0.3, 06/22/2017


The evaluator attempted to establish a SSH connection with each of the following SSH transport public key

algorithms: ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-

nistp384 and ssh-dsa. The evaluator captured packets associated with each of the following connection attempts.

The evaluator observed that the ssh-rsa algorithm was able to successfully connect to the TOE.


TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported data integrity

algorithms, and that that list corresponds to the list in this component.


HMAC-SHA-1, HMAC-SHA2-256, and HMAC-SHA2-512. This is consistent with the requirements.


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).



requirements from [ST]). This section includes a command to configure MAC algorithms functions for TLS and SSH.

Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the integrity

algorithms 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 shall configure an SSH client to only allow the 'none' MAC algorithm. The evaluator shall

attempt to connect from the SSH client to the TOE and observe that the attempt fails.

Test 3: The evaluator shall configure an SSH client to only allow the hmac-md5 MAC algorithm. The evaluator shall

attempt to connect from the SSH client to the TOE and observe that the attempt fails.

The evaluator attempted to establish a SSH connection with each of the following SSH transport MAC algorithms:

hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, AEAD_AES_128_GCM, AEAD_AES_256_GCM, hmac-

md5, and ‘none’. The evaluator captured packets associated with each of these connection attempts. The

evaluator observed that only the hmac-sha1, hmac-sha2-256 and hmac-sha2-512 algorithms were able to

successfully connect to the TOE.


TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported key exchange

algorithms, and that that list corresponds to the list in this component.

Version 0.3, 06/22/2017




methods:



ecdh-sha2-nistp384.


contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are

used in SSH connections with the TOE.



requirements from [ST]). This section includes a command to configure key exchange algorithms functions for TLS

and SSH.

Testing Assurance Activities: Test 1: The evaluator shall configure an SSH client to only allow the diffiehellman-

group1-sha1 key exchange. The evaluator shall attempt to connect from the SSH client to the TOE and observe that

the attempt fails.

Test 2: For each allowed key exchange method, the evaluator shall configure an SSH client to only allow that

method for key exchange, attempt to connect from the client to the TOE, and observe that the attempt succeeds.

The evaluator attempted to establish a SSH connection with each of the following key exchange method: diffie-

hellman-group1-sha1, diffie-hellman-group14-sha, ecdh-sha2-nistp256, and ecdh-sha2-nistp384, the evaluator

captured packets associated with each of these connection attempts. The evaluator observed that the TOE did not

connect using diffie-hellman-group1-sha1, but was able to connect using the other key exchange methods.




Testing Assurance Activities: The evaluator shall configure the TOE to create a log entry when a rekey occurs. The

evaluator shall connect to the TOE with an SSH client and cause 2^28 packets to be transmitted from the client to

the TOE, and subsequently review the audit log to ensure that a rekey occurred.

The evaluator configured the TOE rekey interval for a period of 15 minutes, established an SSH session and

monitored audit records. Audit records confirmed that the SSH session was rekeyed after 15 minutes.

Version 0.3, 06/22/2017


The evaluator configured the TOE time interval for 60 minutes and executed a scripted test. The scripted test

logged into the TOE, waited for a prompt and immediately issued the ‘help’ command. The test repeated the

‘help’ command each time a prompt was presented, thus issuing commands as quickly as possible. The SSH

session rekeyed at 60 minutes, since the log of the SSH session was approximately 125Mb, the TOE had rekeyed as

a result of the time limit. This shows that administrative command line activity could not exceed 1 Gb in 1 hour.

According to NIAP TD0167, this is an acceptable result.




2.2.11 TLS CLIENT PROTOCOL WITH AUTHENTICATION (FCS_TLSC_EXT.2)

2.2.11.1 FCS_TLSC_EXT.2.1


TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the

ciphersuites specified include those listed for this component.

Section 6.2 of the ST states that the TOE supports TLSv1.1 and TLSv1.2 with AES (CBC) 128 or 256 bit ciphers, in

conjunction with SHA-1 and SHA-256 and RSA. The following cipher suites are implemented by the TOE:

1. TLS_RSA_WITH_AES_128_CBC_SHA,


3. TLS_RSA_WITH_AES_128_CBC_SHA256, and

4. TLS_RSA_WITH_AES_256_CBC_SHA256.

The list of ciphersuites in the TSS is consistent with those listed in the requirement.


contains instructions on configuring the TOE so that TLS conforms to the description in the TSS.



requirements from [ST]). This section explains that the by applying the default_cc template, the TLS cryptographic

configuration is defined in such a way that the TOE meets the requirements of [ST].

Version 0.3, 06/22/2017


Testing Assurance Activities: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites

specified by the requirement. This connection may be established as part of the establishment of a higher-level

protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to

satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an

attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not

256-bit AES).

Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains

the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The

evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server

Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two

certificates should be identical except for the extendedKeyUsage field.

Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-

selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA

ciphersuite). The evaluator shall verify that the TOE disconnects after receiving the server's Certificate handshake

message.

Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify

that the client denies the connection. Test 2 in FCS_TLSS_EXT.1.1 or FCS_TLSS_EXT.2.1 can be used as a substitute

for this test.

Test 5: The evaluator perform the following modifications to the traffic:

a) Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example

1.3 represented by the two bytes 03 04) and verify that the client rejects the connection.

b) Modify at least one byte in the server's nonce in the Server Hello handshake message, and verify that the client

rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies

the client's Finished handshake message.

c) Modify the server's selected ciphersuite in the Server Hello handshake message to be a ciphersuite not

presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection

after receiving the Server Hello.

d) Modify the signature block in the Server's Key Exchange handshake message, and verify that the client rejects

the connection after receiving the Server Key Exchange message.

e) Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon

receipt and does not send any application data.

f) Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify

that the client denies the connection.

Version 0.3, 06/22/2017


Test 1: The evaluator established a TLS session from the TOE to a test server with the test server configured to

accept connections with only one of the claimed cipher suites. The evaluator used a network sniffer to capture the

TLS session negotiation. The evaluator examined each traffic capture and observed that the expected TLS cipher

was negotiated.

Test 2: The evaluator configured the TOE (i.e., the client) to communicate with a test server. The when the TOE

inititated the connection the test server sent a certificate with the Server Authentication purpose in the

extendedKeyUsage field. Using a network sniffer the evaluator captured the TLS session negotiation and observed

that the TLS session was accepted by the TOE. The evaluator reconfigured the test server to retry the TLS session

using a cert that was missing the Server Authentication purpose in the extendedKeyUsage field. Using a network

sniffer the evaluator captured the TLS session negotiation and observed that the TLS session is rejected by the TOE.

Test 3: The evaluator established a TLS session from the TOE to a test server using syslog. The test server was

modified to negotiate an RSA ciphersuite, but return an ECDSA Certificate. Using a network sniffer to capture the

TLS session negotiation, the evaluator observed that the TLS session is rejected by the TOE.

Test 4: The evaluator configured a test server to accept only the TLS_NULL_WITH_NUL_NULL ciphersuite. The

evaluator then attempted to establish a TLS session from the TOE to that test server. Using a network sniffer the

evaluator captured the TLS session negotiation and observed that the TLS session is rejected by the TOE.

Test 5: The evaluator obtained a packet capture of the TSL session negotiation between the TOE (i.e., the client)

and a test server with Mutual Authentication configured on the test server. The evaluator made connection

attempts from the client to the test server. The server implementation of the TLS protocol was modified as stated

in the 5 scenarios stated immediately above. Scenarios “D” became two parts, the first to issues the Finished

message out of order, and the second to use the old session identifier. Inspect the packet captures to ensure that

the connections are rejected for each scenario.


TSS Assurance Activities: The evaluator shall ensure that the TSS describes the client's method of establishing all

reference identifiers from the administrator/application configured reference identifier, including which types of

reference identifiers are supported (e.g Common Name, DNS Name, URI Name, Service Name, or other

application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The

evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is

supported or used by the TOE.

Per TD0152, the text 'The evaluator shall ensure that the TSS describes “whether” wildcards are supported' is

interpreted as referring to the statement in Application Notes 75 & 79 that '[T]he client should avoid constructing

reference identifiers using wildcards'. The tests in sections 2.2.13.3 & 2.2.14.3 examine the way the client responds

when presented with server certificates that contain wildcards, which refers to the other part of the statement in

Application Notes 75 & 79 that 'if the presented identifiers include wildcards, the client must follow the best

practices regarding matching; these best practices are captured in the assurance activity'. The difference is thus

Version 0.3, 06/22/2017


between use of wildcards in a reference identifier list that the TOE constructs (which is discouraged, but optional),

and support for the use of wildcards in a certificate that is presented to the TOE (which is required).

Section 6.3 of [ST] indicates that the common name (or SAN values if present) needs to be a fully qualified domain

name or IP address. It also indicates that wildcards are allowed in certificates only for 1 level of sub-domain and

not for the main domain (i.e., *.edu is not allowed). Section 6.2 of [ST] indicates that certificate pinning is not

supported.

Guidance Assurance Activities: The evaluator shall verify that the AGD guidance includes instructions for setting

the reference identifier to be used for the purposes of certificate validation in TLS.



requirements from [ST]). This section explains that the defined switch name along with the configured DNS

specifies the TOE’s reference identifier.

Testing Assurance Activities: The evaluator shall configure the reference identifier according to the AGD guidance

and perform the following tests during a TLS connection:

Test 1: The evaluator shall present a server certificate that does not contain an identifier in either the Subject

Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. The evaluator shall verify

that the connection fails.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier,

contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier.

The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN

type.

Test 3: The evaluator shall present a server certificate that contains a CN that matches the reference identifier and

does not contains the SAN extension. The evaluator shall verify that the connection succeeds.

Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference

identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection

succeeds.

Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier:

1) The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the

presented identifier (e.g. foo.*.example.com) and verify that the connection fails.

2) The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g. *.example.com).

The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.example.com) and verify

that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in

Version 0.3, 06/22/2017


the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference

identifier with two left-most labels (e.g. bar.foo.example.come) and verify that the connection fails.

Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the

DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS

name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds.

The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the

connection fails.

Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not

match the pinned certificate and verify that the connection fails.

Test 1: The evaluator established a TSL session from the TOE targeting a server using a valid certificate with a CN

matching the domain name used by the client. Using a network sniffer to capture the TLS session negotiation the

evaluator examined the traffic capture and observed a successful connection. The evaluator then established a TLS

session from the TOE targeting a server using a server certificate that does not contain an identifier in either the

Subject Alternative Name (SAN) or Common Name (CN) that matches the reference identifier. Using a network

sniffer to capture the TLS session negotiation the evaluator examined the traffic capture and observed that the TLS

session was not negotiated successfully.

Test 2: The evaluator established a TLS session from the TOE targeting a server using a server certificate that

contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier

in the SAN that matches the reference identifier. Using a network sniffer to capture the TLS session negotiation the

evaluator examined the traffic capture and observed that the TLS session was not negotiated successfully.


contains a CN that matches the reference identifier and does not contain the SAN extension. Using a network

sniffer to capture the TLS session negotiation the evaluator examined the traffic capture and observed that the TLS

session was negotiated successfully.


contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches.

Using a network sniffer to capture the TLS session negotiation the evaluator examined the traffic capture and

observed that the TLS session was negotiated successfully.

Test 5: The evaluator configured a test server to use a server certificate containing a reference identifier as

described by test 5 from the above assurance activity. The evaluator established a TLS session from the TOE

targeting the name shown in column 2 of the following table. Using a network sniffer to capture the TLS session

negotiation the evaluator examined the traffic capture and observed that the TLS session was negotiated as shown

in column 3 of the following table.

Certificate Contents Host ID Expected Result

Version 0.3, 06/22/2017


CN=bar.*.example.com bar.foo.example.com No Connection

SAN=bar.*.example.com bar.foo.example.com No Connection

CN=*.example.com foo.example.com Successful Connection

SAN=*.example.com foo.example.com Successful Connection

CN=*.example.com example.com No Connection

SAN=*.example.com example.com No Connection

CN=*.example.com bar.foo.example.com No Connection

SAN=*.example.com bar.foo.example.com No Connection

Test 6: The TOE does not support the optional URI or Service Name used as reference identifiers.

Test 7: The TOE does not support certificate pinning.




Testing Assurance Activities: Test 1: The evaluator shall demonstrate that using a certificate without a valid

certification path results in the function failing. Using the administrative guidance, the evaluator shall then load a

certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the

function succeeds. If the certificate is validated and a trusted channel is established, the test passes. The evaluator

then shall delete one of the certificates, and show that the certificate is not validated and the trusted channel is

not established.

The evaluator attempted to establish a TLS session with a test server using the TOE where the test server was

configured with a certificate having a valid certification path. Using a network sniffer to capture the TLS session

negotiation the evaluator observed that the connection is successfully established. The evaluator removed the

root CA certificate from the TOE and attempted to establish another TLS session with the test server. Using a

network sniffer to capture the TLS session negotiation the evaluator observed that the connection is NOT

successfully established.


TSS Assurance Activities: The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and

whether the required behavior is performed by default or may be configured.

This activity is not applicable since there are no ciphersuites for elliptic curves selected in FCS_TLSC_EXT.2.1.

Guidance Assurance Activities: If the TSS indicates that the Supported Elliptic Curves Extension must be configured

to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the Supported

Elliptic Curves Extension.

Version 0.3, 06/22/2017


The TOE does not support DHE or ECDHE key exchanges.

Testing Assurance Activities: Test 1: The evaluator shall configure the server to perform an ECDHE key exchange in

the TLS connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects after

receiving the server's Key Exchange handshake message.

The TOE does not support DHE or ECDHE key exchanges.


TSS Assurance Activities: The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1

includes the use of client-side certificates for TLS mutual authentication.

Section 6.3 and 6.3 of [ST] explain that the TOE acts as a syslog client using TLS to protect communication with a

syslog server. These sections also indicate that the client loads a certificate that it uses to authenticate itself to the

syslog server when requested by the server (per the TLS protocol definition). These sections also indicate that the

TOE authenticates the TLS server using certificates which must chain to installed root certificates.

Guidance Assurance Activities: The evaluator shall verify that the AGD guidance required per FIA_X509_EXT.2.1

includes instructions for configuring the client-side certificates for TLS mutual authentication.


configuration steps that form the instructions for generating a CSR, exporting the CSR for signing, importing

trusted root CA certificates and importing the signed TOE certificates that are used by the TOE for HTTPS and

syslog TLS connections.

Testing Assurance Activities: Test 1: The evaluator shall perform the following modification to the traffic:

a) Configure the server to require mutual authentication and then modify a byte in a CA field in the Server's

Certificate Request handshake message. The modified CA field must not be the CA used to sign the client's

certificate. The evaluator shall verify the connection fails.

The evaluator attempted to establish a TLS session with a test server using the TOE. The evaluator used the test

server to modify a byte in a CA field of the Server’s Certificate Request handshake message. Using a network

sniffer to capture the TLS session negotiation the evaluator examined the traffic capture and observed that the

client detected the modification and rejected the connection.



Version 0.3, 06/22/2017



2.2.12 TLS SERVER PROTOCOL (FCS_TLSS_EXT.1)

2.2.12.1 FCS_TLSS_EXT.1.1


TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the

ciphersuites specified are identical to those listed for this component.

Section 6.2 of the ST states that the TOE supports TLSv1.2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with SHA-1 and SHA-256 and RSA. The following cipher suites are implemented by the TOE:



7. TLS_RSA_WITH_AES_128_CBC_SHA256, and

8. TLS_RSA_WITH_AES_256_CBC_SHA256.

This list of cipher suites is consistent with the requirement.


contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the

set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements).



requirements from [ST]). The command to configure the use of the default_cc template ensures that the TOE TLS

configuration conforms to ciphersuites, protocol version, keys size and key agreement methods defined by [ST].

Testing Assurance Activities: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites

specified by the requirement. This connection may be established as part of the establishment of a higher-level

protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to

satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an

attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not

256-bit AES).

Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of

the ciphersuites in the server's ST and verify that the server denies the connection. Additionally, the evaluator shall

send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the

server denies the connection.

Version 0.3, 06/22/2017


Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that the does not

match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the

TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA

ciphersuites.) The evaluator shall verify that the TOE either sends an alert after receiving the client's

ChangeCipherSpec message or Finished message; or terminates the connection after receiving the client's

ChangeCipherSpec message or Finished message. (TD0143 applied)

Test 4: The evaluator shall perform the following modifications to the traffic:

a) & b) removed per TD0151

c) Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and

does not send any application data.

d) After generating a fatal alert by sending a Finished message from the client before the client sends a

ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that

the server denies the connection.

e) Send a garbled message from the client after the client has issued the ChangeCipherSpec message and verify

that the Server denies the connection.

Test 1: The evaluator established a TLS session on the TOE for each accessible server interface with each of the

claimed cipher suites in turn. Using a network sniffer to capture the TLS session negotiation and observed that the

expected TLS cipher is negotiated.

Test 2: Establish a TLS session on the TOE for each accessible server interface and each secure client interface with

the TLS_NULL_WITH_NULL_NULL cipher suite. Using a network sniffer to capture the TLS session negotiation and

observed that the session is not successfully negotiated.

Test 3: The evaluator established a TLS session with the TOE and configure the remote peer (i.e., the client) to

change the ciphersuite to one that doesn’t match the server-selected cipher suite. Using a network sniffer to

capture the TLS session negotiation and observed that the TLS session cannot be negotiated.

Test 4: Part a & b of test 4 are not applicable as the TOE does not support mutual authentication on its TLS Server

interface. Parts c, d & e however do apply to this TOE. The evaluator made connection attempts from a client to

the TOE. The client implementation of the TLS protocol was modified as stated in parts c, d & e of the assurance

activity. Scenarios “D” became two parts, the first to issues the Finished message out of order, and the second to

use the old session identifier. The evaluator observed in packet captures that the connections are rejected for

each scenario.


Version 0.3, 06/22/2017


TSS Assurance Activities: The evaluator shall verify that the TSS contains a description of the denial of old SSL and

TLS versions.

Section 6.2 of [ST] indicates that the TOE supports TLSv1.2 and rejects older version of TLS and SSL.

Guidance Assurance Activities: The evaluator shall verify that any configuration necessary to meet the

requirement must be contained in the AGD guidance.





Testing Assurance Activities: The evaluator shall send a Client Hello requesting a connection with version SSL 1.0

and verify that the server denies the connection. The evaluator shall repeat this test with SSL 2.0, SSL 3.0, TLS 1.0,

and any selected TLS versions.

The evaluator attempted to establish a TLS session on the TOE for each accessible server interface with each of the

unsupported versions of SSL and TLS. Using a network sniffer to capture the session negotiation and observed that

the expected protocol and version were offered and rejected during negotiation. Only TLSv1.2 was supported by

the TOE.


TSS Assurance Activities: The evaluator shall verify that the TSS describes the key agreement parameters of the

server key exchange message.

Section 6.2 of the ST indicates that the TOE supports TLSv1.2 with AES (CBC) 128 or 256 bit ciphers, in conjunction

with SHA-1 and SHA-256 and RSA. Table 7 in Section 6.2 indicates that RSA with key size 2048 bits is supported.

Guidance Assurance Activities: The evaluator shall verify that any configuration necessary to meet the

requirement must be contained in the AGD guidance.





Testing Assurance Activities: The evaluator shall attempt establishing connection using each claimed key

establishment protocol (RSA, DH, ECDHE) with each claimed parameter (RSA key size, Diffie-Hellman parameters,

supported curves) as selected in FCS_TLSS_EXT.1.3 (or FCS_TLSS_EXT.2.3). For example, determining that the RSA

Version 0.3, 06/22/2017


key size matches the claimed size is sufficient to satisfy this test. The evaluator shall ensure that each supported

parameter combination is tested.

Note that this testing can be accomplished in conjunction with the other testing activities. (TD0155 applied)

The evaluator attempted to establish a TLS session with the TOE on port 443 when the remote peer (i.e., the client)

included only one key exchange in the Client Hello. The evaluator tried to use the following key exchanges: 2048-

bit RSA Key Exchange, 3072-bit RSA Key Exchange, 4096-bit RSA Key Exchange, 2048-bit DHE, 3072-bit DHE,

secp256r1 ECDHE, and secp384r1 ECDHE. Since the TOE supports only RSA cipher key exchanges using 2048-bit

keys, all other attempts failed.




Version 0.3, 06/22/2017


2.3 IDENTIFICATION AND AUTHENTICATION (FIA)

2.3.1 PASSWORD MANAGEMENT (FIA_PMG_EXT.1)

2.3.1.1 FIA_PMG_EXT.1.1






determine that it provides guidance to security administrators on the composition of strong passwords, and that it

provides instructions on setting the minimum password length.

The section entitled, “Configuring the Fabric OS switch for Common Criteria” in the [CC-Guide] states that each

administrator should have their own user account and their password should be protected. It provides the

command used to set the password policy including the minimum length and indicates that passwords can be

required to have special characters, numbers, capital letters, etc.

Component Testing Assurance Activities: The evaluator shall perform the following tests.

Test 1: 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.

The evaluator configured a password policy to include a minimum length of 15 characters and verified that the

policy minimum length must be between 8 and 40 characters as identified in the ST. The evaluator then

proceeded to create a user and assign both good and bad passwords to that user to verify that the password policy

was enforced. This activity was performed via both the CLI and the Web UI.

Version 0.3, 06/22/2017


2.3.2 PROTECTED AUTHENTICATION FEEDBACK (FIA_UAU.7)

2.3.2.1 FIA_UAU.7.1






Component Testing Assurance Activities: The evaluator shall perform the following test for each method of local

login allowed:

Test 1: 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.

The evaluator observed that passwords are obscured while logging in at the console, via SSH and via the web UI.

2.3.3 PASSWORD-BASED AUTHENTICATION MECHANISM (FIA_UAU_EXT.2)

2.3.3.1 FIA_UAU_EXT.2.1




Component TSS Assurance Activities: Evaluation Activities for this requirement are covered under those for

FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the

activities for FIA_UIA_EXT.1.

See FIA_UIA_EXT.1

Component Guidance Assurance Activities: Evaluation Activities for this requirement are covered under those for



Version 0.3, 06/22/2017


See FIA_UIA_EXT.1

Component Testing Assurance Activities: Evaluation Activities for this requirement are covered under those for



See FIA_UIA_EXT.1

2.3.4 USER IDENTIFICATION AND AUTHENTICATION (FIA_UIA_EXT.1)

2.3.4.1 FIA_UIA_EXT.1.1




2.3.4.2 FIA_UIA_EXT.1.2




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that it describes the logon

process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall

contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and

what constitutes a 'successful logon'.

Section 6.3 of the ST describes the login process for local and remote (HTTPS, SSH) sessions supported by the TOE.

The TOE authenticates administrative users accessing the TOE via the local console, SSH or web interface (HTTPS)

in the same manner using its own authentication mechanism. The TOE provides its own password authentication

mechanism to authenticate administrative users. In order for an administrative user to access the TOE (i.e., to

perform any functions except to see a configured login banner or to access network or SAN services), a user

account including a user name and password must be created for the user, and an administrative role must be

assigned. Additionally, section 6.3 of [ST] explains that the SSH interface support public key authentication. Users

are associated with a public key that must be provided during the authentication process.

Version 0.3, 06/22/2017


The TOE also supports the configuration of RSA and ECDSA certificates for users and once configured the user can

login via SSH using the certificate rather than providing their password.

When authentication succeeds, the TOE looks up the user’s defined privilege level, assigns that to the user’s

session, and presents the user with a command prompt.


determine that any necessary preparatory steps (e.g., establishing credential material such as preshared keys,

tunnels, certificates, etc.) to logging in are described. For each supported the login method, the evaluator shall

ensure the guidance documentation provides clear instructions for successfully logging on. If configuration is

necessary to ensure the services provided before login are limited, the evaluator shall determine that the guidance

documentation provides sufficient instruction on limiting the allowed services.

The section entitled “Configuring the Fabric OS switch for Common Criteria” in the [CC-Guide] describes how to

configure the TOE to limit the cryptographic algorithms available for SSH and TLS sessions to those algorithms

specified in the ST. It also provides the commands for configuring SSH using password or public key authentication

and describes how to set up the certificates to be used to identify the client for secure communications using

Webtools, as well as secure communications with the syslog server. Additionally, this section describes how users

are associated with roles and how administrators can manage the TOE both locally and remotely by logging into

the TOE via console, SSH or Webtools.

Component Testing Assurance Activities: The evaluator shall perform the following tests for each method by

which administrators access the TOE (local and remote), as well as for each type of credential supported by the

login method:

Test 1: The evaluator shall use the guidance documentation 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 to access the system, while providing incorrect information results in denial of

access.

Test 2: The evaluator shall configure the services allowed (if any) according to the guidance documentation, 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 3: 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 1 - The evaluator configured the TOE for local console access. The evaluator then performed an unsuccessful

and successful logon of each type using bad and good credentials respectively.

Test 2 - The evaluator was able to observe the TOE displayed a banner to the user before login.

Version 0.3, 06/22/2017


Test 3 - No functions were available to the administrator accessing the console with the exception of

acknowledging the banner.

2.3.5 X.509 CERTIFICATE VALIDATION (FIA_X509_EXT.1)

2.3.5.1 FIA_X509_EXT.1.1



Testing Assurance Activities: The evaluator shall perform the following tests for FIA_X509_EXT.1.1:

Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the

function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the

certificate to be used in the function, and demonstrate that the function succeeds. The evaluator shall then delete

one of the certificates, and show that the function fails.

Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing.

Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-â€“conditional on whether

CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall

test revocation of the TOE certificate and revocation of the TOE intermediate CA certificate i.e. the intermediate

CA certificate should be revoked by the root CA. The evaluator shall ensure that a valid certificate is used, and that

the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for

each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function

fails.

Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present

a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If

CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign

key usage bit set, and verify that validation of the CRL fails.

Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the

certificate fails to validate. (The certificate will fail to parse correctly.)

Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate

fails to validate. (The signature on the certificate will not validate.)

Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate

fails to validate. (The hash of the certificate will not validate.)

Version 0.3, 06/22/2017


Test 1 – The evaluator configured the TOE and a peer with valid certificates. The evaluator then attempted to make

a connection between the peer devices. A successful connection was made. The evaluator then configured a

server certificate with an invalid certification path by deleting an intermediate root CA so that the certificate chain

was invalid because of a missing (or deleted) certificate. The connection between the peers was refused.

Test 2 – The evaluator used the TOE’s TLS client (syslog) to attempt connections to a test server. The test server

then presented a certificate during the TLS negotiation where the certificate was expired.

Test 3 –The evaluator used a test server to accept connection attempts from the TOE TLS client (syslog). The test

server then presented a certificate during the TLS negotiation where the certificate was valid. A packet capture

was obtained of this TLS negotiation which shows that the connection was successful. The evaluator revoked

certificates in the chain (individually) and attempted the same connection from the syslog client. The attempt

after revoking the certificate was not successful.

Test 4 – The evaluator configured an OCSP responder to present a certificate that does not have the OCSP signing

purpose. The evaluator established a TLS session from the TOE TLS client such that the TOE receives OCSP

response signed by the invalid certificate and ensured that the TLS session was not negotiated successfully.

Test 5- The evaluator configured a test server to present a certificate that had a byte in the first eight bytes

modified to the TOE. The evaluator then attempted to make a connection between the peer devices. When the

TOE attempted to connect, the connection failed.

Test 6 – The evaluator configured a test server to present a certificate that had a byte in the last eight bytes

modified to the TOE. The evaluator then attempted to make a connection between the peer devices. When the

TOE attempted to connect, the connection failed.

Test 7- The evaluator configured a test server to present a certificate that had a byte in the public key of the

certificate modified to the TOE. The evaluator then attempted to make a connection between the peer devices.

When the TOE attempted to connect, the connection was refused.

2.3.5.2 FIA_X509_EXT.1.2



Testing Assurance Activities: The evaluator shall perform the following tests for FIA_X509_EXT.1.2. The tests

described must be performed in conjunction with the other certificate services assurance activities, including the

functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the

uses that require those rules.

The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two intermediate

CAs, and the self-signed Root CA.

Version 0.3, 06/22/2017


Test 1: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE's

certificate does not contain the basicConstraints extension. The validation of the certificate path fails.


certificate has the cA flag in the basicConstraints extension set to FALSE. The validation of the certificate path fails.


certificate has the cA flag in the basicConstraints extension set to TRUE. The validation of the certificate path

succeeds.

The evaluator created a certificate chain containing a CA certificate lacking the basicConstraints extension. The

evaluator then attempted to import this chain into the TOE and the attempt to import was rejected.

The evaluator created a certificate chain containing a CA certificate having the basicConstraints section but with

the cA flag not set. The evaluator then attempted to import this chain into the TOE and the attempt to import was

rejected.

The evaluator created a certificate chain containing a CA certificate having the basicConstraints section but with

the cA flag set to TRUE. The evaluator then imported this chain into the TOE successfully.

Component TSS Assurance Activities: The evaluator shall ensure the TSS describes where the check of validity of

the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path

validation algorithm.

(Per TD0117) The evaluator shall ensure the TSS describes when the check of validity of the certificates takes place.

It is expected that revocation checking is performed when a certificate is used in an authentication step and when

performing trusted updates (if selected). It is not sufficient to verify the status of a X.509 certificate only when it's

loaded onto the device.

It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for

using X.509 certificates for self-testing is selected).

Section 6.3 of [ST] explains that certificates are validated as part of the authentication process when they are

presented to the TOE and when they are loaded into the TOE. This section also provide an explanation of the

validation of a certificate.


Component Testing Assurance Activities: (Per TD0117) The evaluator shall demonstrate that checking the validity

of a certificate is performed when a certificate is used in an authentication step or when performing trusted

updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it's

loaded onto the device.

Version 0.3, 06/22/2017


It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for

using X.509 certificates for self-testing is selected).

The FIA_X509_EXT.1.1 tests are performed by sending a certificate chain to the TOE where the presented

certificates have issues specific to each test. In some tests, the certificates are even revoked. While the TOE

includes pre-loaded certificates (in comes cases certificates for the same entity), the fact that the TOE detects

revoked, certificates or issues with the certificates being presented during a connection, indicates that the TOE is

examining the presented certificates not simply accepting a preloaded certificate as valid.

2.3.6 X.509 CERTIFICATE AUTHENTICATION (FIA_X509_EXT.2)

2.3.6.1 FIA_X509_EXT.2.1




2.3.6.2 FIA_X509_EXT.2.2




Component TSS Assurance Activities: The evaluator shall check the TSS to ensure that it describes how the TOE

chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the

operating environment so that the TOE can use the certificates.

The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection

cannot be established during the validity check of a certificate used in establishing a trusted channel. The

evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the

administrator is able to specify the default action, then the evaluator shall ensure that the guidance

documentation contains instructions on how this configuration action is performed.

Section 6.3 also states that if certificates are found invalid, they are not accepted. Section 6.3 states that

certificates are check (for their OCSP status), and if not found to be valid, the certificates are rejected. This

includes the case where an OCSP server cannot be contacted.

Version 0.3, 06/22/2017



Component Testing Assurance Activities: The evaluator shall perform the following test for each trusted channel:

The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be

performed in at least some part by communicating with a non-TOE IT entity. The evaluator shall then manipulate

the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action

selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator

shall follow the guidance documentation to determine that all supported administrator-configurable options

behave in their documented manner.

The evaluator established a syslog connection from the TOE to a remote test server protected by TLS and obtained

a packet capture of the activity. This was repeated when the OCSP responder was available and unavailable. When

available the connection succeeded. When the OCSP responder was unavailable, the connection failed.

2.3.7 X.509 CERTIFICATE REQUESTS (FIA_X509_EXT.3)

2.3.7.1 FIA_X509_EXT.3.1




2.3.7.2 FIA_X509_EXT.3.2




Component TSS Assurance Activities: If the ST author selects 'device-specific information', the evaluator shall

verify that the TSS contains a description of the device-specific fields used in certificate requests.

This is not applicable since the requirement does not specify “device-specific information”.

Component Guidance Assurance Activities: The evaluator shall check to ensure that the guidance documentation

contains instructions on requesting certificates from a CA, including generation of a Certificate Request Message. If

the ST author selects 'Common Name', 'Organization', 'Organizational Unit', or 'Country', the evaluator shall ensure

Version 0.3, 06/22/2017


that this guidance includes instructions for establishing these fields before creating the certificate request

message.

The section entitled, “Configuring the Fabric OS switch for Common Criteria“in [CC-Guide] provides a list of


requirements from [ST]). Once specific step involves creation of a Certificate Request Message, and outlines the

fields requested by the TOE to create the Certificate Request Message.


Test 1: The evaluator shall use the guidance documentation to cause the TOE to generate a certificate request

message. The evaluator shall capture the generated message and ensure that it conforms to the format specified.

The evaluator shall confirm that the certificate request provides the public key and other required information,

including any necessary user-input information.

Test 2: The evaluator shall demonstrate that validating a certificate response message without a valid certification

path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed

to validate the certificate response message, and demonstrate that the function succeeds. The evaluator shall then

delete one of the certificates, and show that the function fails.

Test 1- The evaluator generated a certificate signing request as part of the configuration of the TOE. The evaluator

followed the instructions in the Admin-Guide when generating the request. The request was then exported to a

test server where it was examined and found to include the fields identified in the Security Target. The CSR was

also used to generate certificates on the test server, which were imported back into the TOE to complete

configuration.

Test 2 - The evaluator tested that a certificate without an intermediate CA cannot be imported into the TOE.

2.4 SECURITY MANAGEMENT (FMT)

2.4.1 MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR - TRUSTED UPDATE

(FMT_MOF.1(1))

2.4.1.1 FMT_MOF.1(1).1



Version 0.3, 06/22/2017





Component Testing Assurance Activities: The evaluator shall try to perform the update using a legitimate update

image without prior authentication as security administrator (either by authentication as a user with no

administrator privileges or without user authentication at all â€“ depending on the configuration of the TOE). This

test should fail.

The evaluator shall try to perform the update with prior authentication as security administrator using a legitimate

update image. This test should pass. This test case should be covered by the tests for FPT_TUD_EXT.1 already.

As can be seen in the FTP_TRP.1-t1 test evidence, no functions are offered to users prior to a successful login. Any

user that can login, is considered an administrator and can perform TOE updates.

2.4.2 MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR - AUDIT (FMT_MOF.1(3))

2.4.2.1 FMT_MOF.1(3).1






Component Testing Assurance Activities: The evaluator shall try to modify all parameters for configuration of the

transmission protocol for transmission of audit data to an external IT entity without prior authentication as

security administrator (either by authentication as a user with no administrator privileges or without user

authentication at all â€“ depending on the configuration of the TOE). This test should fail.

The evaluator shall try to modify all parameters for configuration of the transmission protocol for transmission of

audit data to an external IT entity with prior authentication as security administrator. The effects of the

modifications should be confirmed.

The evaluator does not necessarily have to test all possible values of all parameters for configuration of the

transmission protocol for transmission of audit data to an external IT entity but at least one allowed value per

configurable parameter.

Version 0.3, 06/22/2017



user that can login, is considered an administrator and can configure the TOE.

2.4.3 MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR - AUDIT (FMT_MOF.1(4))

2.4.3.1 FMT_MOF.1(4).1






Component Testing Assurance Activities: The evaluator shall try to modify all parameters for configuration of the

handling of audit data without prior authentication as security administrator (either by authentication as a user

with no administrator privileges or without user authentication at all â€“ depending on the configuration of the

TOE). This test should fail. The term 'handling of audit data' refers to the different options for selection and

assignments in SFRs FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2.

The evaluator shall try to modify all parameters for configuration of the handling of audit data with prior

authentication as security administrator. The effects of the modifications should be confirmed. The term 'handling

of audit data' refers to the different options for selection and assignments in SFRs FAU_STG_EXT.1.2,

FAU_STG_EXT.1.3 and FAU_STG_EXT.2.

The evaluator does not necessarily have to test all possible values of all parameters for configuration of the

handling of audit data but at least one allowed value per configurable parameter.


user that can login, is considered an administrator and can configure the TOE auditing.

2.4.4 MANAGEMENT OF TSF DATA (FMT_MTD.1(1))

Version 0.3, 06/22/2017


2.4.4.1 FMT_MTD.1(1).1




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that, for each

administrative function identified in the guidance documentation; those that are accessible through an interface

prior to administrator log-in are identified. For each of these functions, the evaluator shall also confirm that the

TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-

administrative users.

Section 6.4 of the ST states that none of the functions available to an authorized administrator are available prior

to the user being identified and authenticated.

Component Guidance Assurance Activities: The evaluator shall review the guidance documentation to determine

that each of the TSF-data-manipulating functions implemented in response to the requirements of the cPP is

identified, and that configuration information is provided to ensure that only administrators have access to the

functions.

The section entitled, “Configuring the Fabric OS switch for Common Criteria“in [CC-Guide] directs the user to log in

as administrator and describes the default roles as well as how to configure user defined roles with administrative

privileges. All such users are considered administrators and can manage the TOE both locally and remotely by

logging into the TOE via console, SSH or Web Tools.


2.4.5 MANAGEMENT OF TSF DATA - ADMIN ACTIONS (FMT_MTD.1(2))

2.4.5.1 FMT_MTD.1(2).1






Version 0.3, 06/22/2017


Component Testing Assurance Activities: The evaluator shall try to perform at least one of the related actions

without prior authentication as security administrator (either by authentication as a user with no administrator

privileges or without user authentication at all â€“ depending on the configuration of the TOE). This test should

fail.

The evaluator shall try to perform at least one of the related actions with prior authentication as security

administrator. This test should pass.

FMT_MOF.1(1)-t1 demonstrates that administrative commands to update the TOE are not available prior to the

administrator being authenticated. FPT_TUD_EXT.1-t1 shows the same commands being used by an administrator

after login.

2.4.6 SPECIFICATION OF MANAGEMENT FUNCTIONS (FMT_SMF.1)

2.4.6.1 FMT_SMF.1.1




Component TSS Assurance Activities: The security management functions for FMT_SMF.1 are distributed

throughout the cPP and are included as part of the requirements in FTA_TAB.1, FTA_SSL.3, FTA_SSL.4,

FMT_MOF.1(1), FMT_MOF.1(2) (if included in the ST), FIA_X509_EXT.2.2 & FPT_TUD_EXT.2.2 (if included in the ST

and if they include an administrator-configurable action), FMT_MOF.1(1), FMT_MOF.1(2)t, FMT_MOF.1.1(1),

FMT_MOF.1.1(2) and FMT_MOF.1 (for all of these SFRs that are included in the ST), FMT_MTD, FPT_TST_EXT, and

any cryptographic management functions specified in the reference standards. Compliance to these requirements

satisfies compliance with FMT_SMF.1.

Compliance to the security management functions for FMT_SMF.1 is verified and described throughout this AAR.



Version 0.3, 06/22/2017


2.4.7 RESTRICTIONS ON SECURITY ROLES (FMT_SMR.2)

2.4.7.1 FMT_SMR.2.1




2.4.7.2 FMT_SMR.2.2




2.4.7.3 FMT_SMR.2.3





Component Guidance Assurance Activities: The evaluator shall review the guidance documentation to ensure that

it contains instructions for administering the TOE both locally and remotely, including any configuration that needs

to be performed on the client for remote administration.

The “Network Interface” section in [CC-Guide] provides instructions and references for configuring and using Web

Tools and an SSH client. The section entitled “Configuring the Fabric OS switch for Common Criteria” in the [CC-

Guide] describes how to configure the TOE for secure communications using SSH and Web Tools. Additionally, this

section describes how users are associated with roles and how administrators can manage the TOE both locally

and remotely by logging into the TOE via console, SSH or Webtools.

Component Testing Assurance Activities: In the course of performing the testing activities for the evaluation, the

evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an

administrative action with each interface. The evaluator shall ensure, however, that each supported method of

administering the TOE that conforms to the requirements of this cPP be tested; for instance, if the TOE can be

administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration

must be exercised during the evaluation team's test activities.

Version 0.3, 06/22/2017


Testing of TOE security protocols (e.g., SSH and TLS) along with the manipulation of X509 certificates was

conducted using primarily the TOE CLI that is available via SSHv2. Refer to FCS_TLSS_EXT.1 and FCS_TLSC_EXT.1

for results of that testing.

Testing of timeout values, authentication, TOE updates, self-tests, and changes to time were tested using both the

SSH and Web UI, thus demonstrating the capability of both interfaces.

2.5 PROTECTION OF THE TSF (FPT)

2.5.1 PROTECTION OF ADMINISTRATOR PASSWORDS (FPT_APW_EXT.1)

2.5.1.1 FPT_APW_EXT.1.1




2.5.1.2 FPT_APW_EXT.1.2




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details all

authentication data that are subject to this requirement, and the method used to obscure the plaintext password

data when stored. The TSS shall also detail passwords are stored in such a way that they are unable to be viewed

through an interface designed specifically for that purpose, as outlined in the application note.

Section 6.5 of the ST states that the TOE is designed specifically to not provide access to locally stored passwords

(which are protected using MD-5 hashing) and also, while cryptographic keys can be entered, the TOE does not

disclose any cryptographic keys stored in the TOE. The TOE does not offer any functions that will disclose to any

user a plain text password or a stored cryptographic key.



Version 0.3, 06/22/2017


2.5.2 PROTECTION OF TSF DATA (FOR READING OF ALL SYMMETRIC KEYS)

(FPT_SKP_EXT.1)

2.5.2.1 FPT_SKP_EXT.1.1




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details how any

preshared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an

interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in

plaintext, the TSS shall describe how they are protected/obscured.

Section 6.5 of the ST states that the TOE is designed specifically to not provide access to locally stored passwords

and cryptographic keys. While cryptographic keys can be entered, the TOE does not offer any functions to any

user that will disclose cryptographic keys stored in the TOE.



2.5.3 RELIABLE TIME STAMPS (FPT_STM.1)

2.5.3.1 FPT_STM.1.1




Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it lists each security

function that makes use of time. The TSS provides a description of how the time is maintained and considered

reliable in the context of each of the time related functions.

The evaluator examines the guidance documentation to ensure it instructs the administrator how to set the time.

If the TOE supports the use of an NTP server, the guidance documentation instructs how a communication path is

Version 0.3, 06/22/2017


established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support

this communication.

Section 6.5 of the ST states that the TOE’s embedded OS manages the clock and exposes administrator clock-

related functions. The TOE can be configured to periodically synchronize its clock with a time server, but the TOE

can only ensure its own reliability and not that of an external time mechanism. The TOE also implements the

timing elements through timeout functionality due to inactivity for terminating both local and remote sessions.

Note that the clock is used primarily to provide timestamp for audit records, but is also used to support timing

elements of cryptographic functions.



Test 1: The evaluator uses the guidance documentation to set the time. The evaluator shall then use an available

interface to observe that the time was set correctly.

Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance documentation 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. If the TOE supports multiple protocols for

establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol

claimed in the guidance documentation.

If the audit component of the TOE consists of several parts with independent time information, then the evaluator

shall verify that the time information between the different parts are either synchronized or that it is possible for

all audit information to relate the time information of the different part to one base information unambiguously.

The evaluator followed the guidance instructions to configure the time on the TOE. The evaluator read the time

from the TOE using a date command and also found audit records confirming that the time was successfully

changed.

The evaluator followed the guidance instructions to configure an NTP server to synchronize the time on the TOE.

The ‘date’ command confirms that the time change was successful and the audit record was consistent in

describing the change.

2.5.4 TSF TESTING (FPT_TST_EXT.1)

2.5.4.1 FPT_TST_EXT.1.1



Version 0.3, 06/22/2017



Component TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it details the self tests

that are run by the TSF; this description should include an outline of what the tests are actually doing (e.g., rather

than saying 'memory is tested', a description similar to 'memory is tested by writing a value to each memory

location and reading it back to ensure it is identical to what was written' shall be used). The evaluator shall ensure

that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly.

Section 6.5 of the ST states that the TOE includes a number of built in diagnostic tests that are run during start-up

to determine whether the TOE is operating properly. An administrator can configure the TOE to reboot or to stop,

with errors displayed, when an error is encountered. When configured, the power-on self-tests comply with the

FIPS 140-2 requirements for self-testing. The module performs cryptographic algorithm known answer tests,

firmware integrity tests using RSA signature verification and conditional self-tests for PRNG, pair-wise consistency

tests on generation of RSA keys, and a firmware load test (RSA signature verification). Upon failing any of its FIPS

mode power-on self-tests, the TOE will refuse to boot.

Component Guidance Assurance Activities: The evaluator shall also ensure that the guidance documentation

describes the possible errors that may result from such tests, and actions the administrator should take in

response; these possible errors shall correspond to those described in the TSS.

The “Self-tests” section of [CC-Guide] includes a note stating the following.

“During a self-test failure, Brocade recommends that you restart the system and test again. If the failure

persists, proceed with the Return Materials Authorization (RMA) request for the device.”

Component Testing Assurance Activities: Future versions of this cPP will mandate a clearly defined minimum set

of self tests. But also for this version of the cPP it is expected that at least the following tests are performed:

a) Verification of the integrity of the firmware and executable software of the TOE

b) Verification of the correct operation of the cryptographic functions necessary to fulfill any of the SFRs.

Although formal compliance is not mandated, the self tests performed should

aim for a level of confidence comparable to:

a) FIPS 140-2, chap. 4.9.1, Software/firmware integrity test for the verification of the integrity of the firmware and

executable software.

b) FIPS 140-2, chap. 4.9.1, Cryptographic algorithm test for the verification of the correct operation of

cryptographic functions. Alternatively, national requirements of any CCRA member state for the security

evaluation of cryptographic functions should be considered as appropriate.

Version 0.3, 06/22/2017


The evaluator shall verify that the self tests described above are either carried out during initial start-up and that

the developer has justified any deviation from this (if applicable).

During a reboot of the TOE, the evaluator confirmed that the TOE performed self tests to verify the firmware

integrity and the cryptographic functions as identified in the screenshot below. The output of these tests indicate

that they were successful. The firmware integrity test passed and all other tests were successfully completed with

no errors.

2.5.5 TRUSTED UPDATE (FPT_TUD_EXT.1)

2.5.5.1 FPT_TUD_EXT.1.1




2.5.5.2 FPT_TUD_EXT.1.2




2.5.5.3 FPT_TUD_EXT.1.3




Component TSS Assurance Activities: The evaluator shall verify that the TSS describes all TSF software update

mechanisms for updating the system software. The evaluator shall verify that the description includes a digital

signature verification of the software before installation and that installation fails if the verification fails.

Alternatively an approach using a published hash can be used. In this case the TSS shall detail this mechanism

instead of the digital signature verification mechanism. The evaluator shall verify that the TSS describes the

method by which the digital signature or published hash is verified to include how the candidate updates are

Version 0.3, 06/22/2017


obtained, the processing associated with verifying the digital signature or published hash of the update, and the

actions that take place for both successful and unsuccessful signature verification or published hash verification.

If the ST author indicates that a certificate-based mechanism is used for software update digital signature

verification, the evaluator shall verify that the TSS contains a description of how the certificates are contained on

the device. The evaluator also ensures that the TSS (or guidance documentation) describes how the certificates are

installed/updated/selected, if necessary.

(Per TD0094) If a published hash is used to protect the trusted update mechanism, then the evaluator shall verify

that the trusted update mechanism does involve an active authorization step of the Security Administrator, and

that download of the published hash value, hash comparison and update is not a fully automated process involving

no active authorization by the Security Administrator. In particular, authentication as Security Administration

according to FMT_MOF.1/ManualUpdate needs to be part of the update process when using published hashes.

Per TD0154: If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe

how and when the inactive version becomes active. The evaluator shall verify this description.

Section 6.5 of the ST states that the TOE supports loading a new software image manually by the administrator

using CLI commands. From the CLI, an administrator can use the ‘firmwareDownload’ command in order to

download a new firmware image, and the TOE, prior to actually installing and using the new software image, will

verify its digital certificate using the public key in the certificate configured in the TOE. An unverified image cannot

be installed. When a new firmware is downloaded, the new firmware always replaces the public key file on the

switch with what is in the new firmware.

Component Guidance Assurance Activities: The evaluator shall verify that the guidance documentation describes

how the verification of the authenticity of the update is performed (digital signature verification or verification of

published hash). The description shall include the procedures for successful and unsuccessful verification. The

description shall correspond to the description in the TSS.

(Per TD0094) If a published hash is used to protect the trusted update mechanism, the evaluator shall verify that

the guidance documentation describes how the Security Administrator can obtain authentic published hash values

for the updates.

The section entitled, “Firmware update” in [CC-Guide] describes how the verification of the authenticity of the

update is performed via digital signature verification. RPM packages are signed using a 2048-bit RSA key with SHA-

256 during the firmware build and each package is validated by verifying the signature during firmware installation.

When a new firmware is downloaded, the new firmware always replaces the public key file on the switch with

what is in the new firmware. If the installation fails, an error with details is displayed and the download procedure

is terminated. This description is consistent with the description in the TSS.


Version 0.3, 06/22/2017


Test 1: The evaluator performs the version verification activity to determine the current version of the product as

well as the most recently installed version (should be the same version before updating). The evaluator obtains a

legitimate update using procedures described in the guidance documentation and verifies that it is successfully

installed on the TOE. For some TOEs loading the update onto the TOE and activation of the update are separate

steps ('activation' could be performed e.g. by a distinct activation step or by rebooting the device). In that case the

evaluator verifies after loading the update onto the TOE but before activation of the update that the current

version of the product did not change but the most recently installed version has changed to the new product

version. After the update, the evaluator performs the version verification activity again to verify the version

correctly corresponds to that of the update and that current version of the product and most recently installed

version match again.

(Per TD0094) Test 2 (if digital signatures are used): The evaluator first confirms that no updates are pending and

then performs the version verification activity to determine the current version of the product, verifying that it is

different from the version claimed in the update(s) to be used in this test. The evaluator obtains or produces

illegitimate updates as defined below, and attempts to install them on the TOE. The evaluator verifies that the TOE

rejects all of the illegitimate updates. The evaluator performs this test using all of the following forms of

illegitimate updates:

1. A modified version (e.g. using a hex editor) of a legitimately signed update.

2. An image that has not been signed

3. An image signed with an invalid signature (e.g. by using a different key as expected for creating the signature or

by manual modification of a legitimate signature).

4. If the TOE allows a gap between the installation of an update and a required reboot or activation to execute the

updated code, the TOE must be able to display both the currently executing version and most recently installed

version. The handling of version information of the most recently installed version might differ between different

TOEs depending on the point in time when an attempted update is rejected. The evaluator shall verify that the TOE

handles the most recently installed version information for that case as described in the guidance documentation.

After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently

installed version, reflect the same version information as prior to the update attempt.

Test 2 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security

Administrator and the verification of the hash value over the update file(s) against the published hash is performed

by the TOE, then the evaluator shall perform the following tests. The evaluator first confirms that no update is

pending and then performs the version verification activity to determine the current version of the product,

verifying that it is different from the version claimed in the update(s) to be used in this test.

1. The evaluator obtains or produces an illegitimate update such that the hash of the update does not match the

published hash. The evaluator provides the published hash value to the TOE and calculates the hash of the update

either on the TOE itself (if that functionality is provided by the TOE), or else outside the TOE. The evaluator

Version 0.3, 06/22/2017


confirms that the hash values are different, and attempts to install the update on the TOE, verifying that this fails

because of the difference in hash values (and that the failure is logged). Depending on the implementation of the

TOE, the TOE might not allow the user to even attempt updating the TOE after the verification of the hash value

fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct

behaviour of the TOE.

2. The evaluator uses a legitimate update and tries to perform verification of the hash value without storing the

published hash value on the TOE. The evaluator confirms that this attempt fails. Depending on the implementation

of the TOE it might not be possible to attempt the verification of the hash value without providing a hash value to

the TOE, e.g. if the hash value needs to be handed over to the TOE as a parameter in a command line message and

the syntax check of the command prevents the execution of the command without providing a hash value. In that

case the mechanism that prevents the execution of this check shall be tested accordingly, e.g. that the syntax

check rejects the command without providing a hash value, and the rejection of the attempt is regarded as

sufficient verification of the correct behaviour of the TOE in failing to verify the hash. The evaluator then attempts

to install the update on the TOE (in spite of the unsuccessful hash verification) and confirms that this fails.

Depending on the implementation of the TOE, the TOE might not allow to even attempt updating the TOE after the

verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as

sufficient verification of the correct behaviour of the TOE.

3. If the TOE allows a gap between the installation of an update and a required reboot or activation to execute the

updated code, the TOE must be able to display both the currently executing version and most recently installed

version. The handling of version information of the most recently installed version might differ between different

TOEs. Depending on the point in time when the attempted update is rejected, the most recently installed version

might or might not be updated. The evaluator shall verify that the TOE handles the most recently installed version

information for that case as described in the guidance documentation. After the TOE has rejected the update the

evaluator shall verify, that both, current version and most recently installed version, reflect the same version

information as prior to the update attempt.

The evaluator shall perform the Tests 1 and 2 for all methods supported (manual updates, automatic checking for

updates, automatic updates). If the verification of the hash value over the update file(s) against the published hash

is not performed by the TOE, Test 2 shall be skipped.

Prior to performing an update, the evaluator verified the TOE version TOE commands. The evaluator then

followed guidance to install a valid update to the TOE. Upon successful installation, the evaluator verified the TOE

version once again and confirmed that the version after the successful update was changed as expected.

The evaluator attempted to perform a TOE update using a legitimate update that was modified using a hex editor.

The TOE rejected the modified update and the product version did not change.

The evaluator attempted to perform a TOE update using an image with the digital signature removed. The TOE

rejected the modified update and the product version did not change.

Version 0.3, 06/22/2017


The evaluator attempted to perform a TOE update using an image with the digital signature manually modified.

The TOE rejected the modified update and the product version did not change.

2.6 TOE ACCESS (FTA)

2.6.1 TSF-INITIATED TERMINATION (FTA_SSL.3)

2.6.1.1 FTA_SSL.3.1






Component Testing Assurance Activities: The evaluator shall perform the following test:

Test 1: The evaluator follows the guidance documentation 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.

The evaluator followed the guidance to configure the session timeout periods for SSH CLI remote sessions and

confirmed that the session was terminated after the configured time period. The inactivity time period was

configured for periods of 1 minute, 3 minutes and 5 minutes

2.6.2 USER-INITIATED TERMINATION (FTA_SSL.4)

2.6.2.1 FTA_SSL.4.1





Version 0.3, 06/22/2017




Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the guidance

documentation to exit or log off the session and observes that the session has been terminated.

Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the guidance

documentation to exit or log off the session and observes that the session has been

terminated.

The evaluator logged in to the local console and then typed in the command ‘logout’. The screenshot below

shows that the session ended and the login prompt was presented.

2.6.3 TSF-INITIATED SESSION LOCKING (FTA_SSL_EXT.1)

2.6.3.1 FTA_SSL_EXT.1.1






Component Testing Assurance Activities: The evaluator shall perform the following test:

Test 1: The evaluator follows the guidance documentation 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

reauthentication is needed when trying to unlock the session.

The evaluator followed the guidance to configure the idle timeout periods for the Local Console session and

confirmed that the session was terminated after the configured time period. The inactivity time period was

configured using the ‘timeout’ command for periods of 1 minute, 3 minutes and 5 minutes.

Version 0.3, 06/22/2017


2.6.4 DEFAULT TOE ACCESS BANNERS (FTA_TAB.1)

2.6.4.1 FTA_TAB.1.1




Component TSS Assurance Activities: The evaluator shall check the TSS to ensure that it details each method of

access (local and remote) available to the administrator (e.g., serial port, SSH, HTTPS).

Section 6.6 of the ST states that the TOE can be configured to display an administrator-configured message of the

day and banner that will be displayed before authentication is completed. In the case of the console and SSH, the

message of the day is displayed before entering the user password and the banner is displayed afterwards. In the

case of the web interface, the banner is displayed when connected to a session.


Component Testing Assurance Activities: The evaluator shall also perform the following test:

Test 1: The evaluator follows the guidance documentation 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.

The evaluator configured two banners (one for before authentication and a second to follow authentication) and

then verified that the banners displayed appropriately for each login method.

2.7 TRUSTED PATH/CHANNELS (FTP)

2.7.1 INTER-TSF TRUSTED CHANNEL (FTP_ITC.1)

2.7.1.1 FTP_ITC.1.1




Version 0.3, 06/22/2017


2.7.1.2 FTP_ITC.1.2




2.7.1.3 FTP_ITC.1.3




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that, for all

communications with authorized IT entities identified in the requirement, each communications mechanism is

identified in terms of the allowed protocols for that IT entity. The evaluator shall also confirm that all protocols

listed in the TSS are specified and included in the requirements in the ST.

Section 6.7 of the ST states that remote connections to third-party SYSLOG servers are supported for exporting

audit records to an external audit server. Communication with external audit servers is protected using TLS. This is

consistent with the protocol listed in the requirement.

Component Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains

instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery

instructions should a connection be unintentionally broken.



requirements from [ST]). This includes the steps to configure the use of TLS to protect syslog communication.


Test 1: 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 guidance documentation

and ensuring that communication is successful.

Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the

guidance documentation to ensure that in fact the communication channel can be initiated from the TOE.

Version 0.3, 06/22/2017


Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data

is not sent in plaintext.

Test 4: 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.

Further assurance activities are associated with the specific protocols.

The TOE utilizes TLS for trusted channels protecting communication with an external audit server (syslog server).

A successful TOE TLS connection supporting communication to an external audit server was established.

Examining the packet capture from that test we see that the TLS v1.2 connection between the TOE component and

the external syslog server was established; the TOE initiated the connection; and Application data transferred is

encrypted (i.e., not plaintext).

The evaluator began a packet capture off traffic between the TOE and external audit sever. With the connection

established, the evaluator physically disconnected the network between the TOE and the remote audit server. The

evaluator left the network disconnected for roughly 40 minutes, and reconnected the wiring. Because the TOE

automatically reconnects broken TLS connections, the evaluator waited for the syslog server to begin receiving

audit data again and stopped the packet capture shortly after traffic began flowing after the disruption. The

evaluator observed that a new TLS session was negotiated and no data was transmitted unprotected.

2.7.2 TRUSTED PATH (FTP_TRP.1)

2.7.2.1 FTP_TRP.1.1




2.7.2.2 FTP_TRP.1.2




Version 0.3, 06/22/2017


2.7.2.3 FTP_TRP.1.3




Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that the methods of

remote TOE administration are indicated, along with how those communications are protected. The evaluator shall

also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified

in the requirement, and are included in the requirements in the ST.

Section 6.7 of the ST states that the TOE uses SSH and HTTPS to provide a trusted path for remote management

interfaces. The TOE provides a trusted path for its remote administrative users accessing the TOE via the Ethernet

ports provided on the TOE using either the command line interface using SSH or Advanced Web Tools using

TLS/HTTPS. When an administrator attempts to connect to the TOE remotely, the TOE attempts to negotiate a

session. If the session cannot be negotiated, the connection is dropped. When negotiating a TLS/HTTPS or SSH

session, the TOE and the client application (SSH client or web browser) used by the administrator will negotiate the

most secure algorithms available at both ends to protect that session. The protocols described in the TSS for

remote management are consistent with those identified in the requirements.

Component Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains

instructions for establishing the remote administrative sessions for each supported method.



requirements from [ST]). This includes the steps to configure the use of HTTPS/TLS to protect use of the Web UI

and SSH to protect use of the CLI.


Test 1: The evaluators shall ensure that communications using each specified (in the guidance documentation)

remote administration method is tested during the course of the evaluation, setting up the connections as

described in the guidance documentation and ensuring that communication is successful.

Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the

guidance documentation to ensure that in fact the communication channel can be initiated from the TOE.

Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data

is not sent in plaintext.

Version 0.3, 06/22/2017


Test 4: The evaluators shall ensure that, 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.

Further assurance activities are associated with the specific protocols.

The TOE offers the following remote administration interfaces:

An HTTPS/TLS protected Graphical User Interface (GUI)

An SSHv2 protected command line interface (CLI)

The evaluator repeated the following on the GUI and to the CLI.

a) The evaluator initiated a packet capture of traffic between a remote administrative workstation

and the TOE.

b) The evaluator connected to the TOE and performed a login using an administrator account

c) The evaluator then terminated the connection by ‘Logout’ and terminated the packet capture.

The evaluator established two packet capture of an SSH and HTTPS connection to the TOE respectively, then

caused a physical disruption of the network connection between the administrative workstation and the TOE. The

disruption lasted roughly 3 minutes. The sessions both terminated and needed to be renegotiated following the

reconnection of the network. No date was transmitted unprotected.

Version 0.3, 06/22/2017


3 PROTECTION PROFILE SAR ASSURANCE ACTIVITIES

The following sections address assurance activities specifically defined in the claimed Protection Profile that

correspond with Security Assurance Requirements.

3.1 DEVELOPMENT (ADV)

3.1.1 BASIC FUNCTIONAL SPECIFICATION (ADV_FSP.1)

Assurance Activities: The functional specification describes the TOE Security Functions Interfaces (TSFIs). It is not

necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to

this cPP will necessarily have interfaces to the Operational Environment that are not directly invokable by TOE

users, there is little point specifying that such interfaces be described in and of themselves since only indirect

testing of such interfaces may be possible. For this cPP, the Evaluation Activities for this family focus on

understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces

presented in the AGD documentation. No additional 'functional specification' documentation is necessary to satisfy

the Evaluation Activities specified in the SD.

The Evaluation Activities in the SD are associated with the applicable SFRs; since these are directly associated with

the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is

necessary.

The evaluator shall check the interface documentation to ensure it describes the purpose and method of use for

each TSFI that is identified as being security relevant.

In this context, TSFI are deemed security relevant if they are used by the administrator to configure the TOE, or to

perform other administrative functions (e.g., audit review or performing updates). Additionally, those interfaces

that are identified in the ST, or guidance documentation, as adhering to the security policies (as presented in the

SFRs), are also considered security relevant. The intent, is that these interfaces will be adequately tested, and

having an understanding of how these interfaces are used in the TOE is necessary to ensure proper test coverage is

applied.

The evaluator shall check the interface documentation to ensure it identifies and describes the parameters for

each TSFI that is identified as being security relevant.

The documents to be examined for this assurance component in an evaluation are therefore the Security Target,

AGD documentation, and any supplementary information required by the cPP for aspects such as entropy analysis

or cryptographic key management architecture1: no additional 'functional specification' documentation is

necessary to satisfy the Evaluation Activities. The interfaces that need to be evaluated are also identified by

reference to the assurance activities listed for each SFR, and are expected to be identified in the context of the

Version 0.3, 06/22/2017


Security Target, AGD documentation, and any supplementary information required by the cPP rather than as a

separate list specifically for the purposes of CC evaluation. The direct identification of documentation

requirements and their assessment as part of the Evaluation Activities for each SFR also means that the tracing

required in ADV_FSP.1.2D is treated as implicit, and no separate mapping information is required for this element.

However, if the evaluator is unable to perform some other required Evaluation Activity because there is

insufficient design and interface information, then the evaluator is entitled to conclude that an adequate

functional specification has not been provided, and hence that the verdict for the ADV_FSP.1 assurance

component is a 'fail'.

For this cPP, the Evaluation Activities for this family focus on understanding the interfaces presented in the TSS in

response to the functional requirements and the interfaces presented in the AGD documentation. No additional

'functional specification' documentation is necessary to satisfy the Evaluation Activities specified in the SD.

3.2 GUIDANCE DOCUMENTS (AGD)

3.2.1 OPERATIONAL USER GUIDANCE (AGD_OPE.1)

Assurance Activities: The operational user guidance does not have to be contained in a single document. Guidance

to users, administrators and application developers can be spread among documents or web pages.

The developer should review the Evaluation Activities contained in the SD to ascertain the specifics of the guidance

that the evaluator will be checking for. This will provide the necessary information for the preparation of

acceptable guidance.

The evaluator shall check the requirements below are met by the guidance documentation.

Guidance documentation shall be distributed to administrators and users (as appropriate) as part of the TOE, so

that there is a reasonable guarantee that administrators and users are aware of the existence and role of the

documentation in establishing and maintaining the evaluated configuration.

Guidance documentation must be provided for every Operational Environment that the product supports as

claimed in the Security Target and must adequately address all platforms claimed for the TOE in the Security

Target.

The contents of the guidance documentation will be verified by the Evaluation Activities defined below and as

appropriate for each individual SFR in section 2 above.

In addition to SFR-related Evaluation Activities, the following information is also required.

Version 0.3, 06/22/2017


a) The guidance documentation shall contain instructions for configuring any cryptographic engine associated with

the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other

cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.

b) The documentation must describe the process for verifying updates to the TOE by verifying a digital signature.

The evaluator shall verify that this process includes the following steps:

1) Instructions for obtaining the update itself. This should include instructions for making the update accessible to

the TOE (e.g., placement in a specific directory).

2) Instructions for initiating the update process, as well as discerning whether the process was successful or

unsuccessful. This includes generation of the hash/digital signature.

c) The TOE will likely contain security functionality that does not fall in the scope of evaluation under this cPP. The

guidance documentation shall make it clear to an administrator which security functionality is covered by the

Evaluation Activities.

The [CC-Guide] contains guidance to administrator on how to configure and use the TOE in a manner consistent

with the requirements in [ST]. Sections within [CC-Guide] provide information related to firmware updates,

cryptographic configuration, Self-tests, and refer to the [ST] for specific references related to features that were

evaluated.

3.2.2 PREPARATIVE PROCEDURES (AGD_PRE.1)

Assurance Activities: As with the operational guidance, the developer should look to the Evaluation Activities to

determine the required content with respect to preparative procedures.

The evaluator shall check the requirements below are met by the preparative procedures.

The contents of the preparative procedures will be verified by the Evaluation Activities defined below and as


Preparative procedures shall be distributed to administrators and users (as appropriate) as part of the TOE, so that

there is a reasonable guarantee that administrators and users are aware of the existence and role of the

documentation in establishing and maintaining the evaluated configuration.

The contents of the preparative procedures will be verified by the Evaluation Activities defined below and as


In addition to SFR-related Evaluation Activities, the following information is also required.

Preparative procedures must include a description of how the adminstrator verifies that the operational

environment can fulfil its role to support the security functionality (including the requirements of the Security

Objectives for the Operational Environment specified in the Security Target). The documentation should be in an

Version 0.3, 06/22/2017


informal style and should be written with sufficient detail and explanation that they can be understood and used

by the target audience (which will typically include IT staff who have general IT experience but not necessarily

experience with the TOE product itself).

Preparative procedures must be provided for every Operational Environment that the product supports as claimed

in the Security Target and must adequately address all platforms claimed for the TOE in the Security Target.

The preparative procedures must include

a) instructions to successfully install the TSF in each Operational Environment; and

b) instructions to manage the security of the TSF as a product and as a component of the larger operational

environment; and

c) instructions to provide a protected administrative capability.



requirements from [ST]).

3.3 LIFE-CYCLE SUPPORT (ALC)

3.3.1 LABELLING OF THE TOE (ALC_CMC.1)

Assurance Activities: This component is targeted at identifying the TOE such that it can be distinguished from

other products or versions from the same vendor and can be easily specified when being procured by an end user.

A label could consist of a 'hard label' (e.g., stamped into the metal, paper label) or a 'soft label' (e.g., electronically

presented when queried).

The evaluator performs the CEM work units associated with ALC_CMC.1.

The evaluator verified that the ST, TOE and Guidance are all labeled with the same hardware versions and

software. The information is specific enough to procure the TOE and it includes hardware models and software

versions. The evaluator checked the TOE software version and hardware identifiers during testing by examining

the actual machines used for testing.

3.3.2 TOE CM COVERAGE (ALC_CMS.1)

Assurance Activities: Given the scope of the TOE and its associated evaluation evidence requirements, the

evaluator performs the CEM work units associated with ALC_CMS.1.

See 3.3.1 for an explanation of how all CM items are addressed.

Version 0.3, 06/22/2017


3.4 SECURITY TARGET (ASE)

3.4.1 SECURITY TARGET (ASE_TSS.1)

3.5 TESTS (ATE)

3.5.1 INDEPENDENT TESTING - CONFORMANCE (ATE_IND.1)

Assurance Activities: Testing is performed to confirm the functionality described in the TSS as well as the guidance

documentation (includes 'evaluated configuration' instructions). The focus of the testing is to confirm that the

requirements specified in Section 5 are being met. The Evaluation Activities in the SD identify the specific testing

activities necessary to verify compliance with the SFRs. The evaluator produces a test report documenting the plan

for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are

claiming conformance to this cPP.

The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration

under evaluation as specified in the ST.

The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state.

The evaluator shall prepare a test plan that covers all of the testing actions for ATE_IND.1 in the CEM and in the

SFR-related Evaluation Activities. While it is not necessary to have one test case per test listed in an Evaluation

Activity, the evaluator must show in the test plan that each applicable testing requirement in the SFR-related

Evaluation Activities is covered.

The test plan identifies the platforms to be tested, and for any platforms not included in the test plan but included

in the ST, the test plan provides a justification for not testing the platforms. This justification must address the

differences between the tested platforms and the untested platforms, and make an argument that the differences

do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect;

rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.

The test plan describes the composition and configuration of each platform to be tested, and any setup actions

that are necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is

expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as

a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument

(not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the

functionality by the TOE and its platform. This also includes the configuration of any cryptographic engine to be

used (e.g. for cryptographic protocols being evaluated).

Version 0.3, 06/22/2017


The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those

objectives, and the expected results.

The test report (which could just be an updated version of the test plan) details the activities that took place when

the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account,

so if there was a test run that resulted in a failure, so that a fix was then installed and then a successful re-run of

the test was carried out, then the report would show a 'fail' result followed by a 'pass' result (and the supporting

details), and not just the 'pass' result.

The evaluator created a Detailed Test Report (DTR) to address all aspects of this requirement. The DTR discusses

the test configuration, test cases, expected results, and test results. Section 1.1, “Test Platform Equivalency”

describes the test configuration and test support environment used by the evaluators.

3.6 VULNERABILITY ASSESSMENT (AVA)

3.6.1 VULNERABILITY SURVEY (AVA_VAN.1)

Assurance Activities: Appendix A in [SD] provides a guide to the evaluator in performing a vulnerability analysis.

The evaluator shall document their analysis and testing of potential vulnerabilities with respect to this

requirement. This report could be included as part of the test report for ATE_IND, or could be a separate

document.

The evaluator formulates hypotheses in accordance with process defined in Appendix A. The evaluator documents

the flaw hypotheses generated for the TOE in the report in accordance with the guidelines in Appendix A.5. The

evaluator shall then perform vulnerability analysis in accordance with Appendix A.4. The results of the analysis

shall be documented in the report according to Appendix A.5.

The vulnerability analysis is in the Detailed Test Report (DTR) prepared by the evaluator. The vulnerability analysis

includes a public search for vulnerabilities and fuzz testing. None of the public search for vulnerabilities, or the

fuzz testing uncovered any residual vulnerability.

The evaluator searched the National Vulnerability Database (https://web.nvd.nist.gov/view/vuln/search) and

Vulnerability Notes Database (http://www.kb.cert.org/vuls/) with the following search terms: "SAN”, “Brocade”,

“FabricOS”, “OpenSSH”, and “OpenSSL”.

https://web.nvd.nist.gov/view/vuln/search

http://www.kb.cert.org/vuls/

assurance activity report (ndcpp10) for brocade ... · pdf file3.2 guidance documents (agd)...

Documents