Assurance Activity Report for Cisco Expressway X12.5 ... - NIAP

Assurance Activity Report

for

Cisco Expressway X12.5

Cisco Expressway X12.5 System Common Criteria Security Target, Version 1.5

Cisco Expressway X12.5 System Common Criteria Configuration Guide, Version 1.4

Collaborative Protection Profile for Network Devices Version 2.0 + Errata 20180314

2

Revision History:

Version Date Changes

Version 1.1 10/14/2019 Updates based on vendor updates Version 1.2 01/10/2020 Updated based on ECR comments Version 1.3 02/03/2020 Updated based on ECR comments Version 1.4 02/12/2020 Updated based on ECR comments Version 1.5 02/17/2020 Updated based on ECR comments Version 1.6 02/19/2020 Updated based on updated doc versions Version 1.7 02/19/2020 Updated based on updated doc versions

3

Table of Contents

1 TOE Overview .............................................................................................................. 15

1.1 TOE Description .............................................................................................................. 15

1.2 Physical Scope of the TOE .............................................................................................. 18

2 Equivalency Analysis .................................................................................................... 22

2.1 Architectural Description ............................................................................................... 22

2.2 OS, Processor, and Firmware Analysis ........................................................................... 22

2.3 Hardware Interface Analysis .......................................................................................... 23

2.4 Storage Interface Analysis .............................................................................................. 23

2.5 Network Interface Analysis ............................................................................................ 23

2.6 Serial Interface Analysis ................................................................................................. 24

2.7 USB Interface Analysis .................................................................................................... 24

2.8 Processor Interface Analysis .......................................................................................... 24

2.9 General Platform Analysis .............................................................................................. 26

2.10 Additional Equivalency Analysis ................................................................................. 27

2.10.1 Software/OS Dependencies: ................................................................................... 27

2.10.2 Differences in Libraries Used to Provide TOE Functionality ................................... 27

2.10.3 TOE Management Interface Differences ................................................................ 27

2.10.4 TOE Functional Differences ..................................................................................... 27

2.11 Recommendations/Conclusions ................................................................................. 28

3 Test Diagram ................................................................................................................ 29

3.1 Test Bed #1 ..................................................................................................................... 29

3.1.1 Visual Diagram ........................................................................................................ 29

3.1.2 Configuration Information ..................................................................................... 29

3.1.3 Test Time/Location................................................................................................. 30

4 Detailed Test Cases ...................................................................................................... 31

4.1 Test Cases (Auditing) ...................................................................................................... 31

4.1.1 FAU_GEN.1 TSS 1 .................................................................................................... 31

4.1.2 FAU_GEN.1 Guidance 1 .......................................................................................... 32

4.1.3 FAU_GEN.1 Guidance 2 .......................................................................................... 32

4.1.4 FAU_GEN.1 Test 1 ................................................................................................... 39

4.1.5 FAU_GEN.2 ............................................................................................................. 40

4

4.1.6 FAU_STG_EXT.1 TSS 1............................................................................................. 40

4.1.7 FAU_STG_EXT.1 TSS 2............................................................................................. 40

4.1.8 FAU_STG_EXT.1 TSS 3............................................................................................. 40

4.1.9 FAU_STG_EXT.1 TSS 4............................................................................................. 41

4.1.10 FAU_STG_EXT.1 Guidance 1 ................................................................................... 41

4.1.11 FAU_STG_EXT.1 Guidance 2 ................................................................................... 42

4.1.12 FAU_STG_EXT.1. Guidance 3.................................................................................. 42

4.1.13 FAU_STG_EXT.1 Test 1 ........................................................................................... 42

4.1.14 FAU_STG_EXT.1 Test 2 ........................................................................................... 43

4.1.15 FAU_STG_EXT.1 Test 4 ........................................................................................... 43

4.2 Test Cases (Communication) .......................................................................................... 44

4.2.1 FCO_CPC_EXT.1 TSS 1 ............................................................................................. 44

4.2.2 FCO_CPC_EXT.1 TSS 2 ............................................................................................. 44

4.2.3 FCO_CPC_EXT.1 Guidance 1 ................................................................................... 45



4.2.6 FCO_CPC_EXT.1 Test 1.1 ......................................................................................... 46

4.2.7 FCO_CPC_EXT.1 Test 1.2 ......................................................................................... 46

4.2.8 FCO_CPC_EXT.1.2 Test 2 ......................................................................................... 47

4.2.9 FCO_CPC_EXT.1 Test 3 ............................................................................................ 47

4.2.10 FCO_CPC_EXT.1 Test 4 ............................................................................................ 48

4.2.11 FCO_CPC_EXT.1 Test 5 ............................................................................................ 48

4.3 Test Cases (Cryptographic Support) ............................................................................... 48

4.3.1 FCS_CKM.1 TSS 1 .................................................................................................... 48

4.3.2 FCS_CKM.1 Guidance 1 .......................................................................................... 49

4.3.3 FCS_CKM.1 Test 1 ................................................................................................... 49

4.3.4 FCS_CKM.2 TSS 1 .................................................................................................... 49

4.3.5 FCS_CKM.2 Guidance 1 .......................................................................................... 50

4.3.6 FCS_CKM.2 Test 1 ................................................................................................... 50

4.3.7 FCS_CKM.2 Test 2 ................................................................................................... 51

4.3.8 FCS_CKM.4.1 TSS 1 ................................................................................................. 51

4.3.9 FCS_CKM.4 TSS 2 .................................................................................................... 52

5

4.3.10 FCS_CKM.4 TSS 3 .................................................................................................... 53

4.3.11 FCS_CKM.4 TSS 4 .................................................................................................... 54

4.3.12 FCS_CKM.4 TSS 5 .................................................................................................... 54

4.3.13 FCS_CKM.4 Guidance 1 .......................................................................................... 54

4.3.14 FCS_CKM.4 Guidance 2 .......................................................................................... 55

4.3.15 FCS_COP.1/DataEncryption Test 1 ........................................................................ 55

4.3.16 FCS_COP.1/SigGen Test 1 ....................................................................................... 55

4.3.17 FCS_COP.1/Hash TSS 1 ........................................................................................... 56

4.3.18 FCS_COP.1/Hash Guidance 1 ................................................................................. 56

4.3.19 FCS_COP.1/Hash Test 1 .......................................................................................... 56

4.3.20 FCS_COP.1/KeyedHash TSS 1 ................................................................................. 57

4.3.21 FCS_COP.1/KeyedHash Test 1 ................................................................................ 57

4.3.22 FCS_RBG_EXT.1 TSS 1 ............................................................................................. 58

4.3.23 FCS_RBG_EXT.1 Guidance 1 ................................................................................... 58

4.3.24 FCS_RBG_EXT.1.1 Test 1 ......................................................................................... 58

4.4 Test Cases (HTTPS) ......................................................................................................... 59

4.4.1 FCS_HTTPS_EXT.1 TSS 1.......................................................................................... 59

4.4.2 FCS_HTTPS_EXT.1 Test #1 ...................................................................................... 59

4.4.3 FCS_HTTPS_EXT.1 Test #2 ...................................................................................... 59

4.5 Test Cases (SSHC) ........................................................................................................... 59

4.5.1 FCS_SSHC_EXT.1.2 TSS 1 ......................................................................................... 59

4.5.2 FCS_SSHC_EXT.1.2 Test 1 ....................................................................................... 60

4.5.3 FCS_SSHC_EXT.1.3 TSS 1 ......................................................................................... 60

4.5.4 FCS_SSHC_EXT.1.3 Test 1 ....................................................................................... 61

4.5.5 FCS_SSHC_EXT.1.4 TSS 1 ......................................................................................... 61

4.5.6 FCS_SSHC_EXT.1.4 Guidance 1 ............................................................................... 61

4.5.7 FCS_SSHC_EXT.1.4 Test 1 ....................................................................................... 62

4.5.8 FCS_SSHC_EXT.1.5 TSS 1 ......................................................................................... 62


4.5.10 FCS_SSHC_EXT.1.5 Test 1 ....................................................................................... 63

4.5.11 FCS_SSHC_EXT.1.5 Test 2 ....................................................................................... 64

4.5.12 FCS_SSHC_EXT.1.6 TSS 1 ......................................................................................... 64

6


4.5.14 FCS_SSHC_EXT.1.6 Test 1 ....................................................................................... 65

4.5.15 FCS_SSHC_EXT.1.6 Test 2 ....................................................................................... 65

4.5.16 FCS_SSHC_EXT.1.7 TSS 1 ......................................................................................... 65


4.5.18 FCS_SSHC_EXT.1.7 Test 1 ....................................................................................... 66

4.5.19 FCS_SSHC_EXT.1.8 TSS 1 ......................................................................................... 66


4.5.21 FCS_SSHCS_EXT.1.8 Test 1...................................................................................... 67

4.5.22 FCS_SSHC_EXT.1.9 Test 1 ....................................................................................... 68

4.5.23 FCS_SSHC_EXT.1.9 Test 2 ....................................................................................... 69

4.6 Test Cases (SSHS) ............................................................................................................ 69

4.6.1 FCS_SSHS_EXT.1.2 TSS 1 ......................................................................................... 69

4.6.2 FCS_SSHS_EXT.1.2 Test 1 ........................................................................................ 70

4.6.3 FCS_SSHS_EXT.1.2 Test 2 ........................................................................................ 70

4.6.4 FCS_SSHS_EXT.1.3 TSS 1 ......................................................................................... 70

4.6.5 FCS_SSHS_EXT.1.3 Test 1 ........................................................................................ 70

4.6.6 FCS_SSHS_EXT.1.4 TSS 1 ......................................................................................... 71

4.6.7 FCS_SSHS_EXT.1.4 Guidance 1 ............................................................................... 71

4.6.8 FCS_SSHS_EXT.1.4 Test 1 ........................................................................................ 72

4.6.9 FCS_SSHS_EXT.1.5 TSS 1 ......................................................................................... 72


4.6.11 FCS_SSHS_EXT.1.5 Test 1 ........................................................................................ 73

4.6.12 FCS_SSHS_EXT.1.5 Test 2 ........................................................................................ 73

4.6.13 FCS_SSHS_EXT.1.5 Test 3 ........................................................................................ 74

4.6.14 FCS_SSHS_EXT.1.6 TSS 1 ......................................................................................... 74


4.6.16 FCS_SSHS_EXT.1.6 Test 1 ........................................................................................ 75

4.6.17 FCS_SSHS_EXT.1.6 Test 2 ........................................................................................ 75

4.6.18 FCS_SSHS_EXT.1.7 TSS 1 ......................................................................................... 76


4.6.20 FCS_SSHS_EXT.1.7 Test 1 ........................................................................................ 76

7

4.6.21 FCS_SSHS_EXT.1.7 Test 2 ........................................................................................ 77

4.6.22 FCS_SSHS_EXT.1.8 TSS 1 ......................................................................................... 77


4.6.24 FCS_SSHS_EXT.1.8 Test 1 ........................................................................................ 78

4.7 Test Cases (TLSC) ............................................................................................................ 79

4.7.1 FCS_TLSC_EXT.2.1 TSS 1 ......................................................................................... 79

4.7.2 FCS_TLSC_EXT.2.1 Guidance 1 ............................................................................... 79

4.7.3 FCS_TLSC_EXT.2.1 Test 1 ........................................................................................ 80

4.7.4 FCS_TLSC_EXT.2.1 Test 2 ........................................................................................ 80

4.7.5 FCS_TLSC_EXT.2.1 Test 3 ........................................................................................ 81

4.7.6 FCS_TLSC_EXT.2.1 Test 4 ........................................................................................ 81

4.7.7 FCS_TLSC_EXT.2.1 Test 5a ...................................................................................... 81

4.7.8 FCS_TLSC_EXT.2.1 Test 5b ...................................................................................... 81

4.7.9 FCS_TLSC_EXT.2.1 Test 5c ...................................................................................... 82

4.7.10 FCS_TLSC_EXT.2.1 Test 5d ...................................................................................... 82

4.7.11 FCS_TLSC_EXT.2.1 Test 5e ...................................................................................... 82

4.7.12 FCS_TLSC_EXT.2.1 Test 5f ....................................................................................... 82

4.7.13 FCS_TLSC_EXT.2.2 TSS 1 ......................................................................................... 83


4.7.15 FCS_TLSC_EXT.2.2 Test 1 ........................................................................................ 83

4.7.16 FCS_TLSC_EXT.2.2 Test 2 ........................................................................................ 84

4.7.17 FCS_TLSC_EXT.2.2 Test 3 ........................................................................................ 84

4.7.18 FCS_TLSC_EXT.2.2 Test 4 ........................................................................................ 84

4.7.19 FCS_TLSC_EXT.2.2 Test 5a ...................................................................................... 85

4.7.20 FCS_TLSC_EXT.2.2 Test 5b ...................................................................................... 85

4.7.21 FCS_TLSC_EXT.2.2 Test 6 (Conditional) ................................................................. 85

4.7.22 FCS_TLSC_EXT.2.3 Test 1 ........................................................................................ 86

4.7.23 FCS_TLSC_EXT.2.4 TSS 1 ......................................................................................... 86


4.7.25 FCS_TLSC_EXT.2.4 Test 1 ........................................................................................ 87

4.7.26 FCS_TLSC_EXT.2.5 TSS 1 ......................................................................................... 87


8

4.7.28 FCS_TLSC_EXT.2.5 Test 1 ........................................................................................ 88

4.7.29 FCS_TLSC_EXT.2.5 Test 2 ........................................................................................ 88

4.8 Test Cases (TLSS) ............................................................................................................ 88

4.8.1 FCS_TLSS_EXT.2.1 TSS 1 ......................................................................................... 88

4.8.2 FCS_TLSS_EXT.2.1 Guidance 1 ............................................................................... 89

4.8.3 FCS_TLSS_EXT.2.1 Test 1 ........................................................................................ 89

4.8.4 FCS_TLSS_EXT.2.1 Test 2 ........................................................................................ 90

4.8.5 FCS_TLSS_EXT.2.1 Test 3 ........................................................................................ 90

4.8.6 FCS_TLSS_EXT.2.1 Test 4c ...................................................................................... 90

4.8.7 FCS_TLSS_EXT.2.1 Test 4d ...................................................................................... 90

4.8.8 FCS_TLSS_EXT.2.1 Test 4e ...................................................................................... 91

4.8.9 FCS_TLSS_EXT.2.2 TSS 1 ......................................................................................... 91


4.8.11 FCS_TLSS_EXT.2.2 Test 1 ........................................................................................ 92

4.8.12 FCS_TLSS_EXT.2.3 TSS 1 ......................................................................................... 92


4.8.14 FCS_TLSS_EXT.2.3 Test 1 ........................................................................................ 93

4.8.15 FCS_TLSS_EXT.2.4/2.5 TSS 1 .................................................................................. 93

4.8.16 FCS_TLSS_EXT.2.4/2.5 Guidance 1 ......................................................................... 94

4.8.17 FCS_TLSS_EXT.2.4/2.5 Test 1 ................................................................................. 94

4.8.18 FCS_TLSS_EXT.2.5/2.5 Test 2 ................................................................................. 94

4.8.19 FCS_TLSS_EXT.2.4/2.5 Test 3 ................................................................................. 95

4.8.20 FCS_TLSS_EXT.2.4/2.5 Test 4 ................................................................................. 95

4.8.21 FCS_TLSS_EXT.2.4/2.5 Test 5 ................................................................................. 95

4.8.22 FCS_TLSS_EXT.2.4/2.5 Test 6a ............................................................................... 96

4.8.23 FCS_TLSS_EXT.2.4/2.5 Test 6b ............................................................................... 96

4.8.24 FCS_TLSS_EXT.2.6 TSS 1 ......................................................................................... 96

4.8.25 FCS_TLSS_EXT.2. Guidance 1 ................................................................................. 97

4.8.26 FCS_TLSS_EXT.2.6 Test 1 ........................................................................................ 97

4.9 Test Cases (Identification and Authentication) .............................................................. 97

4.9.1 FIA_AFL.1 TSS 1 ....................................................................................................... 97

4.9.2 FIA_AFL.1 TSS 2 ....................................................................................................... 98

9

4.9.3 FIA_AFL.1 Guidance 1 ............................................................................................. 98

4.9.4 FIA_AFL.1 Guidance 2 ............................................................................................. 98

4.9.5 FIA_AFL.1 Test #1 ................................................................................................... 99

4.9.6 FIA_AFL.1 Test #2 ................................................................................................... 99

4.9.7 FIA_PMG_EXT.1.1 Guidance 1 ............................................................................. 100

4.9.8 FIA_PMG_EXT.1 Test 1 ......................................................................................... 100

4.9.9 FIA_UIA_EXT.1 TSS 1 ............................................................................................ 101

4.9.10 FIA_UIA_EXT.1 TSS 2 ............................................................................................ 101

4.9.11 FIA_UIA_EXT.1 Guidance 1 .................................................................................. 102

4.9.12 FIA_UIA_EXT.1 Test #1 ......................................................................................... 102

4.9.13 FIA_UIA_EXT.1 Test #2 ......................................................................................... 103

4.9.14 FIA_UIA_EXT.1 Test #3 ......................................................................................... 103

4.9.15 FIA_UIA_EXT.1 Test #4 ......................................................................................... 103

4.9.16 FIA_UAU_EXT.2 .................................................................................................... 104

4.9.17 FIA_UAU.7 Test #1 ................................................................................................ 104

4.9.18 FIA_X509_EXT.1.1/ITT TSS 1 ................................................................................ 104

4.9.19 FIA_X509_EXT.1.1/ITT Test 1 ............................................................................... 105

4.9.20 FIA_X509_EXT.1.1/ITT Test 2 ............................................................................... 105

4.9.21 FIA_X509_EXT.1.1/ITT Test 3 ............................................................................... 105

4.9.22 FIA_X509_EXT.1.1/ITT Test 4 ............................................................................... 106

4.9.23 FIA_X509_EXT.1.1/ITT Test 5 ............................................................................... 106

4.9.24 FIA_X509_EXT.1.1/ITT Test 6 ............................................................................... 106

4.9.25 FIA_X509_EXT.1.1/ITT Test 7 ............................................................................... 106

4.9.26 FIA_X509_EXT.1.2/ITT Test 1 ............................................................................... 107

4.9.27 FIA_X509_EXT.1.2/ITT Test 2 ............................................................................... 107

4.9.28 FIA_X509_EXT.1.1/Rev TSS 1 ............................................................................... 108

4.9.29 FIA_X509_EXT.1.1/Rev Test 1 .............................................................................. 108

4.9.30 FIA_X509_EXT.1.1/Rev Test 2 .............................................................................. 109

4.9.31 FIA_X509_EXT.1.1/Rev Test 3 .............................................................................. 109

4.9.32 FIA_X509_EXT.1.1/Rev Test 4 .............................................................................. 110

4.9.33 FIA_X509_EXT.1.1/Rev Test 5 .............................................................................. 110

4.9.34 FIA_X509_EXT.1.1/Rev Test 6 .............................................................................. 110

10

4.9.35 FIA_X509_EXT.1.1/Rev Test 7 .............................................................................. 111

4.9.36 FIA_X509_EXT.1.2/Rev Test 1 .............................................................................. 111

4.9.37 FIA_X509_EXT.1.2/Rev Test 2 .............................................................................. 112

4.9.38 FIA_X509_EXT.2 TSS 1 .......................................................................................... 112

4.9.39 FIA_X509_EXT.2 TSS 2 .......................................................................................... 113

4.9.40 FIA_X509_EXT.2 Test #1 ....................................................................................... 113

4.9.41 FIA_X509_EXT.3 TSS 1 .......................................................................................... 114

4.9.42 FIA_X509_EXT.3 Guidance 1 ................................................................................ 114

4.9.43 FIA_X509_EXT.3 Test #1 ....................................................................................... 114

4.9.44 FIA_X509_EXT.3 Test #2 ....................................................................................... 115

4.10 Test Cases (Security Management) .......................................................................... 115

4.10.1 FMT_MOF.1/ManualUpdate Guidance 1 ............................................................ 115

4.10.2 FMT_MOF.1/ManualUpdate Test #1 ................................................................... 116

4.10.3 FMT_MOF.1/ManualUpdate Test #2 ................................................................... 116

4.10.4 FMT_MTD.1/CoreData TSS 1 ............................................................................... 116

4.10.5 FMT_MTD.1/CoreData Guidance 1 ..................................................................... 117

4.10.6 FMT_MTD.1/CryptoKeys Test #1 ......................................................................... 117

4.10.7 FMT_MTD.1/CryptoKeys Test #2 ......................................................................... 117

4.10.8 FMT_SMF.1 ........................................................................................................... 118

4.10.9 FMT_SMF.1 Test #1 .............................................................................................. 119

4.10.10 FMT_SMR.2 Guidance 1 ................................................................................... 119

4.10.11 FMT_SMR.2 Test #1 .......................................................................................... 119

4.11 Test Cases (Protection of the TSF) ............................................................................ 120

4.11.1 FPT_SKP_EXT.1 TSS 1 ............................................................................................ 120

4.11.2 FPT_APW_EXT.1 TSS 1 .......................................................................................... 120

4.11.3 FPT_APW_EXT.1 TSS 2 .......................................................................................... 121

4.11.4 FPT_ITT.1 TSS 1 ..................................................................................................... 121

4.11.5 FPT_ITT.1 Guidance 1 ........................................................................................... 121

4.11.6 FPT_ITT.1 Test #1 .................................................................................................. 121

4.11.7 FPT _ITT.1 Test #2 ................................................................................................. 122

4.11.8 FPT _ITT.1 Test #3 ................................................................................................. 122

4.11.9 FPT_STM_EXT.1 TSS 1 .......................................................................................... 123

11

4.11.10 FPT_STM_EXT.1 Guidance 1 ............................................................................. 123

4.11.11 FPT_STM_EXT.1 Test #1 .................................................................................... 124

4.11.12 FPT_STM_EXT.1 Test #2 .................................................................................... 124

4.11.13 FPT_TST_EXT.1.1 TSS 1 ..................................................................................... 124

4.11.14 FPT_TST_EXT.1.1 TSS 2 ..................................................................................... 125

4.11.15 FPT_TST_EXT.1.1 Guidance 1 ........................................................................... 125

4.11.16 FPT_TST_EXT.1.1 Test #1 .................................................................................. 126

4.11.17 FPT_TUD_EXT.1 TSS 1 ....................................................................................... 126

4.11.18 FPT_TUD_EXT.1 TSS 2 ....................................................................................... 127

4.11.19 FPT_TUD_EXT.1 Guidance 1 ............................................................................. 127

4.11.20 FPT_TUD_EXT.1 Guidance 2 ............................................................................. 128

4.11.21 FPT_TUD_EXT.1 Test #1 .................................................................................... 128

4.11.22 FPT_TUD_EXT.1 Test #3a .................................................................................. 129

4.11.23 FPT_TUD_EXT.1 Test #3b .................................................................................. 129

4.11.24 FPT_TUD_EXT.1 Test #3c .................................................................................. 130

4.12 Test Cases (TOE Access) ............................................................................................ 131

4.12.1 FTA_SSL_EXT.1 Test #1 ......................................................................................... 131

4.12.2 FTA_SSL_EXT.1/FTA_SSL.3 Guidance 1 ................................................................ 131

4.12.3 FTA_SSL.3 Test #1 ................................................................................................. 131

4.12.4 FTA_SSL.4 Guidance 1 .......................................................................................... 132

4.12.5 FTA_SSL.4 Test #1 ................................................................................................. 132

4.12.6 FTA_SSL.4 Test #2 ................................................................................................. 132

4.12.7 FTA_TAB.1 TSS 1 ................................................................................................... 132

4.12.8 FTA_TAB.1 Guidance 1 ......................................................................................... 133

4.12.9 FTA_TAB.1 Test #1 ................................................................................................ 133

4.13 Test Cases (Trusted Path/Channels) ......................................................................... 134

4.13.1 FTP_ITC.1 TSS 1 ..................................................................................................... 134

4.13.2 FTP_ITC.1 TSS 2 ..................................................................................................... 134

4.13.3 FTP_ITC.1 Guidance 1 ........................................................................................... 135

4.13.4 FTP_ITC.1 Test #1 .................................................................................................. 135

4.13.5 FTP_ITC.1 Test #2 .................................................................................................. 136

4.13.6 FTP_ITC.1 Test #3 .................................................................................................. 136

12

4.13.7 FTP_ITC.1 Test #4 .................................................................................................. 137

4.13.8 FTP_ITC.1(2) .......................................................................................................... 137

4.13.9 FTP_ITC.1(3) .......................................................................................................... 138

4.13.10 FTP_TRP.1/Admin TSS 1 ................................................................................... 138

4.13.11 FTP_TRP.1/Admin TSS 2 ................................................................................... 138

4.13.12 FTP_TRP.1/Admin Guidance 1 ......................................................................... 139

4.13.13 FTP_TRP.1/Admin Test #1 ................................................................................ 139

4.13.14 FTP_TRP.1/Admin Test #2 ................................................................................ 139

5 Security Assurance Requirements .............................................................................. 140

5.1 ADV Assurance Activities .............................................................................................. 140

5.1.1 ADV_FSP.1 ............................................................................................................ 140

5.2 ASE_CCL.1 Conformance Claims .................................................................................. 140

5.2.1 ASE_CCL.1.8.C ....................................................................................................... 140

5.2.2 ASE_CCL.1.9.C ....................................................................................................... 140

5.2.3 ASE_CCL.1.9.C Test 1 ............................................................................................ 141

5.2.4 ASE_CCL.1.9.C Test 2 ............................................................................................ 142

5.3 AGD_OPE.1 Operational User Guidance ...................................................................... 142

5.3.1 AGD_OPE.1 Test #1 .............................................................................................. 142

5.4 AGD_PRE.1 Preparative Procedures ............................................................................ 143

5.4.1 AGD_PRE.1 ............................................................................................................ 143

5.5 ALC Assurance Activities .............................................................................................. 144

5.5.1 ALC_CMC. 1 ........................................................................................................... 144

5.5.2 ALC_CMS. 1 ........................................................................................................... 144

5.6 ATE_IND.1 Independent Testing – Conformance ........................................................ 144

5.6.1 ATE_IND.1 Test #1 ................................................................................................ 144

5.7 AVA_VAN.1 Vulnerability Survey ................................................................................. 145

5.7.1 AVA_VAN.1 Test #1 .............................................................................................. 145

5.7.2 AVA Fuzzing Test .................................................................................................. 146

6 Technical Decisions .................................................................................................... 147

7 Conclusion ................................................................................................................. 153

13

Evaluated by:

2400 Research Blvd, Suite 395

Rockville, MD, 20850

Prepared for:

National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme

14

The Developer of the TOE: Cisco Systems, Inc.

The Author of the Security Target: Cisco Systems, Inc.

The TOE Evaluation was Sponsored by: Cisco Systems, Inc.

Evaluation Personnel: Acumen Security, LLC

Common Criteria Version Common Criteria Version 3.1 Revision 4

Common Evaluation Methodology Version

CEM Version 3.1 Revision 4

15

1 TOE Overview

The Cisco Expressway X12.5 is designed specifically to provide a gateway solution that extends the services and access to users inside and outside of the organization’s firewall. The TOE includes the hardware models as defined below. Cisco Expressway X12.5 software is a Cisco-developed highly configurable proprietary operating system that provides for efficient and effective services that extend secure services to users inside and outside the organizations firewall. Although Cisco Expressway X12.5 software performs many networking functions, this Security Target only addresses the functions that provide for the security of the TOE itself as described in Section 1.7 TOE logical scope of the Security Target.

1.1 TOE Description This section provides an overview of the Cisco Expressway Target of Evaluation (TOE). Cisco Expressway is an advanced gateway that extend services to users inside and outside the organization firewall, such as desktop share, instant messaging, and presence. The TOE is comprised of both software and hardware. The TOE deployment is the Cisco Expressway instance running X12.5 software installed on one of four different models of the Cisco Unified Computing System™ (Cisco UCS), all of which are described below. The Cisco UCS boxes are administered through a single management entity called the Cisco UCS Manager (Cisco Unified Computing System (UCS) Manager 2.2(3a)). It is assumed the Cisco UCS is setup, configured in their evaluated configurations and ready for use. The Cisco Unified Computing System™ (Cisco UCS) C220 M4 Rack Server (one rack unit [1RU]) offers up to two Intel® Xeon® E5 Series processors, 24 DIMM slots, eight small form-factor (SFF) disk drives or four large form-factor (LFF) drives, and two 1 Gigabit Ethernet LAN‑on-motherboard (LOM) ports. Refer to Table 5 Hardware Models and Specifications for the primary features of the Cisco UCS C220 M4.

Figure 1 Cisco UCS C220 M4 Server

The Cisco Unified Computing System™ (Cisco UCS) C240 M4 Rack Server (two rack unit [2RU] offers up to two Intel® Xeon® E5 Series processors, 24 DIMM slots, 24 small form-factor (SFF) disk drives or 12 large form-factor (LFF) drives, and two 1 Gigabit Ethernet LAN-on-motherboard (LOM) ports. Refer to Table 5 Hardware Models and Specifications for the primary features of the Cisco UCS C240 M4.

16


The Cisco UCS C220 M5 Rack Server is a two-socket 1 Rack Unit (1RU) rack-mount server offers up to two Intel® Xeon® Scalable Series processors. The UCS C220 M5 supports:

up to 24 DDR4 DIMMs

up to 10 Small-Form-Factor (SFF) 2.5-inch drives or 4 Large-Form-Factor (LFF) 3.5-inch drives (77 TB storage capacity with all NVMe PCIe SSDs)

support for 12-Gbps SAS modular RAID controller in a dedicated slot, leaving the remaining PCIe Generation 3.0 slots available for other expansion cards

Modular LAN-On-Motherboard (mLOM) slot that can be used to install a Cisco UCS Virtual Interface Card (VIC) without consuming a PCIe slot

dual embedded Intel x550 10GBASE-T LAN-On-Motherboard (LOM) ports Refer to Table 5 Hardware Models and Specifications for the primary features of the Cisco UCS C220 M5.


The Cisco Unified Computing System™ (Cisco UCS) C240 M5 2 Rack Unit (2RU) offers up to two Intel® Xeon® Scalable series processors. The C240 M5 supports:

up to 24 DDR4 DIMM slots

up to 26 hot-swappable Small-Form-Factor (SFF) 2.5-inch drives, including 2 rear hot-swappable SFF drives

support for 12-Gbps SAS modular RAID controller in a dedicated slot Modular LAN-On-Motherboard (mLOM) slot that can be used to install a Cisco UCS Virtual Interface Card (VIC) without consuming a PCIe slot.

Also supporting dual 10- or 40-Gbps network connectivity, Dual embedded Intel x550 10GBASE-T LAN-On-Motherboard (LOM) ports and modular M.2 or Secure Digital (SD) cards that can be used for boot. Refer to Table 1 Hardware Models and Specifications for the primary features of the Cisco UCS C240 M5.


17

The TOE includes a web-browsable interface for the system configuration for administrators. Cisco Expressway supports the following operating system browsers:

Internet Explorer 8, 9, 10, and 11

Firefox 3 or later

Chrome HTTPS is used to secure the connection between Cisco Expressway and the browser. The TOE will be configured to only to use x.509v3-ssh-rsa public key algorithm for secure connection between Expressway-C and Expressway-E in MRA mode. This is a dedicated SSHv2 connection between the two components. The Expressway-C component is configured as the SSH Client and the Expressway-E is configured as the SSH Server. For the outbound port from Expressway-C (private) it is an ephemeral port to Expressway-E (DMZ) port 2222, a listening port. The Expressway-E listens on port 222 for SSH tunnel traffic and the only legitimate sender of SSH traffic is the Expressway-C. Refer to the Cisco Expressway X12.5 System Common Criteria Configuration Guide for details and configuration settings for the evaluated configuration. TLS is used to secure the connection between Cisco Expressway and the syslog server. This includes any syslog server to which the TOE would transmit syslog messages using TLSv1.1 or TLSv1.2 to secure the connection.

18

The following figure provides a visual depiction of a TOE deployment. The TOE boundary are the blue boxes.

Figure 5 TOE Example Deployment

1.2 Physical Scope of the TOE The TOE is a hardware and software solution that makes up the Cisco Expressway. The TOE hardware platform is at least one of the following Cisco UCS platforms, UCS C220 M4, UCS C240 M4, UCS C220 M5 or the UCS C240 M5. The TOE software is the Cisco Expressway X12.5 software. The network, on which the TOE resides is considered part of the environment. The TOE guidance documentation, the Cisco Expressway Common Criteria Configuration Guide that is also considered to be part of the TOE can be found listed and are downloadable from the http://cisco.com web site. The TOE hardware is comprised of the following physical specifications as described in Table 5 below:

DNS Serv

FIR

EW

AL

L

Cisco Expressway E

FIR

EW

AL

L

Service

Inside network

Perimeter Outside

Cisco

Expressway C

External

Network

Internal

Network

Syslog Serv

CUCM Remote Admin Console

NTP Serv

CA

19

Table 1 Hardware Models and Specifications

Hardware/Processor/ Software

Size Power Interfaces

UCS C220 M4 While tested on the specific processor model listed, any Intel® Xeon® E526xx v4, processor may be used as part of the evaluated configuration with VMware ESXi 6.0 Expressway X12.5 software

1RU: 1.7 x 16.9 x 29.8 in. (4.32 x 43 x 75.6 cm)

Up to two 770 W (AC) hot swappable power supplies or two 1050 W (DC) power supplies. One is mandatory; one more can be added for 1 + 1 redundancy.

Up to 4 LFF or 8 SFF front-accessible, hot-swappable, internal SAS, SATA, or SSD drives, providing redundancy options and ease of serviceability

Various PCIe card ports (dependent on which cards are installed), • Virtual Interface Card (VIC) ports, Converged Network Adapter (CNA) ports, Network Interface Card (NIC) ports, Host Bus Adapter (HBA) ports

I/O performance and flexibility with one x8 half-height and half-length slot, and one x16 full-height and half‑length slot

Up to two internal 326GB or two 64GB Cisco FlexFlash drives (SD cards)

One internal USB flash drive Front panel - One KVM console connector (supplies two USB 2.0 connectors, one GA DB15 connector, and one serial port (RS232) RJ45 connector) Rear panel - One DB15 VGA connector, One RJ45 serial port connector, Two USB 3.0 port connectors, One RJ-45 10/100/1000 Ethernet management port, using Cisco Integrated Management Controller (CIMC) firmware, two Intel i350 embedded (on the motherboard) GbE LOM ports, One flexible modular LAN on motherboard (mLOM) slot that can accommodate various interface cards

UCS C240 M4 While tested on the specific processor model listed, any Intel® Xeon® E526xx v4, processor may be used as part of the evaluated configuration with VMWare ESXi 6.0 Expressway X12.5 software

2RU: 3.43 x 17.65 x 29.0 in. (8.7 x 44.8 x 73.8 cm)

The server is available with four types of power supplies:

650 W (AC)

930 W (DC)

1200 W (AC)

1400 W (AC))

Up to 12 LFF or 24 SFF front-accessible, hot-swappable, SAS, SATA, or SSD drives for local storage, providing redundancy options and ease of serviceability

Rear panel

One DB15 VGA connector

One RJ45 serial port connector

Two USB 3.0 port connectors

One RJ-45 10/100/1000 Ethernet management port, using Cisco Integrated

Management Controller (CIMC) firmware

Two Intel i350 embedded (on the motherboard) GbE LOM ports

One flexible modular LAN on motherboard (mLOM) slot that can accommodate various interface cards, Various PCIe card ports (dependent on which cards are installed)

Virtual Interface Card (VIC) ports

Converged Network Adapter (CNA) ports

Network Interface Card (NIC) ports

20



Host Bus Adapter (HBA) ports Front panel

One KVM console connector (supplies two USB 2.0 connectors, one VGA, DB15 video connector, and one serial port (RS232) RJ45 connector) support the InfiniBand architecture.

A front panel controller provides status indications and control buttons

UCS C220 M5 While tested on the specific processor model listed, any Intel® Xeon® Scalable processor with the Skylake-SP microarchitecture may be used as part of the evaluated configuration with VMware ESXi 6.0 Expressway X12.5 software

Height 1.7 in. (4.32 cm) Width 16.89 in. (43.0 cm) including handles: 18.98 in. (48.2 cm) Depth 29.8 in. (75.6 cm) including handles: 30.98 in. (78.7 cm

Up to two of the following hot-swappable power supplies:

770 W (AC)

1050 W (AC)

1050 W V2 (DC)

Rear panel • One 1-Gbps RJ-45 management port (Marvell 88E6176) • Two 10GBase-T LOM ports (Intel X550 controller embedded on the motherboard) • One RS-232 serial port (RJ45 connector) • One DB15 VGA connector • Two USB 3.0 port connectors • One flexible modular LAN on motherboard (mLOM) slot that can accommodate various interface cards Front panel • One KVM console connector (supplies two USB 2.0 connectors, one VGA DB15 video connector, and one serial port (RS232) RJ45 connector) Modular LAN on Motherboard (mLOM) slot The dedicated mLOM slot on the motherboard can flexibly accommodate the following cards:

Cisco Virtual Interface Cards Quad Port Intel i350 1GbE RJ45 Network Interface Card

(NIC)

UCS C240 M5 While tested on the specific processor model listed, any Intel® Xeon® Scalable processor with the Skylake-SP microarchitecture may be used as part of the evaluated

Height 3.43 in. (8.70 cm) Width (including slam latches) 17.65 in.(44.8 cm) Including handles: 18.96 in (48.2 cm)

Up to two of the following hot-swappable power supplies:

1050 W (AC) power supply

1050 W V2 (DC) power supply

1600 W (AC) power supply

Rear panel • One 1-Gbps RJ-45 management port (Marvell 88E6176) • Two 10GBase-T LOM ports (Intel X550 controller embedded on the motherboard) • One RS-232 serial port (RJ45 connector) • One DB15 VGA connector • Two USB 3.0 port connectors • One flexible modular LAN on motherboard (mLOM) slot that can accommodate various interface cards Front panel

21



configuration with VMware ESXi 6.0 Expressway X12.5 software

Depth 29.0 in. (73.8 cm) Including handles: 30.18 in (76.6 cm)

• One KVM console connector (supplies two USB 2.0 connectors, one VGA DB15 video connector, and one serial port (RS232) Modular LAN on Motherboard (mLOM) slot The dedicated mLOM slot on the motherboard can flexibly accommodate the following cards:

Cisco Virtual Interface Cards

Quad Port Intel i350 1GbE RJ45 mLOM Network Interface Card (NIC)

22

2 Equivalency Analysis

The following section presents an equivalency analysis for the TOE.

2.1 Architectural Description

The TOE is the Cisco Expressway X12.5. The TOE is comprised of hardware and software components. The Cisco Expressway is deployed as a pair of components. The Expressway-C component is located within the organization’s network with a trunk and line-side connection to Unified Call Manager (CUCM) and is used to provide the native endpoint registrations for both SIP and H323 devices in addition to the interworking of Cisco TelePresence endpoints with standards-compliant H.323 and SIP third-party video systems. The Expressway-E component is located at the perimeter of the organization’s network and is the SIP Proxy for devices which are located outside the internal network (for example, home users and mobile worker registering to Unified CM across the internet and 3rd party businesses making calls to, or receiving calls from this network). The Expressway-E is configured with a traversal server zone to receive communications from the Expressway-C in order to allow inbound and outbound calls to traverse the NAT device. All the possible TOE platforms are listed below:

Table 2: TOE Platforms All versions of the TOE run the X12.5 software version.

2.2 OS, Processor, and Firmware Analysis

The following table compares the Operating System, CPU, and firmware that runs on each of the included TOE platforms.

TOE Model Description Analysis

Operating System – This is the OS that runs on the platform

Expressway X12.5 Expressway X12.5 within ESXi 6.0

The TOE is comprised of two components Expressway C and Expressway E that are installed on ESXI 6.0 which is installed on a UCS platform. All of the SFR-enforcing functionality is executed at the virtual ND layer, and is executed the same regardless of

Model Size Hypervisor Processor System Memory

UCS C220 M4S (Intel Xeon E5 26XX v4)

1 RU ESXi 6.0 Intel Xeon E5 26XX v4 24 DIMMs

UCS C220 M5S (Intel Scalable Platinum 8160M)

1 RU ESXi 6.0 Intel Scalable Platinum 8160M

24 DIMMs

UCS C240 M4S (Intel Xeon E5 26XX v4)

2 RU ESXi 6.0 Intel Xeon E5 26XX v4 24 DIMMs

UCS C240 M5S (Intel Scalable Platinum 8160M)

2 RU ESXi 6.0 Intel Scalable Platinum 8160M

24 DIMMs

23

TOE Model Description Analysis

which physical platform it is installed on. All claimed TOE platforms run the same hypervisor, ESXi 6.0.

Base Processor

UCS C220 M4 Intel Xeon E5 26XX v4 There are four TOE hardware platforms. The UCS M4 series uses Intel Xeon E5 processors, while the UCS M5 series use Intel Xeon scalable (Platinum, etc.) processors. However, all processors support the same virtualization extensions.

UCS C240 M4 Intel Xeon E5 26XX v4

UCS C220 M5 Intel Xeon Scalable (Platinum 8160M)

UCS C240 M5 Intel Xeon Scalable (Platinum 8160M)

Table 3 TOE Comparison

2.3 Hardware Interface Analysis

The following section examines how the TOE interfaces with each hardware platform in several key areas. These areas include storage interface, network interface, and processor interface.

2.4 Storage Interface Analysis

The following section looks at the hardware storage supported on each platform,

Platform Storage

UCS C220 M4 Up to 8 Cisco branded small form-factor (SFF) disk drives or 4 Cisco branded large form-factor (LFF) drives manufactured and provided by Toshiba

UCS C240 M4 Up to 24 Cisco branded small form-factor (SFF) disk drives or 12 Cisco branded large form-factor (LFF) drives manufactured and provided by Toshiba

UCS C220 M5 Up to 10 small form-factor (SFF) disk drives or 4 large form-factor (LFF) drives manufactured and provided by Toshiba

UCS C240 M5 Up to 26 Cisco branded small form-factor (SFF) disk drives manufactured and provided by Toshiba

Table 2 Storage Difference Highlight Each of the UCS appliances support the exact same storage hardware. Each drive is either a small or large form-factor HDD. There is only one manufacturer (Toshiba) and the disks are rebranded as Cisco disks. The drivers used to interface with the disks are identical. The only difference between platforms is the maximum number of drives supported. The software interfaces with the hard drives via the same driver set across platforms. Result: All platforms are equivalent

2.5 Network Interface Analysis

The following section looks at the hardware network interfaces supported on each platform,

Platform Network Interface Hardware Interface

UCS C220 M4 IC-COMM,ETHERNET,SWITCH,1000Mb/s,3.3V,0C TO 70C,125C,TQFP128,9%,88E6176,Pb-FREE manufactured and provided by Marvell



24


Table 3 Network Interface Difference Highlight The software interfaces with the external interface via an internal ethernet switch. The Ethernet switch is not different per platform and there is only one manufacturer (Marvell). The exact part number is used in each hardware platform and each platform had only a single switch. The drivers the software uses to interface with the hardware is identical across platforms. Result: All platforms are equivalent

2.6 Serial Interface Analysis

Each platform model (UCS 220 M4, UCS240 M4, UCS 220 M5, UCS 240 M5) includes a serial interface. This component is identical and directly manufactured by Cisco. The exact component is used in each hardware platform. The drivers the software uses to interface with the hardware is identical across platforms. Result: All platforms are equivalent

2.7 USB Interface Analysis

No USB interfaces are able to be used in conjunction with the TOE. The USB ports associated with the platforms were never used during testing. Result: Not applicable to the TOE configuration and all platforms are equivalent

2.8 Processor Interface Analysis

The following table provides a comparison of each of the categories with differences.

Platform Model Software Base Processor

UCS 220 M4 Expressway X12.5 on ESXi 6.0 Intel Xeon E5 26XX v4

UCS 240 M4 Expressway X12.5 on ESXi 6.0 Intel Xeon E5 26XX v4

UCS 220 M5 Expressway X12.5 on ESXi 6.0 Intel Xeon Scalable Platinum 8160M

UCS 240 M5 Expressway X12.5 on ESXi 6.0 Intel Xeon Scalable Platinum 8160M

Table 4 TOE Difference Highlight Across appliance platforms, there are several processors included, as follows,

Processor Item Intel Xeon E5 26XX v4 Intel Xeon Scalable Platinum 8160M

Product UCS 220 M4, UCS 240 M4 UCS 220 M5, UCS 240 M5

Micro-architecture Broadwell Skylake

Instruction Set Extensions (ISEs) AVX SSE4.2, AVX, AVX2, AVX-512

AES New Instructions Yes Yes

Secure Key Yes Yes

Execute Disable Bit Yes Yes

Table 5 Processor Difference Highlight Different microarchitectures are used between the Intel Celerons and other CPUs, so the processors are not immediately equivalent. However, a deeper inspection of the security-relevant processor characteristics shows that the only differences are specific to differing ISEs with the aggregate consisting

25

of SSE4.2, AVX, AVX2, and AVX-512. All other security related feature support, including, AES-NI, Secure Key, and Execute Disable Bit are identical between platforms. The Intel Xeon E5 26XX v4 as tested supports Intel® AVX ISA extension. The Intel Scalable processors support Intel® SSE4.2, Intel® AVX, Intel® AVX2, Intel® AVX-512 ISA extensions. While the ISA extensions support differs between the two families of CPU, Intel defines instruction set extensions as “additional instructions which can increase performance when the same operations are performed on multiple data objects”. Instructions sets are additional instructions only used to enhance performance when the same operations are performed on multiple data objects. This does not interfere with any of the core security functionality of the devices being tested. Based on this definition the CCTL has not concluded that these would interfere with SFR functionality in any meaningful way. In both the M4 and M5, the supported virtual network driver includes “VMXNET3” drivers. At the physical level, the M4 and M5 include Intel-based adapters only and use the “igb” and “ixgb” driver at the hypervisor level, the only difference being throughput (e.g. Gigabit vs 10 Gigabit). Therefore, it can be concluded that the network data processing follows identical paths from the physical layer all the way up to the virtual ND layer. While the CCTL has found differences between the ISA/EXT and drivers, the following analysis of each SFR with respect to each difference identifies the potential areas of impact and the CCTL’s assessment of each. However, further consideration is needed due to the TOE including a virtual ND. The evaluator analyzed the each of the processors and found that all of the TOE processors support the following technologies:

Intel® Virtualization Technology (VT-x)

Intel® Virtualization Technology for Directed I/O (VT-d)

Intel® VT-x with Extended Page Tables (EPT)

Intel® TSX-NI

Intel® AES New Instructions

SFR Impact

FAU_GEN.1 FAU_GEN.2 FAU_STG_EXT.1

No impact (code is enforced in Expressway X12.5 with no SFR interference from host CPU or networking differences).

FCS_CKM.1 No impact. DRBG and keygen is implemented within FOM library inside Expressway X12.5. Entropy sources are identical. CAVP certificates have been provided for both processor families.

FCS_CKM.2 No impact. Functionality is implemented within FOM library inside Expressway X12.5 with no interference from host platform. CAVP certificates have been provided for both processor families.

FCS_CKM.4 No impact (code is enforced in Expressway X12.5 with no SFR interference from host CPU or networking differences).

FCS_COP.1/DataEncryption CAVP certificates have been provided for both processor families. AES-NI is supported by both CPUs.

26

FCS_COP.1/SigGen FCS_COP.1/Hash FCS_COP.1/KeyedHash

No impact. Functionality is implemented within FOM library inside Expressway X12.5 with no interference from host platform. CAVP certificates have been provided for both processor families.

FCS_RBG_EXT.1 No impact. DRBG and keygen is implemented within FOM library inside Expressway X12.5. Entropy sources are identical. CAVP certificates have been provided for both processor families.

FCS_SSHS_EXT.1 See FCS* analysis. SSH is implemented at Layer 4 and is fully enforced by Expressway X12.5. Layer 1 and 2 functionality at NIC level does not interfere with SSH functionality.

FCS_SSHC_EXT.1 See FCS* analysis. SSH is implemented at Layer 4 and is fully enforced by Expressway X12.5. Layer 1 and 2 functionality at NIC level does not interfere with SSH functionality.

FCS_TLSC_EXT.1 FCS_TLSS_EXT.1 FCS_HTTPS_EXT.1

See FCS* analysis. TLS is implemented at Layer 4 and above and is fully enforced by Expressway X12.5. Layer 1 and 2 functionality at NIC level does not interfere with TLS functionality.

FIA_AFL.1 FIA_PMG_EXT.1


FIA_X509_EXT.1 FIA_X509_EXT.2 FIA_X509_EXT.3

See FCS* analysis. X509 is fully enforced by Expressway X12.5

FMT_MOF.1 FMT_MTD.1* FMT_SMF.1 FMT_SMR.2 FPT_APW_EXT.1 FPT_SKP_EXT.1 FPT_TST_EXT.1 FPT_TUD_EXT.1 FPT_STM.1 FPT_STM_EXT.1 FTA_SSL_EXT.1 FTA_SSL.3 FTA_SSL.4 FTA_TAB.1


FTP_ITC.1* FTP_TRP.1

Trusted path/channels are implemented at Layer 3 and above and are fully enforced by Expressway X12.5. Layer 1 and 2 functionality at NIC level does not interfere with TLS functionality.

Result: All platforms are equivalent

2.9 General Platform Analysis

The TOE boundary includes the hardware and hypervisor which provide the base execution environment required by the software. The hardware platforms do not provide any of the TSF functionality. All security functionality is implemented in Platform Independent code which is line-by-line identical across hardware models. The hardware within the TOE only differs by configuration and performance.

27

There is a single source of entropy within the ESXi 6.0 platform used to seed the software DRBG implemented within Platform Independent Expressway X12.5 software. Result: All platforms are equivalent

2.10 Additional Equivalency Analysis

The following equivalency analysis provides a per category analysis of key areas of differentiation for each hardware model to determine the minimum subset to be used in testing. The areas examined will use the areas and analysis description provided in the supporting documentation for the NDcPP. Additionally, a comparison of the data presented in section 3 is provided to identify a testing subset that will exercise each of the differences in TOE models.

2.10.1 Software/OS Dependencies:

This category of differences is only applicable if the TOE is installed on an OS outside of the TOE boundary. In this case, all SFR-enforcing software is contained within the Expressway X12.5 which is within the TOE boundary. There are no specific dependencies on the OS since the Expressway does not run on different OSs. Furthermore, all TOE platforms include the same version of the ESXi hypervisor v6.0

Result: The same Expressway X12.5 is used on all TOE models.

2.10.2 Differences in Libraries Used to Provide TOE Functionality

All software binaries compiled in the TOE software are identical and have the same version numbers. There are no differences between the included libraries. Of note, the TOE uses the same FOM to provide its cryptographic functionality. This is the same across platforms.

As demonstrated in the test report, the Expressway X12.5 software enforces all TSF functionality. For cryptographic functionality, CAVP certificates have been provided for both families of CPUs that the TOE supports. The cryptographic library that provides the TOE cryptography is installed within the X12.5 software image. There are no cryptographic dependencies on the hypervisor for cryptographic support.


2.10.3 TOE Management Interface Differences

The TOE is managed via WebUI via HTTPS. These management options are available on all hardware platforms regardless of the configuration. There is no difference in the management interface for any platform.


2.10.4 TOE Functional Differences

Each hardware model within the TOE boundary provides identical functionality. There is no difference in the way the user interacts with each of the devices or the services that are available to the user in for each of these devices. Each device runs the same version of Expressway software. For X12.5 software, differences in the provided functionality is denoted by a different version of the software. If there had been differences in the functionality provided by the software, the actual release version would have been different for the platform.


28

2.11 Recommendations/Conclusions

Based on the equivalency rationale listed above, testing will be performed on the following subset:

UCS 220 M4

Note: A full suite of testing will be performed on the UCS 220 M4. Due to the equivalency as presented in the rationale in section, the other platforms will not be tested. This shall provide enough assurance that the TOE functionality executes identically regardless of the underlying platform.

29

3 Test Diagram

3.1 Test Bed #1

3.1.1 Visual Diagram

Below is a visual representation of the components included in the test bed:

3.1.2 Configuration Information

The following provides configuration information about each device on the test network.

3.1.2.1 Expressway-C (TOE)

Software Version: X12.5.3

3.1.2.2 Expressway-E (TOE)

Software Version: X12.5.3

3.1.2.3 CUCM (virtual)

Software Version: 11.5

3.1.2.4 Test VM A Syslog (virtual)

Software Version: Ubuntu 16.04

3.1.2.5 Test VM B (virtual)

Software Version: Ubuntu 16.04

3.1.2.6 Test VM C (physical)

Software Version: Windows 10

3.1.2.7 Test VM D

Software Version: Windows 10

30

3.1.2.8 Test VM E

Software Version: Kali Linux 2019.2

3.1.2.9 Test VM F


3.1.2.10 Router A (virtual)

Software Version: Cisco CSR 1000V IOS-XE 16.09.03

3.1.2.11 DNS A (virtual)


3.1.2.12 Tools

Acumen-TLSC 3.0

Acumen-TLSC 3.0

OpenSSL 1.0.2

PKIX-SSH 11.6

3.1.3 Test Time/Location

All testing was carried at the Acumen Security offices located in 2400 Research Blvd Suite #340, Rockville, MD 20850. Testing occurred from January 2019 through October 2019. The TOE was located in a physically protected, access controlled, designated test lab with no unattended entry/exit ways. At the start of each day, the test bed was verified to ensure that it was not compromised. All evaluation documentation was kept with the evaluator at all times.

31

4 Detailed Test Cases

4.1 Test Cases (Auditing)

4.1.1 FAU_GEN.1 TSS 1

Objective: For the administrative task of generating/import of, changing, or deleting of cryptographic keys as defined in FAU_GEN.1.1c, the TSS should identify what information is logged to identify the relevant key. Evaluator Findings: The evaluator examined the section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the Security Target to determine the verdict of this assurance activity. The evaluator confirmed that within this section it identified the following information was logged in order to identify the relevant key in relation to import/generation, changing, or deletion of cryptographic keys:

admin login/logout: ----------------------- 2016-06-16T14:57:42.915+00:00 dchokshi-exp-c taa-chkpasswd: Event="pam" Module="pam_unix(taa-chkpasswd-webadmin:session)" Level="INFO" Detail="session opened for user admin by (uid=2)" UTCTime="2016-06-16 14:57:42" 2016-06-16T14:57:42.917+00:00 dchokshi-exp-c httpd[12201]: web: User="admin" Event="Admin Session Start" Src-ip="10.122.81.100" Src-port="55924" UTCTime="2016-06-16 14:57:42" 2016-06-16T14:58:31.731+00:00 dchokshi-exp-c httpd[23604]: web: User="admin" Event="Admin Session Finish" Src-ip="10.122.81.100" Src-port="56108" UTCTime="2016-06-16 14:58:31" admin timeout: ------------------- 2016-06-16T14:59:23.912+00:00 dchokshi-exp-c taa-chkpasswd: Event="pam" Module="pam_unix(taa-chkpasswd-webadmin:session)" Level="INFO" Detail="session opened for user admin by (uid=2)" UTCTime="2016-06-16 14:59:23" 2016-06-16T14:59:23.914+00:00 dchokshi-exp-c httpd[13502]: web: User="admin" Event="Admin Session Start" Src-ip="10.122.81.100" Src-port="56334" UTCTime="2016-06-16 14:59:23" 2016-06-16T15:29:24.810+00:00 dchokshi-exp-c httpd[15188]: web: User="" Event="Admin Session Finish" Src-ip="10.122.81.100" Src-port="35362" Detail="expired" UTCTime="2016-06-16 15:29:24"

Each of the events is specified in the syslog internal to the TOE in enough detail to identify the user for which the event is associated (e.g. user identity, MAC address, IP address), when the event occurred, where the event occurred, the outcome of the event, and the type of event that occurred. Additionally, for cryptographic key related events, the details of the certificate associated with the private key are included within the audit record to identify the key operated on.

Based on these findings, this assurance activity is considered satisfied.

Verdict: Pass

32

4.1.2 FAU_GEN.1 Guidance 1

Objective: The evaluator shall check the guidance documentation and ensure that it provides an example of each auditable event required by FAU_GEN.1 (i.e. at least one instance of each auditable event – comprising the mandatory, optional and selection-based SFR sections as applicable – shall be provided from the actual audit record). TD0410 has been applied Evaluator Findings: The evaluator examined the guidance document to determine if it lists all auditable events. Section 3.2.5.1 Audit Trail Log Entries was used to determine the verdict of this assurance activity. The evaluator first found an identification of each in section 3.2.5.1 Table 9, Auditable Events. The evaluator then compared this list of events to the auditable events listed in the NDcPP 2.0e. Each event listed in NDcPP 2.0e is also listed in the AGD. Next, the evaluator reexamined AGD and found in section 3.2.5.1 Table 9 Auditable Events listing and description of each of the fields in generated audit records that contain the information required in FAU_GEN.1.2.


Verdict: Pass

4.1.3 FAU_GEN.1 Guidance 2

Objective: The evaluator shall also make a determination of the administrative actions that are relevant in the context of the cPP. The evaluator shall examine the guidance documentation and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the cPP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to the cPP. The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it. Evaluator Findings: The evaluator examined the guidance documentation to determine which administrative commands are relevant in the context of the cPP. The ST and AGD were used to determine the verdict of this assurance activity. The evaluator first examined the entirety of AGD to determine what administrative commands and GUI configurations choose as appropriate are associated with each administrative activity. The evaluator found the following are applicable,

Administrative Activity

Method (Command/GUI Configuration) Section

Startup The Restart options page (Maintenance > Restart options) allows you to restart, reboot or shut down the Expressway without having physical access to the hardware.

‘Cisco Expressway Administrator Guide, X12.5’ Section: ‘Restarting, Rebooting and Shutting Down’

Shutdown The Restart options page (Maintenance > Restart options) allows you to restart, reboot or shut down the Expressway without having physical access to the hardware.


33



Login and Logout

GUI (page 13) System configuration is normally carried out through the web interface. To use the web interface: 1. Open a browser window and in the address bar type either: — the IP address of the system — the FQDN of the system 2. Enter a valid administrator Username and Password and click Login (see the user accounts section for details on setting up administrator accounts). You are presented with the Overview page. Note that when logging in using the Expressway web interface, you may receive a warning message regarding the Expressway's security certificate. You can ignore this until you are ready to secure the system CLI (page 14) Using the Command Line Interface (CLI) The Expressway can be configured through a web interface or via a command line interface (CLI). The CLI is available by default over SSH and through the serial port (on the appliance). These settings are controlled on the System administration page. To use the CLI: 1.Start an SSH session. 2.Enter the IP address or FQDN of the Expressway. 3.Log in with your administrator username and password. See if you prefer to use your private key to authenticate. 4.You can now start using the CLI by typing the appropriate commands.

‘Cisco Expressway Administrator Guide, X12.5’ Section: ‘Using the Web Interface’ and ‘Using the Command Line Interface(CLI)’

Generating Keys (certificates)

For upload a server certificate: The section titled ‘Loading Certificates and Keys Onto Expressway’

‘Cisco Expressway Certificate Creation and Use Deployment Guide X12.5’

34



Go to Maintenance > Security certificates > Server certificate

The section titled ‘Loading a Server Certificate and Private Key Onto Expressway’

Use the Browse button in the Upload new certificate section to select and upload the server certificate PEM file.

If you used an external system to generate the Certificate Signing Request (CSR) you must also upload the server private key PEM file that was used to encrypt the server certificate. (The private key file will have been automatically generated and stored earlier if the Expressway was used to produce the CSR for this server certificate.)

o The server private key PEM file must

not be password protected.

o You cannot upload a server private key if a certificate signing request is in progress.

Click Upload server certificate data .

Section: ‘Loading Certificates and Keys Onto Expressway’ and ‘Loading a Server Certificate and Private Key Onto Expressway’

Deleting Keys (certificates)

To delete one or more CA certificates, tick the box(es) next to the relevant CA certificate(s) and click Delete.

‘Cisco Expressway Certificate Creation and Use Deployment X12.5’ Section: ‘Managing the Trusted CA Certificate List’

Resetting Passwords

Resetting Forgotten Passwords: You can reset any account password by logging in to the Expressway as the default admin account or as any other administrator account


Display system information

[4] Overview and Status Information->System Information. Log on from the Cisco Unified Operating System Administration window, the System information page (Status -> System -> Information) and review the fields in the Systems information page.

AGD section: 1.7 ‘Secure Acceptance of the TOE’ (step 7)

Creating Users You can configure the complexity requirements for local administrator passwords on the Password security page (Users > Password security). All passwords and usernames are case sensitive.

‘Cisco Expressway Administrator Guide, X12.5’ Section: ‘Configuring Administrator Accounts’

Configuring CAs

The Trusted CA certificate page (Maintenance > Security certificates > Trusted CA certificate) allows you to manage the list of certificates for the Certificate Authorities (Cas) trusted by this Expressway. When a TLS

‘Manage Certificates, Cisco Expressway X12.5’ Section: ‘Managing the Trusted CA Certificate List’

35



connection to Expressway mandates certificate verification, the certificate presented to the Expressway must be signed by a trusted CA in this list an there must be a full chain of trust (intermediate Cas) to the root CA.

To upload a new file containing one or more CA certificates, Browse to the required PEM file and click Append CA certificate. This will append any new certificates to the existing list of CA certificates. IF you are replacing existing certificates for a particular issuer and subject, you have to manually delete the previous certificates.

Configuring Revocation Servers

Refer to [4] Certificate Revocation Checking Modes for SIP TLS connections. The Certificate revocation checking mode is not enabled by default and must be enabled in the evaluated configuration. The settings include, Use OCSP, Use CRLs, Allow CRL downloads from CDPs and Fallback behavior. In the evaluated configuration, OCSP and/or CRLs are allowed

AGD section: 2.2.3

Generating CSRs

Navigate to Maintenance > Security certificate > Server certificate and click Generate CSR. This will take you to the Generate CSR page. Next, enter the required properties for the certificate and then click Generate CSR

AGD section: 2.2.3

Performing Software Updates

To verify the software version and to register the license, from a PC in your network that has been installed with one of the supported browsers, browse into a server that is running Cisco Expressway and Cisco VCS Administration and log in with administrative privileges. Follow the instructions in [4] Overview and Status Information->System Information. Log on from the Cisco Unified Operating System Administration window, the System information page (Status -> System -> Information) and review the fields in the Systems information page. If installing in a virtual environment, follow the instructions in [3] Installation Process->Deploying OVA to Standalone ESXi Host->Ordering and Entering Release and Option Keys

AGD section: 2 ‘Secure Acceptance of the TOE’ (step 7)

Setting the Time

To set the time on the TOE, navigate to the System > Time page. Refer to Network and System Settings > Network Services > Configure Time Settings [4]. This page is used to specify the local time.

AGD section: 3.2

Configuring NTP

To configure the TOE with one or more NTP servers, you will need to enter the address of up to five servers in one of the following formats depending on the systems DNS settings by checking the DNS page. Navigate to System > DNS page. Refer to Network and System Settings > Network Services > Configure the NTP Servers [4]. On this page, you will also configure the authentication

AGD section: 3.3

36



method used by the TOE when connecting to the NTP server.

Configuring Admin Timeout

Session time out limits. The number of minutes that an administration session (serial port, HTTPS or SSH) may be inactive before the session is timed out. Default is 30 minutes. Refer to Network and System Settings > Network Services >Administration Access Settings [4]. It is recommended to not leave the Cisco Expressway and Cisco VCS Web Interface unattended and that all active sessions be logged out and closed when not being used.

AGD section: 2.2.4

Configuring the Audit Server

Define the remote syslog server(s). To configure the remote syslog server, navigate to the Maintenance-> Logging GUI page, refer to Maintenance-> Configuring Logging [4]

AGD section: 2.2.5

Configuring Access Banner

To set the welcome message title and message, navigate to the System > Login page >Login page configuration page. Refer to Network and System Settings > Network Services > Configure the Login Page [4].

AGD section: 3.1

Setting Password Length

Password security is set using the User > Password security page, [4] User Accounts > Users > Configuring Password security

AGD section: 3.2.3

Configuring TLS

To secure the connection to the remote syslog server, navigate to the Maintenance-> Logging GUI page [4] [5] and click Options button for each server, next specify the Transport protocol and Port you want to use. The default port is UDP over port 514, you will need to select TLS (suggested port is 6514) and by doing so, you will see the option to enable CRL checking for the syslog server. Click Save.

AGD section: 2.2.1

Next, the evaluator examined each of test cases and for those test cases which exercised the above referenced functionality. The audit record associated with the configuration was captured. The following table reflects, identifies the test cases in which those configurations can be found and identifies the specific method for invoking the functionality that generated the audit record.


Method (Command/GUI Configuration) Test Case(s)

Startup The Restart options page (Maintenance > Restart options) allows you to restart, reboot or shut down the Expressway without having physical access to the hardware.

FPT_TST_EXT.1.1_T1

Shutdown The Restart options page (Maintenance > Restart options) allows you to restart, reboot or shut down the Expressway without having physical access to the hardware.

FPT_TST_EXT.1.1_T1

Login GUI System configuration is normally carried out through the web interface. To use the web interface: 1.Open a browser window and in the address bar type either:

FIA_AFL.1 FTA_SSL.4 Test #2

37



— the IP address of the system — the FQDN of the system 2.Enter a valid administrator Username and Password and click Login (see the user accounts section for details on setting up administrator accounts). You are presented with the Overview page. Note that when logging in using the Expressway web interface, you may receive a warning message regarding the Expressway's security certificate. You can ignore this until you are ready to secure the system CLI Using the Command Line Interface (CLI) The Expressway can be configured through a web interface or via a command line interface (CLI). The CLI is available by default over SSH and through the serial port (on the appliance). These settings are controlled on the System administration page. To use the CLI: 1.Start an SSH session. 2.Enter the IP address or FQDN of the Expressway. 3.Log in with your administrator username and password. See if you prefer to use your private key to authenticate. 4.You can now start using the CLI by typing the appropriate commands.

Generating Keys (certificates)

To upload a server certificate:

Go to Maintenance > Security certificates > Server certificate

Use the Browse button in the Upload new certificate section to select and upload the server certificate PEM file.

If you used an external system to generate the Certificate Signing Request (CSR) you must also upload the server private key PEM file that was used to encrypt the server certificate. (The private key file will have been automatically generated and stored earlier if the Expressway was used to produce the CSR for this server certificate.)

o The server private key PEM file must not be

password protected.

FIA_X509_EXT.1.1/Rev

38



o You cannot upload a server private key if a certificate

signing request is in progress.

Click Upload server certificate data .

Deleting Keys (certificates)

To delete one or more CA certificates, tick the box(es) next to the relevant CA certificate(s) and click Delete.

FIA_X509_EXT.1.1/Rev

Display system information

Overview and Status Information->System Information. Log on from the Cisco Unified Operating System Administration window, the System information page (Status -> System -> Information) and review the fields in the Systems information page.

FPT_TUD_EXT.1 Test #1

Creating Users Username name FIA_PMG_EXT.1 Test 1

Configuring CAs

A series of CLI commands are provided for CAs configuration FIA_X509_EXT.1.1/Rev

Configuring Revocation Servers

A series of CLI commands are provided for CAs configuration FIA_X509_EXT.1.1/Rev

Generating CSRs

A series of CLI commands are provided for CAs configuration FIA_X509_EXT.3.1

Performing Software Updates

To verify the software version and to register the license, from a PC in your network that has been installed with one of the supported browsers, browse into a server that is running Cisco Expressway and Cisco VCS Administration and log in with administrative privileges. Follow the instructions in [4] Overview and Status Information->System Information. Log on from the Cisco Unified Operating System Administration window, the System information page (Status -> System -> Information) and review the fields in the Systems information page. If installing in a virtual environment, follow the instructions in [3] Installation Process->Deploying OVA to Standalone ESXi Host->Ordering and Entering Release and Option Keys

FPT_TUD_EXT.1 Test #1

Setting the Time

The Time page (System > Time) is used to configure the Expressway's NTP servers and to specify the local time zone. An NTP server is a remote server with which the Expressway synchronizes in order to ensure its time is accurate. The NTP server provides the Expressway with UTC time. Accurate time is necessary for correct system operation.

FPT_STM_EXT.1 Test #1

Configuring NTP

The Time page (System > Time) is used to configure the Expressway's NTP servers and to specify the local time zone. An NTP server is a remote server with which the Expressway synchronizes in order to ensure its time is accurate. The NTP server provides the Expressway with UTC time. Accurate time is necessary for correct system operation.

FPT_STM_EXT.1 Test #2

Configuring Admin Timeout

Session time out limits. The number of minutes that an administration session (serial port, HTTPS or SSH) may be inactive before the session is timed out. Default is 30 minutes. Refer to Network and System Settings > Network Services >Administration Access Settings [4]. It is recommended to not leave the Cisco Expressway and Cisco VCS Web

FTA_SSL_EXT.1.1_T1

39



Interface unattended and that all active sessions be logged out and closed when not being used.

Configuring the Audit Server

Define the remote syslog server(s). To configure the remote syslog server, navigate to the Maintenance-> Logging GUI page, refer to Maintenance-> Configuring Logging [4]

FAU_GEN.1 Test 1

Configuring Access Banner

System > Login page >Login page configuration page. Refer to Network and System Settings > Network Services > Configure the Login Page

FTA_TAB.1_T1

Setting Password Length

The Password security page (Users > Password security) controls whether or not local administrator account passwords must meet a minimum level of complexity before they are accepted. If Enforce strict passwords is set to On, all subsequently configured local administrator account passwords must conform to the following rules for what constitutes a strict password. If Enforce strict passwords is set to Off, no extra checks are made on local administrator account passwords.

FIA_PMG_EXT.1_T1

Resetting the TOE

The Restart options page (Maintenance > Restart options) allows you to restart, reboot or shut down the Expressway without having physical access to the hardware.

FPT_TST_EXT.1.1_T1

Configuring SSH

A series of CLI commands are provided for SSH configuration FCS_SSHS_EXT.1.4 FCS_SSHC_EXT.1.4

Configuring TLS

A series of CLI commands are provided for TLS configuration FCS_TLSC_EXT.2.1

The above analysis illustrates that each of the relevant configuration methods is appropriately audited by the TOE. Based on these findings, this assurance activity is considered satisfied.


Verdict: Pass

4.1.4 FAU_GEN.1 Test 1

Item Data/Description

Test ID FAU_GEN.1_T1

Objective The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the table of audit events and administrative actions listed above. This should include all instances of an event: for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries.

Test Flow Trigger each auditable event on the TOE

Verify that each audit record is generated and contains the required information

Pass/Fail Explanation

The TOE generates audit records.

Result Pass

40

4.1.5 FAU_GEN.2

None –The evaluation of this SFR is tested in conjunction with the testing of FAU_GEN.1.

4.1.6 FAU_STG_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. Evaluator Findings: The evaluator examined the TSS to ensure that it describes the means by which audit data is transmitted to an external audit server, and how the trusted channel is provided. The TSS entry for FAU_STG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS described that the TOE sends audit records to an external syslog server using a trusted channel provided by TLS. Once the configuration settings of the syslog server and the auditing level are established, audit records are automatically sent as they are generated. The evaluator found that the TSS explicit states: “For a secure connection to the remote syslog server(s), TLS is used. Once the configuration settings to the remote syslog server(s) and the level of auditing is configured, as the audit records are generated they are automatically sent to the remote syslog server(s).” Based on these findings, this assurance activity is considered satisfied. Verdict: Pass 4.1.7 FAU_STG_EXT.1 TSS 2

Objective: The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. Evaluator Findings: The evaluator examined the TSS to ensure that it describes the means by which audit data is transmitted to an external audit server, and how the trusted channel is provided. The TSS entry for FAU_STG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS states that the “TOE event log is a 2GB rotating local log file”. The evaluator next, found that, when the space is nearing exhaustion, the oldest entries will be overwritten. The FAU_GEN.1 entry in the TSS states “The log file is a rotating local log file that overwrites logs as the allocated space fills and it is not available for administrators to edit or tamper with. The TSS entry for FAU_STG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST states that here is no interface in which the Administrator can access the records as such the records are protected against unauthorized access.


Verdict: Pass 4.1.8 FAU_STG_EXT.1 TSS 3

Objective: The evaluator shall examine the TSS to ensure that it details the behavior of the TOE when the storage space for audit data is full. When the option ‘overwrite previous audit record’ is selected this description should include an outline of the rule for overwriting audit data. If ‘other actions’ are chosen

41

such as sending the new audit data to an external IT entity, then the related behavior of the TOE shall also be detailed in the TSS. Evaluator Findings: The evaluator examined the TSS to ensure that it details the behavior of the TOE when the storage space for audit data is full. The FAU_STG_EXT.1 SFR found in section 5.2.1.3 Protected Audit Event Storage of the ST and the TSS entry for FAU_STG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST were used to determine the verdict of this assurance activity. The evaluator found that “[overwrite previous audit records according to the following rule: [when allotted space has reached its threshold]]” was selected in the SFR. Next, the evaluator confirmed that the TSS provides a description of how the TOE implements this functionality. The TSS states “The TOE event log is a 2GB rotating local log file. When the space is nearing exhaustion, the oldest entries will be overwritten.”


Verdict: Pass 4.1.9 FAU_STG_EXT.1 TSS 4

Objective: The evaluator shall examine the TSS to ensure that it details whether the transmission of audit information to an external IT entity can be done in real-time or periodically. In case the TOE does not perform transmission in real-time the evaluator needs to verify that the TSS provides details about what event stimulates the transmission to be made as well as the possible as well as acceptable frequency for the transfer of audit data. Evaluator Findings: The evaluator examined the TSS to ensure that it details whether the transmission of audit information to an external IT entity can be done in real-time or periodically. The TSS entry for FAU_STG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The TSS states “Once the configuration settings to the remote syslog server(s) and the level of auditing is configured, as the audit records are generated they are automatically sent to the remote syslog server(s) in real time.” The evaluator found that the TOE transmitted audit information to an authorized external entity in real time.


Verdict: Pass 4.1.10 FAU_STG_EXT.1 Guidance 1

Objective: The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. Evaluator Findings: The evaluator examined the guidance documentation to determine if it describes how to establish a trusted channel to an audit server. Section 2.2.5, “Logging Configuration” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD states that the TOE securely sends traffic to an external audit server via TLS. Next, the evaluator found that AGD provides instructions for configuring the secure connection between the TOE and the remote audit server via GUI (section 2.2.5).

42


Verdict: Pass 4.1.11 FAU_STG_EXT.1 Guidance 2

Objective: The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the audit server. Evaluator Findings: The evaluator examined the guidance documentation to determine if the relationship between local and external audit data. Section 2.2.5.2, “Audit Trail Capacities” in the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD describes the relationship between local and external audit data, as follows, “The TOE event log is a 2GB rotating local log file. When the space is nearing exhaustion, the oldest entries will be overwritten”. In addition, section 2.2.5.1 of the AGD states the following: For a secure connection to the remote syslog server(s), TLS is used. Once the configuration settings to the remote syslog server(s) and the level of auditing is configured, as the audit records are generated they are automatically sent to the remote syslog server(s) in real time.


Verdict: Pass 4.1.12 FAU_STG_EXT.1. Guidance 3

Objective: The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behavior of the TOE for each possible configuration. The description of possible configuration options and resulting behavior shall correspond to those described in the TSS. Evaluator Findings: The evaluator examined the guidance documentation to determine if it describes all possible configuration options for FAU_STG_EXT.1.3 and the TOE behavior for each possible configuration. The TSS entry for FAU_STG_EXT.1 in section 6.1 of ST and the section 2.2.5.2 titled “Audit Trail Capacities” the of AGD were used to determine the verdict of this assurance activity. The evaluator found that the AGD describes the following configuration options for handling exhausted local audit storage, “The TOE event log is a 2GB rotating local log file. When the space is nearing exhaustion, the oldest entries will be overwritten “Next, the evaluator compared the exhausted local audit handling description found in AGD to the description provided by the TSS of the ST. The descriptions of the behavior found in AGD and ST are consistent.


Verdict: Pass 4.1.13 FAU_STG_EXT.1 Test 1


Test ID FAU_STG_EXT.1_T1

43

Objective Test 1: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing. The evaluator shall verify that the TOE is capable of transferring audit data to an external audit server automatically without administrator intervention.

Test Flow

Confirm secure connection with the audit server.

Send audit data to the audit server from the TOE.

Confirm that audit logs were sent to the syslog server.

Examine traffic to ensure it is not plaintext.


The TOE is capable of transferring encrypted audit data to an external audit server.

Result Pass

4.1.14 FAU_STG_EXT.1 Test 2



Objective Test 2: The evaluator shall perform operations that generate audit data and verify that this data is stored locally. The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behaviour defined in FAU_STG_EXT.1.3. Depending on the configuration this means that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and then verifies that: 1) The audit data remains unchanged with every new auditable event that should be tracked but that the audit data is recorded again after the local storage for audit data is cleared (for the option ‘drop new audit data’ in FAU_STG_EXT.1.3). 2) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option ‘overwrite previous audit records’ in FAU_STG_EXT.1.3) 3) The TOE behaves as specified (for the option ‘other action’ in FAU_STG_EXT.1.3).

Test Flow

Show current logging space used

Fill the audit log

Show current logging space used and verify the behavior


The TOE overwrites the oldest log once the local audit space is filled.

Result Pass

4.1.15 FAU_STG_EXT.1 Test 4



Objective For distributed TOEs, Test 1 defined above should be applicable to all TOE components that forward audit data to an external audit server. For the local storage according to

44

FAU_STG_EXT.1.2 and FAU_STG_EXT.1.3 the Test 2 specified above shall be applied to all TOE components that store audit data locally. For all TOE components that store audit data locally and comply with FAU_STG_EXT.2/LocSpace Test 3 specified above shall be applied. The evaluator shall verify that the transfer of audit data to an external audit server is implemented.


Each of the other tests performed for FAU_STG_EXT.1 were performed for both components of the TOE meeting the required. The TOE does not conform to FAU_STG_EXT.2/LocSpace therefore Test 3 is not applicable.

Result Pass

4.2 Test Cases (Communication)

4.2.1 FCO_CPC_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to confirm that it: a) Describes the method by which a Security Administrator enables and disables communications between pairs of TOE components. b) Describes the relevant details according to the type of channel in the main selection made in FCO_CPC_EXT.1.2:

First type: the TSS identifies the relevant SFR iteration that specifies the channel used

Second type: the TSS (with support from the operational guidance if selected in FTP_TRP.1.3/Join) describes details of the channel and the mechanisms that it uses (and describes how the process ensures that the key is unique to the pair of components) – see also the Evaluation Activities for FTP_TRP.1/Join.

Evaluator Findings: The evaluator examined the FCO_CPC_EXT.1 heading in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST. The TSS describes MRA mode and states “The Authorized Administrator can configure MRA mode between Cisco Expressway C and Expressway E using SSH to secure the connections. This is a persistent, dedicated SSHv2 connection between the two components. This connection protects the TSF data from disclosure and allows for detection of

modification. The MRA mode the TOE provides secure a highly secure traversal link to provide a gateway solution that extends the services and access to users inside and outside of the organization’s firewall. The evaluator also discovered that this section describes the relevant details of MRA mode according to the type of channel in the main selection made in FCO_CPC_EXT.1.2. Based on these findings, this assurance activity is considered satisfied.


Verdict: Pass 4.2.2 FCO_CPC_EXT.1 TSS 2

Objective: The evaluator shall confirm that if any aspects of the registration channel are identified as not meeting FTP_ITC.1 or FPT_ITT.1, then the ST has also selected the FTP_TRP.1/Join option in the main selection in FCO_CPC_EXT.1.2. Evaluator Findings: The evaluator examined the FCO_CPC_EXT.1 heading in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST as well as the similarly titled SFR. No

45

aspects of the registration channel are identified as not meeting FTP_ITC.1 or FPT_ITT.1, therefore FTP_TRP.1/Join is not selected in FCO_CPC_EXT.1.2. Based on this evidence, this assurance activity is considered satisfied.


Verdict: Pass 4.2.3 FCO_CPC_EXT.1 Guidance 1

Objective: The evaluator shall examine the guidance documentation to confirm that it contains instructions for enabling and disabling communications with any individual component of a distributed TOE. The evaluator shall confirm that the method of disabling is such that all other components can be prevented from communicating with the component that is being removed from the TOE (preventing the remaining components from either attempting to initiate communications to the disabled component, or from responding to communications from the disabled component). Evaluator Findings: The evaluator examined section 2.3 ‘MRA‘ in the guidance documentation. The distributed connection is between the Expressway C/VCS Controller as the SSH server and the Expressway E/VCS Expressway acts as the SSH client. The TOE will be configured to only to use x.509v3-ssh-rsa public key algorithm for secure connection between Expressway-C and Expressway-E in MRA mode. The Expressway-E listens on port 222 for SSH tunnel traffic and the only legitimate sender of SSH traffic is the Expressway-C. The AGD describes how to break the connection


Verdict: Pass

4.2.4 FCO_CPC_EXT.1 Guidance 2

Objective: The evaluator shall examine the guidance documentation to confirm that it includes recovery instructions should a connection be unintentionally broken during the registration process. Evaluator Findings: The evaluator examined section 2.3 ‘MRA’ in the guidance documentation and the Mobile Remote Access guide. While there were no specific connection recovery instructions, Appendix 1 of the Remote Access guide provides some troubleshooting steps for several connection-related issues that may arise.


Verdict: Pass

4.2.5 FCO_CPC_EXT.1 Guidance 3

Objective: If the TOE uses a registration channel for registering components to the TOE (i.e. where the ST author uses the FTP_ITC.1/FPT_ITT.1 or FTP_TRP.1/Join channel types in the main selection for FCO_CPC_EXT.1.2) then the evaluator shall examine the Preparative Procedures to confirm that they: a) describe the security characteristics of the registration channel (e.g. the protocol, keys and authentication data on which it is based) and shall highlight any aspects which do not meet the requirements for a SteadyState inter-component channel (as in FTP_ITC.1 or FPT_ITT.1)

46

b) identify any dependencies between the configuration of the registration channel and the security of the subsequent inter-component communications (e.g. where AES-256 inter-component communications depend on transmitting 256-bit keys between components and therefore rely on the registration channel being configured to use an equivalent key length) c) identify any aspects of the channel can be modified by the operational environment in order to improve the channel security and shall describe how this modification can be achieved (e.g. generating a new key pair or replacing a default public key certificate).

Evaluator Findings: The evaluator examined section 2.3 ‘MRA’ of the guidance documentation, which describes the characteristics of the registration channel as follows “When configuring SSHv2 in the evaluated configuration, the TOE will be configured to only use the following encryption algorithms aes256-cbc and aes256-ctr, the following MAC algorithms hmac-sha2-512, and to only allow for ecdh-sha2-nistp256 and ecdh-sha2-nistp384 key exchange methods. In addition, the TOE will be configuring only to use x.509v3-ssh-rsa public key algorithm. Refer to [4] [5] [12] for specific commands, operations and settings regarding SSHv2 and related algorithm support for secure connection between Expressway-C/VCS-Control and Expressway-E/VCS/Expressway in MRA mode”.

The Expressway-E listens on port 2222 for SSH tunnel traffic and the only legitimate sender of SSH traffic is the Expressway-C. This connection forms a highly secure traversal link to provide a gateway solution that extends the services and access to users inside and outside of the organization’s firewall. Next, the evaluator confirmed the x509v3-ssh-rsa key pairs are associated with the X509 certificate, not stored in plaintext and automatically stored in a specified filesystem directory.


Verdict: Pass

4.2.6 FCO_CPC_EXT.1 Test 1.1


Test ID FCO_CPC_EXT.1_T1.1

Objective Test 1.1: the evaluator shall confirm that an IT entity that is not currently a member of the distributed TOE cannot communicate with any component of the TOE until the non-member entity is enabled by a Security Administrator for each of the non-equivalent TOE components that it is required to communicate with (non-equivalent TOE components are as defined in the minimum configuration for the distributed TOE)

Test Flow

Confirm that an IT entity that is not a member of the distributed TOE cannot communicate with any other component of the TOE.

Register the IT member to the TOE and verify communication is successful.


The TOE is only able to communicate with registered IT entities.

Result Pass

4.2.7 FCO_CPC_EXT.1 Test 1.2


Test ID FCO_CPC_EXT.1_T1.2

Objective Test 1.2: the evaluator shall confirm that after enablement, an IT entity can communicate only with the components that it has been enabled for. This includes testing that the enabled communication is successful for the enabled component pair, and that communication

47

remains unsuccessful with any other component for which communication has not been explicitly enabled Some TOEs may set up the registration channel before the enablement step is carried out, but in such a case the channel must not allow communications until after the enablement step has been completed.

Test Flow

After registering the IT entity to the TOE, verify communication is successful between components.

Verify communication is unsuccessful with any other component that is not part of the TOE.


Communication is only successful between registered components of the TOE.

Result Pass

4.2.8 FCO_CPC_EXT.1.2 Test 2


Test ID FCO_CPC_EXT.1_T2

Objective Test 2: The evaluator shall separately disable each TOE component in turn and ensure that the other TOE components cannot then communicate with the disabled component, whether by attempting to initiate communications with the disabled component or by responding to communication attempts from the disabled component.

Test Flow

Disable each TOE component in turn.

Verify other TOE components cannot communicate with the disabled component.


TOE components are not able to communicate with disabled components.

Result Pass

4.2.9 FCO_CPC_EXT.1 Test 3



Objective Test 3: The evaluator shall carry out the following tests according to those that apply to the values of the main (outer) selection made in the ST for FCO_CPC_EXT.1.2. 1) If the ST uses the first type of communication channel in the selection in FCO_CPC_EXT.1.2 then the evaluator tests the channel via the Evaluation Activities for FTP_ITC.1 or FPT_ITT.1 according to the second selection – the evaluator shall ensure that the test coverage for these SFRs includes their use in the registration process. 2) If the ST uses the second type of communication channel in the selection in FCO_CPC_EXT.1.2 then the evaluator tests the channel via the Evaluation Activities for FTP_TRP.1/Join. 3) If the ST uses the ‘no channel’ selection then no test is required.

Test Flow

Configure the TOE components to communicate with one another

Initiate the connection between the components

Perform a packet capture of the traffic between components

Verify that the connection is not sent plaintext


Communications are successful using the specified protocols between each pair of authorized TOE components.

Result Pass

48




Objective Test 4: The evaluator shall perform one of the following tests, according to the TOE characteristics identified in its TSS and operational guidance: 1) If the registration channel is not subsequently used for intercomponent communication, and in all cases where the second selection in FCO_CPC_EXT.1.2 is made (i.e. using FTP_TRP.1/Join) then the evaluator shall confirm that the registration channel can no longer be used after the registration process has completed, by attempting to use the channel to communicate with each of the endpoints after registration has completed 2) If the registration channel is subsequently used for intercomponent communication then the evaluator shall confirm that any aspects identified in the operational guidance as necessary to meet the requirements for a steady-state intercomponent channel (as in FTP_ITC.1 or FPT_ITT.1) can indeed be carried out (e.g. there might be a requirement to replace the default key pair and/or public key certificate).

Test Flow Verify intercomponent channel is successful.


The TOE does allow successful intercomponent channel communication.

Result Pass




Objective Test 5: For each aspect of the security of the registration channel that operational guidance states can be modified by the operational environment in order to improve the channel security (cf. AGD_PRE.1 refinement item 2 in (cf. the requirements on Preparative Procedures in 3.6.1.2), the evaluator shall confirm, by following the procedure described in the operational guidance, that this modification can be successfully carried out.

Test Flow Verify each aspect of the registration channel can be modified to improve channel security.


The TOE allows each aspect of the registration channel to modified to improve channel security.

Result Pass

4.3 Test Cases (Cryptographic Support)

4.3.1 FCS_CKM.1 TSS 1

Objective: The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. Evaluator Findings: The evaluator examined the TSS to determine if it identifies the key sizes supported by the TOE. The TSS entry for FCS_CKM.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS states that the TOE can generate an RSA public-private key pair with a minimum RSA key-size of 2048 bits and ECDSA key pairs using NIST curves P-256 and P384. Next, the evaluator confirmed that the TSS describes how these keys are used by the TOE, the TSS specifies that “Both the RSA and ECC

49

schemes can be used to generate a Certificate Signing Request (CSR) for X509 certificates that are used for securing SSH and TLS sessions.” For key generation for asymmetric keys the TOE implements RSA with key size 2048 bits according to FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 and ECC with NIST curves P-256 and P-384 that meets FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4.


Verdict: Pass

4.3.2 FCS_CKM.1 Guidance 1

Objective: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all cryptographic protocols defined in the Security Target. Evaluator Findings: The evaluator examined section 2.3 ‘MRA’ to determine if it instructs the administrator how to configure TOE to use the selected key generation schemes and key sizes. The evaluator found instructions on configuring the TOE to use the selected key generation schemes and key sizes. The x509v3-ssh-rsa key pairs are associated with the X509 certificate, not stored in plaintext and automatically stored in a specified filesystem directory.


Verdict: Pass

4.3.3 FCS_CKM.1 Test 1

Objective: The evaluator shall verify the implementation of Key Generation by the TOE using the Key Generation test. Testing for FFC Schemes using Diffie-Hellman group 14 is done as part of testing in CKM.2.1 TD0291 has been applied Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the Key Generation test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below. The TOE does not support Diffie-Hellman group 14.


CAVP Algorithm Certificate #:

RSA C905, C924

ECDSA C905, C924

Verdict: Pass


Objective: The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme (including whether

50

the TOE acts as a sender, a recipient, or both). If Diffie-Hellman group 14 is selected from FCS_CKM.2.1, the TSS shall describe how the implementation meets RFC 3526 Section 3. Evaluator Findings: The evaluator examined the TSS to determine if the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. The TSS entries for FCS_CKM.1 and FCS_CKM.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The TOE supports key establishment including RSA-based schemes that meets RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 and Elliptic curve-based schemes that meets NIST Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”. The TOE employs RSA-based key establishment, RSAES-PKCS1-v1_5 used in cryptographic operations as specified in Section 7.2 of RFC 8017.


Verdict: Pass


Objective: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). Evaluator Findings: The evaluator examined the guidance documentation to determine if it instructs the administrator how to configure TOE to use the selected key establishment schemes. The entire AGD was used to determine the verdict of this Assurance Activity. Upon investigation, the evaluator found that no configuration is required, and the key establishment schemes are used automatically when the appropriate cryptographic function is invoked


Verdict: Pass


Objective: The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE. Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the Key Agreement Scheme test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.


CAVP Algorithm Certificate #: C905, C924 Verdict: Pass

51



Test ID FCS_CKM.2_T2

Objective a) The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_TRP.1/Admin, FTP_TRP.1/Join, FTP_ITC.1 and FPT_ITT.1 that uses RSAES-PKCS1-v1_5. b) The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using a known good implementation for each protocol selected in FTP_TRP.1/Admin, FTP_TRP.1/Join, FTP_ITC.1 and FPT_ITT.1 that uses Diffie-Hellman group 14. TD0402 has been applied

Test Flow

Perform a TLS connection to verify the correctness of RSAES-PKCS1-v1_5

Perform a SSH connection to verify the correctness of DH14


a) This testing was performed in conjunction with FCS_TLSC_EXT.2.1 Test 1 and FCS_TLSS_EXT.2.1 Test 1 to demonstrate correct operation. b) The TOE does not support Diffie-Hellman group 14, therefore this test is not applicable.

Result Pass

4.3.8 FCS_CKM.4.1 TSS 1

Objective: The evaluator examines the TSS to ensure it lists all relevant keys (describing the origin and storage location of each), all relevant key destruction situations (e.g. factory reset or device wipe function, disconnection of trusted channels, key change as part of a secure channel protocol), and the destruction method used in each case. For the purpose of this Evaluation Activity the relevant keys are those keys that are relied upon to support any of the SFRs in the Security Target. The evaluator confirms that the description of keys and storage locations is consistent with the functions carried out by the TOE (e.g. that all keys for the TOE-specific secure channels and protocols, or that support FPT_APW.EXT.1 and FPT_SKP_EXT.1, are accounted for). In particular, if a TOE claims not to store plaintext keys in non-volatile memory then the evaluator checks that this is consistent with the operation of the TOE. Evaluator Findings: The evaluator examined the entry for FCS_CKM in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 as well as the Key Zeroization table in section 7.1 titled ‘Key Zeroization’ Table 19 of the ST to ensure that it lists each type of plaintext key material and its origin and storage location. The table below describes the various keys, where they are stored, and how they are deleted/zeroized.

Name Description Storage Zeroization

NTP Keys This is the key that is used for encryption and decryption of authentication of NTP packets. NVRAM

NVRAM Zeroized by overwriting with new key

User Password

This is a variable 15+ character password that is used to authenticate local users.

NVRAM Zeroized by overwriting with new password

SSH Private Key

Once the function has completed the operations requiring the RSA key object, the module over writes the entire object (no matter its contents) using memset. This overwrites the key with all 0’s.

SDRAM Zeroized by overwriting with new key

52


SSH Session Key

The results zeroized using the positioning in free to overwrite the values with 0x00. This is called by the ssh_close function when a session is ended.

SDRAM Automatically when the SSH session is terminated. Overwritten with: 0x00

TLS server private key

This key is used for authentication, so the server can prove who it is. The private key used for TLS secure connections. .


TLS server public key

This key is used to encrypt the data that is used to compute the secret key. The public key used for TLS secure connection.


TLS pre-master secret

The pre-master secret is the client and server exchange of random numbers and a special number, the pre-master secret, This, pre-master secret is using asymmetric cryptography from which new TLS session keys can be created.

SDRAM Automatically after TLS session terminated. Overwritten with: 0x00

TLS session encryption key

The session encryption key is unique for each session and is based on the shared secrets that were negotiated at the start of the session. The Key is used to encrypt TLS session data.


TLS session integrity key

This key is used to provide the privacy and TLS data integrity protection.

SDRAM Automatically after TLS session terminated. The entire object is overwritten with zeros

The evaluator compared the list of keys to the keys which would be expected for the supported cryptographic protocols and found this list consistent with those keys.


Verdict: Pass


Objective: The evaluator shall check to ensure the TSS identifies how the TOE destroys keys stored as plaintext in non-volatile memory, and that the description includes identification and description of the interfaces that the TOE uses to destroy keys (e.g., file system APIs, key store APIs). Evaluator Findings: The evaluator checked to ensure the TSS identifies how the TOE destroys keys stored as plaintext in non-volatile memory, and that the description includes identification and description of the interfaces that the TOE uses to destroy keys (e.g., file system APIs, key store APIs). The section 7.1 titled, ‘Key Zeroization” in ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that all keys used by the TOE regardless if it is stored encrypted or in plaintext are zeroized by overwriting the value with “0x00”.


Verdict: Pass

53


Objective: Where the TSS identifies keys that are stored in a non-plaintext form, the evaluator shall check that the TSS identifies the encryption method and the key-encrypting-key used, and that the key-encrypting-key is either itself stored in an encrypted form or that it is destroyed by a method included under FCS_CKM.4. Evaluator Findings: The evaluator examined the heading FCS CKM.4 under section 6.1 of the ST, the relevant SFR and table 19 in section 7.1. The TSS does not identify which keys are stored in non-plain text form. Table 19 lists the various keys, their description and how they are zeroized.


NTP Keys This is the key that is used for encryption and decryption of authentication of NTP packets. NVRAM


User Password

This is a variable 15+ character password that is used to authenticate local users.

NVRAM Zeroized by overwriting with new password

SSH Private Key

Once the function has completed the operations requiring the RSA key object, the module over writes the entire object (no matter its contents) using memset. This overwrites the key with all 0’s.

SDRAM Zeroized by overwriting with new key

SSH Session Key

The results zeroized using the positioning in free to overwrite the values with 0x00. This is called by the ssh_close function when a session is ended.

SDRAM Automatically when the SSH session is terminated. Overwritten with: 0x00

TLS server private key

This key is used for authentication, so the server can prove who it is. The private key used for TLS secure connections. .


TLS server public key

This key is used to encrypt the data that is used to compute the secret key. The public key used for TLS secure connection.


TLS pre-master secret

The pre-master secret is the client and server exchange of random numbers and a special number, the pre-master secret, This, pre-master secret is using asymmetric cryptography from which new TLS session keys can be created.


TLS session encryption key

The session encryption key is unique for each session and is based on the shared secrets that were negotiated at the start of the session. The Key is used to encrypt TLS session data.


TLS session integrity key

This key is used to provide the privacy and TLS data integrity protection.

SDRAM Automatically after TLS session terminated. The entire object is overwritten with zeros

54


Verdict: Pass


Objective: The evaluator shall check that the TSS identifies any configurations or circumstances that may not conform to the key destruction requirement (see further discussion in the Guidance Documentation section below). Note that reference may be made to the Guidance Documentation for description of the detail of such cases where destruction may be prevented or delayed. Evaluator Findings: The TSS entry for FCS_CKM.4 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity in addition to that section 7.1 titled, ‘Key Zeroization. Upon investigation, the evaluator found that the TOE zeroizes all secrets, keys and associated values when they are no longer required. Hence no circumstances were found where destruction may be prevented or delayed.


Verdict: Pass


Objective: Where the ST specifies the use of “a value that does not contain any CSP” to overwrite keys, the evaluator examines the TSS to ensure that it describes how that pattern is obtained and used, and that this justifies the claim that the pattern does not contain any CSPs. Evaluator Findings: The evaluator examined the heading FCS CKM.4 under section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST as well as the relevant SFR under section 5.2.3.3. Section 5.2.3.3 does not specify the use of “a value that does not contain any CSP” to overwrite keys.


Verdict: Pass


Objective: The evaluator shall check that the guidance documentation identifies configurations or circumstances that may not strictly conform to the key destruction requirement, and that this description is consistent with the relevant parts of the TSS (and any other supporting information used).

Evaluator Findings: The evaluator examined the guidance documentation identifies configurations or circumstances that may not strictly conform to the key destruction requirement, and that this description is consistent with the relevant parts of the TSS The Section 2.2.3 titled “Certificates and Keys” of the AGD was used to determine the verdict of this Assurance Activity. The evaluator reviewed the TSS and AGD documentation for the TOE and found “Keys that are related to secure sessions, such as SSH and TLS, the keys are overwrite with zeros upon termination of the session.”

55

Additionally, none of the credentials, CSPs, symmetric keys, pre-shared keys, or private keys are stored in plaintext form.


Verdict: Pass


Objective: The evaluator shall check that the guidance documentation provides guidance on situations where key destruction may be delayed at the physical layer.

Evaluator Findings: The evaluator reviewed the TSS and AGD documentation for the TOE and found no situation that would prevent or delay key destruction.


Verdict: Pass

4.3.15 FCS_COP.1/DataEncryption Test 1

Objective: The evaluator shall verify the implementation of symmetric encryption supported by the TOE. Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the Encryption test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.



AES C905, C924

Verdict: Pass

4.3.16 FCS_COP.1/SigGen Test 1

Objective: The evaluator shall verify the implementation of the digital signature algorithms supported by the TOE. Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the Digital Signature test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.



RSA C905, C924

Verdict: Pass

56

4.3.17 FCS_COP.1/Hash TSS 1

Objective: The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. Evaluator Findings: The evaluator examined the TSS to determine that the association of the hash function with other TSF cryptographic features is documented in the TSS. The TSS entry for FCS_COP.1 Hash in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that per the TSS, the TOE provides SHS hashing in support of the following TSF cryptographic functions:

HTTPS

TLS

SSH

Verification of software updates

Additionally, the evaluator compared the list of cryptographic functions provided by the TSF to the functions mapped in the TSS and found them to be consistent.


Verdict: Pass

4.3.18 FCS_COP.1/Hash Guidance 1

Objective: The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. Evaluator Findings: The evaluator examined the guidance documents to determine if they describe any configuration that is required for the required hash sizes. The section 3.2.2 titled “Enabling FIPS Mode” of AGD was used to determine the verdict of this assurance activity. Upon investigation, TSS entry for FCS_COP.1 Hash in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST the evaluator found that the following hash sizes configurations are required for HTTPS and TLS.

SHA-1

SHA-256

SHA-384

SHA-512

Additionally, the evaluator compared the instructions listed in AGD to the actual usage of the TOE during testing and found that the listed configuration covers each way the hash functions can be configured for the TOE.


Verdict: Pass

4.3.19 FCS_COP.1/Hash Test 1

Objective: The evaluator shall verify the implementation of hashing supported by the TOE.

57

Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the Hashing test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.



SHS C905, C924

Verdict: Pass

4.3.20 FCS_COP.1/KeyedHash TSS 1

Objective: The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used.

Evaluator Findings: The evaluator examined the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. The TSS entry for FCS_COP.1KeyedHash in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator found the following information in the TSS for the supported HMACs:

Key length: 160-bit, 256-bit, 384-bit, 512-bit

Hash function used: SHA-1, SHA-256, SHA-384, SHA-512

Block size: 512 bits (HMAC-SHA-1, HMAC-SHA-256), 1024 bits (HMAC-SHA-384, HMAC-SHA-512)

Output MAC: 160-bit, 256-bit, 384-bit, 512-bit

Additionally, the evaluator compared the values provided in the TSS to the definition of the SFR in ST and the operation of the TOE during testing. The evaluator found that values listed to be consistent with the implementation of the algorithm.


Verdict: Pass

4.3.21 FCS_COP.1/KeyedHash Test 1

Objective: The evaluator shall verify the implementation of MACing supported by the TOE. Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the HMAC test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.


CAVP Algorithm Certificate #: HMAC-SHA C905, C924

Verdict: Pass

58

4.3.22 FCS_RBG_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that it specifies the DRBG type, identifies the entropy source(s) seeding the DRBG, and state the assumed or calculated min-entropy supplied either separately by each source or the min-entropy contained in the combined seed value. Evaluator Findings: The evaluator examined the TSS to determine that the association of the DRBG type, identifies the entropy source(s) seeding the DRBG with other TSF cryptographic features is documented in the TSS. The TSS entry for FCS_RBG_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST states “The TOE implements a NIST-approved AES-CTR Deterministic Random Bit Generator (DRBG), as specified in SP 800-90 seeded by an entropy source that accumulates entropy from a TSF-hardware based noise source. The deterministic RBG is seeded with a minimum of 256 bits of entropy, which is at least equal to the greatest security strength of the keys and hashes that it will generate.”


Verdict: Pass

4.3.23 FCS_RBG_EXT.1 Guidance 1

Objective: The evaluator shall confirm that the guidance documentation contains appropriate instructions for configuring the RNG functionality. Evaluator Findings: No configuration is required for implementation of the RNG functionality.


Verdict: Pass

4.3.24 FCS_RBG_EXT.1.1 Test 1

Objective: The evaluator shall verify the implementation of SP 800-90A DRBG supported by the TOE. Evaluator Findings: The implemented cryptographic module employed by the TOE has been subject to the DRBG test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below.


CAVP Algorithm Certificate #: DRBG C905, C924

Verdict: Pass

59

4.4 Test Cases (HTTPS)

4.4.1 FCS_HTTPS_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS and determine that enough detail is provided to explain how the implementation complies with RFC 2818. Evaluator Findings: The evaluator examined the FCS HTTPS EXT.1 heading in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST. The TOE supports HTTPS to secure the sessions for remote administration over TLS, this implementation complies with RFC 2818.


Verdict: Pass

4.4.2 FCS_HTTPS_EXT.1 Test #1


Test ID FCS_HTTPS_EXT.1_T1

Objective The evaluator shall attempt to establish each trusted path or channel that utilizes HTTPS, observe the traffic with a packet analyser, verify that the connection succeeds, and verify that the traffic is identified as TLS or HTTPS.

Test Flow

Connect to the TOE using a web browser.

Verify the connection succeeds


The TOE utilizes a secure HTTPS connection with a TLS handshake.

Result Pass

4.4.3 FCS_HTTPS_EXT.1 Test #2


Test ID FCS_HTTPS_EXT.1_T2

Objective The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a valid certificate and certification path, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the selection listed in the ST occurs.

Test Flow

Demonstrate that using a certificate without a valid certification path results in an application notification.

Load a valid certificate and certification path and demonstrate the function succeeds.

Delete one of the certificates and verify the connection is unsuccessful.


The TOE allows a connection when a successful certificate and certification path is present.

Result Pass

4.5 Test Cases (SSHC)

4.5.1 FCS_SSHC_EXT.1.2 TSS 1

Objective: The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHC_EXT.1.5 and

60

ensure that password-based authentication methods are methods have been selected in the ST then these are also described. TD0339 has been applied. Evaluator Findings: The evaluator checked to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHC_EXT.1.5 and ensure that password-based authentication methods are also allowed. The definition of FCS_SSHC_EXT.1 in ST and the TSS entry for FCS_SSHC_EXT.1 in the section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST were used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS identifies the following public key algorithms for authentication,

x509v3-ssh-rsa

Next, the evaluator examined the definition of FCS_SSHC_EXT.1 in ST and found that the identified public key algorithms to be consistent with the public key algorithms specified in the TSS. Finally, the evaluator again reviewed the TSS of ST and found that the TSS states that password-based authentication is supported for SSH users.


Verdict: Pass

4.5.2 FCS_SSHC_EXT.1.2 Test 1


Test ID FCS_SSHC_EXT.1.2_T1

Objective Test 1: If password-based authentication methods have been selected in the ST then using the guidance documentation, the evaluator shall configure the TOE to perform password-based authentication to an SSH server, and demonstrate that a user can be successfully authenticated by the TOE to an SSH server using a password as an authenticator.

Test Flow NA – The TOE only supports public-key based authentication.


NA – The TOE only supports public-key based authentication.

Result NA – The TOE only supports public-key based authentication.


Objective: The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. Evaluator Findings: The evaluator examined the TSS to determine if it describes how large packets are handled. The TSS entry for FCS_SSHC_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS of ST states, “Drops packets that are greater than 32768 bytes since that size is in violations with the IP packet size limitations”


Verdict: Pass

61




Objective The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped.

Test Flow

Send a large packet to the TOE.

Verify the TOE drops the packet.


The TOE drops a large packet.

Result Pass


Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component. Evaluator Findings: The evaluator examined the TSS to determine if optional SSH characteristics and supported encryption algorithms are specified. The definition of FCS_SSHC_EXT.1 and TSS entry for FCS_SSHC_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the encryption algorithms supported for SSH connections by the TOE. The following algorithms are identified as supported within the TSS,

AES-CBC-256, AES-256-CTR

HMAC-SHA-512

Next, the evaluator examined the definition of FCS_SSHC_EXT.1 in ST. The evaluator found that the symmetric encryption specified in the definition of the SFR are consistent with the description within the TSS of ST. Finally, the evaluator reviewed the TSS to ensure that any optional characteristics supported by the TOE are described. The evaluator found that the TSS describes the following optional characteristics for SSH connections described,

No optional SSH characteristics are supported by the TOE


Verdict: Pass

4.5.6 FCS_SSHC_EXT.1.4 Guidance 1

Objective: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements).

Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled “MRA” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the

62

evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH.

Finally, the evaluator compared the configuration described in AGD to the TSS of ST. The evaluator found that the configuration options in AGD are consistent with the description of SSH in the TSS.


Verdict: Pass




Objective The evaluator must ensure that only claimed ciphers and cryptographic primitives are used to establish a SSH connection. To verify this, the evaluator shall start session establishment for a SSH connection with a remote server (referred to as ‘remote endpoint’ below). The evaluator shall capture the traffic exchanged between the TOE and the remote endpoint during protocol negotiation (e.g. using a packet capture tool or information provided by the endpoint, respectively). The evaluator shall verify from the captured traffic that the TOE offers all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS. The evaluator shall perform one successful negotiation of an SSH session to verify that the TOE behaves as expected. It is sufficient to observe the successful negotiation of the session to satisfy the intent of the test. If the evaluator detects that not all ciphers defined in the TSS for SSH are supported by the TOE and/or the TOE supports one or more additional ciphers not defined in the TSS for SSH, the test shall be regarded as failed.

Test Flow

Connect to an SSH server using each of the claimed ciphers

Verify by examining the packet capture that the connection was successful

Repeat the above steps for any additional symmetric algorithms supported by the TOE


The TOE supports successful negotiations when using the claimed ciphersuites. Thus, this requirement has been met.

Result Pass


Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. Evaluator Findings: The evaluator examined the TSS to determine if it specifies optional characteristics and public key algorithms. The definition of FCS_SSHC_EXT.1 and TSS entry for FCS_SSHC_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the public key algorithms supported for SSH connections by the TOE. The following public key algorithms are identified as supported within the TSS,

x509v3-ssh-rsa

63

Next, the evaluator examined the definition of FCS_SSHC_EXT.1 in ST. The evaluator found that the public key algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST. Finally, the evaluator reviewed the TSS to ensure that any optional characteristics supported by the TOE are described. The evaluator found that the TSS describes the following optional characteristics for SSH connections described,



Verdict: Pass



Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled “Administrator Configuration, Credentials and Session Termination” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH from the CLI. Finally, the evaluator compared the configuration described in AGD to the TSS of ST. The evaluator found that the configuration options in AGD are consistent with the description of SSH in the TSS.


Verdict: Pass




Objective Test 1: The evaluator shall establish a SSH connection using each of the public key algorithms specified by the requirement to authenticate an SSH server to the TOE. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test objective: The purpose of this positive test is to check the authentication of the server by the client (when establishing the transport layer connection), and not for checking generation of the authentication message from the client (in the User Authentication Protocol). The evaluator is therefore intended to establish sufficient separate SSH connections (with an appropriately configured server) to cause the TOE to demonstrate use of all public key algorithms claimed in FCS_SSHC_EXT.1.5 in the ST. TD0411 has been applied.

Test Flow

Configure the TOE SSH implementation to support each type of key-based authentication method.

Establish SSH sessions with each type of supported key-based authentication.

Repeat for each type of key-based authentication supported.


The TOE allows a connection with an SSH connection with all the public key algorithm specified in the ST selection. Thus, this requirement has been met.

64

Result Pass




Objective Test 2: The evaluator shall configure an SSH server to only allow a public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the TOE to the SSH server and observe that the connection is rejected.

Test Flow

Configure an SSH server to only allow a public key algorithm that is not included in the ST selection.

Attempt to establish an SSH connection from the TOE to the SSH server.

Verify the connection is unsuccessful.


The TOE does not connect to a SSH server with a public key algorithm that is not included in the ST selection.

Result Pass


Objective: The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. Evaluator Findings: The evaluator examined the TSS to ensure that it lists all supported data integrity algorithms. The definition of FCS_SSHC_EXT.1 and TSS entry for FCS_SSHC_EXT.1 in the section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the data integrity algorithms supported for SSH connections by the TOE. The following data integrity algorithms are identified as supported within the TSS,

hmac-sha2-512

Next, the evaluator examined the definition of FCS_SSHC_EXT.1 in ST. The evaluator found that the data integrity algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass


Objective: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed).

Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled “MRA” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH.

65



Verdict: Pass




Objective Test 1: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall establish an SSH connection using each of the algorithms, except “implicit”, specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. TD0337 has been applied.

Test Flow

Connect to an SSH server using the data integrity algorithms specified in the ST.

Verify through packet captures that the connection succeeds using the specified algorithm


The TOE is be able to make SSH connections with each claimed data integrity algorithm.

Result Pass




Objective Test 2: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall configure an SSH server to only allow a MAC algorithm that is not included in the ST selection. The evaluator shall attempt to connect from the TOE to the SSH server and observe that the attempt fails. TD0337 has been applied.

Test Flow

Configure an SSH server to only allow a MAC algorithm that is not included in the ST selection.

Attempt to connect from the TOE to the SSH server.

Verify the attempt is unsuccessful.


The TOE does not connect to a SSH server when a MAC algorithm is not included in the ST selection.

Result Pass


Objective: The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. Evaluator Findings: The evaluator examined the TSS to ensure that it lists the supported key exchange algorithms. The definition of FCS_SSHC_EXT.1 and TSS entry for FCS_SSHC_EXT.1 in the section 6.1 titled TOE “Security Functional Requirement Measures” of ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the key exchange algorithms supported for SSH connections by the TOE. The following key exchange algorithms are identified as supported within the TSS,

66

ecdh-sha2-nistp256

ecdh-sha2-nistp384

Next, the evaluator examined the definition of FCS_SSHC_EXT.1 in ST. The evaluator found that the key exchange algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass


Objective: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE.

Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 3.2.4 titled “MRA” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH from the CLI. Finally, the evaluator compared the configuration described in AGD to the TSS of ST. The evaluator found that the configuration options in AGD are consistent with the description of SSH in the TSS.


Verdict: Pass




Objective The evaluator shall configure an SSH server to permit all allowed key exchange methods. The evaluator shall attempt to connect from the TOE to the SSH server using each allowed key exchange method, and observe that each attempt succeeds.

Test Flow

From the TOE, connect to an SSH server using the allowed key exchange methods specified in the ST.

Verify through packet captures that the connection succeeds using the specified key exchange.


The TOE is be able to make SSH connections with each claimed data key exchange method.

Result Pass


Objective: The evaluator shall check that the TSS specifies the following: 1. Both thresholds are checked by the TOE. 2. Rekeying is performed upon reaching the threshold that is hit first

67

Evaluator Findings: The evaluator checked that the TSS specifies the following, both thresholds are checked by the TOE and rekeying is performed upon reaching the threshold that is hit first. The FCS_SSHC_EXT.1 entry within the TSS of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS describes that the TOE is capable of rekeying for both 1 GB of data and 1 hour. Additionally, the TSS states that “The TOE can also be configured to ensure that SSH re-keying occurs prior to one hour of time or prior to more than one gigabyte of transmitted data for that session key. If the connection between Expressway C and Expressway E using SSHv2 is unintentionally broken, the connection will need to be re-established. The keys will be overwritten, new keys will need to be generated and the connection reestablished as described in the TOE guidance documentation, the Cisco Expressway Common Criteria Configuration Guide.”


Verdict: Pass


Objective: If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the SFR (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the SFR. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached.




Verdict: Pass

4.5.21 FCS_SSHCS_EXT.1.8 Test 1



Objective The evaluator needs to perform testing that rekeying is performed according to the description in the TSS. The evaluator shall test both, the time-based threshold and the traffic-based threshold. The intention of FCS_SSHC_EXT.1.8 and FCS_SSHS_EXT.1.8 SFRs is to ensure that the TOE implements both thresholds. The NIT also acknowledges that it is possible that hardware limitation may prevent reaching data transfer threshold in less than one hour. In cases where data transfer threshold could not be reached due to hardware limitations it is acceptable to omit testing of this (SSH rekeying based on data transfer threshold) threshold if both the following conditions are met:

68

a. An argument is present in the TSS section describing this hardware-based limitation and b. All hardware components that are the basis of such argument are definitively identified in the ST. For example, if specific Ethernet Controller or WiFi radio chip is the root cause of such limitation, these chips must be identified. For testing of the time-based threshold the evaluator shall use the TOE to connect to an SSH server and keep the session open until the threshold is reached. The evaluator shall verify that the SSH session has been active longer than the threshold value and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one hour of session time but the value used for testing shall not exceed one hour. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH server the TOE is connected to. For testing of the traffic-based threshold the evaluator shall use the TOE to connect to an SSH server, and shall transmit data from and to the TOE within the active SSH session until the threshold for transmitted traffic is reached. The transmitted traffic is the total traffic comprising incoming and outgoing traffic. The evaluator shall verify that more data has been transmitted within the SSH session than the threshold allows and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one gigabyte of transferred traffic but the value used for testing shall not exceed one gigabyte. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH server the TOE is connected to. If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, the evaluator needs to verify that the threshold(s) can be configured as described in the guidance documentation and the evaluator needs to test that modification of the thresholds is restricted to Security Administrators (as required by FMT_MOF.1/Functions). TD0336 has been applied

Test Flow

Establish an SSH connection to the server

Send a sufficient number of packets from the TOE to cause a rekey

Verify that a rekey was initiated by the TOE


The TOE initiates a rekey once the data or time limit has been reached.

Result Pass




Objective Test 1: The evaluator shall delete all entries in the TOE’s list of recognized SSH server host keys and, if selected, all entries in the TOE’s list of trusted certification authorities. The evaluator shall initiate a connection from the TOE to an SSH server. The evaluator shall ensure that the TOE either rejects the connection or displays the SSH server’s public key (either the key bytes themselves or a hash of the key using any allowed hash algorithm) and prompts the user to accept or deny the key before continuing the connection. TD0453 has been applied to the SFR text in the ST

Test Flow This test is not applicable as the TOE uses X509 certificates.

69


This test is not applicable as the TOE uses X509 certificates.

Result Pass




Objective The evaluator shall add an entry associating a host name with a public key into the TOE’s local database. The evaluator shall replace, on the corresponding SSH server, the server’s host key with a different host key. If 'password-based' is selected for the TOE in FCS_SSHC_EXT.1.2, the evaluator shall initiate a connection from the TOE to the SSH server using password-based authentication, shall ensure that the TOE rejects the connection, and shall ensure that the password was not transmitted to the SSH server (for example, by instrumenting the SSH server with a debugging capability to output received passwords). If 'password-based' is not selected for the TOE in FCS_SSHC_EXT.1.2, the evaluator shall initiate a connection from the TOE to the SSH server using public key-based authentication, and shall ensure that the TOE rejects the connection. TD0334 has been applied

Test Flow This test is not applicable as the TOE uses X509 certificates.


This test is not applicable as the TOE uses X509 certificates.

Result Pass

4.6 Test Cases (SSHS)

4.6.1 FCS_SSHS_EXT.1.2 TSS 1

Objective: The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHS_EXT.1.5 and ensure that password-based authentication methods are also allowed. Evaluator Findings: The evaluator checked to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSHS_EXT.1.5 and ensure that password-based authentication methods are also allowed. The definition of FCS_SSHS_EXT.1 in ST and the TSS entry for FCS_SSHS_EXT.1 in the section 6.1 titled TOE “Security Functional Requirement Measures” of ST were used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS identifies the following public key algorithms for authentication,

x509v3-ssh-rsa

Next, the evaluator examined the definition of FCS_SSHS_EXT.1 in ST and found that the identified public key algorithms to be consistent with the public key algorithms specified in the TSS. Finally, the evaluator again reviewed the TSS of ST and found that the TSS states that password-based authentication is supported for SSH users.


Verdict: Pass

70

4.6.2 FCS_SSHS_EXT.1.2 Test 1


Test ID FCS_SSHS_EXT.1.2_T1

Objective Test 1: If password-based authentication methods have been selected in the ST then using the guidance documentation, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that user authentication succeeds when the correct password is provided by the user. TD0339 has been applied




Result Not Applicable




Objective Test 2: If password-based authentication methods have been selected in the ST then the evaluator shall use an SSH client, enter an incorrect password to attempt to authenticate to the TOE, and demonstrate that the authentication fails. TD0339 has been applied






Objective: The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. Evaluator Findings: The evaluator examined the TSS to determine if it describes how large packets are handled. The TSS entry for FCS_SSHS_EXT.1 in the section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS of ST states that, “Drops packets that are greater than 32768 bytes since that size is in violations with the IP packet size limitations. This is accomplished by buffering all data for a particular SSH packet transmission until the buffer limit is reached and then dropping the packet if this limit is exceeded.”


Verdict: Pass




Objective The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped.

71

Test Flow

Send a large packet to the TOE.

Verify the packet is dropped.


The TOE drops large packets.

Result Pass


Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component. Evaluator Findings: The evaluator examined the TSS to determine if optional SSH characteristics and supported encryption algorithms are specified. The definition of FCS_SSHS_EXT.1 and TSS entry for FCS_SSHS_EXT.1 in the section titled TOE Security Functional Requirements of ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the encryption algorithms supported for SSH connections by the TOE. The following algorithms are identified as supported within the TSS,

AES-CBC-256, AES-256-CTR

Next, the evaluator examined the definition of FCS_SSHS_EXT.1 in ST. The evaluator found that the symmetric encryption specified in the definition of the SFR are consistent with the description within the TSS of ST. Finally, the evaluator reviewed the TSS to ensure that any optional characteristics supported by the TOE are described. The evaluator found that the TSS describes the following optional characteristics for SSH connections described,



Verdict: Pass

4.6.7 FCS_SSHS_EXT.1.4 Guidance 1


Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled “MRA” of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH. Finally, the evaluator compared the configuration described in AGD to the TSS of ST. The evaluator found that the configuration options in AGD are consistent with the description of SSH in the TSS.

72


Verdict: Pass




Objective The evaluator must ensure that only claimed ciphers and cryptographic primitives are used to establish a SSH connection. To verify this, the evaluator shall start session establishment for a SSH connection from a remote client (referred to as ‘remote endpoint’ below). The evaluator shall capture the traffic exchanged between the TOE and the remote endpoint during protocol negotiation (e.g. using a packet capture tool or information provided by the endpoint, respectively). The evaluator shall verify from the captured traffic that the TOE offers all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS. The evaluator shall perform one successful negotiation of an SSH session to verify that the TOE behaves as expected. It is sufficient to observe the successful negotiation of the session to satisfy the intent of the test. If the evaluator detects that not all ciphers defined in the TSS for SSH are supported by the TOE and/or the TOE supports one or more additional ciphers not defined in the TSS for SSH, the test shall be regarded as failed.

Test Flow From an SSH client, connect to the TOE using each of the claimed ciphers

Verify by examining the packet capture that the connection was successful

Repeat the above steps for any additional symmetric algorithms supported by the TOE


The TOE supports successful negotiations when using the claimed ciphersuites. Thus, this requirement has been met.

Result Pass


Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. Evaluator Findings: The evaluator examined the TSS to determine if it specifies optional characteristics and public key algorithms. The definition of FCS_SSHS_EXT.1 and TSS entry for FCS_SSHS_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the public key algorithms supported for SSH connections by the TOE. The following public key algorithms are identified as supported within the TSS,

x509v3-ssh-rsa

Next, the evaluator examined the definition of FCS_SSHS_EXT.1 in ST. The evaluator found that the public key algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST. Finally, the evaluator reviewed the TSS to ensure that any optional characteristics supported by the TOE are described. The evaluator found that the TSS describes the following optional characteristics for SSH connections described,

73


Based on these findings, this assurance activity is considered satisfied. Verdict: Pass






Verdict: Pass




Objective Test 1: The evaluator shall establish a SSH connection using each of the public key algorithms specified by the requirement to authenticate the TOE to an SSH client. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

Test Flow

Configure the TOE SSH implementation to support each type of key-based authentication method.

Establish SSH sessions with each type of supported key-based authentication.

Repeat for each type of key-based authentication supported.


The TOE allows a SSH client to connect with all the public key algorithm specified in the ST selection. Thus, this requirement has been met.

Result Pass




Objective Test 2: The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a new key pair for that algorithm without configuring the TOE to recognize the public key for authentication. The evaluator shall use an SSH client to attempt to connect to the TOE with the new key pair and demonstrate that authentication fails. The purpose of this negative test is to verify that the server rejects authentication attempts of clients that present a public key that does not match public key(s) associated

74

by the TOE with the identity of the client (i.e. the public keys are unknown to the server). To demonstrate correct functionality it is sufficient to determine that an SSH connection was not established after using a valid username and an unknown key of supported type. TD0412 has been applied

Test Flow

Re-generate the SSH Key for SSH client used in test FCS_SSHS_EXT.1.5 Test # 1

Without loading the public key onto the TOE, attempt to log in

Verify through the authentication logs that the attempt was unsuccessful.


The attempt to log into the TOE without loading the public key onto the TOE proved to be unsuccessful. Thus, this requirement has been met.

Result Pass




Objective Test 3: The evaluator shall configure an SSH client to only allow the a public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the SSH client to the TOE and observe that the connection is rejected.

Test Flow

Configure an SSH client to use a public key algorithm that is not included in the ST selection.

Attempt to establish an SSH connection from the client to the TOE.



The TOE does not allow a SSH client to connect with a public key algorithm that is not included in the ST selection. Thus, this requirement has been met.

Result Pass


Objective: The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. Evaluator Findings: The evaluator examined the TSS to ensure that it lists all supported data integrity algorithms. The definition of FCS_SSHS_EXT.1 and TSS entry for FCS_SSHS_EXT.1 in the section 6.1 titled TOE “Security Functional Requirement Measures” of ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the data integrity algorithms supported for SSH connections by the TOE. The following data integrity algorithms are identified as supported within the TSS,

hmac-sha2-512

Next, the evaluator examined the definition of FCS_SSHS_EXT.1 in ST. The evaluator found that the data integrity algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass

75


Objective: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed).




Verdict: Pass




Objective Test 1: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall establish an SSH connection using each of the algorithms, except “implicit”, specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. TD0337 has been applied

Test Flow

From an SSH client, connect to the TOE using the data integrity algorithms specified in the ST.

Verify through packet captures that the connection succeeds using the specified algorithm


The TOE is be able to make SSH connections with each claimed data integrity algorithm.

Result Pass




Objective Test 2: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall configure an SSH client to only allow a MAC algorithm that is not included in the ST selection. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. TD0337 has been applied

Test Flow

Configure the SSH client to allow a MAC algorithm that is not included in the ST selection.

Attempt to connect from the SSH client to the TOE.

Verify the connection was unsuccessful.

76


The TOE does not allow a connection with an unclaimed MAC algorithm.

Result Pass


Objective: The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. Evaluator Findings: The evaluator examined the TSS to ensure that it lists the supported key exchange algorithms. The definition of FCS_SSHS_EXT.1 and TSS entry for FCS_SSHS_EXT.1 in the section 6.1 titled TOE “Security Functional Requirement Measures” of ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the key exchange algorithms supported for SSH connections by the TOE. The following key exchange algorithms are identified as supported within the TSS,

ecdh-sha2-nistp256

ecdh-sha2-nistp384

Next, the evaluator examined the definition of FCS_SSHS_EXT.1 in ST. The evaluator found that the key exchange algorithms specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass


Objective: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE.

Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled ‘MRA’ of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH. Finally, the evaluator compared the configuration described in AGD to the TSS of ST. The evaluator found that the configuration options in AGD are consistent with the description of SSH in the TSS.


Verdict: Pass




77

Objective Test 1: The evaluator shall configure an SSH client to only allow the diffie-hellman-group1-sha1 key exchange. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails.

Test Flow

Configure the SSH client to only allow diffie-hellman-group1-sha1 key exchange and attempt to connect to the TOE.



The TOE does not allow a connection to occur when diffie-hellman-group1-sha1 key exchange is used.

Result Pass




Objective Test 2: For each allowed key exchange method, the evaluator shall configure an SSH client to only allow that method for key exchange, attempt to connect from the client to the TOE, and observe that the attempt succeeds.

Test Flow

From an SSH client, connect to the TOE using the allowed key exchange methods specified in the ST.

Verify through packet captures that the connection succeeds using the specified key exchange.


The TOE is able to make SSH connections with each claimed data key exchange method. This meets the testing requirements.

Result Pass


Objective: The evaluator shall check that the TSS specifies the following: 1. Both thresholds are checked by the TOE. 2. Rekeying is performed upon reaching the threshold that is hit first. Evaluator Findings: The evaluator checked that the TSS specifies the following, both thresholds are checked by the TOE and rekeying is performed upon reaching the threshold that is hit first. The FCS_SSHS_EXT.1 entry within the TSS of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS describes that the TOE is capable of rekeying for both 1 GB of data and 1 hour. Additionally, the TSS states that, “The TOE can also be configured to ensure that SSH re-keying occurs prior to one hour of time or prior to more than one gigabyte of transmitted data for that session key. If the connection between Expressway C and Expressway E using SSHv2 is unintentionally broken, the connection will need to be re-established. The keys will be overwritten, new keys will need to be generated and the connection reestablished as described in the TOE guidance documentation, the Cisco Expressway Common Criteria Configuration Guide.”


Verdict: Pass


Objective: If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits

78

specified in the SFR (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the SFR. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached.

Evaluator Findings: The evaluator examined the guidance document to determine if it contains instructions on configuring the TOE so that SSH conforms to the descriptions in the TSS. Section 2.3 titled ‘MRA’ of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator that AGD describes the configuration of SSH on the TOE. Specifically, the evaluator found that AGD describes the characteristics of SSH configuration is listed in section 2.3 through requirements and instructions to enable SSH the evaluator found that AGD describes the configuration of SSH from the CLI.



Verdict: Pass




Objective The evaluator needs to perform testing that rekeying is performed according to the description in the TSS. The evaluator shall test both, the time-based threshold and the traffic-based threshold. The intention of FCS_SSHC_EXT.1.8 and FCS_SSHS_EXT.1.8 SFRs is to ensure that the TOE implements both thresholds. The NIT also acknowledges that it is possible that hardware limitation may prevent reaching data transfer threshold in less than one hour. In cases where data transfer threshold could not be reached due to hardware limitations it is acceptable to omit testing of this (SSH rekeying based on data transfer threshold) threshold if both the following conditions are met: a. An argument is present in the TSS section describing this hardware-based limitation and b. All hardware components that are the basis of such argument are definitively identified in the ST. For example, if specific Ethernet Controller or WiFi radio chip is the root cause of such limitation, these chips must be identified. For testing of the time-based threshold the evaluator shall use an SSH client to connect to the TOE and keep the session open until the threshold is reached. The evaluator shall verify that the SSH session has been active longer than the threshold value and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one hour of session time but the value used for testing shall not exceed one hour. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. For testing of the traffic-based threshold the evaluator shall use an SSH client to connect to the TOE, and shall transmit data from and to the TOE within the active SSH session until the threshold for transmitted traffic is reached. The transmitted traffic is the total traffic comprising incoming and outgoing traffic. The evaluator shall verify that more data has been transmitted within the SSH session than the threshold allows and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator).

79

Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one gigabyte of transferred traffic but the value used for testing shall not exceed one gigabyte. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, the evaluator needs to verify that the threshold(s) can be configured as described in the guidance documentation and the evaluator needs to test that modification of the thresholds is restricted to Security Administrators (as required by FMT_MOF.1/Functions). TD0336 has been applied

Test Flow

From an SSH client, establish an SSH connection to the TOE

Send a sufficient number of packets to the TOE to cause a rekey

Verify that a rekey was initiated by reviewing the TOE logs and through packet capture

Pass/Fail Explanation The TOE initiates a rekey once the data or time limit has been reached.

Result Pass

4.7 Test Cases (TLSC)

4.7.1 FCS_TLSC_EXT.2.1 TSS 1

Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. Evaluator Findings: The evaluator examined the TSS to ensure that the cipher suites supported are specified. The definition of FCS_TLSC_EXT.2 and TSS entry for FCS_TLSC_EXT.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. The evaluator first examined the TSS of ST to identify the cipher suites supported by the TOE for TLS client connections. The following cipher suites are identified as supported within the TSS,

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246


TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC5289

Next, the evaluator examined the definition of FCS_TLSC_EXT.2 in ST. The evaluator found that the cipher suites for TLS client connection specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass

4.7.2 FCS_TLSC_EXT.2.1 Guidance 1

Objective: The evaluator shall check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS.

80

Evaluator Findings: The evaluator examined the operational guidance to ensure that it contains instructions on configuring the TOE as a TLS client. The section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. The evaluator found that AGD identifies the method for configuring TLS client communications on the TOE.


Verdict: Pass

4.7.3 FCS_TLSC_EXT.2.1 Test 1

Data/Description

Test ID FCS_TLSC_EXT.2.1_T1

Objective Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test Flow

Establish a connection using each of the claimed ciphersuites

Verify the connection is established successfully


The TOE is be able to accept a connection using the claimed ciphersuites.

Result Pass


Data/Description


Objective Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage extension and verify that a connection is established. The evaluator shall repeat this test using a different, but otherwise valid and trusted, certificate that lacks the Server Authentication purpose in the extendedKeyUsage extension and ensure that a connection is not established. Ideally, the two certificates should be similar in structure, the types of identifiers used, and the chain of trust. TD0396 has been applied

Test Flow

Attempt to connect to a server that contains the Server authentication purpose in the certificate

Verify the connection is successful

Attempt to connect to a server that contains the Client authentication purpose in the certificate

Verify the connection is unsuccessful


The TOE denies a connection when the server certificate lacks the server authentication purpose. The TOE accepts a connection when the certificate does contain a server authentication purpose.

Result Pass

81


Data/Description


Objective Test 3: The evaluator shall send a server certificate in the TLS connection that does not match the server-selected ciphersuite (for example, send an ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.) The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message.

Test Flow

Send a server certificate in the TLS connection that does not match the server-selected ciphersuite

Verify the TOE rejects the connection


The TOE rejects a connection because the certificate does not match the ciphersuite.

Result Pass


Data/Description


Objective Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection.

Test Flow Configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite

Verify the TOE denies the connection


The TOE denies a connection because it does not support the NULL ciphersuite.

Result Pass

4.7.7 FCS_TLSC_EXT.2.1 Test 5a


Test ID FCS_TLSC_EXT.2.1_T5a

Objective a) Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.5 represented by the two bytes 03 06) and verify that the client rejects the connection.

Test Flow

Change the TLS version selected by the server in the Server Hello to a non-supported TLS version



The TOE denies a connection due to a non-supported TLS version.

Result Pass

4.7.8 FCS_TLSC_EXT.2.1 Test 5b


Test ID FCS_TLSC_EXT.2.1_T5b

Objective b) Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client’s Finished handshake message.

Test Flow

Modify a byte in the server’s nonce in the Server Hello handshake message using the Acumen TLS tool


82


The TOE denies the connection due to a modified server hello nonce.

Result Pass

4.7.9 FCS_TLSC_EXT.2.1 Test 5c


Test ID FCS_TLSC_EXT.2.1_T5c

Objective c) Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello.

Test Flow

Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not in the Client Hello message



The TOE denies a connection due to an unsupported cipher suite.

Result Pass

4.7.10 FCS_TLSC_EXT.2.1 Test 5d


Test ID FCS_TLSC_EXT.2.1_T5d

Objective d) If using DHE or ECDH, modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. This test does not apply to cipher suites using RSA key exchange. If a TOE only supports RSA key exchange in conjunction with TLS then this test shall be omitted.

Test Flow

Modify the signature block in the Server’s Key Exchange handshake message



The TOE denies the connection when receiving a modified handshake message.

Result Pass

4.7.11 FCS_TLSC_EXT.2.1 Test 5e


Test ID FCS_TLSC_EXT.2.1_T5e

Objective Test 5: The evaluator shall perform the following modifications to the traffic: e) Modify a byte in the Server Finished handshake message, and verify that the client sends an Encrypted Message followed by a FIN and ACK message. This is sufficient to deduce that the TOE responded with a Fatal Alert and no further data would be sent. TD0289 has been applied

Test Flow

Modify a byte in the Server Finished handshake message

Verify the TOE does not complete the connection.


The TOE denies a connection due to a modified Server Finished Handshake message.

Result Pass

4.7.12 FCS_TLSC_EXT.2.1 Test 5f


Test ID FCS_TLSC_EXT.2.1_T5f

83

Objective f) Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection.

Test Flow

Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message

Verify the TOE denies the connection


The TOE denies a connection due to modified packets.

Result Pass


Objective: The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/application configured reference identifier, including which types of reference identifiers are supported (e.g. application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies if certificate pinning is supported or used by the TOE and how it is implemented. Evaluator Findings: The evaluator checked the TSS to determine if it describes the client’s method of establishing reference identifiers. The TSS entry for FCS_TLSC_EXT.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes the client’s method of establishing reference identifiers. The TSS does states “wild card certificates can be used as a trust certificate where it is the leftmost identifier, for example CN=*.webexconnect.com. IP addresses are not supported as reference identifiers. Additionally, the TSS also states “Certificate pinning is not supported.”.


Verdict: Pass


Objective: The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. Evaluator Findings: The evaluator examined the operational guidance to ensure that it contains instructions on configuring the TOE as a TLS client. The section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. The evaluator found that AGD identifies the method for configuring TLS client communications on the TOE. The TOE verifies the presented identifier matches the reference identifier per RFC 6125 section 6.


Verdict: Pass




Objective Test 1: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection fails.

84

Remark: Some systems might require the presence of the SAN extension. In this case the connection would still fail but for the reason of the missing SAN extension instead of the mismatch of CN and reference identifier. Both reasons are acceptable to pass Test 1 TD0257 has been applied

Test Flow

Present a server certificate that contains a CN that does not match the reference identifier and does not contain the SAN extension.



The TOE denies the connection due to a mismatched CN and non-existent SAN.

Result Pass




Objective Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

Test Flow

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



The TOE denies the connection because of a mismatched CN and SAN.

Result Pass




Objective Test 3 [conditional]: If the TOE does not mandate the presence of the SAN extension, the evaluator shall present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension. The evaluator shall verify that the connection succeeds. If the TOE does mandate the presence of the SAN extension, this Test shall be omitted. TD0257 has been applied

Test Flow

Present a server certificate that contains a CN that matches the reference identifier and does not contain the SAN extension.

Verify the connection succeeds.


The TOE allows the connection to proceed when the CN matches the reference identifier.

Result Pass




Objective Test 4: The evaluator shall present a server certificate that contains a CN that does not match the reference identifier but does contain an identifier in the SAN that matches. The evaluator shall verify that the connection succeeds.

85

Test Flow

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



The TOE allows a connection when the SAN matches the reference identifier.

Result Pass

4.7.19 FCS_TLSC_EXT.2.2 Test 5a


Test ID FCS_TLSC_EXT.2.2_T5a

Objective 1) The evaluator shall present a server certificate containing a wildcard that is not in the left-most label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails.

Test Flow

Present a server certificate containing a wildcard that is not in the left-most label.



The TOE does not allow a connection when a server certificate contains a wildcard that is not in the left-most label of the presented identifier.

Result Pass

4.7.20 FCS_TLSC_EXT.2.2 Test 5b


Test ID FCS_TLSC_EXT.2.2_T5b

Objective 2) The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g. *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two leftmost labels (e.g. bar.foo.example.come) and verify that the connection fails.

Test Flow

Present a server certificate containing a wildcard in the left-most label.

Configure the reference identifier with a single left most label.


Configure the reference identifier without a left most label.


Configure the reference identifier with two left most labels.



The TOE accepted a connection when there was one label in the left position and a wildcard in the certificate. The TOE then denied a connection when the reference identifier specified no label in the left position. The TOE also rejected a connection when the reference identifier was set with two left-most labels.

Result Pass

4.7.21 FCS_TLSC_EXT.2.2 Test 6 (Conditional)



Objective Test 6: [conditional] If URI or Service name reference identifiers are supported, the evaluator shall configure the DNS name and the service identifier. The evaluator shall present a server certificate containing the correct DNS name and service identifier in the

86

URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails.

Test Flow

NA – URI or Service name reference identifiers are not supported by the TOE.


NA – URI or Service name reference identifiers are not supported by the TOE.

Result NA – URI or Service name reference identifiers are not supported by the TOE.




Objective Test 1: The evaluator shall demonstrate that using a certificate without a valid certification path results in the function failing. Using the administrative guidance, the evaluator shall then load a certificate or certificates needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. If the certificate is validated and a trusted channel is established, the test passes. The evaluator then shall delete one of the certificates and show that the certificate is not validated and the trusted channel is not established.

Test Flow

Present the TOE with a valid chain of certificates.

Verify the connection was successful.

Delete one of the certificates in the presented chain.



The TOE accepts a connection when there is a full chain present. The TOE denies a connection when a cert is deleted from the chain.

Result Pass


Objective: The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured. Evaluator Findings: The evaluator verified that TSS describes no Supported Elliptic Curves Extension and whether the required behavior is performed by default or may be configured. The TSS entry for FCS_HTTPS_EXT.1, FCS_TLSC_EXT.2 and FCS_TLSS_EXT.2 in the section titled TOE Summary Specification of ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found the ST does not claim any elliptic curves. The TSS states, “Following is the TLS with mutual authentication handshake and exchange of parameters between the client and the TOE. Note, elliptic curve extensions are not supported in the Client Hello.”


Verdict: Pass


Objective: If the TSS indicates that the Supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the Supported Elliptic Curves Extension.

87

Evaluator Findings:

The evaluator examined the operational guidance and it states the following: Note, elliptic curve extensions are not supported in the Client Hello.


Verdict: Pass




Objective Test 1: If using DHE or ECDH, the evaluator shall configure the server to perform an ECDHE key exchange in the TLS connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects after receiving the server’s Key Exchange handshake message.

Test Flow

Configure a server to use a non-supported curve.

Verify the TOE does not accept the connection.


The TOE rejected a connection when a weak curve was detected.

Result Pass


Objective: The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. Evaluator Findings: The evaluator ensured that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. The FCS_TLSC_EXT.2 entry of TSS within section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS includes a description of the TLS Mutual authentication handshake used by the TOE for connections.


Verdict: Pass


Objective: If the TSS indicates that mutual authentication using X.509v3 certificates is used, the evaluator shall verify that the AGD guidance includes instructions for configuring the client-side certificates for TLS mutual authentication. Evaluator Findings: The evaluator verified that the AGD includes instructions for configuring the client-side certificates for TLS mutual authentication. The entirety of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the guidance documentation provides instructions for configuring client-side certificates in section 2.2.3 titled, ‘Certificates and Keys’ and 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ of AGD.

88


Verdict: Pass




Objective The purpose of these tests is to confirm that the TOE appropriately handles connection to peer servers that support and do not support mutual authentication. Test 1: The evaluator shall establish a connection to a peer server that is not configured for mutual authentication (i.e. does not send Server’s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE did not send Client’s Certificate message (type 11) during handshake. TD0256 has been applied

Test Flow

Configure a server that does not support mutual authentication.

Verify that the TOE does not send a Client Certificate message.


The TOE does not send a Client Certificate message during the handshake.

Result Pass




Objective Test 2: The evaluator shall establish a connection to a peer server with a shared trusted root that is configured for mutual authentication (i.e. it sends Server’s Certificate Request (type 13) message). The evaluator observes negotiation of a TLS channel and confirms that the TOE responds with a non-empty Client’s Certificate message (type 11) and Certificate Verify (type 15) messages. TD0256 has been applied

Test Flow

Configure a server to support mutual authentication.

Verify that the TOE responds with a non-empty certificate message and certificate verify message.


The TOE responds with a non-empty certificate message and certificate verify message.

Result Pass

4.8 Test Cases (TLSS)

4.8.1 FCS_TLSS_EXT.2.1 TSS 1

Objective: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. Evaluator Findings: The evaluator first examined the entry for FCS_TLSS_EXT.2.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST to identify the ciphersuites

89

supported by the TOE for TLS server connections. The following ciphersuites are identified as supported within the TSS,

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268





TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC5289

Next, the evaluator examined the definition of FCS_TLSS_EXT.2 in the ST. The evaluator found that the ciphersuites for TLS client connection specified in the definition of the SFR are consistent with the description within the TSS of ST.


Verdict: Pass

4.8.2 FCS_TLSS_EXT.2.1 Guidance 1

Objective: The evaluator shall check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements). Evaluator Findings: The evaluator examined the AGD to ensure that it contains instructions on configuring the TOE as a TLS server. The section 5 titled ‘Network Services and Protocols’ and section 2.3 titled ‘MRA’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD identifies the method for configuring TLS server communications on the TOE.


Verdict: Pass

4.8.3 FCS_TLSS_EXT.2.1 Test 1


Test ID FCS_TLSS_EXT.2.1_T1

Objective Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

Test Flow

Establish a TLS connection using each of the ciphersuites specified in the ST.

Verify the connection was successful


The TOE should allow a connection using each of the specified ciphersuites specified in the ST.

Result Pass

90




Objective Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally, the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the server denies the connection.

Test Flow

Connect to the TOE with a cipher that is not included in the ST.

Verify the TOE denies the connection.

Connect to the TOE using the TLS_NULL_WITH_NULL ciphersuite.



The TOE does not allow connections with ciphers that are not included in the ST.

Result Pass




Objective Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the Key Exchange message.

Test Flow

Connect to the TOE using a key exchange that does not match the server-selected ciphersuite.

Verify the TOE disconnects after receiving the Key Exchange message.


The TOE disconnects after receiving the Key Exchange message.

Result Pass

4.8.6 FCS_TLSS_EXT.2.1 Test 4c


Test ID FCS_TLSS_EXT.2.1_T4c

Objective c) Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and does not send any application data.

Test Flow

Modify a byte in the Client Finished handshake message.

Verify the TOE rejects the connection and does not send any application data


The TOE does not send any application data when a modified Client Finished handshake message is received.

Result Pass

4.8.7 FCS_TLSS_EXT.2.1 Test 4d


Test ID FCS_TLSS_EXT.2.1_T4d

Objective d) After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection.

91

Test Flow

Generate a fatal alert by sending a Finished message from the client before a ChangeCipherSpec message is sent.

Send a Client Hello with the session identifier from the previous test.



The TOE denies the connection when a modified Client Hello Is received.

Result Pass

4.8.8 FCS_TLSS_EXT.2.1 Test 4e


Test ID FCS_TLSS_EXT.2.1_T4e

Objective Test Intent: The intent of this test is to ensure that the server's TLS implementation immediately makes use of the key exchange and authentication algorithms to: a) Correctly encrypt (D)TLS Finished message b) Encrypt every (D)TLS message after session keys are negotiated The evaluator shall use one of the claimed ciphersuites to complete a successful handshake and observe transmission of properly encrypted application data. The evaluator shall verify that no Alert with alert level Fatal (2) messages were sent. The evaluator shall verify that the Finished message (Content type hexadecimal 16 and handshake message type hexadecimal 14) is sent immediately after the server's ChangeCipherSpec (Content type hexadecimal 14) message. The evaluator shall examine the Finished message (encrypted example in hexadecimal of a TLS record containing a Finished message, 16 03 03 00 40 11 22 33 44 55...) and confirm that it does not contain unencrypted data (unencrypted example in hexadecimal of a TLS record containing a Finished message, 16 03 03 00 40 14 00 00 0c...), by verifying that the first byte of the encrypted Finished message does not equal hexadecimal 14 for at least one of three test messages. There is a chance that an encrypted Finished message contains a hexadecimal value of '14' at the position where a plaintext Finished message would contain the message type code '14'. If the observed Finished message contains a hexadecimal value of '14' at the position where the plaintext Finished message would contain the message type code, the test shall be repeated three times in total. In case the value of '14' can be observed in all three tests it can be assumed that the Finished message has indeed been sent in plaintext and the test has to be regarded as 'failed'. Otherwise it has to be assumed that the observation of the value '14' has been due to chance and that the Finished message has indeed been sent encrypted. In that latter case the test shall be regarded as 'passed'. TD0342 has been applied

Test Flow

Attempt to connect to the TOE.

Complete a successful connection and verify application data is encrypted.

Verify the Finished message is sent after the server’s ChangeCipherSpec and is encrypted.


The TOE is be able to complete a successful handshake and encrypt application data.

Result Pass


Objective: The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions.

92

Evaluator Findings: The evaluator ensured that the TSS contains a description of the denial of old SSL and TLS versions. The FCS_TLSS_EXT.2 entry of section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS states that, “Once configured, the TOE will not establish TLS v1.0 and related SSL versions connections if offered by the client. In addition, the TOE will only establish a connection if the peer presents a valid certificate during the handshake.”


Verdict: Pass


Objective: The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Evaluator Findings: The evaluator examined the AGD to ensure that it contains instructions on configuring the TOE as a TLS server. The section 2.2 titled ‘Initial Setup of Cisco Expressway’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the AGD states that the TOE supports TLSv1.1 or TLSv1.2.


Verdict: Pass




Objective The evaluator shall send a Client Hello requesting a connection for all mandatory and selected protocol versions in the SFR (e.g. by enumeration of protocol versions in a test client) and verify that the server denies the connection for each attempt.

Test Flow

Send a Client Hello for all mandatory and selected protocol versions in the SFR.

Verify the TOE denies the connection for each attempt.


The TOE successfully denies unsupported TLS versions.

Result Pass


Objective: If using ECDHE or DHE ciphers, the evaluator shall verify that the TSS describes the key agreement parameters of the server Key Exchange message. TD0450 has been applied Evaluator Findings: The evaluator ensured that the TSS describes the key agreement parameters of the server Key Exchange message. The FCS_TLSS_EXT.2 entry of section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator first found that the TOE does support ECDHE and DHE ciphers. Next, the evaluator found that the TSS describes the key agreement parameters, as follows,” Using the above listed TLS_RSA ciphers the RSA public key (with a minimum RSA key size 2048) is used for authentication

93

and key exchange. Using the above listed TLS_ECDHE ciphers the standard Diffie-Hellman parameters P, Q, and G are used for key exchange.” The TSS entry for FCS_TLSS_EXT.2 which describes in detail the key agreement parameters of the server Key Exchange message.


Verdict: Pass


Objective: The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Evaluator Findings: The evaluator verified that the AGD includes instructions for configuring the RSA keys. The entirety of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that section 5 ‘Network Services and Protocols’ and section 2.2.1 titled ‘Licenses and Release Keys’ of the AGD contains the procedures to enable and configure TLS for the TOE.


Verdict: Pass




Objective The evaluator shall attempt a connection using an ECDHE ciphersuite and a configured curve. Using a packet analyser, verify that the key agreement parameters in the Key Exchange message are the ones configured. (Determining that the size matches the expected size for the configured curve is sufficient.) The evaluator shall repeat this test for each supported NIST Elliptic Curve and each supported Diffie-Hellman key size. The evaluator shall attempt establishing connection using each claimed key establishment protocol (RSA, DH, ECDHE) with each claimed parameter (RSA key size, Diffie-Hellman parameters, supported curves) as selected in FCS_TLSS_EXT.2.3. For example, determining that the RSA key size matches the claimed size is sufficient to satisfy this test. The evaluator shall ensure that each supported parameter combination is tested.

Test Flow

Connect to the TOE with an RSA Cipher suite and supported key sizes

Verify that the connection succeeds


The TOE successfully connects with the supported key sizes.

Result Pass

4.8.15 FCS_TLSS_EXT.2.4/2.5 TSS 1

Objective: The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. Evaluator Findings: The evaluator ensured that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. The FCS_TLSS_EXT.2 entry of

94

section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS includes a description of the TLS Mutual authentication handshake used by the TOE for connections.


Verdict: Pass

4.8.16 FCS_TLSS_EXT.2.4/2.5 Guidance 1

Objective: If the TSS indicates that mutual authentication using X.509v3 certificates is used, the evaluator shall verify that the AGD guidance includes instructions for configuring the client-side certificates for TLS mutual authentication. Evaluator Findings: The evaluator verified that the AGD includes instructions for configuring the client-side certificates for TLS mutual authentication. The entirety of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the guidance documentation provides instructions for configuring client-side certificates in section 2.2.3 titled, ‘Certificates and Keys’.


Verdict: Pass

4.8.17 FCS_TLSS_EXT.2.4/2.5 Test 1


Test ID FCS_TLSS_EXT.2.4/2.5_T1

Objective Test 1: The evaluator shall configure the server to send a certificate request to the client and shall attempt a connection without sending a certificate from the client. The evaluator shall verify that the connection is denied.

Test Flow

Initiate a connection to the TOE

Verify that a certificate from the client is not sent during the connection.

Verify that the TOE rejects the connection.


The TOE rejects a connection when the client does not send a certificate.

Result Pass




Objective Test 2[conditional]: If TLS1.2 is claimed for the TOE, the evaluator shall configure the server to send a certificate request to the client without the supported_signature_algorithm used by the client's certificate. The evaluator shall attempt a connection using the client certificate and verify that the connection is denied. TD0395 has been applied

Test Flow

Initiate a connection to the TOE

Create a certificate that does not match the supported_signature_algorithm of the TOE.

Verify that the TOE rejects the connection.

95


The TOE does not accept a connection due to a mismatched signature algorithm.

Result Pass




Objective Test 3: 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.

Test Flow

Attempt to connect to the TOE using a valid certificate path.

Verify the connection is successful.

Attempt to connect to the TOE when one of the certificates in the certificate path has been deleted.



When a complete certificate trust chain is present, the TOE is able to make a successful connection. When an incomplete certificate trust chain is present, the TOE is not able to make a successful connection.

Result Pass




Objective Test 4: The aim of this test is to check the response of the server when it receives a client identity certificate that is signed by an impostor CA (either Root CA or intermediate CA). To carry out this test the evaluator shall configure the client to send a client identity certificate with an issuer field that identifies a CA recognised by the TOE as a trusted CA, but where the key used for the signature on the client certificate does not in fact correspond to the CA certificate trusted by the TOE (meaning that the client certificate is invalid because its certification path does not in fact terminate in the claimed CA certificate). The evaluator shall verify that the attempted connection is denied. TD0322 has been applied

Test Flow

Attempt to connect to the TOE with a certificate not in the chain on the TOE.

Verify that the connection is unsuccessful.


The TOE denies a connection due to not knowing the CA of the client certificate.

Result Pass




Objective Test 5: The evaluator shall configure the client to send a certificate with the Client Authentication purpose in the extendedKeyUsage field and verify that the server accepts the attempted connection. The evaluator shall repeat this test without the Client Authentication purpose and shall verify that the server denies the connection. Ideally, the two certificates should be identical except for the Client Authentication purpose.

96

Test Flow

Attempt a connection to the TOE with a certificate that does contain the Client Authentication purpose

Verify that the connection succeeds

Attempt a connection to the TOE with a certificate that does not Client Authentication purpose

Verify that the connection fails due to a missing key usage field


The TOE denies a connection because there is no Client Authentication purpose in the certificate.

Result Pass

4.8.22 FCS_TLSS_EXT.2.4/2.5 Test 6a



Objective a) Configure the server to require mutual authentication and then modify a byte in the client’s certificate. The evaluator shall verify that the server rejects the connection.

Test Flow

Use the Acumen TLS modification tool to modify a byte in the client certificate

Verify that the connection attempt is rejected


The TOE denies a connection when a modified certificate is detected

Result Pass

4.8.23 FCS_TLSS_EXT.2.4/2.5 Test 6b



Objective b) Configure the server to require mutual authentication and then modify a byte in the signature block of the client’s Certificate Verify handshake message. The evaluator shall verify that the server rejects the connection.

Test Flow

Use Acumen’s TLS modification tool to open a TLS connection to the TOE and modify a byte in the client’s Certificate Verify handshake message.

Verify that the attempt is rejected


The TOE denies a connection when there is byte modified in the Certificate Verify handshake.

Result Pass


Objective: The evaluator shall verify that the TSS describes how the DN or SAN in the certificate is compared to the expected identifier. Evaluator Findings: The evaluator ensured that the TSS describes how the DN or SAN in the certificate is compared to the expected identifier. The FCS_TLSS_EXT.2 entry of section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Upon investigation, the evaluator found that the TSS includes a description of how the SAN in the certificate is compared to the expected identifier.


Verdict: Pass

97

4.8.25 FCS_TLSS_EXT.2. Guidance 1

Objective: If the DN is not compared automatically to the Domain Name or IP address, username, or email address, then the evaluator shall ensure that the AGD guidance includes configuration of the expected DN or the directory server for the connection. Evaluator Findings: The evaluator verified that the AGD includes instructions for configuring the Reference Identifiers. The entirety of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the guidance documentation section 2.2.3 titled, ‘Certificates and Keys’ the TOE’s certificate signing request (CSR) tool which prompts for and incorporates the relevant subject alternative name (SAN) entries as appropriate for the Unified Communications features that are supported on that Expressway.


Verdict: Pass




Objective The evaluator shall send a client certificate with an identifier that does not match an expected identifier and verify that the server denies the connection.

Test Flow

Create a certificate with a mismatched identifier

Attempt to connect to the TOE using the certificate

Verify that the connection is denied.


The TOE denies a connection due to an unexpected identifier in the certificate.

Result Pass

4.9 Test Cases (Identification and Authentication)

4.9.1 FIA_AFL.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked. The TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability. Evaluator Findings: The evaluator reviewed TSS in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST and found for FIA_AFL.1 entry stated “The TOE provides the administrator the ability to specify the maximum number of unsuccessful authentication attempts before administrator is locked out. The number can be set between 1-3 attempts, with one (1) being the lowest setting allowed and three (3) being the maximum number of attempts allowed. If the account is locked by exceeding the number of attempts to login, the local Administrator must unlock the user account before the remote Administrator can attempt to login.”


Verdict: Pass

98

4.9.2 FIA_AFL.1 TSS 2

Objective: The evaluator shall examine the TSS to confirm that the TOE ensures that authentication failures by remote administrators cannot lead to a situation where no administrator access is available, either permanently or temporarily (e.g. by providing local logon which is not subject to blocking). Evaluator Findings: The evaluator reviewed the entry for FIA_AFL.1 in the TSS and found that section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST states that, “The number can be set between 1-3 attempts, with one (1) being the lowest setting allowed and three (3) being the maximum number of attempts allowed. If the account is locked by exceeding the number of attempts to login, local access will still be available, and the local Administrator must unlock the user account before the remote Administrator can attempt to login.”.


Verdict: Pass

4.9.3 FIA_AFL.1 Guidance 1

Objective: The evaluator shall examine the guidance documentation to ensure that instructions for configuring the number of successive unsuccessful authentication attempts and time period (if implemented) are provided, and that the process of allowing the remote administrator to once again successfully log on is described for each “action” specified (if that option is chosen). If different actions or mechanisms are implemented depending on the secure protocol employed (e.g., TLS vs. SSH), all must be described. Evaluator Findings: The evaluator examined the AGD to ensure that instructions for configuring the number of successive unsuccessful authentication attempts and that the process of allowing the remote administrator to once again successfully log on is described for each “action” specified. Section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ and the evaluator found that the threshold for the number of authentication failures before lockouts, as well as how to clear a lock out, can be configured within this section.


Verdict: Pass

4.9.4 FIA_AFL.1 Guidance 2

Objective: The evaluator shall examine the guidance documentation to confirm that it describes, and identifies the importance of, any actions that are required in order to ensure that administrator access will always be maintained, even if remote administration is made permanently or temporarily unavailable due to blocking of accounts as a result of FIA_AFL.1. Evaluator Findings: The evaluator examined the AGD to confirm that it describes, and identifies the importance of, any actions that are required in order to ensure that administrator access will always be maintained, even if remote administration is made permanently or temporarily unavailable due to blocking of accounts as a result of FIA_AFL.1. Section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ within the guidance document was used to determine the verdict

99

of this activity. Upon investigation, the evaluator found that the AGD describes the ability to access the TOE after logout, as follows, “The authentication failures cannot lead to a situation where no administrator access is available as the local CLI access would be accessible to the user as the local CLI cannot be locked out.”


Verdict: Pass

4.9.5 FIA_AFL.1 Test #1


Test ID FIA_AFL.1_T1

Objective Test 1: The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE (and, if the time period selection in FIA_AFL.1.2 is included in the ST, then the evaluator shall also use the operational guidance to configure the time period after which access is re-enabled). The evaluator shall test that once the authentication attempts limit is reached, authentication attempts with valid credentials are no longer successful.

Test Flow Configure the TOE to lock out a user after a certain number of attempts.

Connect to the TOE from using incorrect credentials.

Verify that the user is unable to authenticate to the TOE using password-based authentication once the authentication limit has been reached.

Pass/Fail Explanation The TOE did not allow authentication once the authentication attempt limit has been reached.

Result Pass

4.9.6 FIA_AFL.1 Test #2


Test ID FIA_AFL.1_T2

Objective Test 2: After reaching the limit for unsuccessful authentication attempts as in Test 1 above, the evaluator shall proceed as follows. If the administrator action selection in FIA_AFL.1.2 is included in the ST then the evaluator shall confirm by testing that following the operational guidance and performing each action specified in the ST to re-enable the remote administrator’s access results in successful access (when using valid credentials for that administrator). If the time period selection in FIA_AFL.1.2 is included in the ST then the evaluator shall wait for just less than the time period configured in Test 1 and show that an authorisation attempt using valid credentials does not result in successful access. The evaluator shall then wait until just after the time period configured in Test 1 and show that an authorisation attempt using valid credentials results in successful access.

Test Flow Configure the TOE to lock out a user after a certain number of attempts.

Connect to the TOE from using incorrect credentials.

Verify that the user is unable to authenticate to the TOE using password-

based authentication once the authentication limit has been reached.

Using an administrator account, unlock the offending account.

100

Verify the user is able to log in.

Pass/Fail Explanation The TOE does not allow authentication until the configured account has been unlocked by a privileged administrator.

Result Pass

4.9.7 FIA_PMG_EXT.1.1 Guidance 1

Objective: The evaluator shall examine the guidance documentation to determine that it: a) identifies the characters that may be used in passwords and provides guidance to security administrators on the composition of strong passwords, and b) provides instructions on setting the minimum password length and describes the valid minimum password lengths supported. Evaluator Findings: The evaluator examined the AGD to determine if it provides guidance on the composition of strong passwords. Section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD provide instructions to administrative users regarding strong passwords. In particular, the evaluator found that AGD identifies that at minimum passwords must be 15 characters. The evaluator found that AGD provide instructions for configuring passwords via CLI and GUI.


Verdict: Pass

4.9.8 FIA_PMG_EXT.1 Test 1


Test ID FIA_PMG_EXT.1.1_T1

Objective The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

Test Flow

Set the minimum password length to 15 and require it to contain 2 digits, 2

upper case letters, 2 lower case letters, and 2 special characters

Attempt to use the password @cumen Secur1T9!

Verify it fails due to an unrecognizable space character

Attempt to use the password 1234ABCDefgh!$

Verify it fails due to being less than 15 characters

Attempt to use the password AcumenSecurity2400

Verify the password was not accepted because no special characters were

detected

Attempt to use the password !@#$%^&*()AB12

Verify it fails due to there being no lower-case letters

Attempt to use the password 213AB!De@gh4#F3

Verify it succeeds due to it meeting the password policy requirements

101

Set the minimum password length to 255

Attempt to use a password with a length of 254

Verify that the password was not accepted

Attempt to use a password with a length of 255

Verify the password was accepted due to it matching the password policy

Pass/Fail Explanation The TOE was able to create users with good passwords and reject user creation with bad passwords.

Result Pass

4.9.9 FIA_UIA_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”. Evaluator Findings: The evaluator examined the TSS to determine that it describes the logon process for each logon method. The TSS entry for FIA_UIA_EXT.1 and FIA_UAU_EXT.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS identifies the following authentication methods for the users of the TOE,

Both the local and remote GUI interfaces (HTTPS)

Once a potential administrative user attempts to access the GUI of the TOE through a HTTPS secured connection, the TOE prompts the user for a username and password credentials. Only after the administrative user presents the correct authentication credentials (username and password) will access to the TOE administrative functionality be granted. Access to the administrative functionality of the TOE is prevented until an administrator is successfully identified and authenticated, which constitutes a successful logon.


Verdict: Pass

4.9.10 FIA_UIA_EXT.1 TSS 2

Objective: The evaluator shall examine the TSS to determine that it describes which actions are allowed before user identification and authentication. The description shall cover authentication and identification for local and remote TOE administration. Evaluator Findings: The evaluator examined the TSS to determine that it describes which actions are allowed before user identification and authentication. The TSS entry for FIA_UIA_EXT.1 and FIA_UAU_EXT.2 under section 6 was used to determine the verdict of this activity. Upon investigation, the evaluator found that “The TOE requires all users to be successfully identified and authenticated before allowing any TSF mediated actions to be performed except for the login warning banner that is displayed prior to user authentication and any network packets as configured by the authorized administrator may flow through the TOE. This is required for both the local and remote GUI interfaces.” Furthermore, the TSS also states in FIA_UIA_EXT.2, “Administrative access to the TOE is facilitated

102

through the TOE’s GUI. The TOE mediates all administrative actions through the GUI. Once a potential administrative user attempts to access the GUI of the TOE through a HTTPS secured connection, the TOE prompts the user for a username and password credentials. Only after the administrative user presents the correct authentication credentials (username and password) will access to the TOE administrative functionality be granted. No access is allowed to the administrative functionality of the TOE until an administrator is successfully identified and authenticated, which constitutes a successful logon.”


Verdict: Pass

4.9.11 FIA_UIA_EXT.1 Guidance 1

Objective: The evaluator shall examine the operational guidance to determine that any necessary preparatory steps (e.g., establishing credential material such as pre- shared keys, tunnels, certificates, etc.) to logging in are described. For each supported the login method, the evaluator shall ensure the operational guidance provides clear instructions for successfully logging on. If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the operational guidance provides sufficient instruction on limiting the allowed services. Evaluator Findings: The evaluator examined the operational guidance to determine that any necessary preparatory steps to logging in are described. The sections 3.1 ‘Login Banners’, 2.2.4 ‘Administrator Configuration, Credentials and Session Termination’ and 2.3 ‘MRA’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD provides instructions for configuring user authentication on the TOE. Authentication may be configured via CLI and GUI as described in section 2.2.4 of the AGD. The instructions provided by AGD place the TOE in a configuration that requires authentication for all administrative access.


Verdict: Pass

4.9.12 FIA_UIA_EXT.1 Test #1


Test ID FIA_UIA_EXT.1.1_T1

Objective The evaluator shall use the guidance documentation to configure the appropriate credential supported for the login method. For that credential/login method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access.

Test Flow

Attempt to login from a local connection with incorrect credentials

Confirm that access was denied

Log into the TOE from a local connection with correct credentials

Confirm that access was granted

Verify audits were generated showing the both login failure and success

Attempt to login from a remote GUI connection with incorrect credentials

Confirm that access was denied

Log into the TOE from a remote GUI connection with correct credentials

Confirm that access was granted

103

Verify that an audit records were generated showing the both login failure and success


Presenting incorrect authentication credentials results in denied access to the TOE. Presenting correct authentication credentials results in access being allowed to the TOE.

Result Pass




Objective The evaluator shall configure the services allowed (if any) according to the guidance documentation, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement.

Test Flow

Connect to the TOE to determine which services are available to an external remote entity.

Verify the list of services available is limited to those specified in the requirement.


The list of services available is limited to those specified in the requirement.

Result Pass




Objective Test 3: For local access, the evaluator shall determine what services are available to a local administrator prior to logging in, and make sure this list is consistent with the requirement.

Test Flow

Determine what services are available to a local administrator prior to logging in to the TOE.

Verify the list is consistent with the requirement.


The TOE allows the services that are listed in the ST to be available prior to logging in.

Result Pass




Objective Test 4: For distributed TOEs where not all TOE components support the authentication of

Security Administrators according to FIA_UIA_EXT.1 and FIA_UAU_EXT.2, the evaluator

shall test that the components authenticate Security Administrators as described in the

TSS.

Test Flow

All TOE components support local authentication of administrators logging in at the

console.

Pass/Fail

Explanation

All TOE components support local authentication of administrators logging in at the

console.

Result All TOE components support local authentication of administrators logging in at the

console.

104

4.9.16 FIA_UAU_EXT.2

None – The evaluation of this SFR is tested in conjunction with the testing of FIA_UIA_EXT.1.

4.9.17 FIA_UAU.7 Test #1


Test ID FIA_UAU.7.1_T1

Objective The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information.

Test Flow

At the directly connected login prompt, enter incorrect authentication credentials

Verify that at most obscured feedback is provided

At the directly connected login prompt, enter correct authentication credentials

Verify that at most obscured feedback is provided

Pass/Fail Explanation The TOE does not provide anything more than obscured feedback.

Result Pass

4.9.18 FIA_X509_EXT.1.1/ITT TSS 1

Objective: The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place, and that the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied).If selected, the TSS shall describe how certificate revocation checking is performed. It is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device. Evaluator Findings: The evaluator examined the FIA_X509_EXT.1.1/ITT TSS entry in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST which states the following: “The certificate chain establishes a sequence of trusted certificates, from a peer certificate to the root CA certificate. Within the PKI hierarchy, all enrolled peers can validate the certificate of one another if the peers share a trusted root CA certificate or a common subordinate CA. Each CA corresponds to a trust point. When a certificate chain is received from a peer, the default processing of a certificate chain path continues until the first trusted certificate, or trust point, is reached. The administrator may configure the level to which a certificate chain is processed on all certificates including subordinate CA certificates. The TSS also states “The TOE uses X.509v3 certificates as defined by RFC 5280 to support mutual authentication for TLS connections. The certificate request message includes the public key and common name per RFC 2986. The CN naming attributes in the certificate is compared with the expected CN naming attributes and deemed valid if the attribute types are the same and the values are the same and as expected.” Checking is also done for the basicConstraints extension and the CA flag to determine whether they are present and set to TRUE. The certificate(s) that was imported must contain the basic constraints extension with the CA flag set to true, the check also ensures that the key usage extension is present, and the keyEncipherment bit or the keyAgreement bit or both are set. If they are not, the certificate is not accepted. Additional checking of the extendedKeyUsage field includes the server and client authentication.”


Verdict: Pass

105

4.9.19 FIA_X509_EXT.1.1/ITT Test 1


Test ID FIA_X509_EXT.1.1/ITT_T1

Objective Test 1a: The evaluator shall load a valid chain of certificates (terminating in a trusted CA certificate) as needed to validate the certificate to be used in the function, and shall use this chain to demonstrate that the function succeeds. Test 1b: The evaluator shall then delete one of the certificates in the chain (i.e. the root CA certificate or other intermediate certificate, but not the end-entity certificate), and show that the function fails

Test Flow







Result Pass




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

Test Flow

Create an expired certificate.




The TOE does not allow a connection due to an expired certificate.

Result Pass




Objective Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-–conditional on whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the TOE certificate and revocation of the TOE intermediate CA certificate i.e. the intermediate CA certificate should be revoked by the root CA. The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. No testing is required if no revocation method is selected.

Test Flow Not applicable as the TOE does not claim a revocation method.


Not applicable as the TOE does not claim a revocation method.


106




Objective Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.

Test Flow




Result Not applicable as the TOE does not claim a revocation method.




Objective Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.)

Test Flow

Connect to the TOE.

Modify any byte in the first eight bytes of the certificate.

Verify the connection was not successful


The TOE does not allow a connection when the certificate has been modified.

Result Pass




Objective Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.)

Test Flow

Connect to the TOE.

Modify any byte in the last byte of the certificate.




Result Pass




Objective Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The hash of the certificate will not validate.)

107

Test Flow

Connect to the TOE.

Modify any byte in the public key of the certificate.



The TOE should not allow a connection when the certificate has been modified.

Result Pass




Objective The goal of the following tests it to verify that the TOE accepts only certificates that have been marked as CA certificates by using basicConstraints with the CA flag set to True (and implicitly that the TOE correctly parses the basicConstraints extension as part of X509v3 certificate chain validation). For each of the following tests the evaluator shall create a chain of at least two certificates: a self-signed root CA certificate and a leaf (node) certificate. The properties of the certificates in the chain are adjusted as described in each individual test below (and this modification shall be the only invalid aspect of the relevant certificate chain). Test 1: The evaluator shall ensure that at least one of the CAs in the chain does not contain the basicConstraints extension. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate without the basicConstraints extension to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). TD0228 has been applied

Test Flow

Connect to the TOE using a chain of certificates where one of the CAs does not contain the basicConstraints extension.



The TOE denies a connection when it cannot detect the basicConstraints extension.

Result Pass




Objective Test 2: The evaluator shall ensure that at least one of the CA certificates in the chain has a basicConstraints extension in which the CA flag is set to FALSE. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate with the CA flag set to FALSE to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). TD0228 has been applied

Test Flow

Present the TOE with a chain of certificates where one of the CAs contains the basicConstraints extensions set to true.

Verify the connection is successful.

108

Connect to the TOE using a chain of certificates where one of the CAs contains the basicConstraints extension set to false.



The TOE denies a connection when it detects a CA with the basicConstraints set to FALSE.

Result Pass

4.9.28 FIA_X509_EXT.1.1/Rev TSS 1

Objective: The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place, and that the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied). It is expected that revocation checking is performed when a certificate is used in an authentication step and when performing trusted updates (if selected). It is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). Evaluator Findings: The evaluator examined the TSS to determine where certificate validation occurs. The TSS entry for FIA_X509_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST states: “If you set it to Certificate Validation, you will enter this mode. To enter this mode, you must upload a CA certificate to use for client certificate verification and the latest CRL for that CA since all CRLs in the trusted certificate chain of the CA that issued the client’s certificate are checked. Checking is also done for the basicConstraints extension and the CA flag to determine whether they are present and set to TRUE. The certificate(s) that was imported must contain the basic constraints extension with the CA flag set to true, the check also ensures that the key usage extension is present, and the keyEncipherment bit or the keyAgreement bit or both are set. If they are not, the certificate is not accepted. Additional checking of the extendedKeyUsage field includes the server and client authentication.”


Verdict: Pass

4.9.29 FIA_X509_EXT.1.1/Rev Test 1


Test ID FIA_X509_EXT.1.1/Rev_T1

Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 1a: The evaluator shall present the TOE with a valid chain of certificates (terminating in a trusted CA certificate) as needed to validate the certificate to be used in the function, and shall use this chain to demonstrate that the function succeeds. Test 1b: The evaluator shall then delete one of the certificates in the presented chain (i.e. the root CA certificate or other intermediate certificate, but not the end-entity certificate), and show that an attempt to validate an incomplete chain fails.

109

Test Flow







Result Pass




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing.

Test Flow

Create an expired certificate.




The TOE does not allow a connection due to an expired certificate.

Result Pass




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-–conditional on whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the peer certificate and revocation of the peer intermediate CA certificate i.e. the intermediate CA certificate should be revoked by the root CA. The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails.

Test Flow

Attempt to validate an end entity certificate that is valid

Verify that the TOE recognizes it as valid while reaching out to the CRL

Revoke the certificate

Verify that the TOE recognizes the certificate as revoked

Repeat above steps with a CA


The TOE establishes a session when the certificate is valid. The TOE does not establish a session when the certificate has been revoked.

Result Pass

110




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.

Test Flow

Upload a certificate to the TOE

Configure the CRL server to use a certificate that doesn’t have the cRLsign key usage

Verify the CRL response is not accepted by the TOE


The TOE does not allow a connection to complete when it detects a CRL signed by a CA that does not contain the CRLsign key usage field. This meets testing requirements.

Result Pass




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.)

Test Flow

Connect to the TOE.

Modify any byte in the first eight bytes of the certificate.




Result Pass




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE.

111

Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.)

Test Flow

Connect to the TOE.

Modify any byte in the last byte of the certificate.




Result Pass




Objective The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The hash of the certificate will not validate.)

Test Flow

Connect to the TOE.

Modify any byte in the public key of the certificate.




Result Pass




Objective The goal of the following tests it to verify that the TOE accepts only certificates that have been marked as CA certificates by using basicConstraints with the CA flag set to True (and implicitly that the TOE correctly parses the basicConstraints extension as part of X509v3 certificate chain validation). For each of the following tests the evaluator shall create a chain of at least three certificates: a self-signed root CA certificate, an intermediate CA certificate and a leaf (node) certificate. The properties of the certificates in the chain are adjusted as described in each individual test below (and this modification shall be the only invalid aspect of the relevant certificate chain). Test 1: The evaluator shall ensure that at least one of the CAs in the chain does not contain the basicConstraints extension. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate without the basicConstraints extension to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). TD0228 has been applied

112

Test Flow

Connect to the TOE using a chain of certificates where one of the CAs does not contain the basicConstraints extension.



The TOE denies a connection when it cannot detect the basicConstraints extension.

Result Pass




Objective The goal of the following tests it to verify that the TOE accepts only certificates that have been marked as CA certificates by using basicConstraints with the CA flag set to True (and implicitly that the TOE correctly parses the basicConstraints extension as part of X509v3 certificate chain validation). For each of the following tests the evaluator shall create a chain of at least four certificates: a self-signed root CA certificate, two intermediate CA certificates, and a leaf (node) certificate. The properties of the certificates in the chain are adjusted as described in each individual test below (and this modification shall be the only invalid aspect of the relevant certificate chain). Test 2: The evaluator shall ensure that at least one of the CA certificates in the chain has a basicConstraints extension in which the CA flag is set to FALSE. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate with the CA flag set to FALSE to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains).TD0228 has been applied

Test Flow

Connect to the TOE using a chain of certificates where one of the CAs contains the basicConstraints extension in which the CA flag is set to false.



The TOE denies a connection when it detects a CA with the basicConstraints set to FALSE.

Result Pass

4.9.38 FIA_X509_EXT.2 TSS 1

Objective: 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 TSS to determine if it describes how the TOE chooses which certificates to use. The TSS entry for FIA_X509_EXT.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST and the section 2.2.3 titled ‘Certificates and Keys’ of AGD were used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes how the TOE chooses the certificates to use for communications. The TSS states the following:

“Certificate chains are uploaded to the TOE via the TOE GUI. Once a certificate is uploaded to the TOE, endpoints connecting to the TOE which are signed by the configured certificate chains may be used for

113

secure connections with the TOE. In the case where multiple certificate chains are configured on the TOE, the TOE compares peer presented endpoint certificates to each of the configured certificate chains to verify the validity of the certificate. If the presented certificate is not signed by any of the configured chains, the TOE will deny the configuration.”

Next, the evaluator examined the AGD in section 2.2.3 titled ‘Certificates and Keys’. The evaluator found that AGD discusses how to use certificates. Specifically, the referenced section, “Loading Certificates and Keys Onto Expressway” of “Cisco Expressway Certificate Creation and Use Deployment Guide” describes how to load and work with the certificates needed for connections. The environmental requirements for the TOE including everything necessary to use certificates with the TOE is described in the section titled “Supported non-TOE Hardware/ Software/ Firmware” in AGD.


Verdict: Pass

4.9.39 FIA_X509_EXT.2 TSS 2

Objective: The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. Evaluator Findings: The evaluator examined 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. The TSS entry for FIA_X509_EXT.2 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes how the TOE handles the validity of the peer certificate. Specifically, the TSS states that the TOE handles these scenarios, as follows: If a connection cannot be established with the trust point to verify the certificate validity, the TOE will continue to accept the certificate.”

The evaluator found that this behavior is applicable to the following connections,

HTTPS

TLS

Next, the evaluator examined AGD. The evaluator found that AGD described the expected behavior of the TOE when the validity of peer certificates cannot be determined.


Verdict: Pass

4.9.40 FIA_X509_EXT.2 Test #1


Test ID FIA_X509_EXT.2_T1

Objective The evaluator shall perform the following test for each trusted channel:

114

The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE IT entity. The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the guidance documentation to determine that all supported administrator-configurable options behave in their documented manner.

Test Flow

Configure a connection with a peer on the TOE

During session establishment ensure that the TOE cannot verify the validity of the peer certificate

Verify that the connection is allowed


The TOE allows the connection to proceed when the TOE cannot verify the validity of the peer certificate.

Result Pass

4.9.41 FIA_X509_EXT.3 TSS 1

Objective: If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests. Evaluator Findings: The ST does not select "device-specific information". Therefore, a description is not required.


Verdict: Pass

4.9.42 FIA_X509_EXT.3 Guidance 1

Objective: The evaluator shall check to ensure that the guidance documentation contains instructions on requesting certificates from a CA, including generation of a Certification Requests. If the ST author selects "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the Certification Request. TD0333 has been applied Evaluator Findings: The evaluator examined the guidance document to determine if instructions for requesting certificates from a CA are provided. Section 2.2.3 titled ‘Certificate and Keys’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD provides instructions for generating CSRs. The evaluator found that these instructions include the complete set of steps necessary to configure a fully formed CSR containing each of the fields described in FIA_X509_EXT.3. Finally, the evaluator found that AGD provides instructions for generating CSRs from the CLI. Based on these findings, this assurance activity is considered satisfied. Verdict: Pass

4.9.43 FIA_X509_EXT.3 Test #1


115

Test ID FIA_X509_EXT.3_1

Objective Test 1: The evaluator shall use the guidance documentation to cause the TOE to generate a Certification Request. The evaluator shall capture the generated request and ensure that it conforms to the format specified. The evaluator shall confirm that the Certification Request provides the public key and other required information, including any necessary user-input information. TD0333 has been applied

Test Flow

Generate a CSR on the TOE.

Verify the CSR contains the following: Common Name, Organization, Organizational Unit, Country


The TOE generates a CSR that contains all the claimed contents.

Result Pass

4.9.44 FIA_X509_EXT.3 Test #2


Test ID FIA_X509_EXT.3_T2

Objective Test 2: The evaluator shall demonstrate that validating a response message to a Certification Request without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the response message, and demonstrate that the function succeeds. TD0333 has been applied

Test Flow

Generate a CSR request on the TOE.

Sign the CSR with an external CA and ensure the full trust chain is not present on the TOE.

Verify the TOE rejects loading the signed certificate due to the missing trust chain.

Add the missing intermediate CA to the TOE’s certificate store.

Verify the TOE accepts the signed certificate because the path validation succeeded.


The TOE does not accept a signed certificate when the chain is not present.

Result Pass

4.10 Test Cases (Security Management)

4.10.1 FMT_MOF.1/ManualUpdate Guidance 1

Objective: The evaluator shall examine the guidance documentation to determine that any necessary steps to perform manual update are described. The guidance documentation shall also provide warnings regarding functions that may cease to operate during the update (if applicable). Evaluator Findings: The evaluator examined the AGD “to determine that any necessary steps to perform manual update are described. The AGD section 3.3 titled, ‘Product Updates’ was used to determine the verdict of this activity. Upon investigation, the evaluator found that section 2 and 3.3 describe the process of manually updating the software on the TOE.

116


Verdict: Pass

4.10.2 FMT_MOF.1/ManualUpdate Test #1


Test ID FMT_MOF.1/ManualUpdate_T1

Objective The evaluator shall try to perform the update using a legitimate update image without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all – depending on the configuration of the TOE). The attempt to update the TOE shall fail.

Test Flow

Verify that there is a user with a lower privilege level

Attempt to login to the TOE as this user

Verify that this user cannot update the TOE due to their lower privilege


The TOE does not allow a user with a lower privilege level to update the TOE.

Result Pass

4.10.3 FMT_MOF.1/ManualUpdate Test #2


Test ID FMT_MOF.1/ManualUpdate_T2

Objective The evaluator shall try to perform the update with prior authentication as security administrator using a legitimate update image. This attempt should be successful. This test case should be covered by the tests for FPT_TUD_EXT.1 already.

Test Flow

Login to the TOE as a super user

Attempt to update the TOE with a software image

Verify that the TOE accepts the update due to a privileged user executing this action


The TOE allows a super user to update the TOE.

Result Pass

4.10.4 FMT_MTD.1/CoreData TSS 1

Objective: The evaluator shall examine the TSS to determine that, for each administrative function identified in the operational guidance; those that are accessible through an interface prior to administrator log-in are identified. For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users. Evaluator Findings: The evaluator examined the TSS to determine what administrative functions are accessible prior to administrator log-in. The TSS entry for FMT_MTD.1/CoreDatain section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS states “The TOE provides the ability for Authorized Administrators to access TOE data, such as audit data, configuration data, security attributes and login banners via the GUI. The term “Authorized Administrator” is used in this ST to refer to any user which is permitted to perform the relevant action.”

117


Verdict: Pass

4.10.5 FMT_MTD.1/CoreData Guidance 1

Objective: The evaluator shall review the operational guidance to determine that each of the TSF-data-manipulating functions implemented in response to the requirements of this PP is identified, and that configuration information is provided to ensure that only administrators have access to the functions. Evaluator Findings: The evaluator examined the operational guidance to determine if configuration information is provided to ensure that only administrators have access to TSF-data manipulating functions. Section 3 titled ‘Secure Management’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD describes how administrative users can configure the TSF-data manipulating functions for the TOE. The evaluator found that the configuration of the following functionality is described within AGD,

Audit data – section 3

Configuration data - section 3

Security attributes – section 2 & 5

Login banners – section 4.1

The evaluator found that this encompasses all the TSF-data manipulating functionality required by the NDcPP.


Verdict: Pass

4.10.6 FMT_MTD.1/CryptoKeys Test #1


Test ID FMT_MTD.1/CryptoKeys_T1

Objective The evaluator shall try to perform at least one of the related actions (modify, delete, generate/import) without prior authentication as security administrator (either by authentication as a non-administrative user, if supported, or without authentication at all). Attempts to perform related actions without prior authentication should fail. According to the implementation no other users than the Security Administrator might be defined and without any user authentication the user might not be able to get to the point where the attempt to manage cryptographic keys can be executed. In that case it shall be demonstrated that access control mechanisms prevent execution up to the step that can be reached without authentication as Security Administrator.

Test Flow

Attempt a crypto function without authenticating

Verify the attempt fails


The TOE did not allow a non-administrative user to make changes.

Result Pass

4.10.7 FMT_MTD.1/CryptoKeys Test #2


118

Test ID FMT_MTD.1/CryptoKeys_T2

Objective The evaluator shall try to perform at least one of the related actions with prior authentication as security administrator. This attempt should be successful.

Test Flow

Enter enable password for full authentication

Attempt a crypto function after authenticating

Verify the attempt succeeds


The TOE does allow changes to the configuration once the user has authenticated as a security administrator.

Result Pass

4.10.8 FMT_SMF.1

Objective: The evaluator shall examine the TSS and Guidance Documentation to verify they both Describe the local administrative interface. The evaluator shall ensure the Guidance Documentation includes appropriate warnings for the administrator to ensure the interface is local. The evaluator shall examine the TSS, Guidance Documentation and the TOE as observed during all other testing and shall confirm that the management functions specified in FMT_SMF.1 are provided by the TOE. The evaluator shall confirm that the TSS details which security management functions are available through which interface(s) (local administration interface, remote administration interface). TD0408 has been applied Evaluator Findings: The evaluator examined the TSS, Guidance Documentation and the TOE as observed during all other testing and shall confirm that the management functions specified in FMT_SMF.1 are provided by the TOE. The ST, AGD, and TOE itself was used to determine the verdict of this activity. Upon investigation, the evaluator found that following management activities,

Local and remote administration of the TOE and the services provided by the TOE via the TOE GUI as described above;

The ability to configure a notice and consent warning banner that is displayed prior to logging on the TOE;

The ability to configure inactivity session time periods;

The ability to update the TOE software (using published hash comparisons)

The ability to configure the authentication failure parameters

The ability to configure the auditing capabilities and the secure transmission of the logs to a remote syslog server

The ability to configure the cryptographic functionality

The ability to configure the communications and interactions between TOE components,

The ability to manage and change user passwords and The evaluator confirmed that each of the functionalities were available and described in the ST/TSS, AGD, and on the TOE itself. Based on these findings, this assurance activity is considered satisfied. Note: The security management functions for FMT_SMF.1 are distributed throughout the cPP and are included as part of the requirements in FTA_SSL_EXT.1, FTA_SSL.3, FTA_TAB.1, FMT_MOF.1/ManualUpdate, FMT_MOF.1/AutoUpdate (if included in the ST), FIA_AFL.1, FIA_X509_EXT.2.2 (if included in the ST), FPT_TUD_EXT.1.2 & FPT_TUD_EXT.2.2 (if included in the ST and if they include an administrator-configurable action), FMT_MOF.1/Services, and FMT_MOF.1/Functions (for all of these SFRs that are included in the ST), FMT_MTD, FPT_TST_EXT, and any cryptographic

119

management functions specified in the reference standards. Compliance to these requirements satisfies compliance with FMT_SMF.1. Verdict: Pass

4.10.9 FMT_SMF.1 Test #1


Test ID FMT_SMF.1_T1

Objective The evaluator tests management functions as part of testing the SFRs identified in section 2.4.4. No separate testing for FMT_SMF.1 is required unless one of the management functions in FMT_SMF.1.1 has not already been exercised under any other SFR.

Test Flow All management functions have been tested as part of this evaluation.


The evaluator has met this requirement through execution of the entirety of this test report for the TOE interfaces. This test has passed.

Result Pass

4.10.10 FMT_SMR.2 Guidance 1

Objective: The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration. Evaluator Findings: The evaluator examined the operational guidance to determine if instructions for administering the TOE locally and remotely are included. The sections 2.2.1 ‘Licenses and Release Keys’ and 2.2.4 ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD describes the configuration necessary to administer the TOE from a variety of interfaces, as follows,

Via console

Via remote GUI over HTTPS/TLS

For remote administration, the evaluator found that AGD describes all configurations necessary to connect to the TOE.


Verdict: Pass

4.10.11 FMT_SMR.2 Test #1


Test ID FMT_SMR.2_T2

Objective In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this cPP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities.

Test Flow All management functions have been tested as part of this evaluation.

120


The evaluator has met this requirement through execution of the entirety of this test report for the TOE interfaces. This test has passed.

Result Pass

4.11 Test Cases (Protection of the TSF)

4.11.1 FPT_SKP_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how they are protected/obscured. Evaluator Findings: The evaluator examined the TSS to determine that it details how any pre-shared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. The TSS entry for FPT_SKP_EXT.1 in the section titled section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST of ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes the methods keys are store within the TOE. The methods described in the TSS include the following,

The TOE stores all private keys in a secure directory that is not readily accessible to administrators

Additionally, the TSS describes that there are not administrative interfaces available that would allow a key to be viewed. Finally, the evaluator found that the TSS states that the key is store in plaintext in a protected directory.


Verdict: Pass

4.11.2 FPT_APW_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored. Evaluator Findings: The TSS entry for FPT_APW_EXT.1 section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST states that “The TOE also ensures that passwords will not be stored in plaintext. The Administrator passwords are stored in a database where the password is encrypted before being stored.”


Verdict: Pass

121

4.11.3 FPT_APW_EXT.1 TSS 2

Objective: The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. Evaluator Findings: The evaluator examined the TSS to determine if passwords are store in such a way that they are unable to be viewed through an interface designed specifically for that purpose. The TSS entry for FPT_APW_EXT.1 section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS explicitly states that the “The TOE also ensures that passwords will not be stored in plaintext. The Administrator passwords are stored in a database where the password is encrypted before being stored.”


Verdict: Pass

4.11.4 FPT_ITT.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that, for all communications between components of a distributed TOE, each communications mechanism is identified in terms of the allowed protocols for that IT entity. The evaluator shall also confirm that all protocols listed in the TSS for these inter-component communications are specified and included in the requirements in the ST. Evaluator Findings:


Verdict: Pass

4.11.5 FPT_ITT.1 Guidance 1

Objective: The evaluator shall confirm that the guidance documentation contains instructions for establishing the relevant allowed communication channels and protocols between each pair of authorized TOE components, and that it contains recovery instructions should a connection be unintentionally broken. Evaluator Findings: The evaluator confirmed that the guidance documentation in section 2.2 ‘Initial Setup of Cisco Expressway’ and 2.3 ‘MRA’ contains instructions for establishing the relevant allowed communication channels and protocols between each pair of authorized TOE components, and that it contains recovery instructions should a connection be unintentionally broken.


Verdict: Pass

4.11.6 FPT_ITT.1 Test #1


Test ID FPT _ITT.1_T1

Objective Test 1: The evaluator shall ensure that communications using each protocol between each pair of authorized TOE components is tested during the course of the evaluation,

122

setting up the connections as described in the guidance documentation and ensuring that communication is successful.

Test Flow

Configure the TOE components to communicate with one another

Initiate the connection between the components

Perform a packet capture of the traffic between components



Communications are successful using the specified protocols between each pair of authorized TOE components.

Result Pass

4.11.7 FPT _ITT.1 Test #2



Objective Test 2: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext.

Test Flow

Configure the TOE to connect with an authorized IT entity

Initiate the connection between the TOE and the IT entity

Perform a packet capture of the traffic between the TOE and the IT entity



The TOE does not send traffic between the TOE and IT entity in plaintext.

Result Pass

4.11.8 FPT _ITT.1 Test #3



Objective c) Test 3: Objective: The objective of this test is to ensure that the TOE reacts appropriately to any connection outage or interruption of the route between distributed components. The evaluator shall ensure that, for each different pair of non-equivalent component types, the connection is physically interrupted for the following durations: i) a duration that exceeds the TOE’s application layer timeout setting, ii) a duration that is shorter than the application layer timeout but is of sufficient length to interrupt the MAC layer. The evaluator shall ensure that when physical connectivity is restored, either communications are appropriately protected, or the secure channel is terminated and the registration process (as described in the FTP_TRP.1/Join) re-initiated, with the TOE generating adequate warnings to alert the administrator. In the case that the TOE is able to detect when the cable is removed from the device, another physical network device (e.g. a core switch) shall be used to interrupt the connection between the components. The interruption shall not be performed at the virtual node (e.g. virtual switch) and must be physical in nature.

Test Flow





Disconnect the remote entity from the network

From the TOE, continue to send data

123

Verify that the data sent from the TOE is not sent plaintext

Reconnect the remote entity to the network




The TOE should handle secure traffic properly.

Result Pass

4.11.9 FPT_STM_EXT.1 TSS 1

Objective: The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time, and that it provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. Evaluator Findings: The evaluator examined the TSS to determine if each security function that makes use of time. The TSS entry for FPT_APW_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS states “The TOE synchronizes with an NTP server for its reliable and accurate timestamp. The TOE can be configured to support up to five (5) NTP servers. The TOE supports NTPv4 and validates the integrity of the time-source using SHA1 symmetric key authentication. In addition, the TOE does not allow the timestamp to be updated from broadcast addresses. Expressway maintains its system time in UTC (Coordinated Universal Time) as does NTP to synchronize computer clock times to a millisecond, and sometimes to a fraction of a millisecond.” The TSS goes into further detail to list the NTP status information shown in the Status area and includes the following information that is also considered as audit logs:

Starting: the NTP service is starting.

Synchronized: the Expressway has successfully obtained accurate system time from an NTP server

Unsynchronized: the Expressway is unable to obtain accurate system time from an NTP server

Down: the Expressway's NTP client is not running

Reject: the NTP service is not accepting NTP responses

Offset: the difference between the NTP server's time and the Expressway's time

Next, the evaluator reviewed the TSS and found that the TSS describes the method for maintaining time on the TOE. Finally, the evaluator reviewed the TSS and found that a rationale is provided regarding why the time is considered reliable.


Verdict: Pass

4.11.10 FPT_STM_EXT.1 Guidance 1

Objective: The evaluator examines the guidance documentation to ensure it instructs the administrator how to set the time. If the TOE supports the use of an NTP server, the guidance documentation instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication.

124

Evaluator Findings: The evaluator examined the guidance document to determine if it instructs administrators how to set the time. The section 3.2 titled ‘Clock Management’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD describes the method for configuring NTP communications on the TOE. AGD provides instructions for configuring NTP communications via CLI and GUI.


Verdict: Pass

4.11.11 FPT_STM_EXT.1 Test #1


Test ID FPT_STM_EXT.1.1_T1

Objective Test 1: If the TOE supports direct setting of the time by the Security Administrator then the evaluator uses the guidance documentation to set the time. The evaluator shall then use an available interface to observe that the time was set correctly.

Test Flow Not applicable as the TOE does not support the direct setting of time.


Not applicable as the TOE does not support the direct setting of time.

Result Not applicable as the TOE does not support the direct setting of time.

4.11.12 FPT_STM_EXT.1 Test #2


Test ID FPT_STM_EXT.1.1_T2

Objective Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance documentation to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol claimed in the guidance documentation.

Test Flow

Manually set the system time to an incorrect value.

Follow the guidance documentation to enable NTP synchronization

Synchronize with an NTP server and observe that the system time is set to the current time.


The TOE enforces the configure inactivity period for local connections.

Result Pass

4.11.13 FPT_TST_EXT.1.1 TSS 1

Objective: 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). Evaluator Findings: The evaluator examined the TSS to determine if it details the self-tests that are run by the TSF on start-up. The TSS entry for FPT_TST_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity.

125

Upon investigation, the evaluator found that the TSS states that the following self-test are run by the TOE,

Power-on Self-Tests

Additionally, the evaluator found that the descriptions of the test provide details of what the tests are doing (rather than a broad generalization of the test).


Verdict: Pass

4.11.14 FPT_TST_EXT.1.1 TSS 2

Objective: The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. Evaluator Findings: The evaluator examined the TSS to determine if it makes an argument for why the tests are sufficient to demonstrate that the TSF is operating correctly. The TSS entry for FPT_TST_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS provides an argument that the included self-tests sufficiently demonstrate that the TSF is operating correctly. The TSS states “The TOE runs a suite of self-test during initial start-up to verify its correct operation. These tests are sufficient to verify that the correct version of the TOE software is running as well as that the cryptographic operations are all performing as expected. The TOE also runs a periodic continuous random number generator health test, which will also be run any time a request for entropy is made by the application. If any of the tests fail, the TOE will not boot, and the Authorized Administrator is instructed to contact Cisco Technical Assistance Center (TAC). During the system bootup process (power on or reboot), all the Power on Startup Test (POST) components for all the cryptographic modules perform the POST for the corresponding component (hardware or software). In addition the TSS states “Prior to installing the image, the Authorized Administrator can verify the public hash to ensure the files has not been tampered with prior to installing. In addition, the Software Integrity Test is run automatically whenever the IOS system images is loaded and confirms that the image file that’s about to be loaded has maintained its integrity. The tests are run on all components of the TOE to ensure correct operation of the TOE.”


Verdict: Pass

4.11.15 FPT_TST_EXT.1.1 Guidance 1

Objective: The evaluator shall also ensure that the operational guidance describes the possible errors that may result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS. Evaluator Findings: The evaluator examined the operational guidance to determine if it describes the possible errors that may result from self-test failures. The section 2.2.2 titled ‘Enabling FIPS Mode’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that states “If the file image that includes the cryptographic module (FOM), checksums or

126

certificate signatures were tampered with or modified in anyway, the installation would halt or if an error in the cryptographic module (FOM) a log message to indicate FIPS POST failure will be logged and the TOE will reboot at which time the Administrator will need to call Cisco TAC to obtaining technical assistance. If all the checks of the image software passes, to include the cryptographic module (FOM), there will be no log message other than to indicate that the POST started and POST finished and the Administrator will be presented with the logon prompt.”

Additionally, the evaluator found that the behavior of the TOE an any required administrative actions are also described in AGD.


Verdict: Pass

4.11.16 FPT_TST_EXT.1.1 Test #1


Test ID FPT_TST_EXT.1.1_T1

Objective It is expected that at least the following tests are performed: a) Verification of the integrity of the firmware and executable software of the TOE b) Verification of the correct operation of the cryptographic functions necessary to fulfil any of the SFRs. The evaluator shall either verify that the self-tests described above are carried out during initial start-up or that the developer has justified any deviation from this. For distributed TOEs the evaluator shall perform testing of self-tests on all TOE components according to the description in the TSS about which self-test are performed by which component.

Test Flow

Power on the TOE

Observer the output of the TOE upon start up

Pass/Fail Explanation The TOE performs the required self-tests.

Result Pass

4.11.17 FPT_TUD_EXT.1 TSS 1

Objective: The evaluator shall verify that the TSS describe how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe how and when the inactive version becomes active. The evaluator shall verify this description. Evaluator Findings: The evaluator reviewed section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST to determine the verdict of this requirement. In entry for FPT_TUD_EXT.1, Table 18 the evaluator found that “The Authorized Administrator can query the software version running on the TOE by accessing the Administration web page that displays the system version and can initiate updates to (replacements of) software images. When software updates are made available by Cisco, an administrator can obtain, verify the integrity of, and install those updates. The updates can be downloaded from Cisco.com website. The image verification, a SHA-512 hash is used to verify software/firmware update file to make sure it has not been modified from the originals distributed by Cisco before they are used to actually update the TOE. Once the Authorized Administrator has verified the TOE image, the Authorized Administrator can install the file on the TOE after they have logged in and have been successfully identified and authenticated.

127

If the verification of the image files fails, the Authorized Administrator is instructed to contact Cisco Technical Assistance Center (TAC). For full details on downloading and installing the TOE software, refer to the Cisco Expressway X12.5 System Common Criteria Operational User Guidance And Preparative Procedures.”


Verdict: Pass

4.11.18 FPT_TUD_EXT.1 TSS 2

Objective: The evaluator shall verify that the TSS describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. Alternatively, an approach using a published hash can be used. In this case the TSS shall detail this mechanism instead of the digital signature verification mechanism. The evaluator shall verify that the TSS describes the method by which the digital signature or published hash is verified to include how the candidate updates are obtained, the processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification. Evaluator Findings: The evaluator verified that the TSS describes all TSF software update mechanisms for updating the system software. The TSS entry for FPT_TUD_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes the software update mechanism of the TOE. The TSS states that the TOE uses a SHA-512 hash to verify the integrity of software updates. The evaluator also found that the TSS describes the behavior of the TOE if the integrity test over the software update fails. Specifically, the TSS states “If the verification of the image files fails, the Authorized Administrator is instructed to contact Cisco Technical Assistance Center (TAC).” Finally, the evaluator verified that the TSS describes the method that software updates are obtained by the administrative user of the TOE.


Verdict: Pass

4.11.19 FPT_TUD_EXT.1 Guidance 1

Objective: The evaluator shall verify that the guidance documentation describes how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the guidance documentation needs to describe how to query the loaded but inactive version. Evaluator Findings: The evaluator verified that the guidance documentation describes how to query the currently active version. Section 1.7 ‘Secure Acceptance of the TOE’ was used to determine the verdict of this activity. Upon investigation, the evaluator found that step 7 of section 2 of the AGD states “To verify the software version and to register the license, from a PC in your network that has been installed with one of the supported browsers, browse into a server that is running Cisco Expressway Administration and log in with administrative privileges. Follow the instructions in [4] Overview and Status Information->System Information. Log on from the Cisco Unified

128

Operating System Administration window, the System information page (Status -> System -> Information) and review the fields in the Systems information page. For installing in a virtual environment, follow the instructions in [3] Introduction ->Installing a Virtual Machine and Ordering and Entering Release and Option Keys. See Table 7 below for the details that must be checked to ensure the software has not been modified in anyway.


Verdict: Pass

4.11.20 FPT_TUD_EXT.1 Guidance 2

Objective: The evaluator shall verify that the guidance documentation describes how the verification of the authenticity of the update is performed (digital signature verification or verification of published hash). The description shall include the procedures for successful and unsuccessful verification. The description shall correspond to the description in the TSS. Evaluator Findings: The evaluator examined the guidance documentation to determine if it describes how the verification of the authenticity of updates is performed. The section 3.3 titled ‘Product Updates‘ of AGD was used to determine the verdict of this assurance activity. Upon investigation the evaluator found that AGD describe the software update procedures for the TOE. These procedures include a description of the determination of a successful or unsuccessful verification. Finally, the evaluator compared the description in AGD to the description found in the TSS of ST. The evaluator found that the descriptions were consistent.


Verdict: Pass

4.11.21 FPT_TUD_EXT.1 Test #1


Test ID FPT_TUD_EXT.1_T1

Objective The evaluator performs the version verification activity to determine the current version of the product as well as the most recently installed version (should be the same version before updating). The evaluator obtains a legitimate update using procedures described in the guidance documentation and verifies that it is successfully installed on the TOE. For some TOEs loading the update onto the TOE and activation of the update are separate steps (‘activation’ could be performed e.g. by a distinct activation step or by rebooting the device). In that case the evaluator verifies after loading the update onto the TOE but before activation of the update that the current version of the product did not change but the most recently installed version has changed to the new product version. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again.

Test Flow

Verify the current version of the TOE

Perform the image update

Verify the new version of the TOE

The version should now be the new software version


After executing an update, the TOE reflects the new software version.

129

Result Pass

4.11.22 FPT_TUD_EXT.1 Test #3a


Test ID FPT_TUD_EXT.1_T3a

Objective Test 3 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security Administrator and the verification of the hash value over the update file(s) against the published hash is performed by the TOE, then the evaluator shall perform the following tests. The evaluator first confirms that no update is pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. 1) The evaluator obtains or produces an illegitimate update such that the hash of the update does not match the published hash. The evaluator provides the published hash value to the TOE and calculates the hash of the update either on the TOE itself (if that functionality is provided by the TOE), or else outside the TOE. The evaluator confirms that the hash values are different, and attempts to install the update on the TOE, verifying that this fails because of the difference in hash values (and that the failure is logged). Depending on the implementation of the TOE, the TOE might not allow the user to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE For distributed TOEs the evaluator shall perform Test 1, Test 2 and Test 3 (if applicable) for all TOE components.

Test Flow

Verification of the hash value over the update file(s) against the published hash is not performed by the TOE, but by the administrator. Therefore, this is not applicable.

Pass/Fail Explanation Verification of the hash value over the update file(s) against the published hash is not performed by the TOE, but by the administrator. Therefore, this is not applicable.

Result Verification of the hash value over the update file(s) against the published hash is not performed by the TOE, but by the administrator. Therefore, this is not applicable.

4.11.23 FPT_TUD_EXT.1 Test #3b


Test ID FPT_TUD_EXT.1_T3b

Objective Test 3 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security Administrator and the verification of the hash value over the update file(s) against the published hash is performed by the TOE, then the evaluator shall perform the following tests. The evaluator first confirms that no update is pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. 2) The evaluator uses a legitimate update and tries to perform verification of the hash value without storing the published hash value on the TOE. The evaluator confirms that this attempt fails. Depending on the implementation of the TOE it might not be possible to attempt the verification of the hash value without providing a hash value to the TOE, e.g. if the hash value needs to be handed over to the TOE as a parameter in a command line message and the syntax check of the command prevents the execution of the command without providing a hash value. In that case the mechanism that prevents the execution of this check shall be tested accordingly, e.g.

130

that the syntax check rejects the command without providing a hash value, and the rejection of the attempt is regarded as sufficient verification of the correct behaviour of the TOE in failing to verify the hash. The evaluator then attempts to install the update on the TOE (in spite of the unsuccessful hash verification) and confirms that this fails. Depending on the implementation of the TOE, the TOE might not allow to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE For distributed TOEs the evaluator shall perform Test 1, Test 2 and Test 3 (if applicable) for all TOE components.

Test Flow




4.11.24 FPT_TUD_EXT.1 Test #3c


Test ID FPT_TUD_EXT.1_T3c

Objective Test 3 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security Administrator and the verification of the hash value over the update file(s) against the published hash is performed by the TOE, then the evaluator shall perform the following tests. The evaluator first confirms that no update is pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. 3) If the TOE allows delayed activation of updates, the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs. Depending on the point in time when the attempted update is rejected, the most recently installed version might or might not be updated. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt. For distributed TOEs the evaluator shall perform Test 1, Test 2 and Test 3 (if applicable) for all TOE components.

Test Flow




131

4.12 Test Cases (TOE Access)

4.12.1 FTA_SSL_EXT.1 Test #1


Test ID FTA_SSL_EXT.1.1_T1

Objective The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the evaluator then ensures that reauthentication is needed when trying to unlock the session.

Test Flow

Configure a local time out period of 1 minute on administrative sessions

Connect to the TOE from the local connection

Let the local connection set idle for 1 minutes

Verify that the session was terminated

Configure a local time out period of 3 minutes on administrative sessions

Connect to the TOE from the local connection

Let the local connection set idle for 3 minutes

Verify that the session was terminated

Pass/Fail Explanation The TOE enforces the configure inactivity period for local connections.

Result Pass

4.12.2 FTA_SSL_EXT.1/FTA_SSL.3 Guidance 1

Objective: The evaluator shall confirm that the guidance documentation includes instructions for configuring the inactivity time period for remote administrative session termination. TD0425 has been applied Evaluator Findings: The evaluator confirmed that the guidance documentation states whether local administrative session locking or termination is supported and instructions for configuring the inactivity time period. The section 2.2.4 titled ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. The AGD describes instructions which the Authorized Administrator can configure for inactivity time period for remote administrative session termination within the line items in section 2.2.4.


Verdict: Pass

4.12.3 FTA_SSL.3 Test #1


Test ID FTA_SSL.3.1_T1

Objective The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period.

Test Flow

Configure a remote time out period of 2 minutes

Verify the session is terminated after the configured time period.

132

Configure a remote time out period of 1 minute

Verify the session is terminated after the configured time period.

Pass/Fail Explanation The TOE enforces the configure inactivity period for each instance.

Result Pass

4.12.4 FTA_SSL.4 Guidance 1

Objective: The evaluator shall confirm that the guidance documentation states how to terminate a local or remote interactive session. Evaluator Findings: The evaluator confirmed that the guidance documentation states how to terminate a local or remote interactive session. Section 2.2.4 titled, ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this activity. Upon investigation section 3.2.4 states: “Terminating an administrator session. An administrator may close their own web interface session by clicking the Logout link in the upper right corner of the screen. An administrator may close their CLI session by typing exit and clicking enter.” The evaluator found that this is the method used for terminating a session as well CLI (remote and local) usages defined.


Verdict: Pass




Objective The evaluator initiates an interactive local session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated.

Test Flow

Log onto the TOE through a directly connected interface

Using the instructions provided by the user guide, log off of the TOE

Pass/Fail Explanation The TOE permits a user to log on and log off a local session.

Result Pass




Objective The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated.

Test Flow

Log onto the TOE through each remote interface type.

Using the instructions provided by the user guide, log off the TOE.

Pass/Fail Explanation The TOE allows the user to terminate the remote administrative session.

Result Pass

4.12.7 FTA_TAB.1 TSS 1

Objective: The evaluator shall check the TSS to ensure that it details each administrative method of access (local and remote) available to the Security Administrator (e.g., serial port, SSH, HTTPS). The

133

evaluator shall check the TSS to ensure that all administrative methods of access available to the Security Administrator are listed and that the TSS states that the TOE is displaying an advisory notice and a consent warning message for each administrative method of access. The advisory notice and the consent warning message might be different for different administrative methods of access, and might be configured during initial configuration (e.g. via configuration file)." TD0338 has been applied. Evaluator Findings: The evaluator examined the TSS to determine if it details each method of access available to the administrator. The TSS entry for FTA_TAB_EXT.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that each of the methods to access the TOE are described in the TSS. Specifically, the evaluator found that the TSS states “The Authorized administrator can define a custom login banner that will be displayed on the GUI management interface and the local console interface prior to allowing any administrative access to the TOE. This is applicable for both local and remote TOE administration.”


Verdict: Pass

4.12.8 FTA_TAB.1 Guidance 1

Objective: The evaluator shall check the guidance documentation to ensure that it describes how to configure the banner message. Evaluator Findings: The evaluator checked the guidance documentation to ensure that it describes how to configure the banner message. Under section 3.1 ‘Login Banners’ of the AGD, a privileged administrator can configure the login message with CLI or GUI. In order to configure this the AGD states, “To set the welcome message title and message, navigate to the System > Login page >Login page configuration page. Refer to Network and System Settings > Network Services > Configure the Login Page [4].


Verdict: Pass

4.12.9 FTA_TAB.1 Test #1


Test ID FTA_TAB.1_T1

Objective The evaluator follows the guidance documentation to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance.

Test Flow

Configure an access banner for each administrative interface

Log into the TOE via each administrative interface

Verify that the administrative access banner is displayed


An access banner can be set for all the methods that can be used to access the device.

Result Pass

134

4.13 Test Cases (Trusted Path/Channels)

4.13.1 FTP_ITC.1 TSS 1

Objective: The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each secure communication mechanism is identified in terms of the allowed protocols for that IT entity, whether the TOE acts as a server or a client, and the method of assured identification of the non-TSF endpoint. The evaluator shall also confirm that all secure communication mechanisms are described in sufficient detail to allow the evaluator to match them to the cryptographic protocol Security Functional Requirements listed in the ST. TD0290 has been applied Evaluator Findings: The evaluator examined the TSS to determine if communications mechanisms are identified for all communications with authorized IT entities. The TSS entry for FTP_ITC.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS identifies connections with the following authorized IT entities,

Audit server

NTP server

Expressway C

Expressway E

Next, the evaluator verified that for each communication identified in the TSS that a description of the secure communication mechanism is provided. Specifically, the evaluator found that “The TOE protects communications between the TOE and the remote audit server using TLS that provides a secure channel to transmit the log events, supports NTPv4 for the connection to the NTP server and SSHv2 between Expressway C and Expressway E.”


Verdict: Pass

4.13.2 FTP_ITC.1 TSS 2

Objective: The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. Evaluator Findings: The evaluator examined the TSS to determine if all listed protocols in the TSS are included in the ST requirements. The definition of FPT_ITC.1 and TSS entry for FTP_ITC.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this assurance activity. First, the evaluator reviewed the TSS of ST to identify the protocols described for remote communications. Upon investigation, the evaluator found that the TSS states, “The TOE protects communications between the TOE and the remote audit server using TLS that provides a secure channel to transmit the log events, supports NTPv4 for the connection to the NTP server and SSHv2 between Expressway C and Expressway E.” Next, the evaluator compared the list identified in the TSS to the definition of the SFR in ST. The evaluator found the identified protocols to be consistent.

135


Verdict: Pass

4.13.3 FTP_ITC.1 Guidance 1

Objective: The evaluator shall confirm that the operational guidance contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally broken. Evaluator Findings: The evaluator examined the operational guidance to determine if it contains instructions for establishing allowed protocols with each authorized IT entity. Section 2.2 ‘Initial Setup of Cisco Expressway‘, section 2.3 ‘MRA’ and section 3 ‘Secure Management’: subsection 3.2 ‘Clock Management’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD provide configuration instruction for configuring connections with each authorized IT entity. Specifically, the evaluator found that AGD provides guidance for configuring connections with the following authorized IT entities,

Audit server

NTP server

Expressway C

Expressway E

Next, the evaluator reviewed AGD and found that for each connection a description of how to recover from unintentional disconnections.


Verdict: Pass

4.13.4 FTP_ITC.1 Test #1


Test ID FTP_ITC.1_T1

Objective The vendor shall provide to the evaluator application layer configuration settings for all secure communication mechanisms specified by the FTP_ITC.1 requirement. This information should be sufficiently detailed to allow the evaluator to determine the application layer timeout settings for each cryptographic protocol. There is no expectation that this information must be recorded in any public-facing document or report.

Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful.

For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of external secure channels to TOE components in the Security Target.

Test Flow





136



Result Pass




Objective The vendor shall provide to the evaluator application layer configuration settings for all secure communication mechanisms specified by the FTP_ITC.1 requirement. This information should be sufficiently detailed to allow the evaluator to determine the application layer timeout settings for each cryptographic protocol. There is no expectation that this information must be recorded in any public-facing document or report. Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the guidance documentation to ensure that in fact the communication channel can be initiated from the TOE. For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of external secure channels to TOE components in the Security Target.

Test Flow






The TOE successful initiate a connection to an IT entity.

Result Pass




Objective The vendor shall provide to the evaluator application layer configuration settings for all secure communication mechanisms specified by the FTP_ITC.1 requirement. This information should be sufficiently detailed to allow the evaluator to determine the application layer timeout settings for each cryptographic protocol. There is no expectation that this information must be recorded in any public-facing document or report. Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of external secure channels to TOE components in the Security Target.

Test Flow







Result Pass

137




Objective Test 4: Objective: The objective of this test is to ensure that the TOE reacts appropriately to any connection outage or interruption of the route to the external IT entities. The evaluator shall, for each instance where the TOE acts as a client utilizing a secure communication mechanism with a distinct IT entity, physically interrupt the connection of that IT entity for the following durations: i) a duration that exceeds the TOE’s application layer timeout setting, ii) a duration shorter than the application layer timeout but of sufficient length to interrupt the MAC layer. The evaluator shall ensure that, when the physical connectivity is restored, communications are appropriately protected and no TSF data is sent in plaintext. In the case where the TOE is able to detect when the cable is removed from the device, another physical network device (e.g. a core switch) shall be used to interrupt the connection between the TOE and the distinct IT entity. The interruption shall not be performed at the virtual node (e.g. virtual switch) and must be physical in nature. For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of external secure channels to TOE components in the Security Target. TD0290 has been applied

Test Flow





Disconnect the remote entity from the network



Reconnect the remote entity to the network




The TOE handles secure traffic properly.

Result Pass

4.13.8 FTP_ITC.1(2)

Objective: This SFR is an iteration of FTP_ITC.1 as defined in the NDcPP. The evaluator shall repeat the assurance activities defined for FTP_ITC.1 in the NDcPP for this iteration of the SFR. Evaluator Findings: This assurance activity has been addressed in FTP_ITC.1 above.


Verdict: Pass

138

4.13.9 FTP_ITC.1(3)

Objective: This SFR is an iteration of FTP_ITC.1 as defined in the NDcPP. The evaluator shall repeat the assurance activities defined for FTP_ITC.1 in the NDcPP for this iteration of the SFR. Evaluator Findings: This assurance activity has been addressed in FTP_ITC.1 above. Based on these findings, this assurance activity is considered satisfied. Verdict: Pass

4.13.10 FTP_TRP.1/Admin TSS 1

Objective: The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. Evaluator Findings: The evaluator examined the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. The FTP_TRP.1 entry in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST was used to determine the verdict of this activity. Per the TSS, “All remote administrative communications take place over a secure encrypted HTTPS session. The HTTPS session is over TLS. The remote users (Authorized Administrators) are able to initiate HTTPS communications with the TOE.”


Verdict: Pass

4.13.11 FTP_TRP.1/Admin TSS 2

Objective: The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. Evaluator Findings: The evaluator examined the TSS to determine if all protocols listed in support of TOE administration are consistent with those specified in the requirement. The definition of FTP_TRP.1 in ST and the TSS entry for FTP_TRP.1 in section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST were used to determine the verdict of this assurance activity. First, the evaluator reviewed the TSS and identified the protocols used for remote administration. Specifically, the TSS identifies the following protocols used for remote administration,

HTTPS/TLS

Next, the evaluator compared the protocols identified in the TLS to the definition of the SFR. The evaluator found that the protocols listed in the TSS are consistent with the protocols listed in the definition of the SFR.


Verdict: Pass

139

4.13.12 FTP_TRP.1/Admin Guidance 1

Objective: The evaluator shall confirm that the operational guidance contains instructions for establishing the remote administrative sessions for each supported method. Evaluator Findings: The evaluator examined the operational guidance to determine if it contains instructions for establishing remote administrative sessions. Section 2.2.4 ‘Administrator Configuration, Credentials and Session Termination’ of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD provides instructions for configuring the remote administration of the TOE. In particular, the evaluator found that these instructions include configuration of the protocols used to secure remote administrative session. Specifically, AGD provides instructions for configuring the following protocols,

HTTPS/TLS


Verdict: Pass

4.13.13 FTP_TRP.1/Admin Test #1


Test ID FTP_TRP.1_T1

Objective The evaluators shall ensure that communications using each specified (in the guidance documentation) remote administration method is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful.

For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of trusted paths to TOE components in the Security Target.

Test Flow


Verify the connection succeeds


The TOE is be able to successfully communicate using the remote administration methods specified in the ST.

Result Pass

4.13.14 FTP_TRP.1/Admin Test #2


Test ID FTP_TRP.1_T1

Objective The evaluator shall ensure, for each communication channel, the channel data is not sent in plaintext. For distributed TOEs the evaluator shall perform tests on all TOE components according to the mapping of trusted paths to TOE components in the Security Target.

Test Flow


Verify the connection succeeds and data is not sent in plaintext


The TOE does not send data in plaintext.

Result Pass

140

5 Security Assurance Requirements

5.1 ADV Assurance Activities

5.1.1 ADV_FSP.1

Objective: The evaluator shall examine the interface documentation to ensure it describes the purpose and method of use for each TSFI that is identified as being security relevant. The evaluator shall check the interface documentation to ensure it identifies and describes the parameters for each TSFI that is identified as being security relevant. The evaluator shall examine the interface documentation to develop a mapping of the interfaces to SFRs. Evaluator Findings: Per this cPP, the Evaluation Activities for this family focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional functional specification documentation is necessary to satisfy the Evaluation Activities specified in the ST.


Verdict: Pass

5.2 ASE_CCL.1 Conformance Claims

5.2.1 ASE_CCL.1.8.C

Objective: The evaluator shall check that the statements of security problem definition in the PP and ST are identical. Evaluator Findings: The evaluator checked that the statements of security problem definition in the PP and ST are identical. The section 3 titled ‘Security Problem Definition’ of ST and section 4 of the NDcPP were used to determine the verdict of this work unit. Upon investigation, the evaluator found that the SPD defined in the NDcPP and the SDP defined in the ST are identical.


Verdict: Pass

5.2.2 ASE_CCL.1.9.C

Objective: The evaluator shall check that the statements of security objectives in the PP and ST are identical. Evaluator Findings: The evaluator checked that the statements of security objectives in the PP and ST are identical. The section 4 titled ‘Security Objectives’ of the ST and section 5 of the NDcPP were used to determine the verdict of this work unit. Upon investigation, the evaluator found that the Objectives defined in the NDcPP and the NDcPP defined in the ST are identical.


Verdict: Pass

141

5.2.3 ASE_CCL.1.9.C Test 1

Objective: The evaluator shall check that the statements of security requirements in the ST include all the mandatory SFRs in the cPP, and all of the selection-based SFRs that are entailed by selections made in other SFRs (including any SFR iterations added in the ST). Evaluator Findings: The evaluator shall check that the statements of security requirements in the ST include all the mandatory SFRs in the cPP, and all of the selection-based SFRs that are entailed by selections made in other SFRs. Section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST and section 5 of the NDcPP were used to determine the verdict of this work unit. Upon investigation, the evaluator found that all required SFRs (both mandatory and selection-based) are included in the ST. The following table compares the SFRs found in the ST to the SFRs found in the PP.

SFR found in the Security Target SFR found in the Protection Profile

FAU_GEN.1 FAU_GEN.1

FAU_GEN.2 FAU_GEN.2

FAU_STG_EXT.1 FAU_STG_EXT.1

FCS_CKM.2 FCS_CKM.2

FCS_CKM.4 FCS_CKM.4

FCS_COP.1/DataEncryption FCS_COP.1/DataEncryption

FCS_COP.1/SigGen FCS_COP.1/SigGen

FCS_COP.1/Hash FCS_COP.1/Hash

FCS_COP.1/KeyedHash FCS_COP.1/KeyedHash

FCS_HTTPS_EXT.1 FCS_HTTPS_EXT.1

FCS_RBG_EXT.1 FCS_RBG_EXT.1

FCS_SSHC_EXT.1 FCS_SSHC_EXT.1

FCS_SSHS_EXT.1 FCS_SSHS_EXT.1

FCS_TLSC_EXT.2 FCS_TLSC_EXT.2

FCS_TLSS_EXT.2 FCS_TLSS_EXT.2

FIA_PMG_EXT.1 FIA_PMG_EXT.1

FIA_UIA_EXT.1 FIA_UIA_EXT.1

FIA_UAU_EXT.2 FIA_UAU_EXT.2

FIA_UAU.7 FIA_UAU.7

FIA_X509_EXT.1/ITT FIA_X509_EXT.1/ITT

FIA_X509_EXT.1/Rev FIA_X509_EXT.1/Rev

FIA_X509_EXT.2 FIA_X509_EXT.2

FIA_X509_EXT.3 FIA_X509_EXT.3

FMT_MTD.1/CoreData FMT_MTD.1/CoreData

FMT_MTD.1/CryptoKeys FMT_MTD.1/CryptoKeys

FMT_SMF.1 FMT_SMF.1

FMT_SMR.2 FMT_SMR.2

FPT_ITT.1 FPT_ITT.1

FPT_SKP_EXT.1 FPT_SKP_EXT.1

FPT_STM_EXT.1 FPT_STM_EXT.1

FPT_TST_EXT.1 FPT_TST_EXT.1

FPT_TUD_EXT.1 FPT_TUD_EXT.1

142

SFR found in the Security Target SFR found in the Protection Profile

FPT_STM.1 FPT_STM.1

FPT_STM_EXT.1 FPT_STM_EXT.1

FTA_SSL_EXT.1 FTA_SSL_EXT.1

FTA_SSL.3 FTA_SSL.3

FTA_SSL.4 FTA_SSL.4

FTA_TAB.1 FTA_TAB.1

FTP_ITC.1 FTP_ITC.1

FTP_ITC.1(2) FTP_ITC.1(2)

FTP_ITC.1(3) FTP_ITC.1(3)

FTP_TRP.1 FTP_TRP.1


Verdict: Pass

5.2.4 ASE_CCL.1.9.C Test 2

Objective: The evaluator shall check that if any other SFRs are present in the ST (apart from iterations of SFRs in the cPP) then these are taken only from the list of optional SFRs specified in the cPP (the cPP will not necessarily include optional SFRs, but may do so). Evaluator Findings: The evaluator checked if any other SFRs are present in the ST (apart from iterations of SFRs in the cPP) then these are taken only from the list of optional SFRs specified in the cPP (the cPP will not necessarily include optional SFRs, but may do so). Section 6.1 titled ‘TOE Security Functional Requirement Measures’ Table 18 of the ST and section 5 of the NDcPP were used to determine the verdict of this work unit. The evaluator compared the SFRs found in ST to the SFRs found in the NDcPP and found that no additional SFRs are included in the ST that are not included in the NDcPP.


Verdict: Pass

5.3 AGD_OPE.1 Operational User Guidance

5.3.1 AGD_OPE.1 Test #1

Objective: The evaluator shall ensure the Operational guidance documentation is distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. `The evaluator shall ensure that the Operational guidance is provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target. The evaluator shall ensure that the Operational guidance contains instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. The evaluator shall ensure

143

the Operational guidance makes it clear to an administrator which security functionality and interfaces have been assessed and tested by the EAs. The guidance documentation shall contain instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. The documentation must describe the process for verifying updates to the TOE by verifying a digital signature. The evaluator shall verify that this process includes the following steps: 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 instructions that describe at least one method of validating the hash/digital signature. The TOE will likely contain security functionality that does not fall in the scope of evaluation under this cPP. The guidance documentation shall make it clear to an administrator which security functionality is covered by the Evaluation Activities. Evaluator Findings: The evaluator checked the requirements below are met by the guidance documentation. Guidance documentation shall be distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. Upon investigation, the evaluator found that the CC guidance will be published with the CC certificate on www.niap-ccevs.org.


Verdict: Pass

5.4 AGD_PRE.1 Preparative Procedures

5.4.1 AGD_PRE.1

Objective: The evaluator shall examine the Preparative procedures to ensure they include a description of how the administrator verifies that the operational environment can fulfil its role to support the security functionality (including the requirements of the Security Objectives for the Operational Environment specified in the Security Target).The evaluator shall examine the Preparative procedures to ensure they are provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target. The evaluator shall examine the preparative procedures to ensure they include instructions to successfully install the TSF in each Operational Environment. The evaluator shall examine the preparative procedures to ensure they include instructions to manage the security of the TSF as a product and as a component of the larger operational environment. The preparative procedures must a) include instructions to provide a protected administrative capability; and b) identify TOE passwords that have default values associated with them and instructions shall be provided for how these can be changed. Evaluator Findings: The evaluator checked the requirements below are met by the preparative procedures. Preparative procedures shall be distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. Upon investigation, the evaluator found that the CC guidance will be published with the CC certificate on

http://www.niap-ccevs.org/

144

www.niap-ccevs.org. The evaluator used the guidance documentation when configuring the TOE. The completeness of the documentation is addressed by its use in the AA’s carried out in the evaluation.


Verdict: Pass

5.5 ALC Assurance Activities

5.5.1 ALC_CMC. 1

Objective: When evaluating that the TOE has been provided and is labelled with a unique reference, the evaluator performs the work units as presented in the CEM. Evaluator Findings: The evaluator verified that the ST, TOE and Guidance are all labeled with the same hardware versions and software. The information is specific enough to procure the TOE and it includes hardware models and software versions. The evaluator checked the TOE software version and hardware identifiers during testing by examining the actual machines used for testing.


Verdict: Pass

5.5.2 ALC_CMS. 1

Objective: When evaluating the developer’s coverage of the TOE in their CM system, the evaluator performs the work units as presented in the CEM. Evaluator Findings: The evaluator verified that the ST, TOE and Guidance are all labeled with the same hardware versions and software. The information is specific enough to procure the TOE and it includes hardware models and software versions. The evaluator checked the TOE software version and hardware identifiers during testing by examining the actual machines used for testing.


Verdict: Pass

5.6 ATE_IND.1 Independent Testing – Conformance

5.6.1 ATE_IND.1 Test #1

Objective: The evaluator performs the CEM work units associated with the ATE_IND.1 SAR. Specific testing requirements and EAs are captured for each SFR in Sections 2, 3 and 4. The evaluator should consult Appendix B when determining the appropriate strategy for testing multiple variations or models of the TOE that may be under evaluation. Evaluator Findings: The evaluator examined the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. Upon investigation, the evaluator found that each instance of the TOE used in testing was consistent with TOE description found in the Security Target. Additionally, the evaluator found that the TOE version is consistent with what was

http://www.niap-ccevs.org/

145

specified in the Security Target. The evaluator examined the TOE to determine that it has been installed properly and is in a known state. The details of the installed TOE and any configuration performed with the TOE are found in the separate Test Reports. The evaluator prepared a test plan that covers all the testing actions for ATE_IND.1 in the CEM and in the SFR-related Evaluation Activities


Verdict: Pass

5.7 AVA_VAN.1 Vulnerability Survey

5.7.1 AVA_VAN.1 Test #1

Objective: The evaluator shall document their analysis and testing of potential vulnerabilities with respect to this requirement. Evaluator Findings: The evaluator documented their analysis and testing of potential vulnerabilities with respect to this requirement. Public searches were performed against all keywords found within the Security Target and AGD that may be applicable to specific TOE components. This included protocols, TOE software version, and TOE hardware to ensure sufficient coverage under AVA. The evaluation team found no vulnerabilities were applicable to the TOE version or hardware. The list of keywords searched include:

http://nvd.nist.gov/

The evaluator performed the public domain vulnerability searches using the following key words.

Cisco Systems

Expressway X12.5 System

PKIX-SSH 10.1.1

CiscoSSL 1.0.2n.6.1.368-fips

UCS C220 M4

UCS C240 M4

UCS C220 M5

UCS C240 M5

Cisco UCS platforms

VMware ESXi 6.0

Intel Xeon E526xx v4

Intel Xeon Scalable Processors

TLS

TCP

UDP

SSH

The evaluation lab examined each result provided from NVD and Exploit Search to determine if the current TOE version or component within the environment was vulnerable. Based upon the analysis, any issues found that were generated were patched in the TOE version and prior versions, mitigating the risk

http://nvd.nist.gov/

146

factor. The vulnerability searches was performed on December 27, 2019. The vulnerability searches were reperformed on February 12, 2020.


Verdict: Pass

5.7.2 AVA Fuzzing Test


Test ID AVA_FUZZING_TEST

Objective The evaluator shall perform the following activities to generate type 4 flaw hypotheses:

Fuzz testing o Examine effects of sending:

mutated packets carrying each ‘Type’ and ‘Code’ value that is undefined in the relevant RFC for each of ICMPv4 (RFC 792) and ICMPv6 (RFC 4443)

mutated packets carrying each ‘Transport Layer Protocol’ value that is undefined in the respective RFC for IPv4 (RFC 791) IPv6 (RFC 2460) should also be covered if it is supported and claimed by the TOE.

Since none of these packets will belong to an allowed session, the packets should not be processed by the TOE, and the TOE should not be adversely affected by this traffic. Any results that are unexpected (e.g., core dumps) are candidates for a flaw hypothesis. Mutation fuzz testing of the remaining fields in the required protocol headers. This testing requires sending mutations of wellformed packets that have both carefully chosen and random values inserted into each header field in turn (i.e. testing is to include both carefully chosen and random insertion test cases). The original well-formed packets would be accepted as part of a normal existing communication stream and may still be accepted as valid packets when subject to the carefully chosen mutations (the individual packet alone would be valid although its contents may not be valid in the context of preceding and/or following packets), but will often not be valid packets when random values are inserted into fields. The carefully chosen values should include semantically significant values that can be determined from the type of the data that the field represents, such as values indicating positive and negative integers, boundary conditions, invalid binary combinations (e.g. for flag sets with dependencies between bits), and missing start or end values. Randomly chosen values may not result in well-formed packets, but are included nonetheless to see whether they can lead to the device entering an insecure state. Any results that are unexpected (e.g., core dumps) are candidates for a flaw hypothesis.

Test Flow Perform fuzz testing against the TOE interface

Verify that the packets were sent to the TOE

Verify that the TOE behavior was not adversely affected


TOE does not accept improper packets.

Result Pass

147

6 Technical Decisions

The following Technical Decisions apply to the NDcPPv2.0e: TD Name Protection Profiles References Date Applicable?

TD0453 NIT Technical Decision for Clarify authentication methods SSH clients can use to authenticate SSH

CPP_FW_V2.0E, CPP_ND_V2.0E, CPP_ND_V2.1

FCS_SSHC_EXT.1.9 2019.09.16 Yes - TD has been applied

TD0451 NIT Technical Decision for ITT Comm UUID Reference Identifier


FCS_TLSS_EXT.1.2 and FCS_TLSS_EXT.2.2

2019.09.16 Yes - TD has been applied

TD0450 NIT Technical Decision for RSA-based ciphers and the Server Key Exchange message

CPP_ND_V2.0E, CPP_ND_V2.1

FCS_TLSS_EXT.*.3, FCS_DTLSS_EXT.*.4, ND SD v2.1, ND SD v2.0E


TD0448 NIT Technical Decision for Documenting Diffie-Hellman 14 groups


FCS_CKM.2 2019.09.16 Yes - TD has been applied

TD0447 NIT Technical Decision for Using 'diffie-hellman-group-exchange-sha256' in FCS_SSHC/S_EXT.1.7


FCS_SSHC_EXT.1.7, FCS_SSHS_EXT.1.7

2019.09.16 No - Referenced SFR is not being claimed

TD0425

NIT Technical Decision for Cut-and-paste Error for Guidance AA


ND SD V2.0e, ND SD V2.1, FTA_SSL.3


TD0423

NIT Technical Decision for Clarification about application of RfI#201726rev2


ND SD V2.0E, FW SD V2.0E, ND SD V2.1


TD0412 NIT Technical Decision for FCS_SSHS_EXT.1.5 SFR and AA discrepancy

CPP_FW_V2.0E, CPP_ND_V2.0, CPP_ND_V2.1

FCS_SSHS_EXT.1.5, ND SD V2.0e, ND SD V2.1


TD0411 NIT Technical Decision for FCS_SSHC_EXT.1.5, Test 1 - Server and client side seem to be confused


FCS_SSHC_EXT.1.5, ND SD V2.0E, ND SD V2.1


https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?TD=0451










148

TD Name Protection Profiles References Date Applicable?




TD0410 NIT technical decision for Redundant assurance activities associated with FAU_GEN.1

CPP_ND_V1.0, CPP_ND_V2.0E, CPP_ND_V2.1

FAU_GEN.1, ND SD V1.0, ND SD V2.0e, ND SD V2.1


TD0409 NIT decision for Applicability of FIA_AFL.1 to key-based SSH authentication


FIA_AFL.1, ND SD v2.0e, ND SD v2.1

2019.03.22 No, referenced features is not being claimed

TD0408 NIT Technical Decision for local vs. remote administrator accounts


FIA_AFL.1, FIA_UAU_EXT.2, FMT_SMF.1


TD0407 NIT Technical Decision for handling Certification of Cloud Deployments


2019.03.22 No, referenced features is not being claimed

TD0402 NIT Technical Decision for RSA-based FCS_CKM.2 Selection

CPP_FW_V2.0E, CPP_ND_V2.0E

FCS_CKM.2, ND SD V2.0E


TD0401 NIT Technical Decision for Reliance on external servers to meet SFRs

CPP_ND_V2.0E FTP_ITC.1 2019.02.24 Yes - TD has been applied

TD0400 NIT Technical Decision for FCS_CKM.2 and elliptic curve-based key establishment


FCS_CKM.1, FCS_CKM.2


TD0399 NIT Technical Decision for Manual installation of CRL (FIA_X509_EXT.2)


FIA_X509_EXT.2, ND SD V2.0E, ND SD V2.1


TD0398 NIT Technical Decision for FCS_SSH*EXT.1.1 RFCs for AES-CTR


FCS_SSHC_EXT.1.1, FCS_SSHS_EXT.1.1,


149





TD0397 NIT Technical Decision for Fixing AES-CTR Mode Tests

CPP_ND_V2.0E FCS_COP.1/DataEncryption, ND SD V2.0E


TD0396 NIT Technical Decision for FCS_TLSC_EXT.1.1, Test 2

CPP_ND_V2.0E FCS_DTLSC_EXT.1.1, FCS_DTLSC_EXT.2.1, FCS_TLSC_EXT.1.1, FCS_TLSC_EXT.2.1, ND SD V2.0E


TD0395 NIT Technical Decision for Different Handling of TLS1.1 and TLS1.2

CPP_ND_V2.0E FCS_TLSS_EXT.2.4, FCS_TLSS_EXT.2.5, ND SD V2.0E


TD0394 NIT Technical Decision for Audit of Management Activities related to Cryptographic Keys


FAU_GEN.1, ND SD v2.0E


TD0343 NIT Technical Decision for Updating FCS_IPSEC_EXT.1.14 Tests


ND SD V2.0, FCS_IPSEC_EXT.1.14

2018.08.02 No, Referenced SFR is not being claimed.

TD0342 NIT Technical Decision for TLS and DTLS Server Tests

CPP_ND_V2.0E ND SD V2.0, FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2

08/02/18 Yes - TD has been applied

TD0341 NIT Technical Decision for TLS wildcard checking

CPP_ND_V2.0E ND SD V2.0, FCS_TLSC_EXT.1.2, FCS_TLSC_EXT.2.2, FCS_DTLSC_EXT.1.2, FCS_DTLSC_EXT.2.2,


TD0340 NIT Technical Decision for Handling of the basicConstraints extension in CA and leaf certificates


FIA_X509_EXT.1.1 2018.08.02 Yes - TD has been applied

150





TD0339 NIT Technical Decision for Making password-based authentication optional in FCS_SSHS_EXT.1.2


ND SD V2.0, FCS_SSHS_EXT.1.2


TD0338 NIT Technical Decision for Access Banner Verification

CPP_ND_V2.0E ND SD V2.0, FTA_TAB.1


TD0337 NIT Technical Decision for Selections in FCS_SSH*_EXT.1.6


ND SD V2.0, FCS_SSHC_EXT.1, FCS_SSHS_EXT.1


TD0336 NIT Technical Decision for Audit requirements for FCS_SSH*_EXT.1.8

CPP_ND_V2.0E ND SD V2.0, FCS_SSHC_EXT.1.8, FCS_SSHS_EXT.1.8


TD0335 NIT Technical Decision for FCS_DTLS Mandatory Cipher Suites


FCS_DTLSC_EXT.1.1, FCS_DTLSC_EXT.2.1, FCS_DTLSS_EXT.1.1, FCS_DTLSS_EXT.2.1, FCS_TLSC_EXT.1.1, FCS_TLSC_EXT.2.1, FCS_TLSS_EXT.1.1, FCS_TLSS_EXT.2.1


TD0334 NIT Technical Decision for Testing SSH when password-based authentication is not supported

CPP_ND_V2.0E ND SD V2.0, FCS_SSHC_EXT.1.9


TD0333 NIT Technical Decision for Applicability of FIA_X509_EXT.3


ND SD V2.0, FIA_X509_EXT


TD0324 NIT Technical Decision for Correction of section numbers in SD Table 1

CPP_ND_V2.0E Table 1 05/18/18 Yes - TD has been applied

TD0323 NIT Technical Decision for DTLS server testing - Empty Certificate Authorities list

CPP_ND_V2.0E ND SD V2.0, FCS_DTLSS_EXT.2.7, FCS_DTLSS_EXT.2.8

05/18/18 No, Referenced SFR is not being claimed.

151





TD0322 NIT Technical Decision for TLS server testing - Empty Certificate Authorities list

CPP_ND_V2.0E ND SD V.1.0, ND SD V2.0, FCS_TLSS_EXT.2.4, FCS_TLSS_EXT.2.5


TD0321 Protection of NTP communications


FTP_ITC.1, FPT_STM_EXT.1


TD0291 NIT technical decision for DH14 and FCS_CKM.1

CPP_FW_V1.0, CPP_FW_v2.0, CPP_FW_V2.0E, CPP_ND_V1.0, CPP_ND_V2.0, CPP_ND_V2.0E

FCS_CKM.1.1, ND SD V1.0, ND SD V2.0


TD0290 NIT technical decision for physical interruption of trusted path/channel.

CPP_ND_V1.0, CPP_ND_V2.0, CPP_ND_V2.0E

FTP_ITC.1, FTP_TRP.1, FPT_ITT.1, ND SD V1.0, ND SD V2.0


TD0289 NIT technical decision for FCS_TLSC_EXT.x.1 Test 5e


FCS_TLSC_EXT.1.1, FCS_TLSC_EXT.2.1, FCS_DTLSC_EXT.1.1 (only ND SD V2.0), FCS_DTLSC_EXT.2.1 (only ND SD V2.0)


TD0281 NIT Technical Decision for Testing both thresholds for SSH rekey


FCS_SSHC_EXT.1.8, FCS_SSHS_EXT.1.8, ND SD V1.0, ND SD V2.0


TD0259 NIT Technical Decision for Support for X509 ssh rsa authentication IAW RFC 6187

CPP_FW_v2.0, CPP_FW_V2.0E, CPP_ND_V2.0, CPP_ND_V2.0E

FCS_SSHC_EXT.1.5/FCS_SSHS_EXT.1.5


TD0257 NIT Technical Decision for Updating FCS_DTLSC_EXT.x.2/FCS_TLSC_EXT.x.2 Tests 1-4


ND SD V1.0, ND SD V2.0, FCS_DTLSC_EXT.1.2/FCS_DTLSC_EXT.2.2 Tests 1-4 (ND SD V2.0), FCS_TLSC_EXT.1.2/FCS_TLSC_EXT.2.2, Tests 1-4 (ND SD V1.0, ND SD V2.0)


152





TD0256 NIT Technical Decision for Handling of TLS connections with and without mutual authentication


ND SD V1.0, ND SD V2.0, FCS_DTLSC_EXT.2.5 (ND SD V2.0), FCS_TLSC_EXT.2 (ND SD V1.0, ND SD V2.0)


TD0228 NIT Technical Decision for CA certificates - basicConstraints validation

CPP_FW_V1.0, CPP_ND_V1.0, CPP_ND_V2.0, CPP_ND_V2.0E

ND SD V1.0, ND SD V2.0, FIA_X509_EXT.1.2


153

7 Conclusion

The testing shows that all test cases required for conformance have passed testing.

154

End of Document

Assurance Activity Report for Cisco Expressway X12.5 ... - NIAP

Documents

Transcript of Assurance Activity Report for Cisco Expressway X12.5 ... - NIAP