Assurance Activity Report for Cisco Catalyst 6K Series Switches

Transcription

1 Assurance Activity Report for Cisco Catalyst 6K Series Switches Version /18/15 Prepared by: Gossamer Security Solutions Accredited Security Testing Laboratory Common Criteria Testing Catonsville, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme 2015 Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version /01/15 Compton Initial draft Version /11/15 Compton Update Test Equivalency Version /18/15 Compton Updated for Comments The TOE Evaluation was sponsored by: Cisco Systems, Inc., 170 West Tasman Drive San Jose, CA USA Evaluation Personnel: Tammy Compton Chris Keenan Khai Van 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, September 2012 GSS CCT Evaluation Technical Report Page 2 of Gossamer Security Solutions, Inc.

3 TABLE OF CONTENTS 1. Introduction Protection Profile SFR Assurance Activities Security audit (FAU) Audit Data Generation (FAU_GEN.1) User identity association (FAU_GEN.2) External Audit Trail Storage (FAU_STG_EXT.1) Cryptographic support (FCS) Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1) Cryptographic Key Zeroization (FCS_CKM_EXT.4) Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1)) Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2)) Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3)) Cryptographic Operation (for keyed-hash message authentication) (FCS_COP.1(4)) Explicit: IPSEC (FCS_IPSEC_EXT.1) Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT.1) Explicit: SSH (FCS_SSH_EXT.1) User data protection (FDP) Full Residual Information Protection (FDP_RIP.2) Identification and authentication (FIA) Password Management (FIA_PMG_EXT.1) Extended: Pre-Shared Key Composition (FIA_PSK_EXT.1) Protected Authentication Feedback (FIA_UAU.7) Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2) User Identification and Authentication (FIA_UIA_EXT.1) Security management (FMT) Management of TSF Data (for general TSF data) (FMT_MTD.1) Specification of Management Functions (FMT_SMF.1) Restrictions on Security Roles (FMT_SMR.2) GSS CCT Evaluation Technical Report Page 3 of Gossamer Security Solutions, Inc.

4 2.6 Protection of the TSF (FPT) Extended: Protection of Administrator Passwords (FPT_APW_EXT.1) Extended: Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) Reliable Time Stamps (FPT_STM.1) TSF Testing (FPT_TST_EXT.1) Extended: Trusted Update (FPT_TUD_EXT.1) TOE access (FTA) TSF-initiated Termination (FTA_SSL.3) User-initiated Termination (FTA_SSL.4) TSF-initiated Session Locking (FTA_SSL_EXT.1) Default TOE Access Banners (FTA_TAB.1) Trusted path/channels (FTP) Inter-TSF trusted channel (FTP_ITC.1) Trusted Path (FTP_TRP.1) Protection Profile SAR Assurance Activities Development (ADV) Basic functional specification (ADV_FSP.1) Guidance documents (AGD) Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) Life-cycle support (ALC) Labelling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) Tests (ATE) Independent testing - conformance (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1) GSS CCT Evaluation Technical Report Page 4 of Gossamer Security Solutions, Inc.

5 1. INTRODUCTION This document presents evaluation results of the Cisco Catalyst 6K Series Switches Protection Profile for Network Devices (NDPP) evaluation. This document contains a description of the assurance activities and associated results as performed by the evaluators. Note that this report is based on the Protection Profile for Network Devices, version 1.1, 8 June 2012 with Errata# EQUIVALENCE This section presents the test environment and explains why the test subset was adequate to address all product installations. The TOE includes the Cisco Catalyst Switches 6503-E, 6504-E, 6506-E, 6509-E, 6509-V-E and 6513-E with Supervisor Engine 2T (Excluding Sup720), C6880, 6807-X and the Cisco Catalyst Instant Access Solution using - C6800IA-48FPD, C6800IA-48TD, 6800IA-48FPDR and Cat 3560CX-12PD-S, all running Cisco IOS 15.2(1)SY1a software. All but the C6880 use the Freescale MPC8572 processor and the C6880 uses the Intel Gladden (Intel Core i3-2115c) processor. Since the same software is installed on all the platforms and all security functions provided by the TOE are implemented in software; the TOE security behavior is the same on all the switches for each of the SFRs defined by the NDPPv1.1. These SFRs are instantiated by the same version of the TOE software and in the same way on every platform. The evaluators sampled one TOE from each series of platforms and each processor family (6503 and 6880) and ran the entire test suite on each. The evaluators executed all applicable test requirements on both the 6503 and 6880 switches. The test procedures were based on the available guidance and provided identical in each case. Similarly, the results prove to be identical in each case. This further substantiates that the underlying OS did not have any bearing on the security claims. Note that all models in the evaluated configuration have been subject to CAVP testing and share the same cryptographic library. As such, it is concluded that the cryptographic functions are equivalent despite any model differences. GSS CCT Evaluation Technical Report Page 5 of Gossamer Security Solutions, Inc.

6 2. PROTECTION PROFILE SFR ASSURANCE ACTIVITIES This section of the ETR identifies each of the assurance activities included in the claimed Protection Profile and describes the findings in each case. The following evidence was used to complete the Assurance Activities: AA report v0.1 Cisco Catalyst 6K Series Switches Security Target, Version 1.0, December 18, 2015 [ST] Cisco Catalyst 6K Series Switches Common Criteria Operational User Guidance and Preparative Procedures, Version 0.3, December 18, 2015 [Admin-Guide] 2.1 SECURITY AUDIT (FAU) AUDIT DATA GENERATION (FAU_GEN.1) FAU_GEN.1.1 TSS Assurance Activities: For protocol related audit events: The evaluator shall check to ensure that the TSS contains a list (possibly empty except for authentication failures for user-level connections) of the protocol failures that are auditable. Section 6.1, Table 23 references the table of audit events in the SFR. The reference is a list of events, including protocol failures, starting and stopping the audit function, administrator commands, and authentication events. Guidance Assurance Activities: The evaluator shall check the administrative guide 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 PP is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in Table 1 of the NDPP. The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the administrative guide 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 PP. The evaluator shall document the methodology or approach taken while determining which GSS CCT Evaluation Technical Report Page 6 of Gossamer Security Solutions, Inc.

7 actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. Requirement Auditable Events Additional Audit Record Contents FAU_GEN.1 FAU_GEN.1 FCS_IPSEC_EXT.1 FCS_SSH_EXT.1 Startup of audit Shutdown of audit Failure to establish an IPsec SA. Establishment/Termination of an IPsec SA. Failure to establish an SSH session. Establishment/Termination of an SSH session. 1 Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures. Reason for failure Non-TOE endpoint of connection (IP address) for both successes and failures. FIA_UIA_EXT.1 FIA_UAU_EXT.2 All use of the identification and authentication mechanism. All use of the authentication mechanism. Provided user identity, origin of the attempt (e.g., IP address). Origin of the attempt (e.g., IP address). FPT_STM.1 Changes to the time. The old and new values for the time. Origin of the attempt (e.g., IP address). FPT_TUD_EXT.1 Initiation of update. No additional information. FTA_SSL_EXT.1 Any attempts at unlocking No additional information. of an interactive session. FTA_SSL.3 The termination of a No additional information. remote session by the session locking mechanism. FTA_SSL.4 The termination of an No additional information. interactive session. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted Identification of the initiator and target of failed trusted channels establishment attempt. channel functions. GSS CCT Evaluation Technical Report Page 7 of Gossamer Security Solutions, Inc.

8 FTP_TRP.1 FMT_SMF.1 (Administrator actions) Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Changes to the audit configuration User Account creation and password management Login policy management (time restrictions, minimum password length) Enabling FIPS mode Identification of the claimed user identity. The following commands were used during the evaluation. Access to each command required using the <enable password> and configure terminal commands Clock configuration: Show Clock: Switch> Show Clock Switch # clock set 1:1:1 1 Jan 2015 Router# configure terminal Router(config)# ntp server <IP address of NTP Server> Configure enable password: Switch(config)#enable password F A Configuring password minimum length: Switch(config)#aaa common-criteria policy ccpol GSS CCT Evaluation Technical Report Page 8 of Gossamer Security Solutions, Inc.

9 min-length 15 Configuring user: Switch(config)#username admin privilege 15 password 7 094D5A05180B Update TOE: Switch(config)#boot system flash: c6880x-adventerprisek9-mz.spa sy1a.bin Radius configuration: Switch(config)#radius-server attribute 6 on-for-login-auth Switch(config)#radius-server host key Pa55w*rd Switch(config)#radius-server host auth-port 1812 acct-port 1813 Switch(config)#radius-server key Pa55w*rd Switch(config)#ip radius source-interface Vlan3 Access List Configuration: Switch(config)#ip access-list extended acl_vpn permit icmp log deny icmp host host permit ip log permit ip host host GSS CCT Evaluation Technical Report Page 9 of Gossamer Security Solutions, Inc.

10 IPSec: Isakmp policy configuration example: Switch# conf t Switch(config)#crypto isakmp policy 1 Switch(config-isakmp)#hash sha Switch(config-isakmp)#encryption aes Switch(config-isakmp)#authentication pre-share Switch(config-isakmp)#group 14 Switch(config-isakmp)#lifetime Configuration of pre-shared keys: Switch(config)#crypto isakmp key cisco123!cisco123!cisc address Disable aggressive mode: Switch(config-isakmp)#crypto isakmp aggressive-mode disable IPsec lifetime and transform set configuration: Switch(config)#crypto ipsec security-association lifetime seconds Switch(config)#crypto ipsec security-association lifetime kilobytes Switch(config)#crypto ipsec transform-set myset1 esp-aes esp-sha-hmac mode tunnel Crypto map configuration: GSS CCT Evaluation Technical Report Page 10 of Gossamer Security Solutions, Inc.

11 Switch(config)#crypto map sample 19 ipsec-isakmp Switch(config-crypto-map)#set peer Switch (config-crypto-map)#set transform-set sampleset Switch (config-crypto-map)#set pfs group14 Switch (config-crypto-map)#match address 170 Interface Configuration: Switch (config)#interface gigabitethernet1/0/1 Switch (config-if)#ip address Switch (config-if)#crypto map sample Switch (config-if)#ip access-group acl in Loopback configuration: Switch(config-if)#interface Loopback1 Switch(config-if)#ip address Switch(config-if)#exit Syslog configuration: Switch(config)#logging host IP route configuration: Switch(config)#ip route Auditing: Switch(config)#archive Switch(config-archive)#log config Switch(config-archive-log-cfg)#logging enable GSS CCT Evaluation Technical Report Page 11 of Gossamer Security Solutions, Inc.

12 Switch(config-archive-log-cfg)#hidekeys Switch(config-archive-log-cfg)#logging size entires 1000 Switch(config-archive-log-cfg)#notify syslog Switch(config)#service timestamps log datetime year Switch(config)#service timestamps debug datetime year Switch(config)#login on-failure log Switch(config)#login on-success log Debugging: Switch(config)#debug radius authentication Switch(config)#debug ssh authentication Switch(config)#debug crypto isakmp Switch(config)#debug crypto ipsec Switch(config)#debug crypto ikev1 Switch(config)#debug ntp all Embedded Event Manager: Switch(config)#event manager applet cli_log Switch(config-applet)#event cli pattern ".*" sync yes Switch(config-applet)#action 1.0 info type routername Switch (config-applet)#action 2.0 if $_cli_privilege eq "15" Switch(config-applet)#exec_lvl[$_cli_privilege] command[$_cli_msg] Executed" Switch(config-applet)#action 4.0 end GSS CCT Evaluation Technical Report Page 12 of Gossamer Security Solutions, Inc.

13 Switch(config-applet)#action 5.0 set _exit_status "1" Login Banner: Switch(config)#banner login d This is a banner d Interactive session timeout Switch(config)# line console Switch(config-line)# exec-timeout 0 10 Remote session timeout: Switch(config)# line vty 0 15 Switch(config-line)# exec-timeout 0 10 SSH Configuration: Switch(config)# line vty 0 10 Switch(config)# transport input ssh Switch(config)# ip domain-name cisco.com Switch(config)# crypto key generate rsa 2048 Switch(config)# ip ssh dh min size 2048 SSH Public key configuration: Switch(config)# ip ssh pubkey-chain Switch(conf-ssh-pubkey)#username admin Switch (conf-ssh-pubkey-user)#key-string AG234FHABB GSS CCT Evaluation Technical Report Page 13 of Gossamer Security Solutions, Inc.

14 Remote SSH connection (from enable, no conf t): peer#ssh -l cisco -m hmac-sha Disable non evaluated services: hostname(config)# no ip http server hostname(config)# no ip http secure-server hostname(config)# no snmp-server hostname(config)# no vstack. Section of the Preparative Procedures Guidance details audit record format types and provides sample audit records for each event listed in the table above (Jan :05:49.460: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ranger] [Source: ] [localport: 22] at 00:05:49 EST Thu Jan ). With each record is the identification of how the audit event is generated. The guidance documentation states that the audit records include the date and time of the event, the type of event, subject identity (if applicable), the outcome of the event, and additional information related to the event. It also lists the following information which is included in an audit/log record: Element - Description seq no: - Stamps log messages with a sequence number only if the service sequence-numbers global configuration command is configured. For more information, see the "Enabling and Disabling Sequence Numbers in Log Messages" section. timestamp formats: o mm/dd hh:mm:ss or hh:mm:ss (short uptime) or d h (long uptime) Date and time of the message or event. This information appears only if the service timestamps log [datetime log] global configuration command is configured. For more information, see the "Enabling and Disabling Time Stamps on Log Messages" section. Facility - The facility to which the message refers (for example, SNMP, SYS, and so forth). For a list of supported facilities, see Table severity - Single-digit code from 0 to 7 that is the severity of the message. For a description of the severity levels, see Table MNEMONIC - Text string that uniquely describes the message. description - Text string containing detailed information about the event being reported. hostname-n - Hostname of a stack member and its switch number in the stack. Though the stack master is a stack member, it does not append its hostname to system messages. GSS CCT Evaluation Technical Report Page 14 of Gossamer Security Solutions, Inc.

15 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 table 1 of the NDPP and administrative actions. This should include all instances of an event--for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as expected. For protocol related audit events: The evaluator shall test all identified audit events during protocol testing/audit testing. The evaluator created a mapping for the required audit events to test cases where the associated function was tested. The evaluator then collected the audit event when running the security functional tests. For example, the required event for FCS_IPSEC.1 is Establishment/Termination of an IPsec session. The evaluator collected these audit records when establishing the IPsec sessions to test encryption algorithms for IPsec and recorded them in the 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 FAU_GEN.1.2 Testing Assurance Activities: None Defined GSS CCT Evaluation Technical Report Page 15 of Gossamer Security Solutions, Inc.

16 2.1.2 USER IDENTITY ASSOCIATION (FAU_GEN.2) FAU_GEN.2.1 Testing Assurance Activities: None Defined EXTERNAL AUDIT TRAIL STORAGE (FAU_STG_EXT.1) FAU_STG_EXT.1.1 TSS Assurance Activities: For both types of TOEs (those that act as an audit server and those that send data to an external audit server), there is some amount of local storage. 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. The evaluator shall also examine the operational guidance 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 TOEs that are not acting as an 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. TOE acts as audit server The evaluator shall examine the TSS to ensure it describes the connection supported from non-toe entities to send the audit data to the TOE, and how the trusted channel is provided. TOE is not an audit server 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. GSS CCT Evaluation Technical Report Page 16 of Gossamer Security Solutions, Inc.

17 Section 6.1 explains how the audit trail is protected. Only Authorized Administrators are able to clear the local logs, and local audit records are stored in a directory that does not allow administrators to modify the contents. Only administrators log onto the TOE. Section 6.1 (FAU_GEN.1) also explains there is a local audit log and the possibility of a remote audit log. The local log can store up to bytes of disk space after which the audit entries will be overwritten, oldest first. The administrator can choose to configure an external syslog server where the TOE will send a copy of the audit records if so desired. The TOE can be configured to use IPsec to protect audit logs exported to an external server. Guidance Assurance Activities: TOE acts as audit server The evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel with the TOE, as well as describe any requirements for other IT entities to connect and send audit data to the TOE (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with other IT entities. TOE is not an audit server The evaluator shall also examine the operational guidance 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 guidance documentation (section 3.3.5) details two syslog configurations which meet the trusted channel requirements. Syslog data protection is provided in the following two ways: 1. With a syslog/aaa server acting as an IPsec peer of the TOE and the records tunneled over that connection, or 2. With a syslog/aaa server that is not an IPsec peer of the TOE, but is physically co-located with an IPsec peer of the TOE within a trusted facility, and the records are tunneled over the connection to that IPsec peer. Section states the syslog server as an IPsec peer must, at a minimum, support peer authentication using RSA and pre-shared keys and the following algorithms AES-CBC-128 (as specified by RFC 3602) together with a Secure Hash Algorithm (SHA)-based HMAC, AES-CBC-256 (as specified by RFC 3602) and DH Groups 14 (2048-bit MODP) Section defines the configuration of a Syslog server running on an IPsec Endpoint and section defines the configuration for a Syslog Server Adjacent to an IPsec Peer. Both of these sections detail the configuration on the TOE required to establish an IPsec tunnel and syslog server. Testing Assurance Activities: TOE acts as audit server Testing of the trusted channel mechanism will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. GSS CCT Evaluation Technical Report Page 17 of Gossamer Security Solutions, Inc.

18 The evaluator shall perform the following test for this requirement: Test 1: The evaluator shall establish a session between an external IT entity and the TOE according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the IT entity and the TOE during several activities of the evaluator s choice designed to generate audit data to be transferred to the TOE. 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 TOE. The evaluator shall perform this test for each protocol selected in the second selection. TOE is not an audit server Testing of the trusted channel mechanism will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following test for this requirement: 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 followed the procedures in the guidance documentation for setting up the syslog server connection. The evaluator used Wireshark to observe the traffic between the TOE and the audit log server. The evaluator was able to establish a connection with each of the claimed IPsec ciphers while performing this test. The evaluator used the syslog server to store audit as recommended by the Cisco for the duration of testing so many audit records were recorded during the course of testing. 2.2 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (FOR ASYMMETRIC KEYS) (FCS_CKM.1) FCS_CKM.1.1 TSS Assurance Activities: The evaluator shall ensure that the TSS contains a description of how the TSF complies with A and/or B, depending on the selections made. This description shall indicate the sections in A and/or B that are implemented by the TSF, and the evaluator shall ensure that key establishment is among those sections that the TSF claims to implement. GSS CCT Evaluation Technical Report Page 18 of Gossamer Security Solutions, Inc.

19 Any TOE-specific extensions, processing that is not included in the documents, or alternative implementations allowed by the documents that may impact the security requirements the TOE is to enforce shall be described FCS_CKM.1.1 selected NIST Special Publication B, so the evaluator expected to find only that publication addressed in the TSS. The key pair generation portions of The RSA Validation System for FIPS were used as a guide in testing the FCS_CKM.1 during the FIPS validation. Section 6.1, FCS_CKM.1, states that the TOE implements a random number generator for RSA key establishment schemes. The TOE can create an RSA public-private key pair that can be used to generate a Certificate Signing Request (CSR). Through use of Simple Certificate Enrollment Protocol (SCEP), the TOE can: send the CSR to a Certificate Authority (CA) for the CA to generate a certificate; and receive its certificate from the CA. Integrity of the CSR and certificate during transit are assured through use of digital signatures (encrypting the hash of the TOE s public key contained in the CSR and certificate). The TOE can store and distribute the certificate to external entities including Registration Authorities (RA). Testing Assurance Activities: The evaluator shall use the key pair generation portions of "The FIPS Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and either "The RSA Validation System (RSAVS)" (for FIPS 186-2) or The RSA Validation System (RSA2VS) (for FIPS 186-3) as a guide in testing the requirement above, depending on the selection performed by the ST author. This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test. The TOE has been CAVP tested. The RSA certificate number is #1931 covering all evaluated models CRYPTOGRAPHIC KEY ZEROIZATION (FCS_CKM_EXT.4) FCS_CKM_EXT.4.1 TSS Assurance Activities: The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). 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 zeroization procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are GSS CCT Evaluation Technical Report Page 19 of Gossamer Security Solutions, Inc.

20 zeroized by overwriting once with zeros, while secret keys stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed before each write"). Section 7.1 presents a table about key zeroization. The table has columns for the key name, a description, and how the key is zeroized. 1. Describe each secret key, private key, and CSP: The table identified above serves to describe each key. 2. When they are zeroized: For each key, there is an identification of when it is zeroized. 3. Type of zeroization procedure: The zeroization method is identified for each key. The table also explains where type of key is stored (e.g. DRAM, NVRAM). Testing Assurance Activities: None Defined CRYPTOGRAPHIC OPERATION (FOR DATA ENCRYPTION/DECRYPTION) (FCS_COP.1(1)) FCS_COP.1(1).1 Testing Assurance Activities: The evaluator shall use tests appropriate to the modes selected in the above requirement from "The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation System (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining- Message Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" (these documents are available from as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The TOE has been CAVP tested. The AES certificate numbers is #3755 covering all evaluated models. GSS CCT Evaluation Technical Report Page 20 of Gossamer Security Solutions, Inc.

21 2.2.4 CRYPTOGRAPHIC OPERATION (FOR CRYPTOGRAPHIC SIGNATURE) (FCS_COP.1(2)) FCS_COP.1(2).1 Testing Assurance Activities: The evaluator shall use the signature generation and signature verification portions of "The Digital Signature Algorithm Validation System (DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS), and "The RSA Validation System (RSAVS (for 186-2) or RSA2VS (for 186-3)) as a guide in testing the requirement above. The Validation System used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB or FIPS PUB 186-3). This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The TOE has been CAVP tested. The RSA certificate number is #1931 covering all evaluated models CRYPTOGRAPHIC OPERATION (FOR CRYPTOGRAPHIC HASHING) (FCS_COP.1(3)) FCS_COP.1(3).1 GSS CCT Evaluation Technical Report Page 21 of Gossamer Security Solutions, Inc.

22 Testing Assurance Activities: The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The TOE has been CAVP tested. The SHA certificate number is #3125 covering all evaluated models CRYPTOGRAPHIC OPERATION (FOR KEYED-HASH MESSAGE AUTHENTICATION) (FCS_COP.1(4)) FCS_COP.1(4).1 Testing Assurance Activities: The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test. The TOE has been CAVP tested. The HMAC certificate number is #2457 covering all evaluated models EXPLICIT: IPSEC (FCS_IPSEC_EXT.1) FCS_IPSEC.1.1 Guidance Assurance Activities: The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries into the SPD that specify a rule for DISCARD, BYPASS and PROTECT The ST defines Discard, Bypass, and Protect as follows: GSS CCT Evaluation Technical Report Page 22 of Gossamer Security Solutions, Inc.

23 A crypto map (the Security Policy Definition) set can contain multiple entries, each with a different access list. The crypto map entries are searched in a sequence the router attempts to match the packet to the access list (acl) specified in that entry. When a packet matches a permit entry in a particular access list, the method of security in the corresponding crypto map is applied. If the crypto map entry is tagged as ipsecisakmp, IPsec is triggered. The traffic matching the permit acls would then flow through the IPsec tunnel and be classified as PROTECTED. Traffic that does not match a permit crypto map acl and does not match a non-crypto permit acl on the interface would be DISCARDED. Traffic that does not match a permit acl in the crypto map, but does match a non-crypto permit acl would be allowed to BYPASS the tunnel. For example, a non-crypto permit acl for icmp would allow ping traffic to flow unencrypted if a permit crypto map was not configured that matches the ping traffic. The guidance provides general information on crypto maps and section does state that separate access lists at the interface are required to define blocked or permitted packets. Section goes on to provide examples of how to create each type of rule. Testing Assurance Activities: The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests: Test 1: The evaluator shall configure the SPD such that there is a rule for DISCARD, BYPASS, PROTECT. The selectors used in the construction of the rule shall be different such that the evaluator can send in three network packets with the appropriate fields in the packet header that each packet will match one of the three rules. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packet was dropped, allowed through without modification, was encrypted by the IPsec implementation. Test 2: The evaluator shall devise two equal SPD entries with alternate operations BYPASS and PROTECT. The entries should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first entry is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation. Test 3: The evaluator shall repeat the procedure above, except that the two entries should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule. Test 1 The evaluator created rules for each type of SPD policy. The evaluator then verified the rules by establishing an IPsec tunnel and successfully establishing an administrator connection. It was observed that both the Bypass rule for administrator traffic and the Permit rule for IPsec traffic were successfully enforced against the traffic going through the IPsec tunnel. The evaluator used the packet capture to verify the Discard rules (as well as confirm the other rules). Test 2 The evaluator then applied the same rules that implemented administrative bypass to the interface. These rules were applied to the inbound traffic on the IPSec peer attempting the administrative connection. All administrative was discarded. GSS CCT Evaluation Technical Report Page 23 of Gossamer Security Solutions, Inc.

24 Test 3 The procedure for test case 1 was followed except that the deny and permit rules were reversed in order and the deny rule was a subset of the permit rule. The evaluator found the rules were enforced as expected FCS_IPSEC_EXT.1.2 TSS Assurance Activities: The evaluator checks the TSS to ensure it states that the VPN can be established to operate in tunnel mode and/or transport mode (as selected). Section 6.1, FCS_IPSEC_EXT.1, describes how the TOE operates in tunnel mode. It describes the Phase 1 and 2 negotiations. Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. Section descries tunnel mode and the configuration command required to establish tunnel mode on the TOE. Tunnel mode can be specified with the following command in crypto ipsec transform set mode: mode tunnel Testing Assurance Activities: The evaluator shall perform the following test(s) based on the selections chosen: Test 1 (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE to operate in tunnel mode and also configures a IPsec Peer to operate in tunnel mode. The evaluator configures the TOE and the IPsec Peer to use any of the allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator shall then initiate a connection from the client to connect to the IPsec Peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the tunnel mode. Test 2 (conditional): If transport mode is selected, the evaluator uses the operational guidance to configure the TOE to operate in transport mode and also configures a IPsec Peer to operate in transport mode. The evaluator configures the TOE and the IPsec Peer to use any of the allowed cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The evaluator then initiates a connection from the TOE to connect to the IPsec Peer. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the transport mode Test 1 - The evaluator configured an IPsec peer to require tunnel mode using a PSK. Each device successfully connected to each other and traffic log supporting tunnel mode was used for each device FCS_IPSEC_EXT.1.3 GSS CCT Evaluation Technical Report Page 24 of Gossamer Security Solutions, Inc.

25 TSS Assurance Activities: The evaluator shall examine the TSS to verify that the TSS provides a description of how a packet is processed against the SPD and that if no rules are found to match, that a final rule exists, either implicitly or explicitly, that causes the network packet to be discarded Section 6.1, FCS_IPSEC_EXT.1, provides a description of SPD in terms of a crypto map. The discussion explains the crypto map, and provides examples of how to set the crypto map. The section further states that traffic that does not match a permit crypto map rule and does not match a non-crypto permit rule on the interface would be DISCARDED. Guidance Assurance Activities: The evaluator checks that the operational guidance provides instructions on how to construct the SPD and uses the guidance to configure the TOE for the following tests. The guidance provides general information on crypto maps and section does state that separate access lists at the interface are required to define blocked or permitted packets. Section goes on to provide examples of how to create each type of rule. Testing Assurance Activities: The evaluator shall perform the following test: Test 1: The evaluator shall configure the SPD such that it has entries that contain operations that DISCARD, BYPASS, and PROTECT network packets. The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a BYPASS entry and send that packet. The evaluator should observe that the network packet is passed to the proper destination interface with no modification. The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluator-created entries (there may be a TOE created final entry that discards packets that do not match any previous entries). The evaluator sends the packet, and observes that the packet was not permitted to flow to any of the TOE s interfaces Test 1 - The evaluator sent traffic to the IPsec Peer to ensure it could receive traffic. The evaluator then attempted to send traffic to the IPsec Peer outside the IPsec tunnel. The traffic was discarded as expected FCS_IPSEC_EXT.1.4 TSS Assurance Activities: The evaluator shall examine the TSS to verify that the symmetric encryption algorithms selected (along with the SHA-based HMAC algorithm, if AES-CBC is selected) are described. If selected, the evaluator ensures that the SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash message authentication). Section 6.1, FCS_IPSEC_EXT.1, identifies both AES-CBC-128 and AES-CBC-256 with HMAC_SHA1 as included in the requirement. Guidance Assurance Activities: The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE to use the algorithms selected by the ST author. GSS CCT Evaluation Technical Report Page 25 of Gossamer Security Solutions, Inc.

26 The guidance (section ) specifies that to configure IPsec ESP to use HMAC-SHA-1 and AES-CBC-128 use the following command: crypto ipsec transform-set example esp-aes 128 esp-sha-hmac To change this to the other allowed algorithms, the following options can replace esp-aes 128 in the command below: Encryption Algorithm Command AES-CBC-256 esp-aes 256 Testing Assurance Activities: The evaluator shall also perform the following tests: Test 1: The evaluator shall configure the TOE as indicated in the operational guidance configuring the TOE to using each of the selected algorithms, and attempt to establish a connection using ESP. The connection should be successfully established for each algorithm. Test 1 - The evaluator made an IPsec connection to an IPsec Peer using each of the claimed IPsec ESP ciphersuites. The evaluator was able to capture each ciphersuite using a packet capture FCS_IPSEC_EXT.1.5 TSS Assurance Activities: The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented. Section 6.1, FCS_IPSEC_EXT.1, identifies IKEv1 as being implemented by the TOE. Guidance Assurance Activities: The evaluator shall check the operational guidance to ensure it instructs the administrator how to configure the TOE to use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE to perform NAT traversal for the following test if IKEv2 is selected. The guidance (section ) describes the configuration of IKEv1 transform set algorithms. Testing Assurance Activities: The evaluator shall also perform the following tests: Test 1 (conditional): The evaluator shall configure the TOE/platform so that it will perform NAT traversal processing as described in the TSS and RFC 5996, section The evaluator shall initiate an IPsec connection and determine that the NAT is successfully traversed. Test 1 This test is Not Applicable This test case only applies to IKEv2. GSS CCT Evaluation Technical Report Page 26 of Gossamer Security Solutions, Inc.

27 FCS_IPSEC_EXT.1.6 TSS Assurance Activities: The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv1 and/or IKEv2 payload, and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the selection of the requirement, those are included in the TSS discussion. Section 6.1, FCS_IPSEC_EXT.1, identifies both AES-CBC-128 and AES-CBC-256 as encryption algorithms. This matches the SFR. Guidance Assurance Activities: The evaluator ensures that the operational guidance describes the configuration of the mandated algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure the TOE to perform the following test for each ciphersuite selected. The guidance (section ) states that encryption aes configures IPSec IKEv1 to use AES-CBC-128 for payload encryption and AES-CBC-256 can be selected with encryption aes 256. Testing Assurance Activities: The evaluator shall also perform the following test: Test 1: The evaluator shall configure the TOE to use the ciphersuite under test to encrypt the IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is configured to only accept the payload encrypted using the indicated ciphersuite. The evaluator will confirm the algorithm was that used in the negotiation. Test 1 - The evaluator made an IPsec connection to an IPsec Peer using each of the claimed IKE ciphersuites. The evaluator was able to capture each ciphersuite using a packet capture FCS_IPSEC_EXT.1.7 TSS Assurance Activities: The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol supported by the TOE, it states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and that only main mode is used. It may be that this is a configurable option. Section 6.1, FCS_IPSEC_EXT.1, states that the TOE will be configured to not support aggressive mode for IKEv1 exchanges and to only use main mode. Guidance Assurance Activities: If the mode requires configuration of the TOE prior to its operation, the evaluator shall check the operational guidance to ensure that instructions for this configuration are contained within that guidance. The Guidance documentation (section ) provides instructions on enforcing the configuration of main mode and disabling aggressive-mode. GSS CCT Evaluation Technical Report Page 27 of Gossamer Security Solutions, Inc.

28 Switch(config-isakmp)#crypto isakmp aggressive-mode disable Main mode is the default mode and the crypto isakmp aggressive-mode disable ensures all IKEv1 Phase 1 exchanges will be handled in the default main mode. Testing Assurance Activities: The evaluator shall also perform the following test: Test 1 (conditional): The evaluator shall configure the TOE as indicated in the operational guidance, and attempt to establish a connection using an IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The evaluator should then show that main mode exchanges are supported. This test is not applicable if IKEv1 is not selected above in the FCS_IPSEC_EXT.1.5 protocol selection. Test 1 The evaluator made an IPsec connection to an IPsec Peer that requested aggressive mode. The connection failed. The TOE then requested main mode and successfully connected FCS_IPSEC_EXT.1.8 Guidance Assurance Activities: The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance. If time-based limits are supported, the evaluator ensures that the values allow for Phase 1 SAs values for 24 hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the number of packets or number of bytes, the evaluator just ensures that this can be configured if selected in the requirement The guidance details the configuration of both phase 1 and phase 2 lifetimes. Section demonstrates the configuration of the phase 1 lifetime with the following command: Switch(config-isakmp)#lifetime The default time value for Phase 1 SAs is 24 hours (86400 seconds), but this setting can be changed using the command above with different values. Section states that to configure the TOE for 8 hour phase 2 lifetimes use the following command: crypto ipsec security-association lifetime seconds The guidance also describes how to configure lifetimes by size. The following command configures a lifetime of 100 MB of traffic for Phase 2 SAs. The default amount for this setting is 2560KB, which is the minimum configurable value for this command. The maximum configurable value for this command is 4GB. crypto ipsec security-association lifetime kilobytes GSS CCT Evaluation Technical Report Page 28 of Gossamer Security Solutions, Inc.