Cisco Jabber for Windows VOIP PP Assurance Activity Report. Pascal Patin ISSUED BY Acumen Security, LLC.

Transcription

1 Cisco Jabber for Windows VOIP PP Assurance Activity Report Pascal Patin ISSUED BY Acumen Security, LLC. 1

2 Revision History: Version Version 1.0 Version 1.1 Version 1.2 Version 1.3 Changes Initial Release Updated with new results Updated to address validator comments Updated to address remaining validator comments 2

3 Assurance Activity Report (AAR) for a Target of Evaluation Cisco Jabber for Windows Version 11.0 Cisco Jabber for Windows Security Target Version 1.0, November 12, 2015 Protection Profile for Voice Over IP (VoIP) Applications version 1.3 Version 1.3, November 11, 2015 Evaluated by: Office Park Dr. Montgomery Village, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme 3

4 The Developer of the TOE: Cisco Systems, Inc. 170 West Tasman Drive San Jose, California The Author of the Security Target: Cisco Systems, Inc. 170 West Tasman Drive San Jose, California The TOE Evaluation was Sponsored by: Cisco Systems, Inc. 170 West Tasman Drive San Jose, California Evaluation Personnel: Anthony Busciglio Pascal Patin Common Criteria Version Common Criteria Version 3.1 Revision 4 Common Evaluation Methodology Version CEM Version 3.1 Revision 4 4

5 1 TOE Overview Cisco Jabber for Windows streamlines communications and enhances productivity by unifying presence, instant messaging, video, voice, voice messaging, screen sharing, and conferencing capabilities securely into one client on your desktop. Cisco Jabber for Windows delivers highly secure, clear, and reliable communications. It offers flexible deployment models, is built on open standards, and integrates with commonly used desktop applications. The Cisco Jabber application is a soft phone with wideband and high-fidelity audio, standards based high-definition video (720p), and desk-phone control features. These features mean that high-quality and high-availability voice and video telephony is available on users desk phones, soft clients, and mobile devices. Cisco Jabber OS is a Cisco-developed highly configurable proprietary operating system that provides for efficient and effective unified communications application. 5

6 2 Assurance Activities Identification Test Case ID Activity Type Name of Evaluator/ Tester FCS_CKM_EXT.(2)1 TSS 1 TSS Pascal Patin FCS_SRTP_EXT.1 TSS 1 TSS Pascal Patin FCS_SRTP_EXT.1 Test 1 Testing Pascal Patin FDP_VOP_EXT.1 TSS 1 TSS Pascal Patin FDP_VOP_EXT.1 Test 1 Testing Pascal Patin FDP_VOP_EXT.1 Test 2 Testing Pascal Patin FIA_SIPC_EXT.1 TSS 1 TSS Pascal Patin FIA_SIPC_EXT.1 Test 1 Testing Pascal Patin FIA_SIPC_EXT.1 Test 2 Testing Pascal Patin FIA_SIPC_EXT.1 Test 3 Testing Pascal Patin FMT_SMF.1 Guidance 1 Guidance Pascal Patin FPT_TUD_EXT.1 TSS 1 TSS Pascal Patin FPT_TUD_EXT.1 Test 1 Testing Pascal Patin FTP_ITC.1(1) TSS 1 TSS Pascal Patin FTP_ITC.1(1) Guidance 1 Guidance Pascal Patin FTP_ITC.1(1) Test 1 Testing Pascal Patin FTP_ITC.1(1) Test 2 Testing Pascal Patin FTP_ITC.1(1) Test 3 Testing Pascal Patin FTP_ITC.1(1) Test 4 Testing Pascal Patin FCS_CKM.1(1) (Met by platform) TSS 1 TSS Pascal Patin FCS_CKM.1(1) (Met by TOE) B TSS 1 TSS Pascal Patin FCS_CKM.1(2) (Met by platform) TSS 1 TSS Pascal Patin FCS_CKM_EXT.4 (Met by platform) TSS 1 TSS Pascal Patin FCS_CKM_EXT.4 (Met by platform) TSS 2 TSS Pascal Patin FCS_COP.1(1) (Met by platform) TSS 1 TSS Pascal Patin FCS_COP.1(2) (Met by platform) TSS 1 TSS Pascal Patin FCS_COP.1(3) (Met by platform) TSS 1 TSS Pascal Patin FCS_COP.1(4) (Met by platform) TSS 1 TSS Pascal Patin FCS_RBG_EXT.1 (Met by platform) TSS 1 TSS Pascal Patin FCS_TLS_EXT.1 TSS 1 TSS Pascal Patin FCS_TLS_EXT.1 TSS 2 TSS Pascal Patin FCS_TLS_EXT.1 Test 1 Testing Pascal Patin FCS_TLS_EXT.1 Test 2 Testing Pascal Patin FCS_TLS_EXT.1 Test 3 Testing Pascal Patin FCS_TLS_EXT.1 Test 4 Testing Pascal Patin FCS_TLS_EXT.1 Test 5 Testing Pascal Patin FIA_X509_EXT.1 TSS 1 TSS Pascal Patin FIA_X509_EXT.1 Guidance 1 Guidance Pascal Patin FIA_X509_EXT.1 Test 1 Testing Pascal Patin FIA_X509_EXT.1 Test 2 Testing Pascal Patin FIA_X509_EXT.1 Test 3 Testing Pascal Patin FIA_X509_EXT.1 Test 4 Testing Pascal Patin 6

7 Test Case ID Activity Type Name of Evaluator/ Tester FIA_X509_EXT.1 Test 5 Testing Pascal Patin FIA_X509_EXT.1 Test 6 Testing Pascal Patin FIA_X509_EXT.2.2 TSS 1 TSS Pascal Patin FIA_X509_EXT.2.2 TSS 2 TSS Pascal Patin FIA_X509_EXT.2.3 TSS 1 TSS Pascal Patin FIA_X509_EXT.2.3 TSS 2 TSS Pascal Patin FMT_SMF.1 Guidance 1 Guidance Pascal Patin FPT_TST_EXT.1 TSS 1 TSS Pascal Patin FPT_TST_EXT.1 TSS 2 TSS Pascal Patin FPT_TST_EXT.1 Test 1 Testing Pascal Patin FPT_TST_EXT.1 Test 2 Testing Pascal Patin FPT_TUD_EXT.1 TSS 1 TSS Pascal Patin FPT_TUD_EXT.1 Test 1 Testing Pascal Patin FPT_TUD_EXT.1 Test 2 Testing Pascal Patin FTP_ITC.1(2) TSS 1 TSS Pascal Patin FTP_ITC.1(2) Test 1 Testing Pascal Patin FTP_ITC.1(2) Test 2 Testing Pascal Patin 7

8 3 Reporting on Assurance Activities 3.1 Reporting on TSS Assurance Activities Information required to be in the TSS is largely self-documenting, meaning that the evaluator in most cases is required to ensure that it is present in the TSS, but little beyond that is required in most PPs. For most TSS assurance activities in the AAR, a simple indication that the information is present and a pointer to that information in the ST is sufficient; it is not required to copy and paste the assurance activity or the information in the TSS into the AAR. It is expected that the evaluator ensure that the information in the TSS as a whole is consistent, and that spurious information is not included. For some information in the TSS, the evaluator may be required to make a judgment on that information relative to the security requirement being levied. For these requirements, the evaluator shall write up their rationale in the TSS section of the AAR. 3.2 Reporting on Guidance Assurance Activities The AAR lists specifically all documents used for each platform, model, and hardware component (chassis, blade, processor, etc.) to satisfy the requirements for operational guidance assurance activities. Each applicable administrative manual must be identified in a manner such that an end user can locate the specific manual used for the evaluation. It is acceptable to list general manuals that have evaluation-specific addenda, as long as both are identified. For each assurance activity referencing information in the operational guidance, the AAR must list for each model that has a distinct manual or manuals the specific manual that contains the information, along with a pointer to the section or sections that satisfy the requirement in the assurance activity. 8

9 4 Test Diagram (Test Bed #1) Jabber Client #1 (TOE) CUCM #1 Cisco RTMT (Audit Server) Switch NTP Server Jabber Client #2 CUCM #2 Mgt. Console 9

10 5 Configuration Information (Test Bed #1) CUCM#1: o Hardware Model: C210 M2 o Version: 11.0 o IP address: o Configuration Details: Phone Profile configured for Jabber1 Device configured Jabber1 User configured Jabber1 SIP Trunk Profile configured connecting CUCM#1 to CUCM#2 Packet Capture on outgoing/incoming interfaces configured CUCM #2: o Hardware Model: C210 M2 o Version: 11.0 o IP address: o Configuration Details: Phone Profile configured for device1 Device configured device1 User configured jabber1 SIP Trunk Profile configured connecting CUCM#2 to CUCM#1 Packet Capture on outgoing/incoming interfaces configured Jabber Client #1 (TOE) o Windows 8 Pro 64-bit o Intel Core i5-4210u CPU o 8.0 GB RAM o Cisco Jabber version 11.0 (SIPClient1) o IP address: , Configuration/Installed tools: Wireshark version Jabber Client #2 o Windows 8.1 o Cisco Jabber version 11.0 (SIPClient2) o IP address: , Configuration/Installed tools: Wireshark version Management Console o Windows 8 o IP address: Configuration/Installed tools: Wireshark version , Vsphere Switch: o Linksys SRW

11 6 Test Diagram (Test Bed #2) Jabber Client #1 Switch SSL Server 11

12 7 Configuration Information (Test Bed #2) SSL Server: o PC o Kali Linux Version: o IP address: o Configuration Details: Packet Modification tool version 1.0 Jabber Client #1 o Windows 8 Pro 64-bit o Intel Core i5-4210u CPU o 8.0 GB RAM o Cisco Jabber version 11.0 o IP address: o Configuration/Installed tools: Wireshark version

13 8 Test Diagram (Test Bed #3) Jabber Client #1 Switch SSL Server 13

14 9 Configuration Information (Test Bed #3) SSL Server: o Windows 8 o IP address: o Configuration Details: OpenSSL version c Jabber Client #1 o Windows 8 Pro 64-bit o Intel Core i5-4210u CPU o 8.0 GB RAM o Cisco Jabber version 11.0 o IP address: o Configuration/Installed tools: Wireshark version

15 10 Detailed Test Cases 10.1 Cryptographic Support (FCS) FCS_CKM_EXT.2.1(1) TSS 1 The evaluator shall examine the TSS to ensure it describes in detail how user credentials, certificates, persistent secret and private keys are stored. The evaluator reviews the TSS to determine that it makes a case that key material is not written unencrypted to persistent memory, and that key material is stored by the platform Evaluator Findings The evaluator examined the TSS to ensure that it describes in detail how user credentials, certificates, persistent secrets and private keys are stored. Table 19 in section 6.1 was used to determine the verdict of this assurance activity. The TOE stores keys when it is in the evaluated configuration as described in the TSS entry for FCS_SRTP_EXT.1. The platform s key store is used for this purpose. Security is assured by the platform s key isolation service that is designed for the purpose of hosting secret and private keys in a protected storage space. Based on this the assurance activity is considered satisfied Verdict FCS_SRTP_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how the SRTP session is negotiated for both incoming and outgoing calls. This includes how the keying material is established, as well has how requests to use the NULL algorithm or other unallowed ciphersuites are rejected by the TSF Evaluator Findings The evaluator examined the TSS to verify that it describes how SRTP sessions are negotiated for both incoming and outgoing calls. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. When TLS is used to secure a SIP session then all SRTP ciphers are offered. The SIP server is responsible for TLS cipher negotiation. The SIP server can select either authenticated or encrypted operation. Encrypted SRTP sessions are secured with AES_CM_128_HMAC_SHA1_ Verdict FCS_SRTP_EXT.1 Test 1 Test ID FCS_SRTP_EXT.1 Test 1 The evaluator shall follow the procedure for initializing their device so that they are ready to receive and place calls. The evaluator shall then both place and receive a call and determine that the traffic sent and received by the TOE is encrypted. To ensure that the call is being encrypted and to view the ciphersuites being used a packet capture tool should be used. In order to 15

16 /Fail Criteria FCS_CKM.1.1(1) Met By Platform, TSS 1 decrypt the TLS-SIP traffic and view the SDES negotiation the SIP server s private key needs to be loaded into the packet capture tool. 1. Configure the device according to guidance documentation to place and receive encrypted calls from another client. 2. Place a call to another client. 3. Using a packet capture tool capture the traffic going to and from the device and determine if it is encrypted. 4. Place a call from another client to the TOE. 5. Configure the CUCM server to output an unencrypted version of the negotiation. 6. Verify the SDES communication The SIP exchange shows the negotiated srtp parameters 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application'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 VoIP Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the key establishment claimed for the platform contains the key establishment requirement in the TOE s ST. The Jabber ST and the Windows 8 ST were used to determine the verdict of this assurance activity. The Jabber ST requires that the client device platform generate asymmetric keys used for key establishment in accordance with NIST Special Publications A. Cryptographic key sizes should be equivalent or greater than a symmetric key strength of 112 bits. This matches the claims made in the Windows 8 ST. NIST B key establishment is done by the TOE using cryptographic primitives provided by the platform. This functionality is not claimed in the Windows 8 ST, however it is claimed in mobility PP evaluations for Windows which have been performed. The TOE ST contains a reference to the cryptographic primitive and cryptographic configuration functions from the platform used by the TOE in the TSS entry for FCS_CKM.1(1) and (2). See the table 19 entry for this SFR in the ST for more detail Verdict FCS_CKM.1.1(2) Met By Platform, TSS 1 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the key generation functionality is invoked 16

17 (it should be noted that this may be through a mechanism that is not implemented by the VoIP Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the key generation function claimed for the platform contains the key generation requirement in the TOE s ST. The Jabber ST and the Windows 8 ST were used to determine the verdict of this assurance activity. The Jabber ST requires that the client device platform generate asymmetric keys used for authentication in accordance with FIPS appendices B.3 for RSA schemes and B.4 for ECDSA schemes. According to section of the Windows 8 ST the platform generates keys in accordance with appendices B.1, B.3 and B.4 of FIPS The TOE ST contains a reference to the cryptographic primitive and cryptographic configuration functions from the platform used by the TOE in the TSS entry for FCS_CKM.1(1) and (2). In addition the evaluator examined the TOE ST to determine how the key generation functionality is invoked. According to the TSS key generation is invoked by the SIP server admin setting the device into install/upgrade mode. Keys are generated when the user proceeds with initial configuration and setup. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By Platform, TSS 1 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 Evaluator Findings The evaluator examined the TSS to ensure that each of the secret keys, private keys and CSPs used to generate keys that are not otherwise covered by the SFR are described. Table 19 of section 6.1 was used to determine the verdict of this work unit. According to the TSS all keys and secrets are stored on the client platform. These are described in the TSS entry for FCS_CKM_EXT.4. A reference that describes how the platform handles this is also provided. Based on this the assurance activity is considered satisfied Verdict FCS_CKM_EXT.4.1 Met By Platform, TSS 2 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 Evaluator Findings The evaluator examined the TSS of the ST platform to ensure that each of secret keys, private keys and CSPs used to generate the above listed keys is covered. According to section of the Windows 8 ST, the platform zeroizes all plaintext secret and private cryptographic keys and CSPs when they are no longer required. Section in the platform ST s TSS states that this functionality is performed by the cryptography API. The TSS entry for FCS_CKM_EXT.2(1) 17

18 describes how logins and passwords are handled, all other keys and CSPs are in the entry for FCS_CKM_EXT.4. Based on this the assurance activity is considered satisfied Verdict FCS_COP.1.1(1) Met By Platform, TSS 1 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the encryption/decryption functionality is invoked for each mode and key size selected in the VoIP Client Application's ST (it should be noted that this may be through a mechanism that is not implemented by the VoIP Client Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the encryption/decryption functions claimed in the platform ST contain the encryption/decryption functions in the TOE ST. The Jabber and Windows 8 STs were used to determine the verdict of this assurance activity. According to section of the Jabber ST encryption is performed using AES in CTR, CBC and GCM. Cryptographic key sizes are 128 and 256 bits. Encryption and decryption are done in accordance with FIPS PUB 197, NIST SP800-38A and NIST SP800-38D. Section (FCS_COP.1(AES).1) is the corresponding section of the Windows 8 ST. It was found that the platform uses AES in all of the modes described by the Jabber ST, includes the same key sizes and meets the same FIPS standards and NIST SPs. The TOE ST lists the various.dll files that are invoked in order for the TOE to use the platform s cryptographic functionality. Based on this the assurance activity is considered complete Verdict FCS_COP.1.1(2) Met By Platform, TSS 1 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application'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 VoIP client application (it should be noted that this may be through a mechanism that is not implemented by the VoIP Client Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the digital signature functions claimed in the platform ST contain the digital signature functions in the TOE ST. The Jabber and Windows 8 STs were used to determine the verdict of this assurance activity. 18

19 According to section of the Jabber ST cryptographic signature services are performed in accordance with FIPS appendices B.3 and B.4 using cryptographic key sizes equivalent to or greater than a symmetric key strength of 112 bits. Section (FCS_COP.1(SIGN).1) is the corresponding section of the Windows 8 ST. It was found that both types of digital signature schemes listed in the TOE ST are in the Windows 8 ST, and are performed in accordance with FIPS Key sizes of 2048 bits (considered equivalent to a symmetric key strength of 112 bits) or greater are used. The evaluator also examined the TSS of the TOE to verify that it describes how digital signature functionality is invoked for each operation that it is used for by the TOE. Table 19 of section 6.1 of the TOE ST states that signature verification is only performed to validate server certificates as required by client TLS sessions. Based on this the assurance activity is considered satisfied Verdict FCS_COP.1.1(3) Met By Platform, TSS 1 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the VoIP Client Application's ST (it should be noted that this may be through a mechanism that is not implemented by the VoIP Client Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the hash functions claimed in the platform ST contain the hash functions in the TOE ST. The Jabber and Windows 8 STs were used to determine the verdict of this assurance activity. According to section of the Jabber ST cryptographic hashing is performed in accordance with the SHA-1, SHA-256 and SHA-384 algorithms with message digest sizes of 160, 256 and 384 bits in accordance with FIPS PUB Section (FCS_COP.1(HASH)) is the equivalent section of the Windows 8 ST. Its algorithm and message digest claims include those from the TOE ST. It also states that hashing is done according to FIPS 180-4, which is the standard that superseded FIPS The evaluator also examined the TSS of the TOE to verify that it describes how digital signature functionality is invoked for each operation that it is used for by the TOE. Table 19 of section 6.1 of the TOE ST states that hashing is done on the establishment of TLS connections, as part of SRTP and as part of SIP digest authentication. The TSS entry for this SFR lists the different.dll files that are called in order to invoke the platform s digital signature functionality. Based on this the assurance activity is considered satisfied Verdict FCS_COP.1.1(4) Met By Platform, TSS 1 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 VoIP Client Application's ST. The evaluator shall also examine the TSS of the VoIP Client Application's ST to verify that it describes (for each supported platform) how the keyed-hash functionality is invoked for 19

20 each mode and key size selected in the VoIP Client Application's ST (it should be noted that this may be through a mechanism that is not implemented by the VoIP Client Application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity) Evaluator Findings The evaluator examined the platform ST to ensure that the keyed-hash functions claimed in the platform ST contain the keyed-hash functions in the TOE ST. The Jabber and Windows 8 STs were used to determine the verdict of this assurance activity. According to section of the Jabber ST keyed-hash message authentication is done in accordance with HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384. Cryptographic key sizes and message digest sizes of 160, 256 and 384 are used, and it is done in accordance with FIPS pubs and Section (FCS_COP.1(HMAC).1) is the equivalent section of the Windows 8 ST. Its claimed algorithms, message digest sizes and standards include all of those from the TOE ST, except for the fact that it claims FIPS PUB rather than The evaluator also examined the TSS of the TOE ST to verify that it describes how keyed-hash functionality is invoked by the client. There are two Windows.dll files that are called as appropriate and they are listed in the TSS. Based on this the assurance activity is considered complete Verdict FCS_RBG_EXT.1 Met By Platform, TSS 1 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 VoIP Client Application s ST. The evaluator shall also examine the TSS of the VoIP Client Application 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 VoIP application (it should be noted that this may be through a mechanism that is not implemented by the VoIP application; nonetheless, that mechanism will be identified in the TSS as part of this assurance activity Evaluator Findings The evaluator examined the platform ST to ensure that the RBG functions claimed in the platform ST contain the RBG functions in the TOE s ST. The Jabber and Windows 8 STs were used to determine the verdict of this assurance activity. According to section of the Jabber ST deterministic random bit generation is done in accordance with NIST SP A using CTR DRBG(AES) and FIPS Pub 140-2, Annex C. The deterministic RBG has a minimum entropy of 256 bits. The corresponding section of the Windows 8 ST claims that random bit generation is done in accordance with NIST SP A and that a RBG is seeded with a minimum of 256 bits of entropy. In order to invoke RBG functionality the TOE calls one of two.dll files listed in TSS. Based on this the assurance activity is considered satisfied Verdict 20

21 10.2 User Data Protection (FDP) FDP_VOP_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how each of the functions in the requirement is implemented Evaluator Findings The evaluator examined the ST to verify that it describes how each of the functions in FDP_VOP_EXT.1 is implemented. Table 19 in section 6.1 of that was used to determine the verdict of this assurance activity. According to the SFR the transmission of voice data should be stopped when a call is placed on hold, mute or not connected. There are no other functions that need to be implemented. The TSS states that the transmission of data is stopped when a call is placed on hold. Calls that are placed on mute aren t stopped but no data is sent from the microphone and silence or comfort noise packets are sent instead. Based on this the assurance activity is considered satisfied Verdict FDP_VOP_EXT.1 Test 1 Test ID FDP_VOP_EXT.1 Test 1 The evaluator shall follow the procedure for initializing the device so that it is ready to receive and place calls. Using a packet capture tool, the evaluator shall verify that no voice traffic is transmitted until a call is placed/received. The evaluator shall place a call and verify that the voice traffic is being sent through the secure channel. The evaluator shall then implement each of the functions listed (mute, hold, disconnect, and any other specified actions) and verify that voice traffic is no longer being transmitted. 1. Start up the TOE so that it is in a state where it can place a call to another VoIP client. 2. Start a packet capture tool to monitor data going into and out of the TOE. 3. Place a call from the TOE to the other VoIP client. 4. Once the call is accepted turn the mute feature on the TOE on and then off. 5. Place the TOE on hold and then take it off of hold. 6. Disconnect the TOE from the call. /Fail Criteria The wire capture shows that when the call was muted srtp packets are not passed. 21

22 FDP_VOP_EXT.1 Test 2 Test ID FDP_VOP_EXT.1 Test 2 The evaluator shall follow the procedure for initializing the device so that it is ready to receive and place calls. Using a packet capture tool, the evaluator shall verify that no voice traffic is transmitted until a call is placed/received. The evaluator shall receive a call and verify that the voice traffic is being sent through the secure channel. The evaluator shall then implement each of the functions listed (mute, hold, disconnect, and any other specified actions) and verify that voice traffic is no longer being transmitted. Prerequisites The TOE should be capable of receiving a call from another VoIP client. 1. Start up the TOE so that it is in a state where it can receive a call from another VoIP client. 2. Start a packet capture tool to monitor data going into and out of the TOE. 3. Place a call from another VoIP client to the TOE. 4. Once the call is accepted turn the mute feature on the TOE on and then off. 5. Place the TOE on hold and then take it off of hold. 6. Disconnect the TOE from the call. /Fail Criteria The wire capture shows that when the call was placed on hold srtp packets are not passed Identification and Authentication (FIA) FIA_SIPC_EXT.1 TSS 1 The evaluator shall examine the TSS to verify that it describes how the SIP session is established. This shall include the initiation of the SIP session, registration of the user, and how both outgoing and incoming calls are handled (initiated, described, and terminated). This description shall also include a description of the handling of the password from the time it is entered by the user until the time it is cleared by the TSF Evaluator Findings The evaluator examined the TSS to verify that it describes how the SOP session is established. Table 19 in section 6.1 was used to determine the verdict of this assurance activity. During an attempt to connect to the SIP server the TOE passes a request for a password to the user in order to complete the SIP REGISTER request. The password is passed on to CUCM and then the memory space holding it is immediately overwritten. An authentication token is passed from CUCM to the TOE where it is stored in a SecureString. Once a call is completed the memory space holding the token is overwritten and the space is released for use by other functions. Based on this the assurance activity is considered satisfied. 22

23 Verdict FIA_SIPC_EXT.1 Test 1 Test ID FIA_SIPC_EXT.1 Test 1 The evaluator shall follow the procedure for initializing their device to include establishing a connection to the SIP Server. The evaluator shall confirm that they are prompted for a password prior to successfully completing the SIP REGISTER request. Prerequisites The TOE should be setup with the ability to connect to a SIP server. 1. Attempt to connect the TOE to a SIP server. 2. Start a packet capture of all traffic between the TOE and the SIP server. 3. Verify that the SIP REGISTER request is not completed until after a password is entered into the TOE. /Fail Criteria The SIP REGISTER packet is only sent after authentication FIA_SIPC_EXT.1 Test 2 Test ID FIA_SIPC_EXT.1 Test 2 The evaluator shall follow the procedure for initializing their device to include establishing a connection to the SIP Server. The evaluator shall confirm that entering an incorrect password results in the device not being registered by the SIP Server (e.g., they are unable to successful place or receive calls). The evaluator shall also confirm that entering the correct password allows the successful registration of the device (e.g., by being able to place and receive calls). Prerequisites The TOE should be setup with the ability to connect to a SIP server. 1. Start a wireshark capture 2. Begin to establish a connection between the TOE and a SIP server 3. Enter a bad password 4. Verify that no SIP traffic is passed /Fail Criteria No SIP traffic is sent between the client and the SIP server until the user has successfully authenticated FIA_SIPC_EXT.1 Test 3 Test ID FIA_SIPC_EXT.1 Test 23

24 /Fail Criteria FIA_X509_EXT.1 TSS 1 The evaluator shall set up the test environment such that a variety of passwords are shown to be accepted by the TOE, such that the length and character set identified in FIA_SIPC_EXT.1.3 is represented. The test report shall contain a rationale by the evaluator that the test set used is representative of the allowed lengths and characters. 1. Set the minimum password length for 15 characters 2. Attempt a set of good passwords 3. Verify that the good passwords were accepted 4. Attempt a set of bad passwords 5. Verify the bad passwords were not accepted Only good passwords are accepted. Bad passwords are rejected. 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 Evaluator Findings The evaluator examined the ST to verify that the TSS describes where the check of validity of the certificates takes place. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the entry for FIA_X509_EXT.1 and 2 in table 19 certificate validation is performed by the platform. This is consistent with section of the ST which is the SFR is written. Table 19 states that the TOE uses certificates from either a CUCM server or a third party CA. When the TOE receives a server certificate it uses the platform s certificate validation functionality to validate the server s certificate as well as all of the certificates in the certificate chain. CRL/OCSP revocation checks are performed and the extendedkeyusage field is validated. Based on this the assurance activity is considered complete Verdict FIA_X509_EXT.1 Guidance 1 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 Evaluator Findings The evaluator examined the guidance documentation to determine whether it provides the user with the necessary information to setup the validation check. Section of the guidance document was used to determine the verdict of this assurance activity. 24

25 According to the guidance document the certificate store for the TOE is managed by the operating system, Microsoft Windows 8. If a well-known certificate store is used then Windows may already have the certificate for it. If it does not then the certificate will need to be deployed by following the directions given in section Based on this the assurance activity is considered satisfied Verdict FIA_X509_EXT.1 Test 1 Note: All of the following FIA_X509_EXT.1 tests (1 through 6) were performed against the initial registration connection between the TOE and the Cisco CUCM server, which is required in the operational environment. This is due to the fact that in the operational environment, there is no way for the TOE to receive bad certificates for the voice channel. Moreover the certificate validation mechanism used by the TOE is the same for initial registration and subsequent call setup. As such the mechanism has been tested as part of testing the initial registration. Test ID FIA_X509_EXT.1.1 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. Prerequisites The TOE or TOE platform should be able to able to receive and validate certificates from a certificate authority. 1. Load a certificate without a valid certification path into the TOE or the TOE platform. 2. Attempt to validate the certificate and confirm that any functions which depend on it fail. 3. Load the additional certificates that are required for a valid certification path into the TOE or the TOE platform. 4. Attempt to validate the certificate and confirm that any functions which depend on it succeed. 5. Delete one of the certificates from the certification path from the TOE or the TOE platform. 6. Confirm that any functions which depend on the certificate now no longer function properly. /Fail Criteria The certificate is not validated without a valid certification path, and can validate a certificate with a valid path FIA_X509_EXT.1 Test 2 25

26 Test ID FIA_X509_EXT.1.1 Test #2 The evaluator shall demonstrate that validating an expired certificate results in the function failing. Prerequisites The TOE or TOE platform should be able to able to receive and validate certificates from a certificate authority. Execution Output Actual Output /Fail Criteria The expired certificate will not be validated FIA_X509_EXT.1 Test 3 Test ID FIA_X509_EXT.1.1 Test #3 The evaluator shall test that the TOE can properly handle revoked certificates conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. The evaluator has to only test one up in the trust chain (future revisions 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 validation function succeeds. 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 validation function fails. Execution Output Actual Output /Fail Criteria When a certificate is revoked either by CRL or OCSP, the certificate is not accepted by the platform FIA_X509_EXT.1 Test 4 Test ID FIA_X509_EXT.1.1 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. Prerequisites The TOE or TOE platform should be able to able to receive and validate certificates from a certificate authority. 1. Created a certificate authority whose certificate does not contain the basicconstraints extension. 2. Import the CA s certificate into the TOE or TOE platform. 3. Have the CA generate a client certificate. 4. Import the client certificate into the TOE or TOE platform. 5. Attempt to validate the client certificate and verify that validation fails. 26

27 /Fail Criteria FIA_X509_EXT.1 Test 5 This test passes if the TOE platform rejects certificates issued by a CA whose certificate does not contain the basicconstraints extension. Test ID FIA_X509_EXT.1.1 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 Bed Testbed #1 1. The TOE relies on its platform for certificate validation, so Windows certificate management functionality is used for this test. 2. Create a certificate authority using OpenSSL running on a Linux platform. 3. Create an intermediate certificate authority using OpenSSL. 4. Open the openssl.cnf file for the intermediate CA that was just created. Locate the the basicconstraints for the intermediate CA and make sure it is not set. 5. Issue a client certificate from the intermediate CA. 6. Import the root certificates for the top level and intermediate CAs and the client certificate into Enterprise Trust Certificates in the Windows certificate management console for the current user. 7. Double click on the newly imported client certificate. Check the Certification Path tab to verify that the path is invalid because of the intermediate CA. /Fail Criteria Certificates signed by CAs where the basicconstraints CA flag are not set are not validated FIA_X509_EXT.1 Test 6 Test ID FIA_X509_EXT.1.1 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. 1. The TOE relies on its platform for certificate validation, so Windows certificate management functionality is used for 27

28 /Fail Criteria FIA_X509_EXT.2.2 TSS 1 this test. 2. Create a certificate authority using OpenSSL running on a Linux platform. 3. Open the openssl.cnf file for the CA that was just created. Locate the the basicconstraints for the CA and make sure it is set to TRUE. 4. Issue a client certificate from the CA. 5. Import the root certificates for the top and the client certificate into Enterprise Trust Certificates in the Windows certificate management console for the current user. 6. Double click on the newly imported client certificate. Check the Certification Path tab to verify that the path is valid. The imported certificates are successfully validated. /Fail 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 Evaluator Findings The evaluator examined the ST to verify that the TSS describes where the check of validity of the certificates takes place. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the entry for FIA_X509_EXT.1 and 2 in table 19, the TOE s use of certificates is controlled by Cisco s CUCM server. During initial setup of the TOE CUCM can either generate its own certificates or request them from an external CA. These are the certificates that are used by the TOE to establish secure connections. They are stored in the platform s certificate store. The certificates from CUCM can be sent to the TOE in one of two ways. If the TOE doesn t already have a certificate when it attempts to connect a certificate will be sent by CUCM and the user will be prompted to accept it. Alternately a certificate for CUCM can be manually imported into the platform certificate store that the TOE uses. The procedures for this are in section of the guidance documentation. Based on this the assurance activity is considered satisfied Verdict FIA_X509_EXT.2.2 TSS 2 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 implemented entirely by the platform, the evaluator shall 28

29 examine the ST of each platform to confirm that the selections for this element are contained in each platform s ST Evaluator Findings The evaluator examined the ST to verify that the TSS 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. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the entry for FIA_X509_EXT.1 and 2 in table 19, being unable to connect to a revocation server results in the administrator being able to choose whether to establish a connection. The evaluator also examined the Windows 8 Security Target (VID 10520) and found that the ST contains both CRL and OCSP functionality, as follows: Certificate Revocation List (CRL) capabilities are described in sections , , , and Online Certificate Status Protocol (OCSP) functionality is described in sections and Based on this the assurance activity is considered satisfied Verdict FIA_X509_EXT.2.2 Test 1 This test was not performed because this requirement is implemented by the platform FIA_X509_EXT.2.3 TSS 1 The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates Evaluator Findings The evaluator examined the ST to verify that the TSS describes where the check of validity of the certificates takes place. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the entry for FIA_X509_EXT.1 and 2 in table 19, the TOE s use of certificates is controlled by Cisco s CUCM server. During initial setup of the TOE CUCM can either generate its own certificates or request them from an external CA. These are the certificates that are used by the TOE to establish secure connections. They are stored in the platform s certificate store. The certificates from CUCM can be sent to the TOE in one of two ways. If the TOE doesn t already have a certificate when it attempts to connect a certificate will be sent by CUCM and the user will be prompted to accept it. Alternately a certificate for CUCM can be manually imported into the platform certificate store that the TOE uses. The procedures for this are in section of the guidance documentation. Based on this the assurance activity is considered satisfied Verdict 29

30 FIA_X509_EXT.2.3 TSS 2 The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE 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 Evaluator Findings The evaluator examined the ST to verify that the TSS 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. Table 19 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the entry for FIA_X509_EXT.1 and 2 in table 19, being unable to connect to a revocation server results in the administrator being able to choose whether to establish a connection. Based on this the assurance activity is considered satisfied Verdict FIA_X509_EXT.2.3 Test 1 Test ID FIA_X509_EXT.2.3 Test #1 The evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the function fails. This test is performed in conjunction with FIA_X509_EXT.1 Test 1 /Fail Criteria This test is performed in conjunction with FIA_X509_EXT.1 Test 1 /Fail FIA_X509_EXT.2.3 Test 2 Test ID FIA_X509_EXT.2.3 Test #2 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 30

31 /Fail Criteria administrator-configurable options behave in their documented manner. 1. Generate a CA and certificates with OCSP responder URIs listed in the AIA extension of the leaf certificates 2. Load the certificate Root CA certificate into the TOE Platform s trusted root certificates 3. Disable the actual OCSP responder Connect the TOE to the CUCM server using the certificate /Fail FIA_X509_EXT.2.3 Test 3 Test ID FIA_X509_EXT.2.3 Test #3 The evaluator shall use a certificate signed using the RSA or ECDSA algorithm to authenticate the TOE to the SIP Server during establishment of the trusted channel. This test ensures the TOE has the certificate for the trusted CA that signed the SIP Server's certificate and it will do a bit-wise comparison on the DN. This bitwise comparison of the DN ensures that not only does the SIP Server have a certificate signed by the trusted CA, but the certificate is from the DN that is expected. The evaluator will configure the TSS to associate a certificate or DN (e.g., a certificate map in some implementations) with a trusted channel connection. This is what the DN is checked against. This test is done in conjunction with FIA_X509_EXT2.3 Test #4 /Fail Criteria This test is done in conjunction with FIA_X509_EXT2.3 Test #4 /Fail FIA_X509_EXT.2.3 Test 4 Test ID FIA_X509_EXT.2.3 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 a trusted channel does not get established. 1. Configure TOE to connect the CUCM server using an IP address instead of a hostname 2. Issue a certificate from a trusted authority that uses the FQDN for the CN field in the DN portion of the X509 Certificate 3. Attempt to connect and verify that the CN difference causes 31