Assurance Activity Report (IVPNCPP14) for Aruba, a Hewlett Packard Enterprise company Virtual Intranet Access (VIA) Client version 3.

Transcription

1 Assurance Activity Report (IVPNCPP14) for Aruba, a Hewlett Packard Enterprise company Virtual Intranet Access (VIA) Client version 3.0 Version /03/2018 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 Document: Aruba VIA-VID10871-AAR 2018 Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version /14/2018 Sykes Initial draft Version /27/2018 Sykes ST & Guidance Updates Version /04/2018 Sykes Test Updates Version /25/2018 Sykes Updated to address validator comments Version /01/2018 Sykes Updated to address validator comment Version /03/2018 Sykes ST update The TOE Evaluation was Sponsored by: Aruba, a Hewlett Packard Enterprise Company 1344 Crossman Ave. Sunnyvale, CA Evaluation Personnel: Katie Sykes Chris Keenan 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 GSS CCT Assurance Activity Report Page 2 of Gossamer Security Solutions, Inc.

3 TABLE OF CONTENTS 1. Introduction Equivalence Evaluated Platform Equivalence CAVP Certificate Equivalence References Protection Profile SFR Assurance Activities Cryptographic support (FCS) Cryptographic Key Generation (Asymmetric Keys) (IVPNCPP14:FCS_CKM.1(1)) Cryptographic Key Generation (for asymmetric keys - IKE) (IVPNCPP14:FCS_CKM.1(2)) Cryptographic Key Storage (IVPNCPP14:FCS_CKM_EXT.2) Cryptographic Key Zeroization (IVPNCPP14:FCS_CKM_EXT.4) Cryptographic Operation (Data Encryption/Decryption) (IVPNCPP14:FCS_COP.1(1)) Cryptographic Operation (for cryptographic signature) (IVPNCPP14:FCS_COP.1(2)) Cryptographic Operation (Cryptographic Hashing) (IVPNCPP14:FCS_COP.1(3)) Cryptographic Operation (Keyed-Hash Message Authentication) (IVPNCPP14:FCS_COP.1(4)) Extended: Internet Protocol Security (IPsec) Communications (IVPNCPP14:FCS_IPSEC_EXT.1) Extended: Cryptographic operation (Random Bit Generation) (IVPNCPP14:FCS_RBG_EXT.1) User data protection (FDP) Full Residual Information Protection (IVPNCPP14:FDP_RIP.2) Identification and authentication (FIA) Extended: X.509 Certificate Validation (IVPNCPP14:FIA_X509_EXT.1) Extended: X.509 Certificate Use and Management (IVPNCPP14:FIA_X509_EXT.2) Security management (FMT) Specification of Management Functions (IVPNCPP14:FMT_SMF.1(1)) Specification of Management Functions (IVPNCPP14:FMT_SMF.1(2)) Protection of the TSF (FPT) Extended: TSF Self Test (IVPNCPP14:FPT_TST_EXT.1) Extended: Trusted Update (IVPNCPP14:FPT_TUD_EXT.1) Trusted path/channels (FTP) GSS CCT Assurance Activity Report Page 3 of Gossamer Security Solutions, Inc.

4 2.6.1 Inter-TSF trusted channel (IVPNCPP14:FTP_ITC.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 Assurance Activity Report Page 4 of Gossamer Security Solutions, Inc.

5 1. INTRODUCTION This document presents evaluations results of the Aruba, a Hewlett Packard Enterprise company Virtual Intranet Access (VIA) Client Version 3.0 IVPNCPP14 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 following Protection Profile and associated Technical Decisions: Protection Profile for IPsec Virtual Private Network (VPN) Clients, Version 1.4, 21 October 2013 (IVPNCPP14) with the following NIAP Technical Decisions applied: TD0014, TD0037, TD0053, TD0079, TD0097, TD0107, TD0138, TD EQUIVALENCE This section explains why the test subset was adequate to address all product installations EVALUATED PLATFORM EQUIVALENCE The TOE is Aruba, a Hewlett Packard Enterprise company Virtual Intranet Access (VIA) Client Version 3.0 running on the following platforms: Samsung Galaxy S7, Samsung Galaxy S8, Samsung Note 8 with Android 7.1 Microsoft Windows 10 Linux (Red Hat Enterprise Linux 6.9 and CentOS Linux 6.9) The TOE is a software only mobile VPN client application executing on an Android, Windows or Linux mobile device platform. The underlying platform is considered part of the IT environment and provides some of the security functionality required in the VPNv1.4 Client PP, which is denoted with the phrase TOE Platform in the Security Target. An Aruba Mobility Controller is required to be in the operating environment of the TOE in order to terminate connections from a VIA client. VIA is not a general-purpose VPN client that works with third-party VPN gateways. VIA is supported on an Aruba Mobility Controller running one of the following ArubaOS versions: 6.4, 6.5, or 8.2. An ArubaOS Advanced Cryptography (ACR) license must also be installed on the Aruba Mobility Controller in order for the Suite B algorithms claimed in the ST to be available in the Aruba Common Cryptographic Module (CCM) version and to enable client termination using these algorithms. The evaluation team executed all of the test cases on the TOE which was installed on the following platforms: Samsung Galaxy S8 with Android 7.1 Windows 10 Professional CentOS Linux 6.9 The TOE was fully tested on a variant of each TOE Platform with an Aruba Mobility Controller (ie. VPN Gateway) in the operating environment running ArubaOS v.6.5. The same TOE executable is used for all Windows and Android GSS CCT Assurance Activity Report Page 5 of Gossamer Security Solutions, Inc.

6 platforms. RHEL and CentOS share a Linux build and the only difference is OS specific; all security functionality is identical. The Aruba Common Cryptographic Module (ACCM) library is the same across all platforms. Additionally, while the TOE was tested with ArubaOS v6.5, v8.2 contains the same VPN code and requires the same cryptographic license. All client cryptography is implemented in the TOE. As such, the ArubaOS v6.5 platform is sufficient to address the security requirements under evaluation CAVP CERTIFICATE EQUIVALENCE The TOE performs cryptographic algorithms using the Aruba Common Cryptographic Module (ACCM) library in accordance with the following NIST standards and has received the following CAVP algorithm certificates. The Aruba Common Cryptographic Module (ACCM) library is the same across all platforms. TOE CAVP Certificates Functions Requirement Windows Linux (32/64 bit) Android Cryptographic key generation RSA IFC Key Gen (2048 bits) ECDSA ECC Key Gen (NIST curves P- 256, P-384) DSA FFC Key Gen FCS_CKM.1(1) FCS_CKM.1(2) , , , Cryptographic key establishment ECC-based key exchange FFC-based key exchange FCS_CKM.1(1) FCS_CKM.1(2) , Encryption/Decryption AES CBC, GCM (128 and 256 bits) FCS_COP.1(1) , Cryptographic signature services RSA Digital Signature Algorithm (rdsa) (2048 bits) ECDSA Digital Signature Algorithm (NIST curves P-256, P-384) Cryptographic hashing SHA-1, SHA-256, and SHA-384 (digest sizes 160, 256, and 384 bits) Keyed-hash message authentication HMAC-SHA-1 SHA-256, and SHA-384 (key and digest sizes 160, 256, and 384bits) Random bit generation CTR_DRBG with a minimum of 256 bits of non-determinism FCS_COP.1(2) , , FCS_COP.1(3) , FCS_COP.1(4) , FCS_RBG_EXT , GSS CCT Assurance Activity Report Page 6 of Gossamer Security Solutions, Inc.

7 1.2 REFERENCES The following evidence was used to complete the Assurance Activities: Aruba, a Hewlett Packard Enterprise company Virtual Intranet Access (VIA) Client Version 3.0 (IVPNCPP14) Security Target, Version 1.5, 05/03/2018 (ST) Common Criteria Configuration Guidance, VPN Client Protection Profile, Aruba VIA Client v3.0, Version 2.0, March, 2018 (Admin Guide) Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 7.1 (MDFPP31/WLANCEP10) Security Target, Version 0.7, 2017/11/15 (Samsung Platform-ST) Microsoft Windows 10 (Anniversary Update) and Windows 10 Mobile (Anniversary Update) Security Target, version 0.08, March 24, (Windows Platform-ST) Lacharme, P., Rock, A., Strubel, V., & Videau, M. (2012). The Linux Pseudorandom Number Generator Revisited (Linux PRNG) (Linux Man Pages) Linux (Red Hat Enterprise Linux 6.9 and CentOS Linux 6.9) - No CC evaluation or Security Target exists. See (CentOS) or (RedHat OS) for associated documentation. GSS CCT Assurance Activity Report Page 7 of Gossamer Security Solutions, Inc.

8 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 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (ASYMMETRIC KEYS) (IVPNCPP14:FCS_CKM.1(1)) IVPNCPP14: FCS_CKM.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Requirement met by the Platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the key establishment claimed in that platform's ST contains the key establishment requirement in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the key establishment functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE Key Establishment Schemes: SP800-56B Key Establishment Schemes: At this time, detailed test procedures for RSA-based key establishment schemes are not available. In order to show that the TSF complies with 80056A and/or 80056B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information: - The TSS shall list all sections of the appropriate standard(s) to which the TOE complies. - For each applicable section listed in the TSS, for all statements that are not 'shall' (that is, 'shall not', 'should', and 'should not'), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as 'shall not' or 'should not' in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE. GSS CCT Assurance Activity Report Page 8 of Gossamer Security Solutions, Inc.

9 For each applicable section of 80056A and 80056B (as selected), any omission of functionality related to 'shall' or 'should' statements shall be described. This requirement is met by the TOE. Section 6.1, Table 4 of the ST identifies all the sections of NIST SP A to which the TOE complies. The TOE does not implement any options in statements that are not shall. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall verify the implementation of the key generation routines of the supported schemes using the applicable tests below. Key Generation for RSA-Based Key Establishment Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: 1. Random Primes: - Provable primes - Probable primes 2. Primes with Conditions: - Primes p1, p2, q1,q2, p and q shall all be provable primes - Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes - Primes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Key Generation for Finite-Field Cryptography (FFC) - Based 56A Schemes FFC Domain Parameter and Key Generation Tests GSS CCT Assurance Activity Report Page 9 of Gossamer Security Solutions, Inc.

10 The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: Cryptographic and Field Primes: - Primes q and p shall both be provable primes - Primes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator g: Cryptographic Group Generator: - Generator g constructed through a verifiable process - Generator g constructed through an unverifiable process. The Key generation specifies 2 ways to generate the private key x: Private Key: - len(q) bit output of RBG where 1 <=x <= q-1 - len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1<= x<=q-1. The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm - g!= 0,1 - q divides p-1 - g^q mod p = 1 - g^x mod p = y GSS CCT Assurance Activity Report Page 10 of Gossamer Security Solutions, Inc.

11 for each FFC parameter set and key pair. Key Generation for Elliptic Curve Cryptography (ECC)- Based 56A Schemes ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. ECC Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE using the applicable tests below. SP800-56A Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the DKM, the corresponding TOE's public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields. GSS CCT Assurance Activity Report Page 11 of Gossamer Security Solutions, Inc.

12 If the TOE does not use a KDF defined in SP A, the evaluator shall obtain only the public keys and the hashed value of the shared secret. The evaluator shall verify the correctness of the TSF's implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another party's valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator's public keys, the TOE's public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties' static public keys, both parties' ephemeral public keys and the TOE's static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE's results with the results using a known good implementation verifying that the TOE detects these errors. This requirement is met by the TOE. The TOE has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section CRYPTOGRAPHIC KEY GENERATION (FOR ASYMMETRIC KEYS - IKE) (IVPNCPP14:FCS_CKM.1(2)) IVPNCPP14: FCS_CKM.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 12 of Gossamer Security Solutions, Inc.

13 Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the key generation function claimed in that platform's ST contains the key generation requirement in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the key generation functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE If the TSF implements a FIPS signature scheme, this requirement is verified under FCS_COP.1(2). (TD0107 applied) This requirement is met by the TOE. Refer to FCS_COP.1(2). Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined CRYPTOGRAPHIC KEY STORAGE (IVPNCPP14:FCS_CKM_EXT.2) IVPNCPP14: FCS_CKM_EXT.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Regardless of whether this requirement is met by the TOE or the TOE platform, the evaluator will check the TSS to ensure that it lists each persistent secret (credential, secret key) and private key needed to meet the requirements in the ST. For each of these items, the evaluator will confirm that the TSS lists for what purpose it is used, and how it is stored. The evaluator than performs the following actions. Persistent secrets and private keys manipulated by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the persistent secrets and private keys listed as being stored by the platform in the VPN client ST are identified as being protected in that platform's ST. Persistent secrets and private keys manipulated by the TOE GSS CCT Assurance Activity Report Page 13 of Gossamer Security Solutions, Inc.

14 The evaluator reviews the TSS for to determine that it makes a case that, for each item listed as being manipulated by the TOE, it is not written unencrypted to persistent memory, and that the item is stored by the platform. This requirement is met by the TOE and the TOE platform. Table 5 in Section 6.1 of the ST presents the keys and secrets utilized by the TOE. It identifies the key, it s purpose, where it is stored and how it is cleared. All of the keys needed for the requirements are presented in the table. Section 6.1 states that the TOE does not store these keys unencrypted to persistent storage. While the TOE manipulates keys, on all platforms, the TOE platform s key storage is used. Section 6.2 of the Samsung Platform-ST upon which the VPN TOE relies provides a description of the protections afforded to the keystore, Memory, and FLASH. Section of the Windows Platform-ST upon which the VPN TOE relies provides a description of the protections afforded to the keystore. Section 7 of Linux Man Pages provides a description of Linux keyrings which are used by Linux to retain or cache security data, authentication keys, encryption keys and other data in the kernel. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined CRYPTOGRAPHIC KEY ZEROIZATION (IVPNCPP14:FCS_CKM_EXT.4) IVPNCPP14:FCS_CKM_EXT.4.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall ensure that all plaintext secret and private cryptographic keys and CSPs (whether manipulated by the TOE or exclusively by the platform) are identified in the VPN Client ST's TSS, and that they are accounted for by the assurance activities in this section. Requirement met by the platform 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 that are not otherwise covered by the FCS_CKM_EXT.4 requirement levied on the TOE. GSS CCT Assurance Activity Report Page 14 of Gossamer Security Solutions, Inc.

15 For each platform listed in the ST, the evaluator shall examine the TSS of the ST of the platform to ensure that each of the secret keys, private keys, and CSPs used to generate key listed above are covered. Requirement met by the TOE The evaluator shall check to ensure the TSS describes when each of the plaintext keys are cleared (e.g., system power off, disconnection of an IPsec connection, when no longer needed by the VPN channel per the protocol); and the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase). 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'). This requirement is met by the TOE. Section 6.1 of the ST presents all the keys and secrets used by the TOE. The tables identify the key, its purpose, where it is stored, and how it is cleared. All keys are stored temporarily in volatile RAM. The TOE destroys cryptographic keys when they are no longer in use by the system. The keys are zeroized through zero overwrite. All of the keys needed for the requirements are presented in the table. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE For each key clearing situation described in the TSS, the evaluator shall repeat the following test. Test 1: The evaluator shall utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds to test that keys are cleared correctly, including all intermediate copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key. Cryptographic TOE implementations in software shall be loaded and exercised under a debugger to perform such tests. The evaluator shall perform the following test for each key subject to clearing, including intermediate copies of keys that are persisted encrypted by the TOE: 1. Load the instrumented TOE build in a debugger. 2. Record the value of the key in the TOE subject to clearing. 3. Cause the TOE to perform a normal cryptographic processing with the key from #1. 4. Cause the TOE to clear the key. 5. Cause the TOE to stop the execution but not exit. 6. Cause the TOE to dump the entire memory footprint of the TOE into a binary file. GSS CCT Assurance Activity Report Page 15 of Gossamer Security Solutions, Inc.

16 7. Search the content of the binary file created in #4 for instances of the known key value from #1. The test succeeds if no copies of the key from #1 are found in step #7 above and fails otherwise. The evaluator shall perform this test on all keys, including those persisted in encrypted form, to ensure intermediate copies are cleared. This requirement is met by the TOE. The TOE s cryptographic module provides an API that has been FIPS certified. FIPS includes key destruction testing. The Aruba cryptographic module provides an API for key destruction and the key destruction service zeroizes the key. The evaluator reviewed the Aruba cryptographic module FIPS Security Policy and verified that all key information is provided CRYPTOGRAPHIC OPERATION (DATA ENCRYPTION/DECRYPTION) (IVPNCPP14:FCS_COP.1(1)) IVPNCPP14:FCS_COP.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the encryption/decryption function(s) claimed in that platform's ST contains the encryption/decryption function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the encryption/decryption functionality is invoked for the indicated modes and key sizes in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Not Applicable. This requirement is met by the TOE. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall perform the following activities based on the selections in the ST. AES-CBC Tests AES-CBC Known Answer Tests GSS CCT Assurance Activity Report Page 16 of Gossamer Security Solutions, Inc.

17 There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the other five shall be encrypted with a 256-bit all-zeros key. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption. KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an allzero ciphertext value as input and AES-CBC decryption. KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the two sets of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The first set of keys shall have bit keys, and the second set shall have bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs shall have bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key. KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from AES-CBC encryption of the given plaintext using a 128-bit key value of all zeros with an IV of all zeros and using a 256-bit key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128]. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption. AES-CBC Multi-Block Message Test GSS CCT Assurance Activity Report Page 17 of Gossamer Security Solutions, Inc.

18 The evaluator shall test the encrypt functionality by encrypting an i-block message where 1< i <=10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3- tuple, 1000 iterations shall be run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT = CT[i-1] The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. AES-GCM Monte Carlo Test The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths: 128 bit and 256 bit keys Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported. GSS CCT Assurance Activity Report Page 18 of Gossamer Security Solutions, Inc.

19 Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported. Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested. The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known. The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. This requirement is met by the TOE and has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section CRYPTOGRAPHIC OPERATION (FOR CRYPTOGRAPHIC SIGNATURE) (IVPNCPP14:FCS_COP.1(2)) IVPNCPP14:FCS_COP.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the digital signature functions claimed in that platform's ST contains the digital signature functions in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the digital signature functionality is invoked for each operation they are used for in the VPN client (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). This requirement is met by the TOE. GSS CCT Assurance Activity Report Page 19 of Gossamer Security Solutions, Inc.

20 Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall perform the following activities based on the selections in the ST. Key Generation: Key Generation for RSA Signature Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: 1. Random Primes: â Provable primes â Probable primes 2. Primes with Conditions: â Primes p1, p2, q1,q2, p and q shall all be provable primes â Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes â Primes p1, p2, q1,q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF's implementation by comparing values generated by the TSF with those generated from a known good implementation. ECDSA Key Generation Tests FIPS ECDSA Key Generation Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. GSS CCT Assurance Activity Report Page 20 of Gossamer Security Solutions, Inc.

21 FIPS Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-284 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. ECDSA Algorithm Tests CDSA FIPS Signature Generation Test For each supported NIST curve (i.e., P-256, P-284 and P-521) and SHA function pair, the evaluator shall generate bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation. ECDSA FIPS Signature Verification Test For each supported NIST curve (i.e., P-256, P-284 and P-521) and SHA function pair, the evaluator shall generate a set of bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values. RSA Signature Algorithm Tests Signature Generation Test The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/sha combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages. The evaluator shall verify the correctness of the TSF's signature using a known good implementation and the associated public keys to verify the signatures. Signature Verification Test The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another party's valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure. This requirement is met by the TOE and has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section GSS CCT Assurance Activity Report Page 21 of Gossamer Security Solutions, Inc.

22 2.1.7 CRYPTOGRAPHIC OPERATION (CRYPTOGRAPHIC HASHING) (IVPNCPP14:FCS_COP.1(3)) IVPNCPP14:FCS_COP.1(3).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall check that the association of the hash function with other cryptographic functions (for example, the digital signature verification function) specified in the VPN Client ST (whether these are performed by the platform or by the TOE) is documented in the TSS. Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the hash function(s) claimed in that platform's ST contains the hash function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). This requirement is met by the TOE. Section 6.1 of the ST states that the SHA hash algorithm (all claimed key sizes) is used as part of HMAC, but is also used independently as part of digital signature creation and verification. The TOE generates RSA and ECDSA signatures during IKE peer authentication and verifies these signatures during IKE peer authentication and trusted updates. The TOE implements various HMAC algorithms to be used for authentication with ESP and IKE. The specific algorithms used depend upon the ciphersuite being used. The TOE implements AES-GCM-128, AES-GCM-256, AES-CBC-128, and AES-CBC-256 as ESP encryption algorithms and implements HMAC-SHA1 as the authentication algorithm. The TOE implements AES-CBC-128 and AES-CBC-256 as IKE encryption algorithms and implements HMAC-SHA1, HMAC-SHA-256 and HMAC-SHA-384 as the authentication algorithm. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The TSF hashing functions can be implemented in one of two modes. The first mode is the byteoriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bitoriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bitoriented vs. the byteoriented testmacs. GSS CCT Assurance Activity Report Page 22 of Gossamer Security Solutions, Inc.

23 The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP. Short Messages Test Bitoriented Mode The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Short Messages Test Byteoriented Mode The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test Bitoriented Mode The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is *i, where 1. i. m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test Byteoriented Mode The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is *99*i, where 1. i. m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Pseudorandomly Generated Messages Test This test is for byteoriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF. The TOE is met by the TOE and has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section GSS CCT Assurance Activity Report Page 23 of Gossamer Security Solutions, Inc.

24 2.1.8 CRYPTOGRAPHIC OPERATION (KEYED-HASH MESSAGE AUTHENTICATION) (IVPNCPP14:FCS_COP.1(4)) IVPNCPP14:FCS_COP.1(4).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall check that the association of the keyed-hash function with other cryptographic functions specified in the VPN Client ST (whether these are performed by the platform or by the TOE) is documented in the TSS. Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the keyed hash function(s) claimed in that platform's ST contains the keyed hash function(s) in the VPN Client's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) how the keyed hash functionality is invoked for each digest size and key size selected in the VPN Client's ST (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE Additionally, for all cases where the output of the HMAC following the hash calculation is truncated, the evaluator shall ensure that the TSS states for what operation this truncation takes place; the size of the final output; and the standard to which this truncation complies. The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: keylength, hash function used, block size, and output MAC length used. This requirement is met by the TOE. Section 6.1 of the ST states that the TOE implements various HMAC algorithms to be used for authentication with ESP and IKE. The specific algorithms used depend upon the ciphersuite being used. The TOE implements AES-GCM-128, AES-GCM-256, AES-CBC-128, and AES-CBC-256 as ESP encryption algorithms and implements HMAC-SHA1 as the authentication algorithm. The TOE implements AES- CBC-128 and AES-CBC-256 as IKE encryption algorithms and implements HMAC-SHA1, HMAC-SHA-256 and HMAC- SHA-384 with key sizes and block sizes of 160, 256 and 384 respectively, producing output MAC lengths equal to the block size. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE GSS CCT Assurance Activity Report Page 24 of Gossamer Security Solutions, Inc.

25 For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation. Extended: Internet Protocol Security (FCS_IPSEC_EXT) In order to show that the TSF implements the RFCs in accordance with the requirements of this PP, the evaluator shall perform the assurance activities listed below. In future versions of this PP, assurance activities may be augmented, or new ones introduced that cover more aspects of RFC compliance than are currently described in this publication. The TOE is required to use the IPsec protocol to establish connections used to communicate with a VPN Gateway. The evaluators shall minimally create a test environment equivalent to the test environment illustrated above. It is expected that the traffic generator is used to construct network packets and will provide the evaluator with the ability manipulate fields in the ICMP, IPv4, IPv6, UDP, and TCP packet headers. The evaluators must provide justification for any differences in the test environment. In the following elements of the FCS_IPSEC_EXT.1 component, it is allowable for some or all of the individual elements to be implemented by the platform on which the VPN client operates. The TSS of the VPN client will identify all of the information listed in the assurance activities of the elements; this may be repeated from the underlying platform's (if implemented by the platform) ST and should be indicated as such in the VPN client ST. If the configuration is to be performed on the platform, the evaluators shall ensure that the 'operational guidance' for each platform in the VPN Client ST contains the appropriate information (either through reference in the platform's ST, or by information contained in the VPN client ST). All tests must be performed by the evaluators using the VPN client and a representative sample of platforms listed in the VPN Client ST. This requirement is met by the TOE has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section EXTENDED: INTERNET PROTOCOL SECURITY (IPSEC) COMMUNICATIONS (IVPNCPP14:FCS_IPSEC_EXT.1) IVPNCPP14: FCS_IPSEC_EXT.1.1 TSS Assurance Activities: (TD0138 applied) The evaluator shall examine the TSS and determine that it describes how the IPsec capabilities are implemented and how a packet is processed, e.g., what takes place at the platform and what takes place within the client. The TSS will detail the relationship between the client and the underlying platform, including which aspects are implemented by the client, and those that are provided by the underlying platform. The TSS describes how the client interacts with the platforms network stack (e.g., does the client insert itself within the stack via kernel mods, does the client simply invoke APIs to gain access to network services). GSS CCT Assurance Activity Report Page 25 of Gossamer Security Solutions, Inc.

26 If the SPD is implemented by the client, then the TSS describes how the SPD is implemented and the rules for processing both inbound and outbound packets in terms of the IPsec policy. The TSS describes the rules that are available and the resulting actions available after matching a rule. The TSS describes how those rules and actions form the SPD in terms of the BYPASS (e.g., no encryption), DISCARD (e.g., drop the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC As noted in section of RFC 4301, the processing of entries in the SPD is non-trivial and the evaluator shall determine that the description in the TSS is sufficient to determine which rules will be applied given the rule structure implemented by the TOE. For example, if the TOE allows specification of ranges, conditional rules, etc., the evaluator shall determine that the description of rule processing (for both inbound and outbound packets) is sufficient to determine the action that will be applied, especially in the case where two different rules may apply. This description shall cover both the initial packets (that is, no SA is established on the interface or for that particular packet) as well as packets that are part of an established SA. If the SPD is implemented by the underlying platform, then the TSS describes how the client interacts with the platform to establish and populate the SPD, including the identification of the platform's interfaces that are used by the client. Section 6.1 of the ST states that the TOE implements minimal SPD rules and does not support direct editing of SPD rules. The TOE implements SPD rules that are defined implicitly through the configuration and connection of a VPN session. The PROTECT and BYPASS rules are implicit and are implemented by configuring a split tunnel. The administrator may configure PROTECT and BYPASS rules by enabling or disabling split-tunnel mode in the VIA connection profile on the VPN Gateway. If split-tunnel is disabled, all traffic follows the PROTECT rule. All traffic originating from the client operating system is passed through the tunnel established by the VIA client to the VPN Gateway. With split-tunneling enabled, the VPN Gateway pushes routes configured with the tunnel address command in the VIA connection profile on the VPN Gateway to the VIA client. Traffic matching the routes is forwarded through the IPsec tunnel. The DISCARD rule is not supported by the TOE and must be provided by firewall rules configured on the VPN Gateway and the Platform. Guidance Assurance Activities: The evaluator shall examine the operational guidance to verify it describes how the SPD is created and configured. If there is an administrative interface to the client, then the guidance describes how the administrator specifies rules for processing a packet. The description includes all three cases - a rule that ensures packets are encrypted/decrypted, dropped, and allowing a packet to flow in plaintext. The evaluator shall determine that the description in the operational guidance is consistent with the description in the TSS, and that the level of detail in the operational guidance is sufficient to allow the administrator to set up the SPD in an unambiguous fashion. This includes a discussion of how ordering of rules impacts the processing of an IP packet. If the client is configured by an application, such as the VPN gateway, then the operational guidance describes the client interface used by the application. The description contains information as to how the SPD is established and set up in an unambiguous fashion. The description includes what is configurable via the interface, how ordering of entries may be expressed, as well as the impacts that ordering of entries may have on the packet processing. In either case, the evaluator ensures the description provided In the TSS is consistent with the capabilities and description provided in the operational guidance. GSS CCT Assurance Activity Report Page 26 of Gossamer Security Solutions, Inc.

27 Section FCS_IPSEC_EXT.1.1 in the Admin Guide describes the TOE implementation of the SPD and provides the commands for enabling and disabling the TOE in split-tunnel mode. It states that the administrator may configure BYPASS and PROTECT rules by enabling or disabling split-tunnel mode in the VIA connection profile. If split-tunnel is disabled, all traffic follows the PROTECT rule. With split tunneling enabled, specific routes are pushed to the VIA client, and traffic matching those routes passes through the IPsec tunnel, all other traffic bypasses the tunnel. The DISCARD rule is not implemented by the TOE. If traffic is to be discarded, it should be blocked by firewall rules on the VPN Gateway. The VPN Gateway supports multiple levels of firewall rules. Each VIA client that connects is assigned a role. In the definition of this role, firewall rules can be specified and are evaluated in the order they are entered. By default, the firewall rules in each role have an implicit DISCARD rule at the end. Section FCS_IPSEC_EXT.1.1 in the Admin Guide provides a sample configuration using the commands to set firewall rules on a VIA VPN role. Testing Assurance Activities: (TD0138 applied) The evaluator performs the following tests: Test 1: The evaluator shall configure the SPD such that there is a rule for dropping a packet, encrypting a packet, and allowing a packet to flow in plaintext. The selectors used in the construction of the rule shall be different such that the evaluator can generate a packet and send packets to the client with the appropriate fields (fields that are used by the rule - e.g., the IP addresses, TCP/UDP ports) in the packet header. The evaluator performs both positive and negative test cases for each type of rule. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packets were dropped, allowed through without modification, was encrypted by the IPsec implementation. Test 2: The evaluator shall devise several tests that cover a variety of scenarios for packet processing. These scenarios must exercise the range of possibilities for SPD entries and processing modes as outlined in the TSS and operational guidance. Potential areas to cover include rules with overlapping ranges and conflicting entries, inbound and outbound packets, and packets that establish SAs as well as packets that belong to established SAs. The evaluator shall verify, via the audit trail and packet captures, for each scenario that the expected behavior is exhibited, and is consistent with both the TSS and the operational guidance. Test 1: The evaluator confirmed the split functionality implementation through establishing a VPN tunnel with each TOE and inspecting the corresponding wireshark scan results. In each case the evaluator verified that encrypted packets were sent as ESP and unencrypted packets were sent in clear. After the tunnel was established, the evaluator attempted to send a packet to the TOE IP address which was not encrypted by the tunnel. The evaluator confirmed that the request was dropped and no response was sent from the TOE IP. Test 2: SPD rule configuration is not supported by the TOE. Packet filtering is handled by the TOE platform. For the purpose of the evaluation, the evaluator configured rules on the TOE platforms to demonstrate that the TOE platforms support SPD rule configuration and ordering. GSS CCT Assurance Activity Report Page 27 of Gossamer Security Solutions, Inc.

28 IVPNCPP14: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 of the ST indicates that the TOE implements IKEv2 in tunnel mode only. This is consistent with the requirement. Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions on how to configure the connection in each mode selected. Section FCS_IPSEC_EXT.1.2 of the Admin Guide states that only tunnel mode is supported. No configuration is required to enable tunnel mode. 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/platform to operate in tunnel mode and also configures a VPN GW to operate in tunnel mode. The evaluator configures the TOE/platform and the VPN GW 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 VPN GW 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/platform to operate in transport mode and also configures a VPN GW to operate in transport mode. The evaluator configures the TOE/platform and the VPN GW 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/platform to connect to the VPN GW. The evaluator observes (for example, in the audit trail and the captured packets) that a successful connection was established using the transport mode. The TOE only supports tunnel mode. Test 1: The evaluator verified through inspection of the active IPSec sessions during testing and in each case the session was in tunnel mode IVPNCPP14:FCS_IPSEC_EXT.1.3 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. This requirement is met by the VPN Gateway and the TOE platform. Section 6.1 of the ST states that the TOE implements minimal SPD rules. The PROTECT and BYPASS rules are implicit and are implemented by configuring a GSS CCT Assurance Activity Report Page 28 of Gossamer Security Solutions, Inc.

29 split tunnel. The administrator may configure PROTECT and BYPASS rules by enabling or disabling split-tunnel mode in the VIA connection profile on the VPN Gateway. If split-tunnel is disabled, all traffic follows the PROTECT rule. All traffic originating from the client operating system is passed through the tunnel established by the VIA client to the VPN Gateway. With split-tunneling enabled, the VPN Gateway pushes routes configured with the tunnel address command in the VIA connection profile on the VPN Gateway to the VIA client. Traffic matching the routes is forwarded through the IPsec tunnel. The DISCARD rule is not supported by the TOE and must be provided by firewall rules configured on the VPN Gateway and the Platform. 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/platform for the following tests. Section FCS_IPSEC_EXT.1.1 in the Admin Guide describes the TOE implementation of the SPD and provides the commands for enabling and disabling the TOE in split-tunnel mode. It states that the administrator may configure BYPASS and PROTECT rules by enabling or disabling split-tunnel mode in the VIA connection profile. If split-tunnel is disabled, all traffic follows the PROTECT rule. With split tunneling enabled, specific routes are pushed to the VIA client, and traffic matching those routes passes through the IPsec tunnel, all other traffic bypasses the tunnel. The DISCARD rule is not implemented by the TOE. If traffic is to be discarded, it should be blocked by firewall rules on the VPN Gateway. The VPN Gateway supports multiple levels of firewall rules. Each VIA client that connects is assigned a role. In the definition of this role, firewall rules can be specified and are evaluated in the order they are entered. By default, the firewall rules in each role have an implicit DISCARD rule at the end. Section FCS_IPSEC_EXT.1.1 in the Admin Guide provides a sample configuration using the commands to set firewall rules on a VIA VPN role. 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/platform 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 configured the discard functionality on the VPN gateway such that any traffic from the unprotected network that was bypassed from the tunnel would be discarded. The evaluator confirmed that the traffic was not permitted. GSS CCT Assurance Activity Report Page 29 of Gossamer Security Solutions, Inc.

30 IVPNCPP14:FCS_IPSEC_EXT.1.4 TSS Assurance Activities: The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and AES- GCM-256 are implemented. If the ST author has selected either AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies the TSS describes these as well. In addition, 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 of the ST states that the TOE implements AES-GCM-128, AES-GCM-256, AES-CBC-128, and AES-CBC-256 as ESP encryption algorithms and implements HMAC-SHA1 as the authentication algorithm. The TOE implements AES-CBC-128 and AES-CBC-256 as IKE encryption algorithms and implements HMAC-SHA1, HMAC-SHA-256 and HMAC-SHA-384 as the authentication algorithm. Guidance Assurance Activities: The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE/platform to use the AES-GCM-128, and AES-GCM-256 algorithms, and if either AES- CBC-128 or AES-CBC-256 have been selected the guidance instructs how to use these as well. Section FCS_CKM.1, FCS_CKM.2 and FCS_COP.1 in the Admin Guide indicate that placing the TOE into FIPS mode through use of the enable-fips command in the VIA connection profile ensures that all cryptographic services are compliant with the PP requirements. The enable-fips command will enable a connection profile command to instruct the VIA client to disable non-fips algorithms in the VIA crypto library. Section FCS_IPSEC_EXT.1.4 in the Admin Guide states that the TOE s IKE/IPsec parameters are configured via the VIA connection profile on the Aruba Mobility Controller. This section provides the commands for configuring the the correct IKE policy, IPsec algorithms and IPsec dynamic-map and including it in the VIA connection profile. This includes configuring the AES algorithms in the IPsec policy. For additional guidance on configuring the IPsec policy, a reference to the Common Criteria Configuration Guidance for the VPN Gateway Extension Profile is provided as detailed below. This guide can be accessed via the link found in the Documentation References section. Common Criteria Configuration Guidance for the VPN Gateway Extension Profile The FCS_IPSEC_EXT.1.4 section describes how the IPsec algorithms are configured using transform-sets. These are ordered lists of ciphers - the controller will attempt each one in order until one is successfully negotiated with the peer. ArubaOS provides pre-configured transforms that meet three of the Common Criteria requirements. Note that the Advanced Cryptography License must be installed in order to have access to AES-GCM. The default transforms are: o Transform set default-gcm256: { esp-aes256-gcm } o Transform set default-gcm128: { esp-aes128-gcm } o Transform set default-aes: { esp-aes256 esp-sha-hmac } To configure AES-CBC-128, add a new transform set: o (config) #crypto ipsec transform-set aes128 esp-aes128 esp-sha-hmac These algorithms are consistent with those claimed in the FCS_IPSEC_EXT.1.4 requirement. GSS CCT Assurance Activity Report Page 30 of Gossamer Security Solutions, Inc.

31 Testing Assurance Activities: Test 1: The evaluator shall configure the TOE/platform as indicated in the operational guidance configuring the TOE/platform to using each of the AES-GCM-128, and AES-GCM-256 algorithms, and attempt to establish a connection using ESP. If the ST Author has selected either AES-CBC-128 or AES-CBC-256, the TOE/platform is configured to use those algorithms and the evaluator attempts to establish a connection using ESP for those algorithms selected. Test 1 - Following the operational guidance the evaluator configured the VIA connection profile on the VPN Gateway for each of the claimed algorithms. The evaluator then downloaded the profile to the TOE and successfully established a connection with each algorithm. These results were verified through inspection of each of the packet captures of the established sessions IVPNCPP14: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 of the ST indicates that the TOE implements IKEv2. This is consistent with the requirement. Guidance Assurance Activities: The evaluator shall check the operational guidance to ensure it instructs the administrator how to configure the TOE/platform to use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE/platform to perform NAT traversal for the following test. Section FCS_IPSEC_EXT.1.5 of the Admin Guide indicates that only IKEv2 is included in the evaluated configuration. The command ikev2-proto is used when configuring the VIA connection profile via the VPN Gateway to ensure that only IKEv2 is enabled. NAT-T is supported by default and no additional configuration is required to enable. Testing Assurance Activities: Test 1: 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 - The TOE natively supports NAT-T by default within an established tunnel to the VPN gateway. The evaluator established an IPsec tunnel and verified that the session was performing NAT traversal processing IVPNCPP14: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 of the ST states that the TOE implements AES-CBC-128 and AES-CBC-256 as IKEv2 encryption algorithms and implements HMAC-SHA1, HMAC-SHA-256 and HMAC-SHA-384 as the authentication algorithm. GSS CCT Assurance Activity Report Page 31 of Gossamer Security Solutions, Inc.

32 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/platform to perform the following test for each ciphersuite selected. Section FCS_CKM.1, FCS_CKM.2 and FCS_COP.1 in the Admin Guide indicate that placing the TOE into FIPS mode through use of the enable-fips command in the VIA connection profile ensures that all cryptographic services are compliant with the PP requirements. Section FCS_IPSEC_EXT.1.6 of the Admin Guide indicates that the TOE s IKE/IPsec parameters are configured via the VIA connection profile on the VPN Gateway (ie. Aruba Mobility Controller). This section provides instructions for configuring the IKE policy algorithms using the crypto isakmp policy command as well as creating the IPsec dynamic map and including it in the VIA connection profile. The example provided below shows an IKE policy configured with the AES-CBC-256 algorithm with SHA For additional guidance on configuring the IKE policy, a reference to the Common Criteria Configuration Guidance for the VPN Gateway Extension Profile is provided as detailed below. This guide can be accessed via the link found in the Documentation References section. Common Criteria Configuration Guidance for the VPN Gateway Extension Profile Section FCS_IPSEC_EXT.1.6 describes how to configure an IKEv2 policy that uses the AES-CBC-256 and AES-CBC-128 encryption algorithms by creating an IKE policy using the crypto isakmp policy command and then using the encryption command to specify either aes128 or aes256. These encryption algorithms are consistent with those claimed in the FCS_IPSEC_EXT.1 requirement. Testing Assurance Activities: Test 1: The evaluator shall configure the TOE/platform 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 - Following the operational guidance the evaluator configured the VIA connection profile on the VPN gateway for each of the selected algorithms. The evaluator then downloaded the VIA connection profile to the TOE and successfully established a connection with each algorithm. The evaluator verified through inspection of the corresponding packet captures that the TOE successfully negotiated the selected algorithm IVPNCPP14:FCS_IPSEC_EXT.1.7 TSS Assurance Activities: The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol, 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. Not Applicable the TOE supports IKEv2 only. GSS CCT Assurance Activity Report Page 32 of Gossamer Security Solutions, Inc.

33 Guidance Assurance Activities: If the mode requires configuration of the TOE/platform prior to its operation, the evaluator shall check the operational guidance to ensure that instructions for this configuration are contained within that guidance. Not Applicable the TOE supports IKEv2 only. Testing Assurance Activities: Test 1 (conditional): The evaluator shall configure the TOE/platform 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. Not Applicable the TOE supports IKEv2 only IVPNCPP14:FCS_IPSEC_EXT.1.8 TSS Assurance Activities: None Defined 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 either the Administrator or VPN Gateway are able to configurable 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. Section FCS_IPSEC_EXT.1.8 of the Admin Guide indicates that the TOE s lifetime requirement parameters are configured via the VIA connection profile on the VPN Gateway (ie. Aruba Mobility Controller). This section provides instructions an example for configuring the Phase 1 (IKE) lifetime requirement in seconds by creating an IKE policy using the crypto isakmp policy command and then using the lifetime command to specify the lifetime in seconds. For additional guidance on configuring the IPsec lifetime requirement a reference to the Common Criteria Configuration Guidance for the VPN Gateway Extension Profile is provided as detailed below. This guide can be accessed via the link found in the Documentation References section. Common Criteria Configuration Guidance for the VPN Gateway Extension Profile Section FCS_IPSEC_EXT.1.8 describes how to configure both the Phase 1 (IKE) and Phase 2 (IPsec) lifetimes. Phase 1 (IKE) lifetimes are configured in the IKE policies. The following commands should be used to configure an IKE policy for a 24-hour lifetime (this is the default value): (config) # crypto isakmp policy 100 (config-isakmp)# lifetime GSS CCT Assurance Activity Report Page 33 of Gossamer Security Solutions, Inc.

34 Phase 2 (IPsec) lifetimes are configured in the IPsec dynamic map. The following commands should be used to configure the map and an 8 hour lifetime: (config) #crypto dynamic-map cc-required 1 (config-dynamic-map)# set security-association lifetime seconds SA lifetimes may also be configured based on the number of bytes transmitted. Replace the keyword "seconds" with "kilobytes" in the above configuration and supply the lifetime value. Both time-based and volume-based lifetimes may be configured simultaneously. Testing Assurance Activities: When testing this functionality, the evaluator needs to ensure that both sides are configured appropriately. From the RFC 'A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered.' Each of the following tests shall be performed for each version of IKE selected in the FCS_IPSEC_EXT.1.5 protocol selection: Test 1 (Conditional): The evaluator shall configure a maximum lifetime in terms of the # of packets (or bytes) allowed following the operational guidance. The evaluator shall establish an SA and determine that once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed. Test 2 (Conditional): The evaluator shall construct a test where a Phase 1 SA is established and attempted to be maintained for more than 24 hours before it is renegotiated. The evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a specific way, the evaluator shall implement tests demonstrating that the configuration capability of the TOE works as documented in the operational guidance. Test 3 (Conditional): The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that the lifetime will be 8 hours instead of 24. All IPSec configuration occurs on the VPN gateway which is then downloaded to the TOE prior to establishing a connection. Test 1 The evaluator configured the VPN gateway for a minimum lifetime size of 1000 kb and downloaded the corresponding profile to the TOE. The evaluator then established a session between the TOE and VPN gateway and verified that the lifetime value is enforced. The evaluator verified this through session output on the VPN gateway and packet capture inspection. Test 2 & 3 - The evaluator configured the VPN gateway for 24 hour and 8 hour sessions and downloaded the corresponding profile to the TOE. The evaluator then established a session between the TOE and VPN gateway and GSS CCT Assurance Activity Report Page 34 of Gossamer Security Solutions, Inc.

35 verified that the lifetime values are enforced. The evaluator verified this through session output on the VPN gateway and packet capture inspection IVPNCPP14:FCS_IPSEC_EXT.1.9 TSS Assurance Activities: The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for generating 'x' (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of 'x' and the nonces meet the stipulations in the requirement. Section 6.1 of the ST states that the TOE generates the secret value x used in the IKEv2 Diffie-Hellman key exchange ('x' in g x mod p) using the FIPS validated RBG specified in FCS_RBG_EXT.1 and having possible lengths of 224, 256, or 384 bits. When a random number is needed for a nonce, the probability that a specific nonce value will be repeated during the life of a specific IPsec SA is less than 1 in 2 112, 2 128, or Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14:FCS_IPSEC_EXT.1.10 TSS Assurance Activities: The evaluator shall check to ensure that, for each DH group supported, the TSS describes the process for generating 'x' (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of 'x' and the nonces meet the stipulations in the requirement. Section 6.1 of the ST states that the TOE generates the secret value x used in the IKEv2 Diffie-Hellman key exchange ('x' in g x mod p) using the FIPS validated RBG specified in FCS_RBG_EXT.1 and having possible lengths of 224, 256, or 384 bits. When a random number is needed for a nonce, the probability that a specific nonce value will be repeated during the life of a specific IPsec SA is less than 1 in 2 112, 2 128, or Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14:FCS_IPSEC_EXT.1.11 TSS Assurance Activities: The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer. GSS CCT Assurance Activity Report Page 35 of Gossamer Security Solutions, Inc.

36 Section 6.1 of the ST states the TOE supports the following DH groups: 14, 19, and 20 which are configured on the VPN Gateway (Aruba Mobility Controller). This is consistent with the FCS_IPSEC_EXT.1.11 requirement. Guidance Assurance Activities: None Defined Testing Assurance Activities: The evaluator shall also perform the following test: Test 1: For each supported DH group, the evaluator shall test to ensure that all supported IKE protocols can be successfully completed using that particular DH group. Test 1 - The evaluator configured the VIA connection profile on the VPN gateway and downloaded the profile for each DH group. The evaluator then successfully established a session with each DH group IVPNCPP14:FCS_IPSEC_EXT.1.12 TSS Assurance Activities: The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used to perform peer authentication. The description must be consistent with the algorithms as specified in FCS_COP.1(2) Cryptographic Operations (for cryptographic signature). If pre-shared keys are chosen in the selection, the evaluator shall check to ensure that the TSS describes how preshared keys are established and used in authentication of IPsec connections. The evaluator shall check that the operational guidance describes how pre-shared keys are to be generated and established. The description in the TSS and the operational guidance shall also indicate how pre-shared key establishment is accomplished for TOEs/platforms that can generate a pre-shared key as well as TOEs/platforms that simply use a pre-shared key. Section 6.1 of the ST states that the TOE implements peer authentication using RSA certificates or ECDSA certificates that conform to RFC 4945 and FIPS Table 5 indicates that the ECDSA private key supports NIST curves p256 and p384 and that RSA supports key size This is consistent with the algorithms specified in FCS_COP.1(2). The TOE does not support pre-shared keys. Guidance Assurance Activities: The evaluator ensures the operational guidance describes how to set up the TOE/platform to use the cryptographic algorithms RSA and/or ECDSA. In order to construct the environment and configure the TOE/platform for the following tests, the evaluator will ensure that the operational guidance also describes how to configure the TOE/platform to connect to a trusted CA, and ensure a valid certificate for that CA is loaded into the TOE/platform and marked 'trusted'. Section FCS_IPSEC_EXT.1.12 of the Admin Guide indicates that the required parameters for configuring the TOE to use RSA and ECDSA as well as configuring the TOE to connect to a trusted CA is performed are configured via the VIA connection profile on the VPN Gateway (ie. Aruba Mobility Controller). This section provides an example for configuring the parameters on the VPN Gateway to meet the Diffie Hellman group requirements using the authentication command in the IKE policy. Valid configuration values are rsa-sig, ecdsa-256 or ecdsa-384. GSS CCT Assurance Activity Report Page 36 of Gossamer Security Solutions, Inc.

37 For additional guidance on configuring the authentication parameters and connection to a trusted CA, a reference to the Common Criteria Configuration Guidance for the VPN Gateway Extension Profile is provided as detailed below. This guide can be accessed via the link found in the Documentation References section. Common Criteria Configuration Guidance for the VPN Gateway Extension Profile Section FCS_IPSEC_EXT.1.12 states that ArubaOS supports both RSA and ECDSA certificates. Note that the Advanced Cryptography License must be installed to make use of ECDSA. Minimally, both a "server certificate" and a "trusted root CA" certificate must be loaded onto the controller in order to perform IPsec operations. Once these certificates are loaded on the controller, configure them for use in IPsec. For use with dynamic VPN clients, the following commands should be used: (config) #crypto-local isakmp server-certificate "server-cert" (config) #crypto-local isakmp ca-certificate "trusted-root-ca-cert" To configure an IKE policy to authenticate RSA certificates sent by peers, use the following command: (config) #crypto isakmp policy 100 (config-isakmp)# authentication rsa-sig To configure an IKE policy for ECDSA-384 authentication, use the following command: (config) #crypto isakmp policy 100 (config-isakmp)# authentication ecdsa-384 ECDSA-256 may be supported by replacing "384" with "256". Section FCS_IPSEC_EXT.1.12 of the Admin Guide states that for certificate-based authentication, the user or an authorized entity is responsible for installing certificates. For Android and Windows, VIA uses standard OS interfaces to perform certificate operations VIA is not involved in the certificate loading process. The Linux version of VIA contains an integrated certificate store the user or administrator is responsible for loading those certificates locally through the VIA configuration interface. For specific instructions on each operating system platform, a reference to the Aruba VIA 3.x for ArubaOS 6.5.x User Guide and the Aruba VIA 3.x for ArubaOS 8.x User Guide is provided as detailed below. These guides can be accessed via the links found in the Documentation References section. Aruba VIA 3.x for ArubaOS 6.5.x User Guide and Aruba VIA 3.x for ArubaOS 8.x User Guide Windows OS - the VIA Client for Windows section and the Certificate-Based Authentication sub-section on page 30 describe how to establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. GSS CCT Assurance Activity Report Page 37 of Gossamer Security Solutions, Inc.

38 Android OS - the VIA Client for Android section and the Certificate-Based Authentication sub-section on page 61 describe how to install certificates onto the device and establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. Linux OS - the VIA for Linux CLI section and the Certificate Operations sub-section on page 121 describe how to import user certificates to the VIA store and how to establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. For Windows, section FCS_IPSEC_EXT.1.12 of the Admin Guide further provides the following link which provides instructions for importing certificates into the Windows Trusted Publisher s store: Testing Assurance Activities: For efficiency sake, the testing that is performed here has been combined with the testing for FIA_X509_EXT.2.1 (for IPsec connections), FCS_IPSEC_EXT.1.13, and FIA_X509_EXT.2.3. The following tests shall be repeated for each peer authentication protocol selected in the FCS_IPSEC_EXT.1.12 selection above: Test 1: The evaluator shall have the TOE/platform generate a public-private key pair, and submit a CSR (Certificate Signing Request) to a CA (trusted by both the TOE/platform and the peer VPN used to establish a connection) for its signature. The values for the DN (Common Name, Organization, Organizational Unit, and Country) will also be passed in the request. Alternatively, the evaluator may import to the TOE/platform a previously generated private key and corresponding certificate. (TD0140 applied) Test 2: The evaluator shall use a certificate signed using the RSA or ECDSA algorithm to authenticate the remote peer during the IKE exchange. This test ensures the remote peer has the certificate for the trusted CA that signed the TOE's certificate and it will do a bit-wise comparison on the DN. This bit-wise comparison of the DN ensures that not only does the peer have a certificate signed by the trusted CA, but the certificate is from the DN that is expected. The evaluator will configure the TOE/platform to associate a certificate (e.g., a certificate map in some implementations) with a VPN connection. This is what the DN is checked against. Test 3: The evaluator shall test that the TOE/platform can properly handle revoked certificates - conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the PP, the evaluator has to only test one up in the trust chain (future drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established. The evaluator then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the TOE/platform will not establish an SA. Test 4: The evaluator shall test that given a signed certificate from a trusted CA, that when the DN does not match - any of the four fields can be modified such that they do not match the expected value, that an SA does not get established. Test 5: Test Deleted by TD0053. GSS CCT Assurance Activity Report Page 38 of Gossamer Security Solutions, Inc.

39 Test 6 [conditional]: The evaluator shall generate a pre-shared key and use it, as indicated in the operational guidance, to establish an IPsec connection with the VPN GW peer. If the generation of the pre-shared key is supported, the evaluator shall ensure that establishment of the key is carried out for an instance of the TOE/platform generating the key as well as an instance of the TOE/platform merely taking in and using the key. The evaluator performed each of the following tests. Test 1: The TOE does not generate certificate requests, but rather requires certificates to be loaded through the device UI or through the platform. The certificates for these tests were generated outside the TOE and loaded into the TOE. During the initial exchange with the VPN client, the server certificates are then pushed down to the client. Test 2: The evaluator configured a VIA connection profile for RSA and ECDSA on the VPN Gateway. The evaluator then successfully established a connection with each profile. Test 3: The evaluator configured the VPN gateway for OCSP certificate validation and downloaded the configured profile to the TOE. The evaluator then confirmed that when a revoked certificate was used, the TOE would not establish an SA. Test 4: The TOE Platform allows for optional configuration for domain name checking. This is a feature of the TOE platform and requires no configuration on the VIA client. This configuration forces an exact match to the parameters entered and if these values do not match then the connection is rejected. For the purpose of this test the evaluator configured a domain name profile with an incorrect CN and verified that the connection was rejected. The evaluator then configured the correct CN and the connection succeeded. Test 5: NA Test removed by TD0053. Test 6: NA the TOE does not support pre-shared keys IVPNCPP14:FCS_IPSEC_EXT.1.13 TSS Assurance Activities: (Per TD0037) The assurance activities for this element are performed in conjunction with the assurance activities for the next element. See FCS_IPSEC_EXT Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 39 of Gossamer Security Solutions, Inc.

40 IVPNCPP14:FCS_IPSEC_EXT.1.14 TSS Assurance Activities: (Per TD0037) The evaluator shall ensure that the TSS describes how the TOE compares the peer's presented identifier to the reference identifier. This description shall include whether the certificate presented identifier is compared to the ID payload presented identifier, which field(s) of the certificate are used as the presented identifier (DN, Common Name, or SAN), and, if multiple fields are supported, the logical order comparison. If the ST author assigned an additional identifier type, the TSS description shall also include a description of that type and the method by which that type is compared to the peer's presented certificate. Section 6.1 of the ST states that the TOE implements peer authentication using RSA certificates or ECDSA certificates that conform to RFC If certificates are used, the TOE ensures that the distinguished name (DN) contained in a certificate matches the expected DN for the entity attempting to establish a connection and ensures that the certificate has not been revoked (using the Online Certificate Status Protocol [OCSP] in accordance with RFC 2560). Section 6.3 of the ST states that the TOE processes a VPN connection to a server by first comparing the Identification (ID) Payload received from the server against the certificate sent by the server, and if the DN of the certificate does not match the ID, then the TOE does not establish the connection. Assuming the server s certificate matches the ID, the TOE then validates that it can construct a certificate path from the server s certificate through any intermediary CAs to the CA certificate specified by the user in the VPN configuration. Guidance Assurance Activities: (Per TD0037) The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer. Section FCS_IPSEC_EXT.1.13 of the Admin Guide indicates that in order to configure the peer DN, the dnprofile keyword should be used within the VIA connection profile as shown in the example commands below: aaa authentication via connection-profile default dn-profile CN gateway.nobody.com ORG "Test Lab" OU "Lab1" Country "US" Testing Assurance Activities: (Per TD0037) For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: Test 1: For each field of the certificate supported for comparison, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to match the field in the peer's presented certificate and shall verify that the IKE authentication succeeds. Test 2: For each field of the certificate support for comparison, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to not match the field in the peer's presented certificate and shall verify that the IKE authentication fails. The following tests are conditional: Test 3: (conditional) If, according to the TSS, the TOE supports both Common Name and SAN certificate fields and uses the preferred logic outlined in the Application Note, the tests above with the Common Name field shall be GSS CCT Assurance Activity Report Page 40 of Gossamer Security Solutions, Inc.

41 performed using peer certificates with no SAN extension. Additionally, the evaluator shall configure the peer's reference identifier on the TOE to not match the SAN in the peer's presented certificate but to match the Common Name in the peer's presented certificate, and verify that the IKE authentication fails. Test 4: (conditional) If the TOE supports DN identifier types, the evaluator shall configure the peer's reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer's presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and verify that the IKE authentication fails. Test 5: (conditional) If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the presented identifiers and the reference identifier with the same IP address that differs from the actual IP address of the peer in the IP headers and verifying that the IKE authentication fails. Test 6: (conditional) If, according to the TSS, the TOE performs comparisons between the peer's ID payload and the peer's certificate, the evaluator shall repeat the following test for each combination of supported identifier types and supported certificate fields (as above). The evaluator shall configure the peer to present a different ID payload than the field in the peer's presented certificate and verify that the TOE fails to authenticate the IKE peer. Test 1: DN values were tested as part of FCS_IPSEC_EXT.1.12, Test 4. The evaluator confirmed the TOE could successfully connect with a properly configured DN profile. Test 2: DN values were tested as part of FCS_IPSEC_EXT.1.12, Test 4. The evaluator confirmed the TOE rejected connections with a mismatched DN profile. Test 3: Not Applicable. The TOE only claims DN. Test 4: DN values were tested as part of FCS_IPSEC_EXT.1.12, Test 4. The evaluator confirmed the TOE rejected connections with a mismatched DN profile. The evaluator changed one character in the DN and verified that the TOE successfully rejected the invalid DN. Test 5: Not Applicable. The TOE only claims DN. Test 6: Not Applicable. The TOE only claims DN IVPNCPP14: FCS_IPSEC_EXT.1.15 TSS Assurance Activities: The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also describe the checks that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites to GSS CCT Assurance Activity Report Page 41 of Gossamer Security Solutions, Inc.

42 ensure that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA this is protecting the negotiation. This requirement is met by the VPN Gateway. Section 6.1 of the ST states that the TOE relies upon the VPN Gateway to ensure that the cryptographic algorithms and key sizes negotiated during the IKEv2 negotiation ensure that the security strength of the IKE_SA are greater than or equal to that of the CHILD_SA. The negotiated algorithm will be AES because that is the only evaluated algorithm, so strength is based solely upon key size where more bits is stronger. Guidance Assurance Activities: None Defined Testing Assurance Activities: The evaluator simply follows the guidance to configure the TOE/platform to perform the following tests. Test 1: This test shall be performed for each version of IKE supported. The evaluator shall successfully negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the requirements. Test 2: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). Such attempts should fail. Test 3: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions identified in the requirements. Such an attempt should fail. Test 4: This test shall be performed for each version of IKE supported. The evaluator shall attempt to establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail. Test 1: The evaluator successfully negotiated an IPSec connection for each of the supported algorithms and hash algorithms identified in the ST. Test 2: The evaluator attempted to establish a connection where the IPsec strength was greater than the IKE strength. The TOE rejected the download of the profile due to the configuration and failed to establish a connection. Test 3: The evaluator attempted to establish a connection where the IKE was configured for a non-supported algorithm. The TOE rejected the download of the profile due to the configuration and failed to establish a connection. Test 4: The evaluator attempted to establish a connection where the IPsec was configured for a non-supported algorithm. The TOE rejected the download of the profile due to the configuration and failed to establish a connection. GSS CCT Assurance Activity Report Page 42 of Gossamer Security Solutions, Inc.

43 Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined EXTENDED: CRYPTOGRAPHIC OPERATION (RANDOM BIT GENERATION) (IVPNCPP14:FCS_RBG_EXT.1) IVPNCPP14: FCS_RBG_EXT.1.1 TSS Assurance Activities: None Defined. Guidance Assurance Activities: None Defined Testing Assurance Activities: (Per TD0079) The evaluator shall perform the following tests. 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 operational guidance 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 SP A). 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. GSS CCT Assurance Activity Report Page 43 of Gossamer Security Solutions, Inc.

44 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 less then or equal to 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. The TOE has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section IVPNCPP14:FCS_RBG_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: (Per TD0079) Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that the RBG functions claimed in that platform s ST contains the RBG functions in the VPN Client s ST. The evaluator shall also examine the TSS of the VPN Client s ST to verify that it describes (for each supported platform) how the RBG functionality is invoked for each operation they are used for in the VPN Client (it should be noted that this may be through a mechanism that is not implemented by the VPN Client; nevertheless, that mechanism will be identified in the TSS as part of this assurance activity). Requirement met by the TOE Documentation shall be produced and the evaluator shall perform the activities in accordance with Appendix E. If the ST author has selected a platform-based noise source, the evaluator shall verify the platform s RBG has been validated by examining the platform s ST. The evaluator shall verify that the platform s RBG is seeded with at least the amount of entropy selected by the ST author for this profile. In this case, the ST author is not responsible for Annex E documentation of the platform s RBG. This requirement is met by the TOE and the TOE platform. Section 6.1 of the ST states that Aruba s VIA Client includes an AES-256 CTR_DRBG (irrespective of the underlying Platform) that seeds itself with 384-bits of entropy (composed of a 256-bit entropy_input and a 128-bit nonce) drawn from a Platform function intended to provide cryptographically secure randomness (and conditioned using SHA-1). The following list describes the mechanism by GSS CCT Assurance Activity Report Page 44 of Gossamer Security Solutions, Inc.

45 which VIA obtains its seeding. The Android and Windows interfaces are identified in their associated Security Targets. Linux - /dev/random Android- /dev/random Windows - BCryptGenRandom(). Based on NIAP s Clarification to the Entropy Documentation and Assessment Annex 1, Aruba assumes a minimum entropy of 0.67 bits of entropy per bit of data from platform provided sources. This minimum-entropy estimate along with knowledge that the seed is 384-bits means that the TOE seeds itself with at least 256-bits of entropy. The detailed Entropy description for the TOE 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. The evaluator checked Section in the Windows Platform-ST and found in the FCS_RBG_EXT.1 SFR that the TOE Platform provides the CTR_DRBG (AES) with a minimum of 256 bits of entropy. Section states that the interface for the Windows random number generator is BCryptGenRandom. The evaluator checked Section 6.2 in the Samsung Platform-ST and found that the TOE Platform uses its hardwarebased noise source to continuously fill /dev/random with random data with full entropy, and in turn, draws from /dev/random to seed its AES-256 CTR_DRBG. The TOE platform seeds each of its AES-256 CTR_DRBGs using 384- bits of data from /dev/random, thus ensuring at least 256-bits of entropy. The evaluator checked Section 2.1 in the Linux PRNG document and found that it describes the standard blocking /dev/random interface that the TOE uses to seed its software RBG. Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: Requirement met by the TOE The evaluator shall also perform the following tests, depending on the standard to which the RBG conforms. Implementations Conforming to FIPS 140-2, Annex C The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS). The evaluators shall conduct the following two tests. Note that the 'expected values' are produced by a reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme. The evaluators shall perform a Variable Seed Test. The evaluators shall provide a set of 128 (Seed, DT) pairs to the TSF RBG function, each 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES 1 GSS CCT Assurance Activity Report Page 45 of Gossamer Security Solutions, Inc.

46 algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value is incremented by 1 for each set. The seed values shall have no repeats within the set. The evaluators ensure that the values returned by the TSF match the expected values. The evaluators shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT value to the TSF RBG function; each of these is 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES algorithm) that is constant throughout the test. The evaluators then invoke the TSF RBG 10,000 times, with the DT value being incremented by 1 on each iteration, and the new seed for the subsequent iteration produced as specified in NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms, Section 3. The evaluators ensure that the 10,000th value produced matches the expected value. Implementations Conforming to NIST Special Publication 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 operational guidance 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 SP ). 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 df does not use a nonce), the nonce bit length is one-half the seed length. GSS CCT Assurance Activity Report Page 46 of Gossamer Security Solutions, Inc.

47 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. This requirement is met by the TOE. The TOE has been CAVP tested. Refer to the CAVP certificates identified in the table TOE CAVP Certificates in Section USER DATA PROTECTION (FDP) FULL RESIDUAL INFORMATION PROTECTION (IVPNCPP14:FDP_RIP.2) IVPNCPP 14: FDP_RIP.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Requirement met by the platform For each platform listed in the ST, the evaluator shall examine the ST of the platform to ensure that residual information protection measures with respect to network packets passing through the platform are claimed in that platform's ST. The evaluator shall also examine the TSS of the VPN Client's ST to verify that it describes (for each supported platform) the extent to which the client processes network packets and addresses the FDP_RIP.2 requirement. Requirement met by the TOE 'Resources' in the context of this requirement are network packets being sent through (as opposed to 'to', as is the case when a security administrator connects to the TOE) the TOE. The concern is that once a network packet is sent, the buffer or memory area used by the packet still contains data from that packet, and that if that buffer is re-used, those data might remain and make their way into a new packet. The evaluator shall check to ensure that the TSS describes packet processing to the extent that they can determine that no data will be reused when processing network packets. The evaluator shall ensure that this description at a minimum describes how the previous data are zeroized/overwritten, and at what point in the buffer processing this occurs. GSS CCT Assurance Activity Report Page 47 of Gossamer Security Solutions, Inc.

48 This requirement is met by the TOE. Section 6.2 of the ST states that the TOE ensures that no residual information exists in network packets. When the TOE allocates a new buffer for either an incoming or outgoing a network packet, the new packet data will be used to overwrite any previous data in the buffer. If an allocated buffer exceeds the size of the packet, additional space will be overwritten (padded) with zeros before the packet is forwarded (to the external network or delivered to the appropriate, internal application). Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined 2.3 IDENTIFICATION AND AUTHENTICATION (FIA) EXTENDED: X.509 CERTIFICATE VALIDATION (IVPNCPP14:FIA_X509_EXT.1) IVPNCPP14: FIA_X509_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined I VPNCPP14: FIA_X509_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place - the TOE or the TOE platform. It may be that the TOE requests the platform to perform the check and provide a result, or the TOE may do the check itself. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm, ensuring that it describes how the validation chain will terminate in a trusted root certificate. This requirement is met by the TOE. Section 6.3 of the ST states that the TOE uses a user specified certificate when attempting to establish a VPN connection. The TOE validates authentication certificates (including the full path) and checks their revocation status using OCSP. The TOE processes a VPN connection to a server by first comparing the Identification (ID) Payload received from the server against the certificate sent by the server, and if the DN of GSS CCT Assurance Activity Report Page 48 of Gossamer Security Solutions, Inc.

49 the certificate does not match the ID, then the TOE does not establish the connection. Assuming the server s certificate matches the ID, the TOE then validates that it can construct a certificate path from the server s certificate through any intermediary CAs to the CA certificate specified by the user in the VPN configuration. If the TOE can successfully build the certificate path, then the TOE will next check the validity of the certificates (e.g., checking its validity dates and that the CA flag is present in the basic constraints section for all CA certs). Assuming the certificates are valid, the TOE finally checks the revocation status of all certificates (starting with the server s certificate and working up the chain). Through the Aruba Mobility Controller, the administrator determines if a certificate is accepted or rejected if the connection to OCSP server cannot be reached. Component Guidance Assurance Activities: The evaluator ensures the guidance documentation provides the user with the necessary information to setup the validation check whether it is done by the TOE or TOE platform. The guidance documentation provides instructions how to select the method used for checking, as well as how to setup a protected communication path with the entity providing the information pertaining to certificate validity. Section FCS_CKM_EXT.2 of the Admin Guide states that for certificate-based authentication, the user or an authorized entity is responsible for installing certificates. For Android and Windows, VIA uses standard OS interfaces to perform certificate operations VIA is not involved in the certificate loading process. The Linux version of VIA contains an integrated certificate store the user or administrator is responsible for loading those certificates locally through the VIA configuration interface. For specific instructions on each operating system platform, a reference to the Aruba VIA 3.x for ArubaOS 6.5.x User Guide and the Aruba VIA 3.x for ArubaOS 8.x User Guide is provided as detailed below. These guides can be accessed via the links found in the Documentation References section. Aruba VIA 3.x for ArubaOS 6.5.x User Guide and Aruba VIA 3.x for ArubaOS 8.x User Guide Windows OS - the VIA Client for Windows section and the Certificate-Based Authentication sub-section on page 30 describe how to establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. Android OS - the VIA Client for Android section and the Certificate-Based Authentication sub-section on page 61 describe how to install certificates onto the device and establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. Linux OS - the VIA for Linux CLI section and the Certificate Operations sub-section on page 121 describe how to import user certificates to the VIA store and how to establish a VPN connection using a certificate once VIA is installed and the VPN profile is downloaded. For Windows, section FCS_IPSEC_EXT.1.12 of the Admin Guide further provides the following link which provides instructions for importing certificates into the Windows Trusted Publisher s store: The FIA_X509_EXT.1 section of the Admin Guide states that VIA performs certificate checking for two different server certificates. The first is the server certificate used for the TLS handshake when VIA initially downloads its configuration through HTTPS. Verification of this certificate (including revocation checking) is handled by the GSS CCT Assurance Activity Report Page 49 of Gossamer Security Solutions, Inc.

50 platform operating system. The second certificate is the IKE peer during IPsec negotiation. VIA validates this certificate. VIA performs OCSP checking by first inspecting the AIA field of each certificate in a chain to learn the OCSP responder URL. VIA expects the OCSP responder to be reachable outside the VPN tunnel, since the server certificate must be validated prior to an IPsec connection being established. The Admin Guide provides the commands for configuring OCSP checking via the VIA connection profile on the VPN Gateway (ie. Aruba Mobility Controller). Component Testing Assurance Activities: Regardless of the selection of 'TOE' or 'TOE Platform in the FIA_X509_EXT.1 elements, the evaluator shall perform the following tests. This testing may be combined with the testing performed in the other assurance activities (e.g., for FCS_IPSEC_EXT.1.12). Test 1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function (trusted channel setup, trusted software update, integrity check) failing. 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. The evaluator then shall 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 revoked certificates are properly handled - conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the PP, the evaluator has to only test one up in the trust chain (future drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established. The evaluator then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that an SA will not be established. Test 4: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate does not contain the basicconstraints extension. The validation of the certificate path fails. Test 5: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate has the ca flag in the basicconstraints extension not set. The validation of the certificate path fails. Test 6: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the certificate has the ca flag in the basicconstraints extension set to TRUE. The validation of the certificate path succeeds. Test 1: The evaluator created a certificate bundle without the subsubca-rsa-rsa.pem file and loaded it into the controller. The evaluator then attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was successfully rejected during the connection attempt and the connection did not successfully establish. Test 2: The evaluator created a certificate bundle with an expired subsubca-rsa-rsa.pem file and loaded it into the controller. The evaluator then attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was successfully rejected during the connection attempt and the connection did not successfully establish. GSS CCT Assurance Activity Report Page 50 of Gossamer Security Solutions, Inc.

51 Test 3: The evaluator successfully established a VPN tunnel with OCSP validation for each TOE. The evaluator then revoked the subsubca-rsa-rsa.pem certificate. The evaluator then attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was rejected by the TOE as expected. Test 4: The evaluator created a certificate bundle with a CA with no basic constraints and loaded it into the controller. The evaluator attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was successfully rejected during the connection attempt and the connection did not successfully establish. Test 5: The evaluator created a certificate bundle with a CA with no CA flag and loaded it into the controller. The evaluator then attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was successfully rejected during the connection attempt and the connection did not successfully establish. Test 6: The evaluator created a certificate bundle with the basic constraints extension and CA flag set to TRUE and loaded it into the controller. The evaluator then attempted to connect the controller to the TOE and verified that the certificate bundle that was offered to the TOE was successfully connected and established an IPsec session EXTENDED: X.509 CERTIFICATE USE AND MANAGEMENT (IVPNCPP14:FIA_X509_EXT.2) IVPNCPP14: FIA_X509_EXT.2.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14: FIA_X509_EXT.2.2 TSS Assurance Activities: The evaluator shall check the TSS to ensure that it describes how the TOE/platform chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE/platform can use the certificates. If this functionality is implemented entirely by the platform, the operational guidance for the TOE shall reference the applicable guidance for each platform. The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE/platform when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed. If this behavior is GSS CCT Assurance Activity Report Page 51 of Gossamer Security Solutions, Inc.

52 implemented entirely by the platform, the evaluator shall examine the ST of each platform to confirm that the selections for this element are contained in each platform's ST. Section 6.3 of the ST states that through the policy on the Aruba Mobility Controller, the administrator determines if a certificate is accepted or rejected if the connection to an OCSP server cannot be reached. Per FMT_SMF.1, this functionality can be configured via the VPN Gateway (ie. Aruba Mobility Controller). Section FIA_X509_EXT.2.2 of the Admin Guide indicates that if the TOE fails to obtain a response from an OCSP responder, the administrator may choose whether to treat the certificate as valid or revoked. This is configured in the appropriate VIA connection profile via the following commands: ocsp-responder fallback accept or no ocspresponder fallback accept. Guidance Assurance Activities: None Defined Testing Assurance Activities: If this requirement is fully or partially implemented by the TOE, the evaluator shall perform Test 1 for each function in the system that requires the use of certificates: Test 1: 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 operational guidance to determine that all supported administrator-configurable options behave in their documented manner. This test must be performed for each certificate revocation method selected in FIA_X509_EXT.1.1 (e.g. OCSP and/or CRL). (TD0053 applied) Test 1: The evaluator confirmed that when the validity of a certificate cannot be established, the administrator can choose whether or not to accept the certificate in these cases IVPNCPP14: FIA_X509_EXT.2.3 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: None Defined Component Guidance Assurance Activities: None Defined Component Testing Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 52 of Gossamer Security Solutions, Inc.

53 2.4 SECURITY MANAGEMENT (FMT) SPECIFICATION OF MANAGEMENT FUNCTIONS (IVPNCPP14:FMT_SMF.1(1)) IVPNCPP14: FMT_SMF.1(1).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall check to ensure the TSS describes the client credentials and how they are used by the TOE. Section 6.4 of the ST states that the TOE provides functions allowing the user to select VPN gateway and credentials used to connect to those gateways. Section 6.3 of the ST describes the TOE s usage of X.509 certificates for establishing an IPsec connection. Component Guidance Assurance Activities: The evaluator shall check to make sure that every management function mandated in the ST for this requirement are described in the operational guidance and that the description contains the information required to perform the management duties associated with each management function. The Configuration Instructions section of the Admin Guide references a sample configuration in Appendix A that can be entered on the VPN Gateway (ie. Aruba Mobility Controller) to meet the requirements of the TOE. It states that the sequence of commands is entered by the administrator on either the console port or in an SSH session after logging into the VPN Gateway. The relevant VIA commands are highlighted in yellow in Appendix A. The VIA connection profile is configured using the command aaa authentication via connection-profile default command. For more information on logging in to the Aruba Mobility Controller and modifying and saving the configuration, a reference to the ArubaOS x User Guide and the ArubaOS User Guide is provided as detailed below. These guides can be accessed via the links found in the Documentation References section. ArubaOS x User Guide and ArubaOS User Guide Under Fundamentals, the sub-section CLI provides details on logging in to the Mobility Controller via the CLI. Under Basic User-Centric Networks, the sub-section Save Your Configuration indicates that the writememory command is used to save the configuration. GSS CCT Assurance Activity Report Page 53 of Gossamer Security Solutions, Inc.

54 Section FMT_SMF.1 in the Admin Guide states that the specification of the VPN gateway and all other settings used for connections will be pushed to the VIA client from an Aruba Mobility Controller, once an initial connection is established. The end user is responsible for entering the IP address or hostname of the gateway where configuration may be downloaded, along with a username and password to download the configuration profile. For specific instructions on each operating system platform, a reference to the Aruba VIA 3.x for ArubaOS 6.5.x User Guide and the Aruba VIA 3.x for ArubaOS 8.x User Guide is provided as detailed below. These guides can be accessed via the links found in the Documentation References section. Aruba VIA 3.x for ArubaOS 6.5.x User Guide and Aruba VIA 3.x for ArubaOS 8.x User Guide Windows OS the VIA Client for Microsoft Windows section and the Downloading VPN Profiles subsection on page 20 describe how to install the VIA client and to download the VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller). Android OS the VIA Client for Android section and the Downloading VIA sub-section on page 56 describe how to install the VIA client and to download the VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller). Linux OS Chapter 4 provides instructions for installing the VIA client. The VIA for Linux CLI section and the IPsec sub-section on page 119 provide the commands to start a VIA session and to download a VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller). The evaluator reviewed the TOE documentation and confirmed that all management functions are described within the operational guidance. The guidance describes the configuration and the use of each management function provided by the TOE as identified in this report. Component Testing Assurance Activities: The evaluator shall test the TOE's ability to provide the management functions by configuring the TOE according to the operational guidance and testing each management activity listed in the Security Target. Note that the testing here may be accomplished in conjunction with the testing of FCS_IPSEC_EXT.1. Management functions are tested by using the operational guidance to configure the TOE for testing. The TOE downloads the VIA connection profile from the Aruba Mobility Controller (ie. VPN Gateway) with all configuration preselected. The TOE allows for specification of the client certificate to be used in establishing the tunnel. TOE configuration was tested as part of FCS_IPSEC_EXT SPECIFICATION OF MANAGEMENT FUNCTIONS (IVPNCPP14:FMT_SMF.1(2)) IVPNCPP14:FMT_SMF.1(2).1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 54 of Gossamer Security Solutions, Inc.

55 Testing Assurance Activities: None Defined Component TSS Assurance Activities: As stated in the application note, a TOE may be configured either locally (through functions included in the VPN client itself or on its platform), or remotely by a VPN Gateway. The ST will clearly state which functions can be performed locally and remotely. The operational guidance documentation will describe how this is performed as well. The evaluator is expected to test this functions in all the ways in which the ST and guidance documentation state the configuration can be managed (with the exception noted in the previous paragraph). Section 6.4 of the ST states that the TOE provides the following security management functions: specify VPN gateways, specify client credentials and load X.509v3 certificates. This is consistent with the FMT_SMF.1(1) requirement. Section 6.4 of the ST states that the VPN Gateway provides the following security management functions: configure IKE protocols and authentication techniques, configure the crypto period for the established IPsec session keys, configure the algorithms to be used in IPsec exchanges, configure certificate revocation checking and specify the reference identifier. This is consistent with the FMT_SMF.1(2) requirement. Section 6.4 of the ST states that the TOE Platform provides the following security management functions: the ability to load X.509v3 certificates on the Android and Windows platforms and the ability to update the TOE and to verify the updates. This is consistent with the FMT_SMF.1(2) requirement. Component Guidance Assurance Activities: The evaluator shall check to make sure that every management function mandated by the PP is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function. (Per TD0037) The evaluator shall ensure that the operational guidance instructs the administrator on configuring the reference identifier of the peer. The evaluator follows this guidance in the performance of the assurance activities for the FCS_IPSEC_EXT.1.14 and FCS_IPSEC_EXT.1.15 requirements. The evaluator reviewed the TOE documentation and confirmed that all management functions are described within the operational guidance. The guidance describes the configuration and the use of each management function provided by the TOE as identified in this report. Section FCS_IPSEC_EXT.1.13 of the Admin Guide indicates that in order to configure the peer DN, the dnprofile keyword should be used within the VIA connection profile. Component Testing Assurance Activities: The evaluator shall test the TOE's ability to provide the management functions by configuring the TOE and testing each option listed in the requirement above. In cases where the management function is provided entirely by the platform (meaning that it is not able to be invoked by or through the TOE), the evaluator may simply ensure that the function is included in each underlying platform's ST. Note that the testing here may be accomplished in conjunction with the testing of other requirements, such as FCS_IPSEC_EXT.1. GSS CCT Assurance Activity Report Page 55 of Gossamer Security Solutions, Inc.

56 Test 1 Management functions are tested by using the operational guidance to configure the TOE for testing. The TOE downloads the VIA connection profile from the Aruba Mobility Controller (ie. VPN Gateway) with all configuration preselected. The rest of the settings come from the platform or VPN gateway as empirically demonstrated throughout the IPsec and other tests. 2.5 PROTECTION OF THE TSF (FPT) EXTENDED: TSF SELF TEST (IVPNCPP14:FPT_TST_EXT.1) IVPNCPP14: FPT_TST_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14: FPT_TST_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: Except for where it is explicitly noted, the evaluator is expected to check the following information regardless of whether the functionality is implemented by the TOE or by the TOE platform. The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on start-up; 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. If some of the tests are performed by the TOE platform, the evaluator shall check the TSS to ensure that those tests are identified, and that the ST for each platform contains a description of those tests. Note that the tests that are required by this component are those that support security functionality in this PP, which may not correspond to the set of all selftests contained in the platform STs. The evaluator shall examine the TSS to ensure that it describes how the integrity of stored TSF executable code is cryptographically verified when it is loaded for execution. The evaluator shall ensure that the TSS makes an GSS CCT Assurance Activity Report Page 56 of Gossamer Security Solutions, Inc.

57 argument that the tests are sufficient to demonstrate that the integrity of stored TSF executable code has not been compromised. The evaluator shall check to ensure that the cryptographic requirements listed are consistent with the description of the integrity verification process. The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. This requirement is met by the TOE. Section 6.5 of the ST states that the TOE performs known answer power on self-tests (POST) on its cryptographic algorithms to ensure that they are functioning correctly. The TOE utilizes the Aruba Common Cryptographic Module (ACCM) library which implements known answer tests on its cryptographic algorithms to ensure they are working correctly. These known answer tests involve using the ACCM library functions to encrypt blocks of data and comparing the resulting encrypted block of data to a block that is known to be correct. The result of encrypting a block of data is the same every time if the encryption library operates properly. These tests cover the following algorithms, known answers tests, and pairwise consistency tests: AES-GCM, AES-CBC, SHA-1, SHA-256, SHA-384, HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, RSA Pairwise Consistency Test, RSA Encrypt/Decrypt Known Answer Test, DSA Pairwise Consistency Test, ECDSA Pairwise Consistency Test, ECDH Pairwise Consistency Test, DH Pairwise Consistency Test, and FIPS RNG Known Answer Test. The TOE invokes these self-tests of the ACCM library at start to ensure that those cryptographic algorithms are working correctly. If any self-test fails, the TOE will not start. Component Guidance Assurance Activities: The evaluator also ensures that the TSS (or the operational guidance) describes the actions that take place for successful (e.g. hash verified) and unsuccessful (e.g., hash not verified) cases. For checks implemented entirely by the platform, the evaluator ensures that the operational guidance for the TOE references or includes the platform-specific guidance for each platform listed in the ST. Section FPT_TST_EXT.1 in the Admin Guide states that when FIPS mode is enabled, the VIA crypto library performs the FIPS Power on Self-test that includes KATs for FIPS algorithms and an integrity check for the crypto library. If the self-test fails, the crypto library will not be loaded. Upon failure, VIA will not be able to establish IPSec connections and all crypto operations will fail. No additional configuration is required beyond putting VIA into FIPS mode by using the enable-fips configuration command in the VIA Connection Profile. The VIA client, when in FIPS mode, will restrict the use of non-fips GSS CCT Assurance Activity Report Page 57 of Gossamer Security Solutions, Inc.

58 algorithms in the VIA crypto library (MD5 and MODP768 (DH group 1)). Downloaded IPSec connection profiles with these algorithms will not connect successfully. Component Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluator performs the integrity check on a known good TSF executable and verifies that the check is successful. Test 2: The evaluator modifies the TSF executable, performs the integrity check on the modified TSF executable and verifies that the check fails. Test 1 This is tested in FPT_TUD_EXT.1. The evaluator was able to load the correct product version. Test 2 The evaluator modified each version of the TOE in a hex editor. Each version failed to load as a result of the integrity check failure EXTENDED: TRUSTED UPDATE (IVPNCPP14:FPT_TUD_EXT.1) IVPNCPP14:FPT_TUD_EXT.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14:FPT_TUD_EXT.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14:FPT_TUD_EXT.1.3 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 58 of Gossamer Security Solutions, Inc.

59 Component TSS Assurance Activities: Updates to the TOE are signed by an authorized source and may also have a hash associated with them, or are signed by an authorized source. If digital signatures are used, the definition of an authorized source is contained in the TSS, along with a description of how the certificates used by the update verification mechanism are contained on the device. The evaluator ensures this information is contained in the TSS. The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates are obtained; the processing associated with verifying the digital signature or calculating the hash of the updates; and the actions that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be verified) cases. If these activities are performed entirely by the underlying platform, a reference to the ST of each platform indicating that the required functionality is included for each platform shall be verified by the evaluator. Section 6.5 of the ST states that the TOE supports loading updates by the administrator using CLI commands. For Android versions, the application and signature is provided to and verified by the Google Play Store. The TOE platform checks the signature against the downloaded application when the update is obtained by the TOE platform. For Linux and Windows platforms, the administrator obtains the update in the form of an installer program from Aruba. The installer automatically verifies the digital signature on the update during installation. An unverified update cannot be installed. Section 6.6 of the Samsung Platform-ST upon which the VPN TOE relies indicates that the Android OS requires that all applications bear a valid signature before Android will install the application. Section of the Windows Platform-ST upon which the VPN TOE relies indicates that Windows has update mechanisms to deliver updated operating system and application binaries and a means for a user to confirm that the digital signatures, which ensure the integrity of the update are valid. Windows checks the integrity of all application executable code. Section B.2.2 of the RedHat Linux Enterprise 6 Deployment Guide found via RedHat OS indicates that the signature of a package is checked automatically when installing or upgrading a package. Component Guidance Assurance Activities: The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates are obtained; the processing associated with verifying the digital signature or calculating the hash of the updates; and the actions that take place for successful (hash or signature was verified) Section FPT_TUD_EXT.1 in the Admin Guide states that for Linux and Windows platforms, the administrator obtains the update in the form of an installer program from the Aruba support website. The installer uses an embedded digital signature which is created at build time. The installer automatically verifies its integrity using the digital signature prior to installation. An unverified update cannot be installed. For Android versions, the application and signature are provided to and verified by the Google Play Store. The VIA client installer downloaded from the Google Play Store is validated against the Aruba provided signature. An unverified update cannot be installed. Component Testing Assurance Activities: The evaluator shall perform the following tests (regardless of whether the functionality is implemented by the TOE or by the platform): GSS CCT Assurance Activity Report Page 59 of Gossamer Security Solutions, Inc.

60 Test 1: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE. Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update. Test 2: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE rejects the update. Test 1 - The evaluator obtained a legitimate update for the TOE and verified the previous version prior to applying it. The evaluator then updated the TOE on each platform and verified the new version was installed correctly. Test 2 The evaluator modified each legitimate update in a hex editor and attempted to update. In each case the update package was rejected and the TOE was not updated. The evaluator confirmed that the previous version of the TOE was still installed. 2.6 TRUSTED PATH/CHANNELS (FTP) INTER-TSF TRUSTED CHANNEL (IVPNCPP14:FTP_ITC.1) IVPNCPP14:FTP_ITC.1.1 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined IVPNCPP14:FTP_ITC.1.2 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined GSS CCT Assurance Activity Report Page 60 of Gossamer Security Solutions, Inc.

61 IVPNCPP14: FTP_ITC.1.3 TSS Assurance Activities: None Defined Guidance Assurance Activities: None Defined Testing Assurance Activities: None Defined Component TSS Assurance Activities: The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to a VPN Gateway in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specification. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. Section 6.6 of the ST states that the TOE uses IPsec to provide a protected communication channel between itself and an IPsec VPN gateway. The TOE uses IKEv2 and not IKEv1. Section 6.1 of the ST describes how the TOE establishes IPsec VPN connections with configured VPN gateways. Component Guidance Assurance Activities: The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to the access point, and that it contains recovery instructions should a connection be unintentionally broken. Section FTP_ITC.1 of the Admin Guide states that the connection, disconnection, and reconnection of a disconnected IPSec tunnel is performed using the VIA software. The Windows and Android OS VIA clients make use of a graphical interface. The Linux VIA CLI client makes use of a shell command line interface. For specific instructions on connecting, disconnecting and reconnecting the VIA client on each operating system platform, a reference to the Aruba VIA 3.x for ArubaOS 6.5.x User Guide and the Aruba VIA 3.x for ArubaOS 8.x User Guide is provided as detailed below. These guides can be accessed via the links found in the Documentation References section. Aruba VIA 3.x for ArubaOS 6.5.x User Guide and Aruba VIA 3.x for ArubaOS 8.x User Guide Windows OS the VIA Client for Windows section and the Downloading VPN Profiles sub-section on page 20 describe how to connect to the VPN Gateway (ie. Aruba Mobility Controller) and download the VIA connection profile. The Connecting and Disconnecting VIA sub-section provides instructions for connecting or disconnecting VIA using the VPN connection status ring. Android OS the VIA Client for Android section and the Downloading VIA sub-section on page 56 describe how to connect to the VPN Gateway (ie. Aruba Mobility Controller) and download the VIA connection profile. The Connecting and Disconnecting VIA sub-section provides instructions for connecting or disconnecting VIA using the VPN connection status ring. Linux OS the VIA for Linux CLI section and the IPsec sub-section on page 119 provide the commands to start a VIA session and to download a VIA connection profile created on the VPN Gateway (ie. Aruba GSS CCT Assurance Activity Report Page 61 of Gossamer Security Solutions, Inc.

62 Mobility Controller). The Start VIA session and Stop VIA session sub-sections provide the commands for starting and stopping the VIA IPsec connection. Component Testing Assurance Activities: The evaluator shall also perform the following tests: Test 1: The evaluators shall ensure that the TOE is able to initiate communications with a VPN Gateway using the protocols specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful. Test 2: The evaluator shall ensure, for each communication channel with a VPN Gateway, the channel data is not sent in plaintext. Test 3: The evaluator shall ensure, for each communication channel with a VPN Gateway, modification of the channel data is detected by the TOE. Test 4: The evaluators shall physically interrupt the connection from the TOE to the a VPN Gateway. The evaluators shall ensure that subsequent communications are appropriately protected, at a minimum in the case of any attempts to automatically resume the connection or connect to a new access point. Test 1- IPsec protocols and establishment of the VPN tunnels are tested in the corresponding IPsec requirements. The evaluator attempted to connect the TOE to the VPN Gateway. On each platform, a successful connection was established. Test 2 - This was tested as part of Test 1. All encrypted traffic is shown as ESP in the packet captures. Test 3 - The evaluator established a successful IPsec connection between the TOE and the VPN Gateway. The evaluator then used a device between the TOE and the gateway to add random noise to the network traffic which corrupts network packets. The packet captures demonstrate that the ESP modifications were detected and dropped. Test 4 - The TOE can only establish a trusted channel (IPSec) with the VPN Gateway. The evaluator disconnected the Aruba Mobility Controller (ie. VPN gateway) from the network after a session had been established and then reconnected the Controller to the network. The evaluator observed that after the Controller had been reconnected the IPSec session renegotiated and re-established itself. GSS CCT Assurance Activity Report Page 62 of Gossamer Security Solutions, Inc.

63 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) BASIC FUNCTIONAL SPECIFICATION (ADV_FSP.1) Assurance Activities: There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Sections 4.1 and 4.2, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because the there is insufficient interface information, then an adequate functional specification has not been provided. 3.2 GUIDANCE DOCUMENTS (AGD) OPERATIONAL USER GUIDANCE (AGD_OPE.1) Assurance Activities: With respect to the management functions, while several have also been described in Sections 4.1 and 4.2, additional information is required as follows. For TOE that implement a cryptographic engine, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. The documentation must describe the process for verifying updates to the TOE, either by checking the hash or by verifying a digital signature. The evaluator shall verify that this process includes the following steps: - For hashes, a description of where the hash for a given update can be obtained. For digital signatures, instructions for obtaining the certificate that will be used by the FCS_COP.1(2) mechanism to ensure that a signed update has been received from the certificate owner. This may be supplied with the product initially, or may be obtained by some other means. - 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). - 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. GSS CCT Assurance Activity Report Page 63 of Gossamer Security Solutions, Inc.

64 Section 6.1 of the ST the TOE performs cryptographic algorithms using the Aruba Common Cryptographic Module (ACCM) library. The Introduction section of the Admin Guide warns administrators that use of other cryptographic engines was not evaluated not tested during the CC evaluation of the TOE. Section FPT_TUD_EXT.1 in the Admin Guide states that for Linux and Windows platforms, the administrator obtains the update in the form of an installer program from the Aruba support website. The installer uses an embedded digital signature which is created at build time. The installer automatically verifies its integrity using the digital signature prior to installation. An unverified update cannot be installed. For Android versions, the application and signature are provided to and verified by the Google Play Store. The VIA client installer downloaded from the Google Play Store is validated against the Aruba provided signature. An unverified update cannot be installed. For specific instructions for initiating the TOE update process on each operating system platform, the Admin Guide provides a reference to the Aruba VIA 3.x for ArubaOS 6.5.x User Guide and the Aruba VIA 3.x for ArubaOS 8.x User Guide. These guides can be accessed via the links found in the Documentation References section. Aruba VIA 3.x for ArubaOS 6.5.x User Guide and Aruba VIA 3.x for ArubaOS 8.x User Guide Windows OS the VIA Client for Microsoft Windows section and the Downloading VPN Profiles subsection on page 20 describe how to install the VIA client and to download the VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller). Android OS the VIA Client for Android section and the Downloading VIA sub-section on page 56 describe how to install the VIA client and to download the VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller). Linux OS Chapter 4 provides instructions for installing the VIA client. The VIA for Linux CLI section and the IPsec sub-section on page 119 provide the commands to start a VIA session and to download a VIA connection profile created on the VPN Gateway (ie. Aruba Mobility Controller) PREPARATIVE PROCEDURES (AGD_PRE.1) Assurance Activities: As indicated in the introduction above, there are significant expectations with respect to the documentation-especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms and components (that is, combination of hardware and operating system) claimed for the TOE in the ST. The evaluator shall check to ensure that the following guidance is provided: - As indicated in the introductory material, administration of the TOE is performed by one or more administrators that are a subset of the group of all users of the TOE. While it must be the case that the overall system (TOE plus Operational Environment) provide this capability, the responsibility for the implementation of the functionality can vary from totally the Operational Environment's responsibility to totally the TOE's responsibility. At a high level, the guidance must contain the appropriate instructions so that the Operational Environment is configured so that GSS CCT Assurance Activity Report Page 64 of Gossamer Security Solutions, Inc.

65 it provides the portion of the capability for which it is responsible. If the TOE provides no mechanism to allow separation of administrative users from the population of users, then the instructions, for instance, would cover the OS configuration of the OS I&A mechanisms to provide a unique (OS-based) identity for users, and further guidance would instruct the installer on the configuration of the DAC mechanisms of the OS using the TOE administrative identity (or identities) so that only TOE administrators would have access to the administrative executables. If the TOE provides some or all of this functionality, then the appropriate requirements are included in the ST from Appendix C, and the assurance activities associated with those requirements provide details on the guidance necessary for both the TOE and Operational Environment. The evaluators shall also perform the following tests: Test 1 [Conditional]: If the separation of administrative users from all TOE users is performed exclusively through the configuration of the Operational Environment, the evaluators will, for each configuration claimed in the ST, ensure that after configuring the system according to the administrative guidance, non-administrative users are unable to access TOE administrative functions. There is no role separation. The VIA Client is simply an application on the TOE Platform (Android, Windows or Linux) that receives its configuration settings from an Aruba Mobility Controller (ie. VPN Gateway). Section FMT_SMF.1 of the Admin Guide states that specification of the VPN Gateway and all other settings used for connections will be pushed to the VIA client from an Aruba Mobility Controller once an initial connection is established. Section FCS_CKM.1, FCS_CKM.2 of the Admin Guide explains how to put the VIA Client into FIPS mode. Tests of the VIA Client on the TOE platforms demonstrated the capabilities that users and administrators have when the TOE is in FIPS mode. The VPN is simply an application on the TOE Platform and has no effect on the overall management of the TOE Platform. The configuration of the VIA Client was tested in FMT_SMF.1(1). 3.3 LIFE-CYCLE SUPPORT (ALC) LABELLING OF THE TOE (ALC_CMC.1) Assurance Activities: The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product. The evaluator verified that the ST, TOE and Guidance are all labeled with the same versions. The evaluator checked the TOE version during testing by examining the actual devices used for testing TOE CM COVERAGE (ALC_CMS.1) Assurance Activities: The 'evaluation evidence required by the SARs' in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done GSS CCT Assurance Activity Report Page 65 of Gossamer Security Solutions, Inc.

66 in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. The evaluator verified that the ST, TOE and Guidance are all labeled with the same versions. The evaluator checked the TOE version during testing by examining the actual devices used for testing. 3.4 TESTS (ATE) INDEPENDENT TESTING CONFORMANCE (ATE_IND.1) Assurance Activities: The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the body of this PP's Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluators must document in the test plan that each applicable testing requirement in the ST is covered. The Test Plan identifies the platforms to be tested, and for those 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 platform 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 of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluators are 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) is provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated 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; a fix installed; and then a successful re-run of the test, the report would show a 'fail' and '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. The test configuration consisted of the TOE platforms listed below, an Aruba Mobility Controller running ArubOS v.6.5, and supporting products and tools. Virtual Intranet Access (VIA) Client 3.0 (Windows) Virtual Intranet Access (VIA) Client 3.0 (Linux) Virtual Intranet Access (VIA) Client 3.0 (Android) GSS CCT Assurance Activity Report Page 66 of Gossamer Security Solutions, Inc.

67 The following diagram depicts the test environment: Aruba Controller ( ) Wireless Router VIA Client (Running on Android) ( and DHCP assigned) VIA Client (Running on Windows ) VIA Client (Running on CentOS ) GSS Test Server (Running Windows 10 and CentOS) ( ) To support the test environment the evaluator used the following products and tools: Supporting Products: Dell 3128C Evaluator Setup o Windows 10, 64-bit (GSS Windows Server, TestLab12 ) Standard Windows utilities (e.g., notepad, snip tool) Putty version :r10097 (used to connect to the Linux devices attached to the TOE devices to facilitate session logging) Wireshark version (used to examine network packets) Microsoft Hyper-V (part of Windows) o Ubuntu version 14.10, 64-bit (GSS Test Server, tl12-16x ) ip: Standard Linux commands (e.g., cat, grep, awk) OpenSSL version 1.0.1f (used to generate certificates) tcpdump (comes with Ubuntu used to generate packet capture files for network traffic) syslog-ng version (comes with Ubuntu used to accept TLS protected syslog logs) stunnel4 version 4.53 (dpkg for Ubuntu used to TLS protect syslog traffic) Evaluator developed test scripts to facilitate certificate test cases Supporting Software: GSS CCT Assurance Activity Report Page 67 of Gossamer Security Solutions, Inc.

68 Console Client Putty version 6.2 Wireshark version (3 instances identified above) 3.5 VULNERABILITY ASSESSMENT (AVA) VULNERABILITY SURVEY (AVA_VAN.1) Assurance Activities: As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to determine the vulnerabilities that have been found in VPN Client products in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a key combination on boot-up, for example, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires an electron microscope and a tank of liquid nitrogen, for instance, then a test would not be suitable and an appropriate justification would be formulated. The vulnerability analysis is in the Detailed Test Report (DTR) prepared by the evaluator. The vulnerability analysis includes a public search for vulnerabilities. The public search for vulnerabilities did not uncover any residual vulnerabilities. The evaluator searched the National Vulnerability Database ( Vulnerability Notes Database ( Rapid7 Vulnerability Database ( Tipping Point Zero Day Initiative ( ), Exploit / Vulnerability Search Engin ( SecurITeam Exploit Search ( Tenable Network Security ( Offensive Security Exploit Database ( on 2/27/2018 and on 4/30/2018 with the following search terms: "aruba via", "virtual intranet access", "ipsec", "aruba mobility controller", "tls", "aruba vpn". GSS CCT Assurance Activity Report Page 68 of Gossamer Security Solutions, Inc.