Allied Telesis x930 Series Switches Security Target 16-3347-R-0032 Version: 1.5 April 9, 2018 Prepared For: Allied Telesis, Inc. 3041 Orchard Parkway San Jose, CA 95134 Prepared By: Kenji Yoshino UL Verification Services Inc. Allied Telesis x930 Series Switches Security Target Page 2 of 89 Notices: ©2017 - 2018 Allied Telesis, Inc. All rights reserved. All other brand names are trademarks, registered trademarks, or service marks of their respective companies or organizations It is prohibited to copy, reproduce or retransmit the information contained within this documentation without the express written permission of Allied Telesis, Inc., 3041 Orchard Parkway, San Jose, CA 95134. Allied Telesis x930 Series Switches Security Target Page 3 of 89 Table of Contents Table of Contents.......................................................................................................................................... 3 List of Tables ................................................................................................................................................. 6 1. Security Target (ST) Introduction.......................................................................................................... 7 1.1 Security Target Reference............................................................................................................. 7 1.2 Target of Evaluation Reference..................................................................................................... 7 1.3 Target of Evaluation Overview...................................................................................................... 8 1.3.1 TOE Product Type.................................................................................................................. 8 1.3.2 TOE Usage ............................................................................................................................. 8 1.3.3 TOE Major Security Features Summary................................................................................8 1.3.4 TOE IT environment hardware/software/firmware requirements.......................................8 1.4 Target of Evaluation Description ..................................................................................................8 1.4.1 Target of Evaluation Physical Boundaries.............................................................................8 1.4.2 Target of Evaluation Logical Boundaries...............................................................................9 1.5 Notation, formatting, and conventions ......................................................................................10 2. Conformance Claims........................................................................................................................... 12 2.1 Common Criteria Conformance Claims.......................................................................................12 2.2 Conformance to Protection Profiles ...........................................................................................12 2.3 Conformance to Security Packages.............................................................................................13 2.4 Conformance Claims Rationale...................................................................................................13 3. Security Problem Definition................................................................................................................15 3.1 Threats ........................................................................................................................................ 15 3.2 Organizational Security Policies..................................................................................................16 3.3 Assumptions................................................................................................................................ 16 4. Security Objectives.............................................................................................................................. 18 4.1 Security Objectives for the Operational Environment................................................................18 5. Extended Components Definition.......................................................................................................19 5.1 Extended Security Functional Requirements Definitions ...........................................................19 5.2 Extended Security Assurance Requirement Definitions .............................................................19 6. Security Requirements........................................................................................................................ 20 6.1 Security Function Requirements.................................................................................................20 6.1.1 Class FAU: Security Audit ....................................................................................................21 6.1.2 Class FCS: Cryptographic Support .......................................................................................27 6.1.4 Class FIA: Identification and Authentication.......................................................................43 6.1.5 Class FMT: Security Management.......................................................................................49 Allied Telesis x930 Series Switches Security Target Page 4 of 89 6.1.6 Class FPT: Protection of the TSF..........................................................................................53 6.1.7 Class FTA: TOE Access .........................................................................................................59 6.1.8 Class FTP: Trusted Path/Channels.......................................................................................61 6.2 Security Assurance Requirements ..............................................................................................63 6.2.1 Extended Security Assurance Requirements ......................................................................64 6.2.1.1 ASE: Security Target ............................................................................................................64 7. TOE Summary Specification................................................................................................................70 7.1 Security Audit.............................................................................................................................. 70 7.1.1 Audit Generation.................................................................................................................70 7.1.2 Audit Storage ...................................................................................................................... 71 7.2 Cryptographic Support................................................................................................................71 7.2.1 Cryptographic Key Generation............................................................................................71 7.2.2 Cryptographic Operations...................................................................................................71 7.2.3 SSH Server Protocol.............................................................................................................72 7.2.4 TLS Protocol ........................................................................................................................ 73 7.3 Identification and Authentication...............................................................................................73 7.3.1 Password Management ......................................................................................................73 7.3.2 User Identification and Authentication ..............................................................................73 7.3.3 Protected Authentication Feedback ...................................................................................74 7.3.4 X.509 Certificate Validation ................................................................................................74 7.3.5 X.509 Certificate Authentication.........................................................................................74 7.4 Security Management.................................................................................................................75 7.5 Protection of the TSF ..................................................................................................................75 7.5.1 Protection of Administrator Passwords..............................................................................75 7.5.2 Protection of TSF Data (for reading of all symmetric keys) ................................................75 7.5.3 TSF Testing .......................................................................................................................... 75 7.5.4 Trusted Update ...................................................................................................................76 7.5.5 Reliable Time Stamps..........................................................................................................76 7.6 TOE Access .................................................................................................................................. 76 7.6.1 TSF-initiated Termination ...................................................................................................76 7.6.2 User-initiated Termination..................................................................................................77 7.6.3 Default TOE Access Banners ...............................................................................................77 7.7 Trusted Path/Channels ...............................................................................................................77 7.7.1 Inter-TSF Trusted Channel ..................................................................................................77 7.7.2 Trusted Path........................................................................................................................ 77 Allied Telesis x930 Series Switches Security Target Page 5 of 89 8. Terms and Definitions......................................................................................................................... 78 9. References .......................................................................................................................................... 80 Annex A Algorithm Validation Requirements .......................................................................................82 Allied Telesis x930 Series Switches Security Target Page 6 of 89 List of Tables Table 1: Threats .......................................................................................................................................... 15 Table 2: Organizational Security Policies ....................................................................................................16 Table 3: Assumptions.................................................................................................................................. 16 Table 4: Security Objectives for the Operational Environment..................................................................18 Table 5: Security Functional Requirements ................................................................................................20 Table 6: Auditable Events ........................................................................................................................... 22 Table 7: Assurance Requirements ..............................................................................................................63 Table 8: Conformance Claims ..................................................................................................................... 64 Table 9: Cryptographic Algorithms .............................................................................................................71 Table 10: TOE Abbreviations and Acronyms...............................................................................................78 Table 11: CC Abbreviations and Acronyms.................................................................................................79 Table 12: TOE Guidance Documentation....................................................................................................80 Table 13: TOE Evaluation Evidence.............................................................................................................80 Table 14: Common Criteria v3.1 References ..............................................................................................80 Table 15: Supporting Documentation.........................................................................................................81 Allied Telesis x930 Series Switches Security Target Page 7 of 89 1. Security Target (ST) Introduction • The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE description. • The ST reference shall uniquely identify the ST. • The TOE reference shall identify the TOE. The structure of this document is defined by CC v3.1r4 Part 1 Annex A.2, “Mandatory contents of an ST”: • Section 1 contains the ST Introduction, including the ST reference, Target of Evaluation (TOE) reference, TOE overview, and TOE description. • Section 2 contains conformance claims to the Common Criteria (CC) version, Protection Profile (PP) and package claims, as well as rationale for these conformance claims. • Section 3 contains the security problem definition, which includes threats, Organizational Security Policies (OSP), and assumptions that must be countered, enforced, and upheld by the TOE and its operational environment. • Section 4 contains statements of security objectives for the TOE, and the TOE operational environment as well as rationale for these security objectives. • Section 5 contains definitions of any extended security requirements claimed in the ST. • Section 6 contains the security function requirements (SFR), the security assurance requirements (SAR), as well as the rationale for the claimed SFR and SAR. • Section 7 contains the TOE summary specification, which includes the detailed specification of the IT security functions 1.1 Security Target Reference The Security Target reference shall uniquely identify the Security Target. ST Title: Allied Telesis x930 Series Switches Security Target ST Version: 1.5 ST Author(s): Kenji Yoshino ST Publication Date: April 9, 2018 Keywords Network Device 1.2 Target of Evaluation Reference The Target of Evaluation reference shall identify the Target of Evaluation. TOE Developer: Allied Telesis, Inc. 3041 Orchard Parkway San Jose, CA 95134 TOE Name: Allied Telesis x930 Series Switches TOE Version: x930 Series Switches with AlliedWare Plus version 5.4.6-1 Allied Telesis x930 Series Switches Security Target Page 8 of 89 1.3 Target of Evaluation Overview 1.3.1 TOE Product Type The TOE is classified as a Network Device (a generic infrastructure device that can be connected to a network). 1.3.2 TOE Usage The Allied Telesis x930 Series Switches are stackable Gigabit layer 3 devices. The x930 Series switches come in 28-port and 52-port versions with 10 and 40 Gigabit uplinks. 1.3.3 TOE Major Security Features Summary • Audit • Cryptography • Identification and Authentication • Security Management • Protection of the TSF • TOE Access • Trusted Path/Channels 1.3.4 TOE IT environment hardware/software/firmware requirements The TOE requires the following support from the IT environment: • SSHv2 client o Complaint with RFCs 4251, 4252, 4253, 4254, 5656, and 6668 o Allowing ECDSA P-256 or P-384 Host Authentication o Supporting ECDSA P-256, ECDSA P-384, or password based client authentication o Supporting ECDH P-256 or ECDH P-384 Key Exchange o Supporting AES CBC with 128 or 256 bit keys o Supporting HMAC-SHA-256 • Syslog server o Compliant with RFCs 5424 and 5425 o Allowing connections using TLS_RSA_WITH_AES_128_CBC_SHA • RADIUS server o Compliant with RFCs 2865, 6613, and 6614 o Allowing connections using TLS_RSA_WITH_AES_128_CBC_SHA • OCSP responder(s) o Providing certificate status for the Syslog and RADIUS server certificates 1.4 Target of Evaluation Description 1.4.1 Target of Evaluation Physical Boundaries The TOE consist of the following hardware: • AT-x930-28GTX • AT-x930-28GPX • AT-x930-28GSTX • AT-x930-52GTX • AT-x930-52GPX Running: Allied Telesis x930 Series Switches Security Target Page 9 of 89 • AlliedWare Plus version 5.4.6-1 Each hardware model uses a Freescale PowerPC P2040 processor. The guidance documentation that is part of the TOE is listed in Section 9 “References” within Table 12. The TOE also includes the evaluation evidence listed in Table 13. 1.4.2 Target of Evaluation Logical Boundaries The logical boundary of the TOE include those security functions implemented exclusively by the TOE. These security functions are summarized in Section 1.3.3 above and are further described in the following subsections. A more detailed description of the implementation of these security functions are provided in Section 7 “TOE Summary Specification”. 1.4.2.1 Audit The TOE will audit all events and information defined in Table 6. The TOE will also include the identity of the user that caused the event (if applicable), date and time of the event, type of event, and the outcome of the event. The TOE protects storage of audit information from unauthorized access, deletion, or modification. The TOE can transmit audit data to an external IT entity using the Syslog over TLS protocol. 1.4.2.2 Cryptographic Operations The TOE uses cryptographic algorithms and protocols to protect Syslog server communication, RADIUS sever communications, remote administrator sessions, test the TOE itself, and verify the integrity of updates to the TOE. The TSF zeroizes all plaintext secret and private cryptographic keys and CSPs once they are no longer required. 1.4.2.3 Identification and Authentication The TOE supports passwords consisting of alphanumeric and special characters. The TSF also allows administrators to set a minimum password length and support passwords with 15 characters or more. The TOE requires all administrative-users to authenticate. The TOE allows the following unauthenticated actions: • Viewing the warning banner • Responding to ICMP echo requests • Performing ARP • Performing routing services (.e.g. RIP, OSPF) 1.4.2.4 Security Management The TOE can be administered via a local console port or remotely over SSH. Both methods of administration present the user with a CLI. Authorized administrators are assigned the Security Administrator role when they login. 1.4.2.5 Protection of the TSF The TOE protects itself by: • Preventing the reading of plaintext passwords. • Preventing the reading of secret and private keys. • Providing reliable time stamps for itself. • Running a suite of self-tests during the initial start-up (upon power on) to demonstrate the correction operation of the TSF. Allied Telesis x930 Series Switches Security Target Page 10 of 89 • Verifying firmware updates to the TOE using a published hash prior to installing those updates. 1.4.2.6 TOE Access For local console sessions and remote SSH sessions, the TSF terminates sessions after an administrator configured inactivity period. Before establishing an administrative user session, the TOE is capable of displaying a configurable advisory notice and consent warning message regarding unauthorized use of the TOE. 1.4.2.7 Trusted Path/Channels The TOE uses TLS to provide a trusted communication channel with the Syslog server and RADIUS server. The TOE permits remote administrators to connect using SSH. 1.4.2.8 Unevaluated Features The following features are not NDcPP compliant and shall not be used in the evaluated configuration: • Allied Telesis Management Framework • VCStack (Virtual Chassis Stacking) • Long-distance Stacking The following features fall outside of the scope of NDcPP and were not covered by the evaluation; however, these features may be used in the evaluated configuration: • EPSRing (Ethernet Protection Switched Ring) • Virtual Routing and Forwarding • Optical Digital Diagnostics Monitoring (DDM) • Active Fiber Monitoring • UniDirectional link Detection • Power over Ethernet Plus (PoE+) • Voice VLAN • Microsoft Network Load Balancing Support • sFlow • DHCP Snooping • Wireless Manager • Software Defined Networking 1.5 Notation, formatting, and conventions The notation, formatting, and conventions used in this Security Target are defined below; these styles and clarifying information conventions were developed to aid the reader. Where necessary, the ST author has added application notes to provide the reader with additional details to aid understanding; they are italicized and usually appear following the element needing clarification. Those notes specific to the TOE are marked “TOE Application Note;” those taken from the collaborative Protection Profile for Network Devices are marked “Application Note <#>.” The notation conventions that refer to iterations, assignments, selections, and refinements made in this Security Target are in reference to SARs and SFRs taken directly from CC Part 2 and Part 3 as well as any SFRs and SARs taken from a Protection Profile. Allied Telesis x930 Series Switches Security Target Page 11 of 89 The notation used in those PP to indicate iterations, assignments, selections, and refinements of SARs and SFRs taken from CC Part 2 and Part 3 is not carried forward into this document. Additionally, obvious errors in the PP are corrected and noted as such. The CC permits four component operations (assignment, iteration, refinement, and selection) to be performed on requirement components. These operations are defined in Common Criteria, Part 1; paragraph 6.4.1.3.2, “Permitted operations on components” as: • Iteration: allows a component to be used more than once with varying operations; • Assignment: allows the specification of parameters; • Selection: allows the specification of one or more items from a list; and • Refinement: allows the addition of details. Iterations are indicated by a number in parenthesis following the requirement number, e.g., FIA_UAU.1.1(1); the iterated requirement titles are similarly indicated, e.g., FIA_UAU.1(1). Assignments made by the ST author are identified with bold text. Selections are identified with underlined text. Refinements that add text use bold and italicized text to identified the added text. Refinements that performs a deletion, identifies the deleted text with strikeout, bold, and italicized text. Allied Telesis x930 Series Switches Security Target Page 12 of 89 2. Conformance Claims 2.1 Common Criteria Conformance Claims This Security Target is conformant to the Common Criteria Version 3.1r4, CC Part 2 extended [C2], and CC Part 3 extended [C3]. 2.2 Conformance to Protection Profiles This Security Target claims exact compliance to the collaborative Protection Profile for Network Devices, Version 1.0, dated February 27, 2015 [NDcPP] and Supporting Document Mandatory Technical Document Evaluation Activities for Network Device cPP, Version 1.0, dated February 27, 2015 [SD]. This Protection Profile will be referred to as cPP or PP for convenience throughout this Security Target. The TOE complies with the following [NDcPP] Technical Decisions: • 0291 – NIT technical decision for DH14 and FCS_CKM.1 • 0289 – NIT technical decision for FCS_TLSC_EXT.x.1 Test 5e • 0281* – NIT Technical Decision for Testing both thresholds for SSH rekey • 0257 – NIT Technical Decision for Updating FCS_DTLSC_EXT.x.2/FCS_TLSC_EXT.x.2 Tests 1-4 • 0235 – NIT Technical Decision adding DH group 14 to the selection in FCS_CKM.2 • 0228 – NIT Technical Decision for CA certificates - basicConstraints validation • 0227 – NIT Technical Decision for TOE acting as a TLS Client and RSA key generation • 0226 – NIT Technical Decision for TLS Encryption Algorithms • 0201* – NIT Technical Decision for Use of intermediate CA certificates and certificate hierarchy depth • 0199 – NIT Technical Decision for Elliptic Curves for Signatures • 0189 – NIT Technical Decision for SSH Server Encryption Algorithms • 0188* – NIT Technical Decision for Optional use of X.509 certificates for digital signatures • 0187 – NIT Technical Decision for Clarifying FIA_X509_EXT.1 test 1 • 0185* – NIT Technical Decision for Channel for Secure Update. • 0184* – NIT Technical Decision for Mandatory use of X.509 certificates • 0183* – NIT Technical Decision for Use of the Supporting Document • 0182 – NIT Technical Decision for Handling of X.509 certificates related to ssh-rsa and remote comms. • 0181* – NIT Technical Decision for Self-testing of integrity of firmware and software. • 0170* – NIT Technical Decision for SNMPv3 Support • 0169 – NIT Technical Decision for Compliance to RFC5759 and RFC5280 for using CRLs • 0168* – NIT Technical Decision for Mandatory requirement for CSR generation • 0167 – NIT Technical Decision for Testing SSH 2^28 packets • 0165 – NIT Technical Decision for Sending the ServerKeyExchange message when using RSA • 0164 – NIT Technical Decision for Negative testing for additional ciphers for SSH • 0154 – NIT Technical Decision for Versions of TOE Software in the NDcPP v1.0 and FW cPP v1.0 • 0153* – NIT Technical Decision for Auditing of NTP Time Changes in the NDcPP v1.0 and FW cPP v1.0 Allied Telesis x930 Series Switches Security Target Page 13 of 89 • 0152* – NIT Technical Decision for Reference identifiers for TLS in the NDcPP v1.0 and FW cPP v1.0 • 0150 – NIT Technical Decision for Removal of SSH re-key audit events in the NDcPP v1.0 and FW cPP v1.0 • 0130 – NIT Technical Decision for Requirements for Destruction of Cryptographic Keys • 0126 – NIT Technical Decision for TLS Mutual Authentication • 0117 – NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP • 0116 – NIT Technical Decision for a Typo in reference to RSASSA-PKCS1v1_5 in NDcPP and FWcPP • 0114* – NIT Technical Decision for Re-Use of FIPS test results in NDcPP and FWcPP • 0113 – NIT Technical Decision for testing and trusted updates in the NDcPP v1.0 and FW cPP v1.0 • 0112* – NIT Technical Decision for TLS testing in the NDcPP v1.0 and FW cPP v1.0. • 0111* – NIT Technical Decision for third party libraries and FCS_CKM.1 in NDcPP and FWcPP • 0096* – NIT Technical Interpretation regarding Virtualization • 0095* – NIT Technical Interpretations regarding audit, random bit generation, and entropy in NDcPP • 0094 – NIT Technical Decision for validating a published hash in NDcPP • 0093† – NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP • 0090 – NIT Technical Decision for FMT_SMF.1.1 Requirement in NDcPP * denotes informational TDs. † denotes superseded TDs. 2.3 Conformance to Security Packages This Security Target does not claim conformance to any security function requirements or security assurance requirements packages, neither as package-conformant or package-augmented. 2.4 Conformance Claims Rationale To demonstrate that exact conformance is met, this rationale shows all threats are addressed, all OSP are satisfied, no additional assumptions are made, all objectives have been addressed, and all SFRs and SARs have been instantiated. The following address the completeness of the threats, OSP, and objectives, limitations on the assumptions, and instantiation of the SFRs and SARs: • Threats o All threats defined in the cPP are carried forward to this ST; o No additional threats have been defined in this ST. • Organizational Security Policies o All OSP defined in the cPP are carried forward to this ST; o No additional OSPs have been defined in this ST. • Assumptions o All assumptions defined in the cPP are carried forward to this ST; Allied Telesis x930 Series Switches Security Target Page 14 of 89 o No additional assumptions for the operational environment have been defined in this ST. • Objectives o All objectives defined in the cPP are carried forward to this ST. • All SFRs and SARs defined in the cPP are carried forward to this Security Target. Rationale presented in the body of this ST shows all assumptions on the operational environment have been upheld, all the OSP are enforced, all defined objectives have been met and these objectives counter the defined threats. Additionally, all SFRs and SARs defined in the cPP have been properly instantiated in this Security Target; therefore, this ST shows exact conformance to the cPP. Allied Telesis x930 Series Switches Security Target Page 15 of 89 3. Security Problem Definition 3.1 Threats The following table defines the security threats for the TOE, characterized by a threat agent, an asset, and an adverse action of that threat agent on that asset. These threats are taken directly from the PP unchanged. Table 1: Threats Threat Description T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain administrator access to the network device by nefarious means such as masquerading as an administrator to the device, masquerading as the device to an administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the- middle attacks, which would provide access to the administrative session, or sessions between network devices. Successfully gaining administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target network devices that do not use standardized secure tunneling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man-in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the network device itself. T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints – e.g., shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the network device itself could be compromised. T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the network device without administrator awareness. This could result in the attacker Allied Telesis x930 Series Switches Security Target Page 16 of 89 Table 1: Threats Threat Description finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the administrator would have no knowledge that the device has been compromised. T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the network device and its critical data. The compromise of credentials include replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the administrator or device credentials for use by the attacker. T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak administrative passwords to gain privileged access to the device. Having privileged access to the device provides the attacker unfettered access to the network traffic, and may allow them to take advantage of any trust relationships with other network devices. T.SECURITY_FUNCTIONALITY_FAILURE A component of the network device may fail during start-up or during operations causing a compromise or failure in the security functionality of the network device, leaving the device susceptible to attackers. 3.2 Organizational Security Policies The following table defines the organizational security policies which are a set of rules, practices, and procedures imposed by an organization to address its security needs. These threats are taken directly from the PP unchanged. Table 2: Organizational Security Policies OSP Description P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE. 3.3 Assumptions This section describes the assumptions on the operational environment in which the TOE is intended to be used. It includes information about the physical, personnel, and connectivity aspects of the environment. The operational environment must be managed in accordance with the provided guidance documentation. The following table defines specific conditions that are assumed to exist in an environment where the TOE is deployed. These assumptions are taken directly from the PP unchanged. Table 3: Assumptions Assumption Description A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security and/or interfere with the device’s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cPP will not include any requirements on physical tamper protection or other physical attack mitigations. The cPP will not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. Allied Telesis x930 Series Switches Security Target Page 17 of 89 Table 3: Assumptions Assumption Description A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example the device should not provide computing platform for general purpose Applications (unrelated to networking functionality). A.NO_THRU_TRAFFIC_PROTECTION A standard/generic network device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the network device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the network device, destined for another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs for particular types of network devices (e.g, firewall). A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the network device are assumed to be trusted and to act in the best interest of security for the organization. This includes being appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The network device is not expected to be capable of defending against a malicious administrator that actively works to bypass or compromise the security of the device. A.REGULAR_UPDATES The network device firmware and software is assumed to be updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the network device are protected by the platform on which they reside. Allied Telesis x930 Series Switches Security Target Page 18 of 89 4. Security Objectives 4.1 Security Objectives for the Operational Environment Table 4: Security Objectives for the Operational Environment Objective Description OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. OE.UPDATES The TOE firmware and software is updated by an administrator on a regular basis in response to the release of product updates due to known vulnerabilities. OE.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. Allied Telesis x930 Series Switches Security Target Page 19 of 89 5. Extended Components Definition This section provides definition of the extended security functional and assurance requirements; the components that are CC Part 2 extended, and CC Part 3 extended, i.e., NIAP interpreted requirements, and extended requirements. 5.1 Extended Security Functional Requirements Definitions There are no extended Security Functional Requirements defined in this Security Target. All extended SFRs are defined in the [NDcPP]. 5.2 Extended Security Assurance Requirement Definitions There are no extended Security Assurance Requirements defined in this Security Target. All extended SFRs are defined in the [NDcPP] and [SD]. Allied Telesis x930 Series Switches Security Target Page 20 of 89 6. Security Requirements This section describes the security functional and assurance requirements for the TOE; those that are CC Part 2 conformant, CC Part 2 extended, CC Part 3 conformant, and CC Part 3 extended. 6.1 Security Function Requirements This section describes the functional requirements for the TOE. The security functional requirement components in this security target are CC Part 2 conformant or CC Part 2 extended as defined in Section 2, Conformance Claims. Operations that were performed in the cPP are not signified in this section. Operations performed by the ST are denoted according to the formatting conventions in Section 1.5. Table 5: Security Functional Requirements SFR Description FAU_GEN.1 Audit Data Generation FAU_GEN.2 User Audit Association FAU_STG.1 Protected Audit Trail Storage FAU_STG_EXT.1 Protected Audit Event Storage FCS_CKM.1 Cryptographic Key Generation (Refined) FCS_CKM.2 Cryptographic Key Establishment (Refined) FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1(1) Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1(2) Cryptographic Operation (Signature Generation and Verification) FCS_COP.1(3) Cryptographic Operation (Hash Algorithm) FCS_COP.1(4) Cryptographic Operation (Keyed Hash Algorithm) FCS_RBG_EXT.1 Random Bit Generation FCS_SSHS_EXT.1 SSH Server Protocol FCS_TLSC_EXT.1 TLS Client Protocol FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU.7 Protected Authentication Feedback FIA_X509_EXT.1 X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.3 X.509 Certificate Requests FMT_MOF.1(1)/Trusted Update Management of Security Functions Behaviour FMT_MOF.1(1)/Audit Management of Security Functions Behaviour FMT_MOF.1(2)/Audit Management of Security Functions Behaviour FMT_MTD.1 Management of TSF Data FMT_MTD.1/AdminAct Management of TSF Data FMT_SMF.1 Specification of Management Functions Allied Telesis x930 Series Switches Security Target Page 21 of 89 Table 5: Security Functional Requirements SFR Description FMT_SMR.2 Restrictions on Security Roles FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys) FPT_APW_EXT.1 Protection of Administrator Passwords FPT_TST_EXT.1 TSF Testing FPT_TUD_EXT.1 Trusted Update FPT_STM.1 Reliable Time Stamps FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_TAB.1 Default TOE Access Banners FTP_ITC.1 Inter-TSF Trusted Channel FTP_TRP.1 Trusted Path 6.1.1 Class FAU: Security Audit 6.1.1.1 FAU_GEN.1 Audit Data Generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shut-down of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrative actions comprising: • Administrative login and logout (name of user account shall be logged if individual user accounts are required for administrators). • Security related configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). • Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). • Resetting passwords (name of related user account shall be logged). • Starting and stopping services (if applicable) • no other actions; d) Specifically defined auditable events listed in Table 6. Application Note 1 If the list of ‘administrative actions’ appears to be incomplete, the assignment in the selection should be used to list additional administrative actions which are audited. The ST author replaces the cross-reference to the table of audit events with an appropriate cross-reference for the ST. This must also include the relevant parts of Table 3 and Table 4 for optional and selection-based SFRs included in the ST. Application Note 2 The ST author can include other auditable events directly in the table; they are not limited to the list presented. Allied Telesis x930 Series Switches Security Target Page 22 of 89 The TSS should identify what information is logged to identify the relevant key for the administrative task of generating/import of, changing, or deleting of cryptographic keys. With respect to FAU_GEN.1.1 the term ‘services’ refers to trusted path and trusted channel communications, on demand self-tests, trusted update and administrator sessions (that exist under the trusted path) (e.g. netconf). FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, information specified in column three of Table 6. Application Note 3 The ST author replaces the cross-reference to the table of audit events with an appropriate cross-reference for the ST. This must also include the relevant parts of cPP Table 3 and cPP Table 4 for optional and selection-based SFRs included in the ST. Table 6: Auditable Events SFR Auditable Events Additional Audit Record Contents FAU_GEN.1 None. None. FAU_GEN.2 None. None. FAU_STG.1 None. None. FAU_STG_EXT.1 None. None. FCS_CKM.1 None. None. FCS_CKM.2 None. None. FCS_CKM.4 None. None. FCS_COP.1(1) None. None. FCS_COP.1(2) None. None. FCS_COP.1(3) None. None. FCS_COP.1(4) None. None. FCS_RBG_EXT.1 None. None. FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure. FCS_TLSC_EXT.1 Failure to establish a TLS Session Reason for failure FCS_PMG_EXT.1 None. None. FIA_UIA_EXT.1 All use of the identification and authentication mechanism. Provided user identity, origin of the attempt (e.g., IP address). FIA_UAU_EXT.2 All use of the identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU.7 None. None. FIA_X509_EXT.1 Unsuccessful attempt to validate a certificate. Reason for Failure Allied Telesis x930 Series Switches Security Target Page 23 of 89 Table 6: Auditable Events SFR Auditable Events Additional Audit Record Contents FIA_X509_EXT.2 None. None. FMT_MOF.1(1)/ TrustedUpdate Any attempt to initiate a manual update. None. FMT_MOF.1(1)/ Audit Modification of the behaviour of the transmission of audit data to an external identity. None. FMT_MOF.1(2)/ Audit Modification of the behaviour of the handling of audit data. None. FMT_MTD.1 All management activities of TSF data. None. FMT_MTD.1/ AdminAct Modification, deletion, generation/import of cryptographic keys. None. FMT_SMF.1 None. None. FMT_SMR.2 None. None. FPT_SKP_EXT.1 None. None. FPT_APW_EXT.1 None. None. FPT_TST_EXT.1 None. None. FPT_TUD_EXT.1 Initiation of update; result of the update attempt (success or failure) No additional information. FPT_STM.1 Changes to time. The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FTA_SSL_EXT.1 Any attempts at unlocking of an interactive session. None. FTA_SSL.3 The termination of a remote session by the session locking mechanism. None. FTA_SSL.4 The termination of an interactive session. None. FTA_TAB.1 None. None. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. FTP_TRP.1 Initiation of the trusted path. Termination of the trusted path. Failure of the trusted path functions. Identification of the claimed user identity. Application Note 4 Additional audit events will apply to the TOE depending on the optional and selection-based requirements adopted from Appendix A and Appendix B. The ST author must therefore include the relevant additional Allied Telesis x930 Series Switches Security Target Page 24 of 89 events specified in the tables in [NDcPP] Table 3 and [NDcPP] Table 4. The audit event for FIA_X509_EXT.1 is based on the TOE not being able to complete the certificate validation by ensuring the following: • the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates. • Verification of the digital signature of the trusted hierarchical CA • read/access the CRL or access the OCSP server. If any of these checks fails, then an audit event with the failure should be written to the audit log. ST Application Note FAU_GEN.1, Table 6 was updated as specified by TD0150. Assurance Activity: Guidance The evaluator shall check the administrative guide and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of auditable events. The evaluator shall also make a determination of the administrative actions that are relevant in the context of 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. Test The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the table of audit events and administrative actions listed above. This should include all instances of an event: for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. Logging of all activities related to trusted update should be tested in detail and with utmost diligence. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. 6.1.1.2 FAU_GEN.2 User Identity Association FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. Allied Telesis x930 Series Switches Security Target Page 25 of 89 Assurance Activity This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1. 6.1.1.3 FAU_STG.1 Protected Audit Trail Storage FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the stored audit records in the audit trail. Assurance Activity TSS The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally and how these records are protected against unauthorized modification or deletion. The evaluator shall ensure that the TSS describes the conditions that must be met for authorized deletion of audit records. Guidance The evaluator shall examine the guidance documentation to determine that it describes any configuration required for protection of the locally stored audit data against unauthorized modification or deletion. Test The evaluator shall perform the following tests: a) Test 1: The evaluator shall access the audit trail as an unauthorized administrator and attempt to modify and delete the audit records. The evaluator shall verify that these attempts fail. b) Test 2: The evaluator shall access the audit trail as an authorized administrator and attempt to delete the audit records. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records authorized for deletion are deleted. 6.1.1.4 FAU_STG_EXT.1 Protected Audit Event Storage FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted channel according FTP_ITC.1. Application Note 5 For selecting the option of transmission of generated audit data to an external IT entity the TOE relies on a non-TOE audit server for storage and review of audit records. The storage of these audit records and the ability to allow the administrator to review these audit records is provided by the operational environment in that case. FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. FAU_STG_EXT.1.3 The TSF shall overwrite previous audit records according to the following rule: the oldest log file is overwritten when the local storage space for audit data is full. Application Note 6 Allied Telesis x930 Series Switches Security Target Page 26 of 89 The external log server might be used as alternative storage space in case the local storage space is full. The ‘other action’ could in this case be defined as ‘send the new audit data to an external IT entity’. Assurance Activity TSS The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. If the TOE complies with FAU_STG_EXT.2 the evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3. The evaluator shall examine the TSS to ensure that it details the behaviour of the TOE when the storage space for audit data is full. When the option ‘overwrite previous audit record’ is selected this description should include an outline of the rule for overwriting audit data. If ‘other actions’ are chosen such as sending the new audit data to an external IT entity, then the related behaviour of the TOE shall also be detailed in the TSS. Guidance The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the audit server. The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behaviour of the TOE for each possible configuration. The description of possible configuration options and resulting behaviour shall correspond to those described in the TSS. Test Testing of the trusted channel mechanism for audit will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following additional test for this requirement: a) Test 1: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing. Allied Telesis x930 Series Switches Security Target Page 27 of 89 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: a) The audit data remains unchanged with every new auditable event that should be tracked but that the audit data is recorded again after the local storage for audit data is cleared (for the option ‘drop new audit data’ in FAU_STG_EXT.1.3). b) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option ‘overwrite previous audit records’ in FAU_STG_EXT.1.3) c) The TOE behaves as specified (for the option ‘other action’ in FAU_STG_EXT.1.3). 6.1.2 Class FCS: Cryptographic Support 6.1.2.1 FCS_CKM.1 Cryptographic Key Generation FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: • ECC schemes using “NIST curves” P-256, P-384 that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4; Application Note 7 The ST author selects all key generation schemes used for key establishment and device authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 and selected cryptographic protocols must match the selection. When key generation is used for device authentication, the public key is expected to be associated with an X.509v3 certificate. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. ST Application Note Application Note 7 was updated as specified by TD0227. FCS_CKM.1.1 was updated as specified by TD0291; however, the added option was not selected by the ST author. Assurance Activity TSS 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. Guidance The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP. Test See Annex A for Algorithm Validation Assurance Activities. Allied Telesis x930 Series Switches Security Target Page 28 of 89 6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: • Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”; Application Note 8 This is a refinement of the SFR FCS_CKM.2 to deal with key establishment rather than key distribution. The ST author selects all key establishment schemes used for the selected cryptographic protocols. For Diffie-Hellman group 14, ST authors should make the corresponding selection from the SFR instead of using the Finite field-based key establishment selection. The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation. The elliptic curves used for the key establishment scheme correlate with the curves specified in FCS_CKM.1.1. The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1. ST Application Note FCS_CKM.2.1 was updated as specified by TD0235; however, the added option was not selected by the ST author. Assurance Activity TSS 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 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. Guidance The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). Test See Annex A for Algorithm Validation Assurance Activities. ST Application Note The FCS_CKM.2.1 assurance activities were updated as specified by TD0235. 6.1.2.3 FCS_CKM.4 Cryptographic Key Destruction FCS_CKM.4.1 Allied Telesis x930 Series Switches Security Target Page 29 of 89 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method • For plaintext keys in volatile storage, the destruction shall be executed by a single overwrite consisting of zeroes; • For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by the TSF that logically addresses the storage location of the key and performs a three-pass overwrite consisting of a pseudo-random pattern that meets the following: No Standard. ST Application Note FCS_CKM.4 was updated as specified by TD0130. Assurance Activity TSS The evaluator shall check to ensure the TSS lists each type of plaintext key material and its origin and storage location. The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, etc.). The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write"). 6.1.2.4 FCS_COP.1(1) Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1.1(1) The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in CBC mode and cryptographic key sizes 128 bits, 256 bits that meet the following: AES as specified in ISO 18033-3, CBC as specified in ISO 10116. Application Note 9 For the first selection of FCS_COP.1.1(1), the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. The modes and key sizes selected here correspond to the cipher suite selections made in the trusted channel requirements. Assurance Activity Test See Annex A for Algorithm Validation Assurance Activities. 6.1.2.5 FCS_COP.1(2) Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1(2) Allied Telesis x930 Series Switches Security Target Page 30 of 89 The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm • RSA Digital Signature Algorithm and cryptographic key sizes (modulus) 2048, 3072 bits, • Elliptic Curve Digital Signature Algorithm and cryptographic key sizes 256, 384 bits that meet the following: • For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3, • For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST curves” P-256, P-384; ISO/IEC 14888-3, Section 6.4. Application Note 10 The ST Author chooses the algorithm(s) implemented to perform digital signatures. For the algorithm(s) chosen, the ST author makes the appropriate assignments/selections to specify the parameters that are implemented for that algorithm. The ST author ensures that the assignments and selections for this SFR include all the parameter values necessary for the cipher suites selected for the protocol SFRs (see Appendix B.2.1) that are included in the ST. The ST Author checks for consistency of selections with other FCS requirements, especially when supporting elliptic curves ST Application Note FCS_COP.1(2) was updated as specified by TD0116 and TD0199. Assurance Activity Test See Annex A for Algorithm Validation Assurance Activities. 6.1.2.6 FCS_COP.1(3) Cryptographic Operation (Hash Algorithm) FCS_COP.1.1(3) The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm SHA-1, SHA-256, SHA-384 that meet the following: ISO/IEC 10118-3:2004. Application Note 11 Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1(1) and FCS_COP.1(2) (for example, SHA 256 for 128-bit keys). Assurance Activity TSS 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. Guidance The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. Allied Telesis x930 Series Switches Security Target Page 31 of 89 Test See Annex A for Algorithm Validation Assurance Activities. 6.1.3 FCS_COP.1(4) Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1.1(4) The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-SHA-1, HMAC-SHA-256 and cryptographic key sizes 160, 256, 384 bits and message digest sizes 160, 256 bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. Application Note 12 The key size [k] in the assignment falls into a range between L1 and L2 (defined in ISO/IEC 10118 for the appropriate hash function). For example, for SHA-256, L1=512, L2=256, where L2<=k<=L1. Assurance Activity TSS 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. Test For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation. 6.1.3.1 FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using CTR_DRBG (AES). FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from 1 software-based noise source, 1 hardware-based noise source with a minimum of 256 bits of entropy at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of the keys and hashes that it will generate. Application Note 13 For the first selection in FCS_RBG_EXT.1.2, the ST selects at least one of the types of noise sources. If the TOE contains multiple noise sources of the same type, the ST author fills the assignment with the appropriate number for each type of source (e.g., 2 software-based noise sources, 1 hardware-based noise source). The documentation and tests required in the Evaluation Activity for this element necessarily cover each source indicated in the ST. ISO/IEC 18031:2011 contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used, and include the specific underlying cryptographic primitives used in the requirement. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed. Allied Telesis x930 Series Switches Security Target Page 32 of 89 If the key length for the AES implementation used here is different than that used to encrypt the user data, then FCS_COP.1 may have to be adjusted or iterated to reflect the different key length. For the selection in FCS_RBG_EXT.1.2, the ST author selects the minimum number of bits of entropy that is used to seed the RBG. Assurance Activity Documentation shall be produced—and the evaluator shall perform the activities—in accordance with Appendix D of [NDcPP]. Test The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the guidance documentation contains appropriate instructions for configuring the RNG functionality. If the RNG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 –14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. “generate one block of random bits” means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP800- 90A). If the RNG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 –14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following paragraphs contain more information on some of the input values to be generated/selected by the evaluator. Entropy input: the length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length. Personalization string: The length of the personalization string must be <= seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied. Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths. 6.1.3.2 FCS_SSHS_EXT.1 SSH Server Protocol FCS_SSHS_EXT.1.1 Allied Telesis x930 Series Switches Security Target Page 33 of 89 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and 5656, 6668. Application Note 69 The ST author selects which of the additional RFCs to which conformance is being claimed. Note that these need to be consistent with selections in later elements of this component (e.g., cryptographic algorithms permitted). RFC 4253 indicates that certain cryptographic algorithms are “REQUIRED”. This means that the implementation must include support, not that the algorithms must be enabled for use. Ensuring that algorithms indicated as “REQUIRED” but not listed in the later elements of this component are implemented is out of scope of the assurance activity for this requirement. FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, password-based. Assurance Activity TSS 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. Test Test 1: The evaluator shall, for each public key algorithm supported, show that the TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities required to support this test shall be performed according to instructions in the guidance documentation. Test 2: The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a new key pair for that algorithm without configuring the TOE to recognize the public key for authentication. The evaluator shall use an SSH client to attempt to connect to the TOE with the new key pair and demonstrate that authentication fails. Test 3: Using the guidance documentation, the evaluator shall configure the TOE to accept password- based authentication, and demonstrate that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator. Test 4: The evaluator shall use an SSH client, enter an incorrect password to attempt to authenticate to the TOE, and demonstrate that the authentication fails. FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than 262144 bytes in an SSH transport connection are dropped. Application Note 70 RFC 4253 provides for the acceptance of “large packets” with the caveat that the packets should be of “reasonable length” or dropped. The assignment should be filled in by the ST author with the maximum packet size accepted, thus defining “reasonable length” for the TOE. Assurance Activity TSS Allied Telesis x930 Series Switches Security Target Page 34 of 89 The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. Test The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped. FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms and rejects all other encryption algorithms: aes128-cbc, aes256-cbc. Application Note 71 RFC 5647 specifies the use of the AEAD_AES_128_GCM and AEAD_AES_256_GCM algorithms in SSH. As described in RFC 5647, AEAD_AES_128_GCM and AEAD_AES_256_GCM can only be chosen as encryption algorithms when the same algorithm is being used as the MAC algorithm. Corresponding FCS_COP entries are included in the ST for the algorithms selected here. ST Application Note FCS_SSH_EXT.1.4 was updated as specified by TD0189. Assurance Activity TSS 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. Guidance 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). Test Test 1: The evaluator shall establish a SSH connection using each of the encryption algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test 2: The evaluator shall configure an SSH client to only allow an encryption 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. ST Application Note FCS_SSH_EXT.1.8 Test Assurance Activates were updated as specified by TD0164. FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses ecdsa-sha2-nistp256 and ecdsa-sha2- nistp384 as its public key algorithm(s) and rejects all other public key algorithms. Application Note 72 Allied Telesis x930 Series Switches Security Target Page 35 of 89 Implementations that select only ssh-rsa will not achieve the 112-bit security strength in the digital signature generation for SSH authentication as is recommended in NIST SP 800-131A. Future versions of this profile may remove ssh-rsa as a selection. Assurance Activity TSS 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. Guidance 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). Test 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 2: The evaluator shall configure an SSH client to only allow the ssh-dsa public key algorithm and no other public key algorithms. The evaluator shall attempt to establish an SSH connection from the SSH client to the TOE and observe that the connection is rejected. FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses hmac-sha2-256 and no other MAC algorithms as its MAC algorithm(s) and rejects all other MAC algorithm(s). Application Note 73 RFC 5647 specifies the use of the AEAD_AES_128_GCM and AEAD_AES_256_GCM algorithms in SSH. As described in RFC 5647, AEAD_AES_128_GCM and AEAD_AES_256_GCM can only be chosen as MAC algorithms when the same algorithm is being used as the encryption algorithm. RFC 6668 specifies the use of the sha2 algorithms in SSH. Assurance Activity TSS 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. Guidance 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). Test Allied Telesis x930 Series Switches Security Target Page 36 of 89 Test 1: The evaluator shall establish a SSH connection using each of the integrity algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test 2: The evaluator shall configure an SSH client to only allow the “none” MAC algorithm. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. Test 3: The evaluator shall configure an SSH client to only allow the hmac-md5 MAC algorithm. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. FCS_SSHS_EXT.1.7 The TSF shall ensure that ecdh-sha2-nistp256 and ecdh-sha2-nistp384 are the only allowed key exchange methods used for the SSH protocol. Assurance Activity TSS The evaluator shall check the TSS to ensure that it describes how the SFR is met. This comprises checking that the TSS clarifies that both thresholds are checked by the TOE and that rekeying is performed upon reaching the threshold whichever is hit first. Guidance 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. Test 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 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. FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections the same session keys are used for a threshold of no longer than one hour, and no more than one gigabyte of transmitted data. After either of the thresholds are reached a rekey needs to be performed. Assurance Activity Guidance 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. Test Allied Telesis x930 Series Switches Security Target Page 37 of 89 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. 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 a rekey has been performed. This could be done, e.g., by checking that a corresponding audit event has been generated by the TOE, if the TOE supports auditing of rekey events. The evaluator uses available methods and tools to demonstrate that rekeying occurs. 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 a rekey has been performed. This could be done, e.g., by checking that a corresponding audit event has been generated by the TOE, if the TOE supports auditing of rekey events. The evaluator uses available methods and tools to demonstrate that rekeying occurs. 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(1)/AdminAct). Application Note 168 This SFR defines two thresholds - one for the maximum time span the same session keys can be used and the other one for the maximum amount of data that can be transmitted using the same session keys. Both thresholds need to be implemented and a rekey needs to be performed on whichever threshold is reached first. For the maximum transmitted data threshold the total incoming and outgoing data needs to be counted. The rekey applies to all session keys (encryption, integrity protection) for incoming and outgoing traffic. It is acceptable for a TOE to implement lower thresholds than the maximum values defined in the SFR. For any configurable threshold related to this requirement the guidance documentation needs to specify how the threshold can be configured. The allowed values must either be specified in the guidance documentation and must be lower or equal to the thresholds specified in this SFR or the TOE must not accept values beyond the thresholds specified in this SFR. ST Application Note FCS_SSH_EXT.1.8 was updated as specified by TD0167. Assurance Activity Allied Telesis x930 Series Switches Security Target Page 38 of 89 TSS The evaluator shall check the TSS to ensure that it describes how the SFR is met. This comprises checking that the TSS clarifies that both thresholds are checked by the TOE and that rekeying is performed upon reaching the threshold whichever is hit first. Guidance 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. Test 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. 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 a rekey has been performed. This could be done, e.g., by checking that a corresponding audit event has been generated by the TOE, if the TOE supports auditing of rekey events. The evaluator uses available methods and tools to demonstrate that rekeying occurs. 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 a rekey has been performed. This could be done, e.g., by checking that a corresponding audit event has been generated by the TOE, if the TOE supports auditing of rekey events. The evaluator uses available methods and tools to demonstrate that rekeying occurs. 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(1)/AdminAct). 6.1.3.3 FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 Allied Telesis x930 Series Switches Security Target Page 39 of 89 The TSF shall implement TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346) supporting the following ciphersuites: • TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268. Application Note 74 The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. Note that RFC 5246 makes TLS_RSA_WITH_AES_128_CBC_SHA a mandatory ciphersuite, but it is treated as optional for the purposes of conformance with this cPP (i.e. the selection of ‘TLS 1.2 (RFC 5246)’ will be accepted as conformant with this SFR even if TLS_RSA_WITH_AES_128_CBC_SHA is not one of the ciphersuites listed in the ST). These requirements will be revisited as new TLS versions are standardized by the IETF. In a future version of this cPP TLS v1.2 will be required for all TOEs. ST Application Note FCS_TLSC_EXT.1.1 and the application note were updated as specified by TD0226. Assurance Activity TSS 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. Guidance The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. Test Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES). Test 2: The evaluator shall attempt to establish the connection using a server with a server certificate that contains the Server Authentication purpose in the extendedKeyUsage field and verify that a connection is established. The evaluator will then verify that the client rejects an otherwise valid server certificate that lacks the Server Authentication purpose in the extendedKeyUsage field and a connection is not established. Ideally, the two certificates should be identical except for the extendedKeyUsage field. Test 3: The evaluator shall send a server certificate in the TLS connection that the does not match the server-selected ciphersuite (for example, send a ECDSA certificate while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite).The evaluator shall verify that the TOE disconnects after receiving the server’s Certificate handshake message. Allied Telesis x930 Series Switches Security Target Page 40 of 89 Test 4: The evaluator shall configure the server to select the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the client denies the connection. Test 2 in FCS_TLSS_EXT.1.1 or FCS_TLSS_EXT.2.1 can be used as a substitute for this test. Test 5: The evaluator perform the following modifications to the traffic: a) Change the TLS version selected by the server in the Server Hello to a non-supported TLS version (for example 1.3 represented by the two bytes 03 04) and verify that the client rejects the connection. b) Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the client rejects the Server Key Exchange handshake message (if using a DHE or ECDHE ciphersuite) or that the server denies the client’s Finished handshake message. c) Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello. d) Modify the signature block in the Server’s Key Exchange handshake message, and verify that the client rejects the connection after receiving the Server Key Exchange message. 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. 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. f) Send a garbled message from the Server after the Server has issued the ChangeCipherSpec message and verify that the client denies the connection. ST Application Note FCS_TLSC_EXT.1.1 Tests 5d and 5e were updated as specified by TD0165 and TD0289. FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference identifier according to RFC 6125. Application Note 75 The rules for verification of identify are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g. entering a URL into a web browser or clicking a link), by configuration (e.g. configuring the name of a mail server or authentication server), or by an application (e.g. a parameter of an API) depending on the application service. Based on a singular reference identifier’s source domain and application service type (e.g. HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server’s certificate. The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged as against best practices but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the assurance activity. Assurance Activity Allied Telesis x930 Series Switches Security Target Page 41 of 89 TSS The evaluator shall ensure that the TSS describes the client’s method of establishing all reference identifiers from the administrator/application-configured reference identifier, including which types of reference identifiers are supported (e.g. Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE. Guidance 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. Test The evaluator shall configure the reference identifier according to the AGD guidance and perform the following tests during a TLS connection: a) 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. 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. b) 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. c) 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 contains 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. d) 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. e) Test 5: The evaluator shall perform the following wildcard tests with each supported type of reference identifier: 1) The evaluator shall present a server certificate containing a wildcard that is not in the left- most label of the presented identifier (e.g. foo.*.example.com) and verify that the connection fails. 2) The evaluator shall present a server certificate containing a wildcard in the left-most label (e.g. *.example.com). The evaluator shall configure the reference identifier with a single left-most label (e.g. foo.example.com) and verify that the connection succeeds. The evaluator shall configure the reference identifier without a left-most label as in the certificate (e.g. example.com) and verify that the connection fails. The evaluator shall configure the reference identifier with two left-most labels (e.g. bar.foo.example.come) and verify that the connection fails. f) 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 Allied Telesis x930 Series Switches Security Target Page 42 of 89 containing the correct DNS name and service identifier in the URIName or SRVName fields of the SAN and verify that the connection succeeds. The evaluator shall repeat this test with the wrong service identifier (but correct DNS name) and verify that the connection fails. g) Test 7: [conditional] If pinned certificates are supported the evaluator shall present a certificate that does not match the pinned certificate and verify that the connection fails. ST Application Note FCS_TLSC_EXT.1.2 Tests 1 & 3 were updated as specified by TD0257. FCS_TLSC_EXT.1.3 The TSF shall only establish a trusted channel if the peer certificate is valid. Application Note 76 Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity is tested in accordance with testing performed for FIA_X509_EXT.1. Assurance Activity Test 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. FCS_TLSC_EXT.1.4 The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: none and no other curves. Application Note 77 If ciphersuites with elliptic curves were selected in FCS_TLSC_EXT.1.1, a selection of one or more curves is required. If no ciphersuites with elliptic curves were selected in FCS_TLS_EXT.1.1, then ‘none’ should be selected. This requirement limits the elliptic curves allowed for authentication and key agreement to the NIST curves from FCS_COP.1(2) and FCS_CKM.1 and FCS_CKM.2. This extension is required for clients supporting Elliptic Curve ciphersuites. Assurance Activity TSS The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behaviour is performed by default or may be configured. Guidance 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. Test Allied Telesis x930 Series Switches Security Target Page 43 of 89 Test 1: The evaluator shall configure the server to perform an ECDHE key exchange in the TLS connection using a non-supported curve (for example P-192) and shall verify that the TOE disconnects after receiving the server’s Key Exchange handshake message. 6.1.4 Class FIA: Identification and Authentication 6.1.4.1 FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “"” (0x22 double quote), “'” (0x27 single quote), “+”, “,”, “-“, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “[“, “\”, “]”, “_” (0x5F underscore), “`” (0x60 grave accent), “{“, “|”, “}”, “~”; b) Minimum password length shall be settable by the Security Administrator, and shall support passwords of 15 characters or greater. Application Note 14 The ST author selects the special characters that are supported by TOE; they may optionally list additional special characters supported using the assignment. "Administrative passwords“ refers to passwords used by administrators at the local console, over protocols that support passwords, such as SSH and HTTPS, or to grant configuration data that supports other SFRs in the Security Target. Assurance Activity Guidance The evaluator shall examine the guidance documentation to determine that it provides guidance to security administrators on the composition of strong passwords, and that it provides instructions on setting the minimum password length. Test The evaluator shall perform the following tests. a) Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing. 6.1.4.2 FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the identification and authentication process: • Display the warning banner in accordance with FTA_TAB.1; • Respond to ICMP echo requests, perform ARP, perform routing services (e.g. RIP, OSPF). FIA_UIA_EXT.1.2 Allied Telesis x930 Series Switches Security Target Page 44 of 89 The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user. Application Note 15 This requirement applies to users (administrators and external IT entities) of services available from the TOE directly, and not services available by connecting through the TOE. While it should be the case that few or no services are available to external entities prior to identification and authentication, if there are some available (perhaps ICMP echo) these should be listed in the assignment statement; otherwise “no other actions” should be selected. Authentication can be password-based through the local console or through a protocol that supports passwords (such as SSH), or be certificate based (such as SSH, TLS). For communications with external IT entities (e.g., an audit server or NTP server, for instance), such connections must be performed in accordance with FTP_ITC.1, whose protocols perform identification and authentication. This means that such communications (e.g., establishing the IPsec connection to the authentication server) would not have to be specified in the assignment, since establishing the connection “counts” as initiating the identification and authentication process. Assurance Activity TSS 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”. Guidance The evaluator shall examine the guidance documentation to determine that any necessary reparatory 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 guidance documentation provides clear instructions for successfully logging on. If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the guidance documentation provides sufficient instruction on limiting the allowed services. Test The evaluator shall perform the following tests for each method by which administrators access the TOE (local and remote), as well as for each type of credential supported by the login method: a) Test 1: The evaluator shall use the guidance documentation to configure the appropriate credential supported for the login method. For that credential/ login method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access. b) Test 2: The evaluator shall configure the services allowed (if any) according to the guidance documentation, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement. c) 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. Allied Telesis x930 Series Switches Security Target Page 45 of 89 6.1.4.3 FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, remote password-based authentication via RADIUS to perform administrative user authentication. Application Note 16 The assignment should be used to identify any additional local authentication mechanisms supported. Local authentication mechanisms are defined as those that occur through the local console; remote administrative sessions (and their associated authentication mechanisms) are specified in FTP_TRP.1. Assurance Activity Evaluation Activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1. 6.1.4.4 FIA_UAU.7 Protected Authentication Feedback FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console. Application Note 17 “Obscured feedback” implies the TSF does not produce a visible display of any authentication data entered by a user (such as the echoing of a password), although an obscured indication of progress may be provided (such as an asterisk for each character). It also implies that the TSF does not return any information during the authentication process to the user that may provide any indication of the authentication data. Assurance Activity Test The evaluator shall perform the following test for each method of local login allowed: a) Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information. 6.1.4.5 FIA_X509_EXT.1 X.509 Certificate Validation ST Application Note FIA_X509_EXT.1 is a selection-based SFR as specified by TD0182 and included to support FCS_TLSC_EXT.1. FIA_X509_EXT.1.1 The TSF shall validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certificate path validation. • The certificate path must terminate with a trusted CA certificate. • The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates. • The TSF shall validate the revocation status of the certificate using the Online Certificate Status Protocol (OCSP) as specified in RFC 2560. Allied Telesis x930 Series Switches Security Target Page 46 of 89 • The TSF shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id- kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id- kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. o OCSP Certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. Application Note 18 FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author selects whether revocation status is verified using OCSP or CRLs. The trusted channel/path protocols require that certificates are used; this use requires that the extendedKeyUsage rules are verified. The validation is expected to end in a trusted root CA certificate in a root store managed by the platform. Application Note TD0117 The TSS shall describe when revocation checking is performed. 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). ST Application Note FIA_X509_EXT.1.1 was updated as specified by TD0169; however, the added option was not selected by the ST author. FIA_X509_EXT.1.2 The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. Application Note 19 This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added as trusted CA certificates. Assurance Activity TSS The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. The evaluator shall ensure the TSS describes when the check of validity of the certificates takes place. It is expected that revocation checking is performed when a certificate is used in an authentication step and when performing trusted updates (if selected). It is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). Allied Telesis x930 Series Switches Security Target Page 47 of 89 Test The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). The evaluator shall perform the following tests for FIA_X509_EXT.1.1: a) 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. b) Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. c) 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. d) 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 CLR fails. e) 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.) f) 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.) g) 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.) The evaluator shall perform the following tests for FIA_X509_EXT.1.2. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The 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). Allied Telesis x930 Series Switches Security Target Page 48 of 89 a) 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). b) 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). ST Application Note FIA_X509_EXT.1 Assurance Activities and Application Notes were updated as specified by TD0117, TD0187, TD0228. 6.1.4.6 FIA_X509_EXT.2 X.509 Certificate Authentication ST Application Note FIA_X509_EXT.2 is a selection-based SFR as specified by TD0182 and included to support FCS_TLSC_EXT.1. FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for TLS and no additional uses. Application Note 20 The ST author’s selection matches the selection of FTP_ITC.1.1. Certificates may optionally be used for trusted updates of system software (FPT_TUD_EXT.1) and for integrity verification (FPT_TST_EXT.2). FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall accept the certificate. Application Note 21 Often a connection must be established to check the revocation status of a certificate -either to download a CRL or to perform a lookup using OCSP. The selection is used to describe the behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the selection determines the validity. The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. If the administrator-configured option is selected by the ST Author, the ST Author also selects the corresponding function in FMT_SMF.1. Assurance Activity TSS Allied Telesis x930 Series Switches Security Target Page 49 of 89 The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates. The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. Test The evaluator shall perform the following test for each trusted channel: The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE IT entity. The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2is 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. 6.1.5 Class FMT: Security Management 6.1.5.1 FMT_MOF.1(1)/TrustedUpdate Management of Security Functions Behaviour FMT_MOF.1.1(1)/TrustedUpdate The TSF shall restrict the ability to enable the functions to perform manual update to Security Administrators. Application Note 23 FMT_MOF.1(1)/TrustedUpdate restricts the initiation of manual updates to Security Administrators. Assurance Activity Test The evaluator shall try to perform the update using a legitimate update image without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all –depending on the configuration of the TOE). This test should fail. The evaluator shall try to perform the update with prior authentication as security administrator using a legitimate update image. This test should pass. This test case should be covered by the tests for FPT_TUD_EXT.1 already. 6.1.5.2 FMT_MOF.1(1)/Audit Management of Security Functions Behaviour FMT_MOF.1.1(1)/Audit The TSF shall restrict the ability to determine the behaviour of, modify the behaviour of the functions transmission of audit data to an external IT entity to Security Administrators. Application Note 43 Allied Telesis x930 Series Switches Security Target Page 50 of 89 FMT_MOF.1(1)/Audit should always be chosen if the transmission protocol for transmission of audit data to an external IT entity as defined in FAU_STG_EXT.1.1 is configurable. Assurance Activity Test The evaluator shall try to modify all parameters for configuration of the transmission protocol for transmission of audit data to an external IT entity without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all – depending on the configuration of the TOE). This test should fail. The evaluator shall try to modify all parameters for configuration of the transmission protocol for transmission of audit data to an external IT entity with prior authentication as security administrator. The effects of the modifications should be confirmed. The evaluator does not necessarily have to test all possible values of all parameters for configuration of the transmission protocol for transmission of audit data to an external IT entity but at least one allowed value per configurable parameter. 6.1.5.3 FMT_MOF.1(2)/Audit Management of Security Functions Behaviour FMT_MOF.1.1(2)/Audit The TSF shall restrict the ability to determine the behaviour of, modify the behaviour of the functions handling of audit data to Security Administrators. Application Note 44 FMT_MOF.1(2)/Audit should only be chosen if the handling of audit data is configurable. The term ‘handling of audit data’ refers to the different options for selection and assignments in SFRs FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2. Assurance Activity Test The evaluator shall try to modify all parameters for configuration of the handling of audit data without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all –depending on the configuration of the TOE). This test should fail. The term ‘handling of audit data’ refers to the different options for selection and assignments in SFRs FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2. The evaluator shall try to modify all parameters for configuration of the handling of audit data with prior authentication as security administrator. The effects of the modifications should be confirmed. The term ‘handling of audit data’ refers to the different options for selection and assignments in SFRs FAU_STG_EXT.1.2, FAU_STG_EXT.1.3 and FAU_STG_EXT.2. The evaluator does not necessarily have to test all possible values of all parameters for configuration of the handling of audit data but at least one allowed value per configurable parameter. 6.1.5.4 FMT_MTD.1 Management of TSF Data FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF Data to Security Administrators. Application Note 24 Allied Telesis x930 Series Switches Security Target Page 51 of 89 The word “manage” includes but is not limited to create, initialize, view, change default, modify, delete, clear, and append. This SFR includes also the resetting of user passwords by the Security Administrator. Assurance Activity TSS The evaluator shall examine the TSS to determine that, for each administrative function identified in the guidance documentation; those that are accessible through an interface prior to administrator log-in are identified. For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users. Guidance The evaluator shall review the guidance documentation to determine that each of the TSF-data- manipulating functions implemented in response to the requirements of the cPP is identified, and that configuration information is provided to ensure that only administrators have access to the functions. 6.1.5.5 FMT_MTD.1/AdminAct Management of TSF Data FMT_MTD.1.1/AdminAct The TSF shall restrict the ability to modify, delete, generate/import the cryptographic keys to Security Administrators. Application Note 48 FMT_MTD.1.1/AdminAct should only be chosen if cryptographic keys can be modified, deleted or generated/imported by the Security Administrator. Assurance Activity Test The evaluator shall try to perform at least one of the related actions without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all – depending on the configuration of the TOE). This test should fail. The evaluator shall try to perform at least one of the related actions with prior authentication as security administrator. This test should pass. 6.1.5.6 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: • Ability to administer the TOE locally and remotely; • Ability to configure the access banner; • Ability to configure the session inactivity time before session termination or locking; • Ability to update the TOE, and to verify the updates using hash comparison capability prior to installing those updates; • Ability to configure audit behavior; • Ability to configure the list of TOE-provided services available before an entity is identified and authenticated, as specified in FIA_UIA_EXT.1. Application Note 25 Allied Telesis x930 Series Switches Security Target Page 52 of 89 The TOE must provide functionality for both local and remote administration, including the ability to configure the access banner for FTA_TAB.1 and the session inactivity time(s) for FTA_SSL.3 & FTA_SSL.4. The item “Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates” includes the relevant management functions from FMT_MOF.1(1)/TrustedUpdate, FMT_MOF.1(2)/TrustedUpdate (if included in the ST), FIA_X509_EXT.2.2 and FPT_TUD_EXT.2.2 (if included in the ST and if they include an administrator-configurable action). Similarly, the selection “Ability to configure audit behavior” includes the relevant management functions from FMT_MOF.1(1)/Audit, FMT_MOF.1(2)/Audit, FMT_MOF.1.1(1)/AdminAct, FMT_MOF.1.1(2)/AdminAct and FMT_MOF.1/LocSpace (for all of these SFRs that are included in the ST). If the TOE offers the ability for the administrator to configure the audit behaviour, configure the services available prior to identification or authentication, or if any of the cryptographic functionality on the TOE can be configured, then the ST author makes the appropriate choice or choices in the second selection, otherwise select "No other capabilities." The selection 'Ability to configure thresholds for SSH rekeying' shall be included in the ST if the TOE supports configuration of the thresholds for the mechanisms used to fulfil FCS_SSHC_EXT.1.8 or FCS_SSHS_EXT.1.8 (such configuration then requires the inclusion of FMT_MOF.1(1)/AdminAct in the ST). If the TOE places limits on the values accepted for the thresholds then this is stated in the TSS. ST Application Note FMT_SMF.1.1 was updated as specified by TD0090 and TD0167. Assurance Activity The security management functions for FMT_SMF.1 are distributed throughout the cPP and are included as part of the requirements in FTA_TAB.1, FTA_SSL.3, FTA_SSL.4, FMT_MOF.1(1)/TrustedUpdate, FMT_MOF.1(2)/TrustedUpdate (if included in the ST), IA_X509_EXT.2.2 & FPT_TUD_EXT.2.2 (if included in the ST and if they include an administrator-configurable action), FMT_MOF.1(1)/Audit, FMT_MOF.1(2)/Audit, FMT_MOF.1.1(1)/AdminAct, FMT_MOF.1.1(2)/AdminAct and FMT_MOF.1/LocSpace (for all of these SFRs that are included in the ST), FMT_MTD, FPT_TST_EXT, and any cryptographic management functions specified in the reference standards. Compliance to these requirements satisfies compliance with FMT_SMF.1 6.1.5.7 FMT_SMR.2 Restrictions on Security Roles FMT_SMR.2.1 The TSF shall maintain the roles: • Security Administrator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions: • The Security Administrator role shall be able to administer the TOE locally; • The Security Administrator role shall be able to administer the TOE remotely are satisfied. Application Note 26 Allied Telesis x930 Series Switches Security Target Page 53 of 89 FMT_SMR.2.3 requires that a Security Administrator be able to administer the TOE through the local console and through a remote mechanism (IPsec, SSH, TLS, HTTPS). Assurance Activity Guidance The evaluator shall review the guidance documentation to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration. Test 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. 6.1.6 Class FPT: Protection of the TSF 6.1.6.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. Application Note 27 The intent of this requirement is for the device to protect keys, key material, and authentication credentials from unauthorized disclosure. This data should only be accessed for the purposes of their assigned security functionality, and there is no need for them to be displayed/accessed at any other time. This requirement does not prevent the device from providing indication that these exist, are in use, or are still valid. It does, however, restrict the reading of the values outright. Assurance Activity TSS 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. 6.1.6.2 FPT_APW_EXT.1 Protection of Administrator Passwords FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords. Application Note 28 The intent of the requirement is that raw password authentication data are not stored in the clear, and that no user or administrator is able to read the plaintext password through “normal” interfaces. An all- Allied Telesis x930 Series Switches Security Target Page 54 of 89 powerful administrator of course could directly read memory to capture a password but is trusted not to do so. Assurance Activity TSS The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored. The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. 6.1.6.3 FPT_TST_EXT.1 TSF Testing FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests during initial start-up (on power on), at the request of the authorised user to demonstrate the correct operation of the TSF: • AES Known Answer Test • HMAC Known Answer Test • SHA Known Answer Test • DRBG Known Answer Test • RSA Known Answer Test • ECDSA Pairwise Consistency Test • ECDH Known Answer Test • Firmware Integrity Test. Application Note 29 It is expected that self-tests are carried out during initial start-up (on power on). Other options should only be used if the developer can justify why they are not carried out during initial start-up. It is expected that at least self-tests for verification of the integrity of the firmware and software as well as for the correct operation of cryptographic functions necessary to fulfil the SFRs will be performed. If not all self-test are performed during start-up multiple iterations of this SFR are used with the appropriate options selected. In future versions of this cPP the suite of self-tests will be required to contain at least mechanisms for measured boot including self-tests of the components which perform the measurement. Application Note 30 If certificates are used by the self-test mechanism (e.g. for verification of signatures for integrity verification), certificates are validated in accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TST_EXT.2 must be included in the ST. Assurance Activity TSS The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written "shall be used). The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. Allied Telesis x930 Series Switches Security Target Page 55 of 89 Guidance The evaluator shall also ensure that the guidance documentation describes the possible errors that may result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS. Test Future versions of this cPP will mandate a clearly defined minimum set of self tests. But also for this version of the cPP it is expected that at least the following tests are performed: a) Verification of the integrity of the firmware and executable software of the TOE b) Verification of the correct operation of the cryptographic functions necessary to fulfill any of the SFRs. Although formal compliance is not mandated, the self tests performed should aim for a level of confidence comparable to: a) FIPS 140-2, chap. 4.9.1, Software/firmware integrity test for the verification of the integrity of the firmware and executable software. b) FIPS 140-2, chap. 4.9.1, Cryptographic algorithm test for the verification of the correct operation of cryptographic functions. Alternatively, national requirements of any CCRA member state for the security evaluation of cryptographic functions should be considered as appropriate. The evaluator shall verify that the self tests described above are either carried out during initial start-up and that the developer has justified any deviation from this (if applicable). 6.1.6.4 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and the most recently installed version of the TOE firmware/software. Application Note 31 If a trusted update can be installed on the TOE with a delayed activation the version of both the currently executing image and the installed but inactive image must be provided. In this case the option 'the most recently installed version of the TOE firmware/software' needs to be chosen from the selection in FPT_TUD_EXT.1.1 and the TSS needs to describe how and when the inactive version becomes active. If all trusted updates become active as part of the installation process, only the currently executing version needs to be provided. In this case the option 'no other TOE firmware/software version' shall be chosen from the selection in FPT_TUD_EXT.1.1. ST Application Note FPT_TUD_EXT.1.1 was updated as specified by TD0154. FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and no other update mechanism. Application Note 32 Allied Telesis x930 Series Switches Security Target Page 56 of 89 The selection in FPT_TUD_EXT.1.2 distinguishes the support of automatic checking for updates and support of automatic updates. The first option refers to a TOE that checks whether a new update is available, communicates this to the administrator (e.g. through a message during an administrator session, through log files) but requires some action by the administrator to actually perform the update. The second option refers to a TOE that checks for updates and automatically installs them upon availability. FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a published hash prior to installing those updates. Application Note 33 The digital signature mechanism referenced in the selection of FPT_TUD_EXT.1.3 is one of the algorithms specified in FCS_COP.1(2). The published hash referenced in FPT_TUD_EXT.1.3 is generated by one of the functions specified in FCS_COP.1(3). The ST author should choose the mechanism implemented by the TOE; it is acceptable to implement both mechanisms. Application Note 34 Future versions of this cPP will mandate the use of a digital signature mechanism for trusted updates. Application Note 35 If certificates are used by the update verification mechanism, certificates are validated in accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.2 must be included in the ST. Application Note 36 “Update” in the context of this SFR refers to the process of replacing a non-volatile, system resident software component with another. The former is referred to as the NV image, and the latter is the update image. While the update image is typically newer than the NV image, this is not a requirement. There are legitimate cases where the system owner may want to rollback a component to an older version (e.g. when the component manufacturer releases a faulty update, or when the system relies on an undocumented feature no longer present in the update). Likewise, the owner may want to update with the same version as the NV image to recover from faulty storage. All discrete software components (e.g. applications, drivers, kernel, firmware) of the TSF, should be digitally signed by the corresponding manufacturer and subsequently verified by the mechanism performing the update. Since it is recognized that components may be signed by different manufacturers, it is essential that the update process verify that both the update and NV images were produced by the same manufacturer (e.g. by comparing public keys) or signed by legitimate signing keys (e.g. successful verification of certificates when using X.509 certificates). Assurance Activity TSS 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 Allied Telesis x930 Series Switches Security Target Page 57 of 89 processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification. If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the TSS contains a description of how the certificates are contained on the device. The evaluator also ensures that the TSS (or guidance documentation) describes how the certificates are installed/updated/selected, if necessary. 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. 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. If a published hash is used to protect the trusted update mechanism, then the evaluator shall verify that the trusted update mechanism does involve an active authorization step of the Security Administrator, and that download of the published hash value, hash comparison and update is not a fully automated process involving no active authorization by the Security Administrator. In particular, authentication as Security Administration according to FMT_MOF.1/ManualUpdate needs to be part of the update process when using published hashes. Guidance 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. If a published hash is used to protect the trusted update mechanism, the evaluator shall verify that the guidance documentation describes how the Security Administrator can obtain authentic published hash values for the updates. Test The evaluator shall perform the following tests: a) Test 1: The evaluator performs the version verification activity to determine the current version of the product as well as the most recently installed version (should be the same version before updating). The evaluator obtains a legitimate update using procedures described in the guidance documentation and verifies that it is successfully installed on the TOE. For some TOEs loading the update onto the TOE and activation of the update are separate steps (‘activation’ could be performed e.g. by a distinct activation step or by rebooting the device). In that case the evaluator verifies after loading the update onto the TOE but before activation of the update that the current version of the product did not change but the most recently installed version has changed to the new product version. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again. b) Test 2 (if digital signatures are used): The evaluator first confirms that no updates are pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. The evaluator obtains or produces illegitimate updates as defined below, and attempts to install them on the TOE. The evaluator verifies that the TOE rejects all of the illegitimate updates. 1) A modified version (e.g. using a hex editor) of a legitimately signed update. Allied Telesis x930 Series Switches Security Target Page 58 of 89 2) An image that has not been signed. 3) An image signed with an invalid signature. Test 2 (if published hash is verified on the TOE): 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. 2) The evaluator uses a legitimate update and tries to perform verification of the hash value without storing the published hash value on the TOE. The evaluator confirms that this attempt fails. Depending on the implementation of the TOE it might not be possible to attempt the verification of the hash value without providing a hash value to the TOE, e.g. if the hash value needs to be handed over to the TOE as a parameter in a command line message and the syntax check of the command prevents the execution of the command without providing a hash value. In that case the mechanism that prevents the execution of this check shall be tested accordingly, e.g. that the syntax check rejects the command without providing a hash value, and the rejection of the attempt is regarded as sufficient verification of the correct behaviour of the TOE in failing to verify the hash. The evaluator then attempts to install the update on the TOE (in spite of the unsuccessful hash verification) and confirms that this fails. Depending on the implementation of the TOE, the TOE might not allow to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE. 3) If the TOE allows a gap between the installation of an update and a required reboot or activation to execute the updated code, the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs. Depending on the point in time when the attempted update is rejected, the most recently installed version might or might not be updated. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt. 4) The evaluator shall perform the Tests 1 and 2 for all methods supported (manual updates, automatic checking for updates, automatic updates). ST Application Note FPT_TUD_EXT.1 Assurance Activities were updated as specified by TD0094 and TD0154. 6.1.6.5 FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. Allied Telesis x930 Series Switches Security Target Page 59 of 89 Application Note 37 The TSF does not provide reliable information about the current time at the TOE’s location by itself, but depends on external time and date information, either provided manually by the administrator or through the use of an NTP server. The term ‘reliable time stamps’ refers to the strict use of the time and date information, that is provided externally, and the logging of all changes to the time settings including information about the old and new time. With this information the real time for all audit data can be calculated. Assurance Activity TSS The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. The evaluator examines the guidance documentation to ensure it instructs the administrator how to set the time. If the TOE supports the use of an NTP server, the guidance documentation instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication. Test The evaluator shall perform the following tests: a) Test 1: The evaluator uses the guidance documentation to set the time. The evaluator shall then use an available interface to observe that the time was set correctly. b) Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance documentation to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol claimed in the guidance documentation. If the audit component of the TOE consists of several parts with independent time information, then the evaluator shall verify that the time information between the different parts are either synchronized or that it is possible for all audit information to relate the time information of the different part to one base information unambiguously. 6.1.7 Class FTA: TOE Access 6.1.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, • terminate the session after a Security Administrator-specified time period of inactivity. Assurance Activity Test The evaluator shall perform the following test: Allied Telesis x930 Series Switches Security Target Page 60 of 89 a) Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the evaluator then ensures that re-authentication is needed when trying to unlock the session. 6.1.7.2 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-configurable time interval of session inactivity. Assurance Activity Test The evaluator shall perform the following test: a) Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period. 6.1.7.3 FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. Assurance Activity Test The evaluator shall perform the following tests: a) Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session as been terminated. b) Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated. 6.1.7.4 FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE. Application Note 38 This requirement is intended to apply to interactive sessions between a human user and a TOE. IT entities establishing connections or programmatic connections (e.g., remote procedure calls over a network) are not required to be covered by this requirement. Assurance Activity Allied Telesis x930 Series Switches Security Target Page 61 of 89 TSS The evaluator shall check the TSS to ensure that it details each method of access (local and remote) available to the administrator (e.g., serial port, SSH, HTTPS). Test The evaluator shall also perform the following test: a) Test 1: The evaluator follows the guidance documentation to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance. 6.1.8 Class FTP: Trusted Path/Channels 6.1.8.1 FTP_ITC.1 Inter-TSF Trusted Channel FTP_ITC.1.1 The TSF shall be capable of using TLS to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, authentication server that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. FTP_ITC.1.2 The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for Syslog and RADIUS communication. Application Note 39 The intent of the above requirement is to provide a means by which a cryptographic protocol may be used to protect external communications with authorized IT entities that the TOE interacts with to perform its functions. The TOE uses at least one of the listed protocols for communications with the server that collects the audit information. If it communicates with an authentication server (e.g., RADIUS), then the ST author chooses “authentication server” in FTP_ITC.1.1 and this connection must be capable of being protected by one of the listed protocols. If other authorized IT entities (e.g., NTP server) are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections). The ST author selects the mechanism or mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Appendix B corresponding to their selection are included in the ST. While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorized IT entity. The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection. Allied Telesis x930 Series Switches Security Target Page 62 of 89 ST Application Note Application Note 39 was updated as specified by TD0126. Assurance Activity TSS The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT entity. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. Guidance The evaluator shall confirm that the guidance documentation contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally broken. Test The evaluator shall perform the following tests: a) 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. b) 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. c) Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. d) Test 4: The evaluators shall, for each protocol associated with each authorized IT entity tested during test 1, the connection is physically interrupted. The evaluator shall ensure that when physical connectivity is restored, communications are appropriately protected. Further assurance activities are associated with the specific protocols. 6.1.8.2 FTP_TRP.1 Trusted Path FTP_TRP.1.1 The TSF shall be capable of using SSH to provide a communication path between itself and authorized remote administrators that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and provides detection of modification of the channel data. FTP_TRP.1.2 The TSF shall permit remote administrators to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. Application Note 40 Allied Telesis x930 Series Switches Security Target Page 63 of 89 This requirement ensures that authorized remote administrators initiate all communication with the TOE via a trusted path, and that all communication with the TOE by remote administrators is performed over this path. The data passed in this trusted communication channel are encrypted as defined by the protocol chosen in the first selection. The ST author selects the mechanism or mechanisms supported by the TOE, and then ensures that the detailed protocol requirements in Appendix B corresponding to their selection are included in the ST. Assurance Activity TSS The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. Guidance The evaluator shall confirm that the guidance documentation contains instructions for establishing the remote administrative sessions for each supported method. Test The evaluator shall perform the following tests: a) Test 1: The evaluators shall ensure that communications using each specified (in the guidance documentation) remote administration method is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful. b) 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. c) Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. d) Test 4: The evaluators shall ensure that, for each protocol associated with each authorized IT entity tested during test 1, the connection is physically interrupted. The evaluator shall ensure that when physical connectivity is restored, communications are appropriately protected. Further assurance activities are associated with the specific protocols. 6.2 Security Assurance Requirements This Security Target is conformant with the assurance requirements specified in the [NDcPP]. Table 7: Assurance Requirements Assurance Class Assurance Component Security Target (ASE) Conformance claims (ASE_CCL.1) Extended components definition (ASE_ECD.1) ST introduction (ASE_INT.1) Security objectives for the operational environment (ASE_OBJ.1) Stated security requirements (ASE_REQ.1) Allied Telesis x930 Series Switches Security Target Page 64 of 89 Security Problem Definition (ASE_SPD.1) TOE summary specification (ASE_TSS.1) Development (ADV) Basic functional specification (ADV_FSP.1) Guidance documents (AGD) Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) Life cycle support (ALC) Labeling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) Tests (ATE) Independent testing –sample (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1) 6.2.1 Extended Security Assurance Requirements These requirements are taken directly from the cPP. 6.2.1.1 ASE: Security Target The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be Evaluation Activities specified within the [SD] that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type. [NDcPP, Appendix D] provides a description of the information expected to be provided regarding the quality of entropy in the random bit generator. The requirements for exact conformance of the Security Target are described in [NDcPP, 2] and in [SD, 3.1]. 6.2.1.1.1 Conformance Claims (ASE_CCL.1) The table below indicates the actions to be taken for particular ASE_CCL.1 elements in order to determine exact conformance with a cPP. Table 8: Conformance Claims ASE_CCL.1 Element Evaluator Action ASE_CCL.1.8C The evaluator shall check that the statements of security problem definition in the PP and ST are identical. ASE_CCL.1.9C The evaluator shall check that the statements of security objectives in the PP and ST are identical. ASE_CCL.1.10C 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). 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). If optional SFRs from the cPP are included in the ST then the evaluator shall check that any selection-based SFRs entailed by the optional SFRs adopted are also included in the ST. 6.2.1.1.2 TOE Summary Specification (ASE_TSS.1) Evaluation Activities The TOE summary specification shall describe how the TOE meets each SFR. In the case of entropy analysis the TSS is used in conjunction with required supplementary information on Entropy. Allied Telesis x930 Series Switches Security Target Page 65 of 89 6.2.1.2 ADV: Development The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any required supplementary information required by this cPP that is not to be made public. 6.2.1.2.1 Basic Functional Specification (ADV_FSP.1) The functional specification describes the TOE Security Functions Interfaces (TSFIs). It is not necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to this cPP will necessarily have interfaces to the Operational Environment that are not directly invokable by TOE users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this cPP, the Evaluation Activities for this family focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional “functional specification” documentation is necessary to satisfy the Evaluation Activities specified in the SD. The Evaluation Activities in the SD are associated with the applicable SFRs; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. Evaluation Activities The evaluator shall check the interface documentation to ensure it describes the purpose and method of use for each TSFI that is identified as being security relevant. In this context, TSFI are deemed security relevant if they are used by the administrator to configure the TOE, or to perform other administrative functions (e.g., audit review or performing updates). Additionally, those interfaces that are identified in the ST, or guidance documentation, as adhering to the security policies (as presented in the SFRs), are also considered security relevant. The intent, is that these interfaces will be adequately tested, and having an understanding of how these interfaces are used in the TOE is necessary to ensure proper test coverage is applied. The evaluator shall check the interface documentation to ensure it identifies and describes the parameters for each TSFI that is identified as being security relevant. The documents to be examined for this assurance component in an evaluation are therefore the Security Target, AGD documentation, and any supplementary information required by the cPP for aspects such as entropy analysis or cryptographic key management architecture1 : no additional “functional specification” documentation is necessary to satisfy the Evaluation Activities. The interfaces that need to be evaluated are also identified by reference to the assurance activities listed for each SFR, and are expected to be identified in the context of the Security Target, AGD documentation, and any supplementary information required by the cPP rather than as a separate list specifically for the purposes of CC evaluation. The direct identification of documentation requirements and their assessment as part of the Evaluation Activities for each SFR also means that the tracing required in ADV_FSP.1.2D is treated as implicit, and no separate mapping information is required for this element. However, if the evaluator is unable to perform some other required Evaluation Activity because there is insufficient design and interface information, then the evaluator is entitled to conclude that an adequate 1 The Security Target and AGD documentation are public documents. Supplementary information may be public or proprietary: the cPP and/or Evaluation Activity descriptions will identify where such supplementary documentation is permitted to be proprietary and non-public. Allied Telesis x930 Series Switches Security Target Page 66 of 89 functional specification has not been provided, and hence that the verdict for the ADV_FSP.1 assurance component is a ‘fail’. 6.2.1.3 AGD: Guidance Documentation The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes: • instructions to successfully install the TSF in that environment; and • instructions to manage the security of the TSF as a product and as a component of the larger operational environment; and • instructions to provide a protected administrative capability. Guidance pertaining to particular security functionality must also be provided; requirements on such guidance are contained in the Evaluation Activities specified in the SD. 6.2.1.3.1 Operational User Guidance (AGD_OPE.1) The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. The developer should review the Evaluation Activities contained in the SD to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance. Evaluation Activities The evaluator shall check the requirements below are met by the guidance documentation. Guidance documentation shall be distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. Guidance documentation must be provided for every Operational Environment that the product supports as claimed in the Security Target and must adequately address all platforms claimed for the TOE in the Security Target. The contents of the guidance documentation will be verified by the Evaluation Activities defined below and as appropriate for each individual SFR in section 2 above. In addition to SFR-related Evaluation Activities, the following information is also required. a) The guidance documentation shall contain instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. b) The documentation must describe the process for verifying updates to the TOE by verifying a digital signature. The evaluator shall verify that this process includes the following steps: 1) Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). Allied Telesis x930 Series Switches Security Target Page 67 of 89 2) Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature. c) The TOE will likely contain security functionality that does not fall in the scope of evaluation under this cPP. The guidance documentation shall make it clear to an administrator which security functionality is covered by the Evaluation Activities. 6.2.1.3.2 Preparative Procedures (AGD_PRE.1) As with the operational guidance, the developer should look to the Evaluation Activities to determine the required content with respect to preparative procedures. Evaluation Activities The evaluator shall check the requirements below are met by the preparative procedures. The contents of the preparative procedures will be verified by the Evaluation Activities defined below and as appropriate for each individual SFR in section 2 above. Preparative procedures shall be distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. The contents of the preparative procedures will be verified by the Evaluation Activities defined below and as appropriate for each individual SFR in section 2 above. In addition to SFR-related Evaluation Activities, the following information is also required. Preparative procedures must 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 documentation should be in an informal style and should be written with sufficient detail and explanation that they can be understood and used by the target audience (which will typically include IT staff who have general IT experience but not necessarily experience with the TOE product itself). Preparative procedures must be provided for every Operational Environment that the product supports as claimed in the Security Target and must adequately address all platforms claimed for the TOE in the Security Target. The preparative procedures must include a) instructions to successfully install the TSF in each Operational Environment; and b) instructions to manage the security of the TSF as a product and as a component of the larger operational environment; and c) instructions to provide a protected administrative capability. 6.2.1.4 Class ALC: Life-cycle Support At the assurance level provided for TOEs conformant to this cPP, life-cycle support is limited to end-user- visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level. Allied Telesis x930 Series Switches Security Target Page 68 of 89 6.2.1.4.1 Labelling of the TOE (ALC_CMC.1) This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user. A label could consist of a “hard label” (e.g., stamped into the metal, paper label) or a “soft label” (e.g., electronically presented when queried). The evaluator performs the CEM work units associated with ALC_CMC.1. 6.2.1.4.2 TOE CM Coverage (ALC_CMS.1) Given the scope of the TOE and its associated evaluation evidence requirements, the evaluator performs the CEM work units associated with ALC_CMS.1. 6.2.1.5 Class ATE: Tests Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. For this cPP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. 6.2.1.5.1 Independent Testing – Conformance (ATE_IND.1) Testing is performed to confirm the functionality described in the TSS as well as the guidance documentation (includes “evaluated configuration” instructions). The focus of the testing is to confirm that the requirements specified in Section 5 are being met. The Evaluation Activities in the SD identify the specific testing activities necessary to verify compliance with the SFRs. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this cPP. Evaluation Activities The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. The evaluator shall prepare a test plan that covers all of the testing actions for ATE_IND.1 in the CEM and in the SFR-related Evaluation Activities. While it is not necessary to have one test case per test listed in an Evaluation Activity, the evaluator must show in the test plan that each applicable testing requirement in the SFR-related Evaluation Activities is covered. The test plan identifies the platforms to be tested, and for any platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition and configuration of each platform to be tested, and any setup actions that are necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes Allied Telesis x930 Series Switches Security Target Page 69 of 89 the configuration of any cryptographic engine to be used (e.g. for cryptographic protocols being evaluated). The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives, and the expected results. The test report (which could just be an updated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure, so that a fix was then installed and then a successful re-run of the test was carried out, then the report would show a “fail” result followed by a “pass” result (and the supporting details), and not just the “pass” result2 . 6.2.1.6 Class AVA: Vulnerability Assessment For the first generation of this cPP, the iTC is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products and provide that content into the AVA_VAN discussion. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. This information will be used in the development of future protection profiles. 6.2.1.6.1 Vulnerability Survey (AVA_VAN.1) Appendix A in [SD] provides a guide to the evaluator in performing a vulnerability analysis. Evaluation Activities The evaluator shall document their analysis and testing of potential vulnerabilities with respect to this requirement. This report could be included as part of the test report for ATE_IND, or could be a separate document. The evaluator formulates hypotheses in accordance with process defined in Appendix A. The evaluator documents the flaw hypotheses generated for the TOE in the report in accordance with the guidelines in Appendix A.5. The evaluator shall then perform vulnerability analysis in accordance with Appendix A.4. The results of the analysis shall be documented in the report according to Appendix A.5. 2 It is not necessary to capture failures that were due to errors on the part of the tester or test environment. The intention here is to make absolutely clear when a planned test resulted in a change being required to the originally specified test configuration in the test plan, to the evaluated configuration identified in the ST and guidance documentation, or to the TOE itself. Allied Telesis x930 Series Switches Security Target Page 70 of 89 7. TOE Summary Specification This section provides evaluators and potential consumers of the TOE with a high-level description of each SFR, thereby enabling them to gain a general understanding of how the TOE is implemented. These descriptions are intentionally not overly detailed, thereby disclosing no proprietary information. These sections refer to SFRs defined in Section 6, . The TOE consists of the following Security Functions: • Security Audit • Cryptographic Support • Identification and Authentication • Security Management • Protection of the TSF • TOE Access • Trusted Path/Channels 7.1 Security Audit 7.1.1 Audit Generation The TSF generates audit records for the following events: • Startup and shutdown of the audit function • Administrator login and logout events • Security related configuration changes • Generation of a CSR and associated keypair • Installation of a certificate • Resetting passwords • Failure to establish an SSH session • Successful SSH rekey • Failure to establish a TLS session • All use of the identification and authentication mechanism (local and remote connections to the TSF) • Unsuccessful attempts to validate a certificate • Initiation of a software update • Result of a software update • Changes to the time • Attempts to unlock a local administrative session • Termination of a remote administrative session due to timeout • Modification of the behavior of the TSF • Failure of self-tests • Initiation, termination, and failure of the trusted channel and trusted path Each audit record includes the date and time, type, subject identity (IP address, hostname, and/or username), the outcome (success or failure when not implicitly defined in the event), and any additional information specified in column three of Table 6. FAU_GEN.1, FAU_GEN.2 Allied Telesis x930 Series Switches Security Target Page 71 of 89 7.1.2 Audit Storage The TSF implements the Syslog protocol and Syslog over TLS according to RFCs 5424 and 5425 respectively. The trusted channel with the Syslog server is described in greater detail in Sections 7.2.4 and 7.7.1. Audit records are transmitted to the Syslog server simultaneously with local logging. The TSF stores audit records in local log files. The security administrator can configure the size of the log files to be 10KB to 50 KB each, resulting in between 50KB to 250KB of logs being stored locally. When the active log file reaches the configured size, the oldest log file is deleted, and the TSF begins writing logs to a new log file. The CLI described in section 7.4 does not allow direct access to the log files to prevent unauthorized access, modification, or deletion. The TSF only provides commands for authenticated security administrators to view the log files. Additionally, the CLI does not allow any unauthenticated access to TSF data (including audit logs). FAU_STG.1, FAU_STG_EXT.1 7.2 Cryptographic Support 7.2.1 Cryptographic Key Generation The TSF generates 256 bit and 384 bit ECDSA/ECDH keys. The ECDSA keys are used to identify the TSF when it is operating as an SSH server. The EC Diffie-Hellman keys are used for key agreement in SSH. FCS_CKM.1, FCS_CKM.2 The TSF stores the following persistent keys on battery backed static RAM in plaintext: • SSH Private ECDSA Key – generated according to FCS_CKM.1 The TSF loads the persistent keys into dynamic RAM when they are used and the TSF also stores the following ephemeral keys in dynamic RAM: • Ephemeral EC Diffie-Hellman keys – generated according to FCS_CKM.1 and FCS_CKM.2 • TLS Session Keys – derived according to FCS_TLSC_EXT.1 • SSH Session Keys – derived according to FCS_SSHS_EXT.1 Persistent keys (static RAM) are destroyed by a overwriting the file containing the key three times with a random pattern that is changed before each write. Keys in volatile memory (dynamic RAM) are zeroized by writing zeroes over the key and reading the key location to verify that the zeroization succeeded. FCS_CKM.4 7.2.2 Cryptographic Operations The cryptographic algorithms utilized by the TSF are contained within the AW+ OpenSSL FIPS Object Module Version 2.0.10. These algorithms have received the following CAVP certificates: Table 9: Cryptographic Algorithms SFR Description Cert. FCS_CKM.1 FIPS 186-4 Appendices B.4 and B.4.2 ECDSA P-256/P-384 Key Generation ECDSA #858 FCS_CKM.2 P-256, P-384 Elliptic Curve Diffie-Hellman SP800-56A Key Agreement (recipient) CVL #1834 Allied Telesis x930 Series Switches Security Target Page 72 of 89 Table 9: Cryptographic Algorithms SFR Description Cert. FCS_COP.1(1) AES 128/256-bit CBC Encryption/Decryption AES #3919 FCS_COP.1(2) RSA 2048, 3072 Signature Verification RSA #2229, #28713 ECDSA P-256, P-384 Signature Generation, Signature Verification ECDSA #858 FCS_COP.1(3) SHA-1, SHA2-256, SHA2-384 SHS #3228 FCS_COP.1(4) HMAC-SHA1, HMAC-SHA2-256 HMAC #2546 FCS_RBG_EXT.1 AES-256 CTR_DRBG DRBG #1133 SHA-1 hashing is used in the SSH KDF, SSH Key Agreement, and HMAC generation/verification. SHA-256 hashing is used in SSH Key Agreement, HMAC generation/verification, digital signature generation/verification, and firmware update hashing. SHA-384 hashing is used in SSH Key Agreement and digital signature generation/verification. HMAC-SHA-1 is implemented with a 512 bit block size and a 160 bit MAC. HMAC-SHA-1 is used in the TLS KDF (256 or 384 bit key), TLS message authentication (160 bit key), and SSH message authentication (160 bit key). HMAC-SHA-256 is implemented with a 512 bit block size and 256 bit MAC. HMAC-SHA-256 is used in the TLS KDF (256 or 384 bit key) and TLS message authentication (256 bit key). The DRBG used by the TSF is a SP800-90A CTR_DRBG using AES-256. It is seeded with at least 256 bits of entropy. The entropy is gathered from a software based noise source and a third party hardware based noise source as described in [ENT]. FCS_CKM.1, FCS_CKM.2, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_RBG_EXT.1 7.2.3 SSH Server Protocol The TSF acts as an SSH server that is compliant with RFCs 4251, 4252, 4253, 4254, and 5656. The TSF enables the following options from the RFCs: • Host Authentication: ECDSA P-256, ECDSA P-384 • Client Authentication: ECDSA P-256, ECDSA P-384, and password based • Key Exchange (responder): ECDH P-256, ECDH P-384 • Data Encipherment: AES CBC with 128 and 256 bit keys • Message Authentication: HMAC-SHA-256 • Large Packet Limit: 262144 bytes The TSF determines the SSH packet size (for the large packet limit) by reading the packet_length field from the SSH header. If the packet size is greater than 262144 bytes, the TSF does not process the packet and writes a message to the audit log. The TSF initiates a rekey after 1 hour or after 1GB of data has been transferred using a key. The TSF maintains a counter for the number of AES blocks encrypted with each (send or receive) key. When the number of blocks encrypted by either key reaches the configured threshold (data threshold in bits / 128 bits / block), the TSF initiates a rekey. The TSF also maintains a timer and initiates a rekey when 3 RSA Signature Generation is not used by the TOE outside of the self-tests; however, it is required by FCS_COP.1(2). Allied Telesis x930 Series Switches Security Target Page 73 of 89 the timer reaches the configured time threshold. The counters and timer are reset to zero when a rekey occurs. FCS_SSHS_EXT.1, FCS_CKM.2 7.2.4 TLS Protocol The TSF acts as a TLSv1.1 or TLSv1.2 client for communications with the Syslog server and the RADIUS server. TLS communication with the Syslog server is performed according to RFC 5425. TLS communication with the RADIUS server is performed according to RFC 6614. The TSF supports the following TLS ciphersuite: • TLS_RSA_WITH_AES_128_CBC_SHA The TSF uses the RSA 2048 or RSA 3072 public key from the server certificate to encrypt the pre-master secret as specified in RFC 4346 or RFC 5246. The TSF is the sender in this non-SP800-56B compliant RSA key transport scheme. The TSF verifies that it is connected to the correct TLS sever by verifying the identification information the X.509 certificate presented by the server as per RFC 6125. The TSF supports the use of subject alternative name with a fallback to Common Name (if a SAN is not present) to authenticate the remote server. For Syslog and RADIUS communication, the TSF supports the use of IP address and performs an exact match of the configured IP address to the presented IP address. For RADIUS communication, the TSF also supports use of DNS names which are specified as a fully qualified domain name. The domain name must match the DNS name provided in the Server’s X.509 certificate, otherwise the connection will fail. Only the first field of the presented DNS name can be a wild-card character. The TSF does not support the use of URI or Service name. The TSF also validates the X.509 server certificate and certificate chain using RSA 2048 or RSA 3072 as described in Section 7.3.4. FCS_TLSC_EXT.1 7.3 Identification and Authentication 7.3.1 Password Management The TSF allows administrator passwords to be composed of characters represented by ASCII Codes 0x21- 0x3E, 0x40-0x7E. This set consists of all printable non-whitespace 7-bit ASCII characters except “?” which is reserved for help functionality. The TSF enforces a minimum password length that is settable by the administrator. The minimum password length can be configured to be 1 to 23 characters. FIA_PMG_EXT.1.1 7.3.2 User Identification and Authentication The TSF supports three authentication methods: local password authentication, RADIUS password authentication, and local public key based authentication. The two password based authentication methods can be used over the local console while remote administration over SSH supports all three authentication methods. When the local password authentication method is used; the TSF takes the provided password, combines it with a stored salt value (looked up by the provide username), SHA-256 hashes combined value, and checks to see if the hash matches the stored hash of the correct password and salt. Allied Telesis x930 Series Switches Security Target Page 74 of 89 When RADIUS password authentication is used; the TSF takes the provided password and sends it to the RADIUS server over a TLS protected channel. The TSF authenticates the user or rejects the users credential based on the response from the RADIUS server. When public key based authentication is used, the TSF attempts to use the public key configured for the user to validate a signature as described in RFC 4252. FIA_UIA_EXT.1, FIA_UAU_EXT.2 7.3.3 Protected Authentication Feedback When the user is entering their password over the local console, the TSF does not echo any characters back. FIA_UAU.7 7.3.4 X.509 Certificate Validation When a certificate is used (to identify the TSF or identify an external entity to the TSF), the TSF verifies certificates by checking the following: 1. The current date between the “Valid from” and “Valid to” dates 2. The certificate is not deemed invalid by the OCSP server. If the TSF has a cached response that has not expired, the TSF uses the cached response in lieu of querying the OCSP server. If the TSF does not receive a response from the OCSP server, the TSF assumes the certificate is valid. 3. The certificate chain is valid: o Each certificate in the certificate chain passes the checks described in #1 and #2. o Each certificate (other than the first certificate) in the certificate chain has the Subject Type=CA flag set. o Each certificate is signed using RSA 2048 or 3072 by:  a certificate in the certificate chain, or  a trusted root CA that has been installed in the TSF The TSF verifies the validity of a certificate when: • A certificate being imported by the TOE • A TLS client establishes a TLS connection (TLS Server Certificate) • The TSF verifies the server certificate of the Syslog server • The TSF verifies the server certificate of the RADIUS server If the Security Administrator loads a certificate with a Subject Type=CA, the TSF does not validate the certificate path. FIA_X509_EXT.1 7.3.5 X.509 Certificate Authentication When establishing a connection to the Syslog or RADIUS server, the TSF uses the certificate presented to verify the server’s identity. See 7.2.4 for more details. Once the TSF has verified that the certificate identifier(s) are valid, the TSF verifies the validity of the certificate as described in Section 7.3.4. If any of the other Section 7.3.4 validity checks fail, the TSF rejects the certificate and does not establish the connection. FIA_X509_EXT.2 Allied Telesis x930 Series Switches Security Target Page 75 of 89 7.4 Security Management The TSF assigns the Security Administrator role to authorized administrators of the TOE. The TSF allows the Security Administrators to administer the TSF via a local or remote CLI. The TSF permission restrict access to these management functions to users that have been identified, authenticated, and authorized with the Security Administrator role. The TSF allows the Security Administrator to perform the following management functions: • Initiate Firmware Updates • View/Edit settings for sending audit data to the Syslog server • View/Edit the amount of space allocated local audit storage • View/Load/Delete X.509 Certificates • Generate and configure cryptographic keys used to identify the TOE • Configure cryptographic keys used to authenticate users • View/Edit the TOE access banner • View/Edit the session inactivity timeout • View/Edit user accounts The administrative interfaces provided by the TSF do not allow any of these functions to be accessed by unauthenticated or unauthorized users. FMT_MOF.1(1)/TrustedUpdate, FMT_MOF.1(1)/Audit, FMT_MOF.1(2)/Audit, FMT_MTD.1, FMT_MTD.1/AdminAct, FMT_SMF.1, FMT_SMR.2 7.5 Protection of the TSF 7.5.1 Protection of Administrator Passwords The TSF subjects Security Administrator passwords to the requirements of FPT_APW_EXT.1. The TSF does not store plaintext passwords. The TSF stores the SHA-256 hash of each Security Administrator’s password. Additionally, the TSF does not provide a user interface to view the password hashes. FPT_APW_EXT.1 7.5.2 Protection of TSF Data (for reading of all symmetric keys) The TSF stores persistent private keys in plaintext; however, it does not provide an interface to allow any user to view any of values. FPT_SKP_EXT.1 7.5.3 TSF Testing The TSF performs the following self-tests at power-on and when invoked by the Security Administrator: • FW Integrity Check using SHA-256 • AES 128-ECB Known Answer Test • HMAC-SHA-1 Known Answer Test • HMAC-SHA-256 Known Answer Test • SHA-384 Known Answer Test • CTR_DRBG using AES 256 Known Answer Test • RSA 2048 Sign and Verify Known Answer Tests • ECDSA P-224 Sign and Verify Pairwise Consistency Test • ECDH P-224 Known Answer Test Allied Telesis x930 Series Switches Security Target Page 76 of 89 These tests provide assurance that the TSF is operating correctly by verifying that the firmware has not been corrupted and that the CPU and RAM are correctly executing the instructions necessary for the cryptographic operations correctly. The Known Answer Tests (KATs) are essentially test vectors. These test vectors contain input (e.g. values, seed) and known correct output values. These tests simply perform the cryptographic operation and check that the output matches the expected value. FPT_TST_EXT.1 7.5.4 Trusted Update The vendor posts software updates and SHA-256 hashes of the updates on their website. The process for installing an update is as follows: 1. The Security Administrator downloads the update from the website and records the hash. 2. The Security Administrator uploads the update to the TOE. 3. The Security Administrator runs the “crypto verify” command with the update file and hash as arguments. 4. The TSF reports “Verification failed” if the hash of the update does not match the specified hash. 5. If the verification fails, the Guidance instructs Security Administrator to delete the update file and contact Allied Telesis support. 6. If the verification succeeds, the Guidance instructs the Security Administrator to: a. Install the update by using the “boot system” command. b. Save the configuration changes using the “write” command. c. Reboot the TSF to make the updated firmware image the active image. Prior to activation of the update in Step 6c, the TSF allows the administrator to view the currently running firmware version as well as the firmware version that will be active after the reboot. FPT_TUD_EXT.1 7.5.5 Reliable Time Stamps The TSF contains a hardware clock with an accuracy of less than .5 seconds/day of drift. The following TSF security functions rely on the time: timestamping audit log records, determining user session timeouts, determining certificate validity, and TLS nonce generation. A high degree of accuracy is not necessary, because: • Audit logs are maintained in the order they are generated regardless of the exact timestamp applied • User session timeouts are relative times so drift measured over days is not relevant • Certificate Validity is measured in months, so a few seconds of drift is not relevant • SSH rekey threshold • TLS nonces – use the time as a unique value, but do not require the time to be exact. FPT_STM.1 7.6 TOE Access 7.6.1 TSF-initiated Termination For local console sessions and remote SSH sessions, the TSF terminates sessions after an administrator configured inactivity period. For remote of SSH sessions, the TSF associates a timer with the session when the user connects. The timer is set to the administrator configured inactivity period and started immediately. Each time the user Allied Telesis x930 Series Switches Security Target Page 77 of 89 performs an action over SSH, the TSF resets the timer to the configured inactivity period. If the timer expires, the TSF terminates the associated SSH session. For local console sessions, the TSF starts a timer whose value is equal to the administrator configured inactivity period. The TSF also updates a timestamp when there is user activity on the console. When the timer expires, the TSF calculates the idle time using the current time and the timestamp of the last activity. If the idle time is greater than or equal to the configured inactivity period, the TSF terminates the session. Otherwise, the TSF sets the timer to the configured inactivity period less the idle time and the process repeats. FTA_SSL_EXT.1, FTA_SSL.3 7.6.2 User-initiated Termination For local and remote sessions, the user can terminate the session by running the “logout” or “exit” command. FTA_SSL.4 7.6.3 Default TOE Access Banners For local sessions, the TSF displays an administrator configurable text banner before displaying the username and password prompts. For remote sessions using password authentication, the TSF sends an administrator configurable text banner to the SSH client before requesting a password. For remote sessions using public key authentication, the TSF sends an administrator configurable text banner to the SSH client immediately after successful authentication. The SSH protocol automatically performs public key authentication during the handshake, so the banner cannot be sent prior to public key authentication. FTA_TAB.1 7.7 Trusted Path/Channels 7.7.1 Inter-TSF Trusted Channel The TSF communicates with the Syslog server and RADIUS server using a trusted channels secured by TLS. TLS is described in Section 7.2.4. The TSF initiates the trusted channel with both servers, so the TSF acts as the TLS client. FTP_ITC.1 7.7.2 Trusted Path The TSF provides a trusted path for remote administration using SSH as described in Section 7.2.3. FTP_TRP.1 Allied Telesis x930 Series Switches Security Target Page 78 of 89 8. Terms and Definitions Table 10: TOE Abbreviations and Acronyms Abbreviations/ Acronyms Description AES Advanced Encryption Standard ARP Address Resolution Protocol ASCII American Standard Code for Information Interchange CA Certificate Authority CBC Cipher Block Chaining CLI Command Line Interface CN Common Name CSR Certificate Signing Request DH Diffie-Hellman DHCP Dynamic Host Configuration Protocol DRBG Deterministic Random Bit Generator DSA Digital Signature Algorithm ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm EEPROM Electrically Erasable Programmable Read-Only Memory FFC Finite Field Cryptography FIPS Federal Information Processing Standards HMAC Hash Message Authentication Code ICMP Internet Control Message Protocol IEC International Electrotechnical Commission IP Internet Protocol ISO International Organization for Standardization IV Initialization Vector KAT Known Answer Test KB Kilobyte KDF Key Derivation Function MAC Message Authentication Code NIST National Institute of Standards and Technology OCSP Online Certificate Status Protocol OSPF Open Shortest Path First PCT Pairwise Consistency Test PKCS Public Key Cryptography Standards RADIUS Remote Authentication Dial In User Service RAM Random Access Memory RBG Random Bit Generator RFC Request for Comments RIP Routing Information Protocol RNG Random Number Generator RSA Rivest-Shamir-Adleman SHA Secure Hash Algorithm SP Special Publication SSH Secure Shell TLS Transport Layer Security Allied Telesis x930 Series Switches Security Target Page 79 of 89 Table 11: CC Abbreviations and Acronyms Abbreviations/ Acronyms Description CC Common Criteria CSP Critical Security Parameter IT Information Technology OSP Organizational Security Policy PP Protection Profile SAR Security Assurance Requirement SFR Security Functional Requirement SFP Security Function Policy SPD Security Problem Definition ST Security Target TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface TSS TOE Summary Specification Allied Telesis x930 Series Switches Security Target Page 80 of 89 9. References Table 12: TOE Guidance Documentation Reference Description Version Date [T1] Common Criteria Operational User Guidance and Preparative Procedures – Allied Telesis x930 Series Switches C613- 02065-00 REV J [T2] Command Reference for AlliedWare Plus™ Version 5.4.6-1.x C613- 50100-01 REV C 2016 [T3] Installation Guide for Stand-alone Switches C613- 002100 Rev. C 2015 [T4] AlliedWare Plus™ Best Practice Guide [T5] AlliedWare Plus™ Operating System Log Message Reference C613- 50013-00 REV G 2016 [T6] Bootloader and Startup Feature Overview and Configuration Guide C613- 22003-00 REV A [T7] Logging Feature Overview and Configuration Guide C613- 22059-00 REV A [T8] RADIUS Server Feature Overview and Configuration Guide C613- 22056-00 REV A [T9] Secure Shell (SSH) Feature Overview and Configuration Guide C613- 22051-00 REV A Table 13: TOE Evaluation Evidence Reference Description Version Date [ENT] Entropy Assessment – X930 [CM] Allied Telesis x930 Series Switches Labeling of the TOE C613- 05046-00 REV A [CMC] Allied Telesis x930 Series Switches TOE CM Coverage C613- 05047-00 REV A [FSP] Allied Telesis x930 Series Switches Basic Functional Specification C613- 05048-00 REV A Table 14: Common Criteria v3.1 References Reference Description Version Date [C1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model CCMB-2012-09-001 V3.1 R4 September 2012 [C2] Common Criteria for Information Technology Security Evaluation V3.1 R4 September 2012 Allied Telesis x930 Series Switches Security Target Page 81 of 89 Table 14: Common Criteria v3.1 References Reference Description Version Date Part 2: Security functional components CCMB-2012-09-002 [C3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components CCMB-2012-09-003 V3.1 R4 September 2012 [C4] Common Criteria for Information Technology Security Evaluation Evaluation Methodology CCMB-2012-09-004 V3.1 R4 September 2012 Table 15: Supporting Documentation Reference Description Version Date [NDcPP] Collaborative Protection Profile for Network Devices 1.0 February 27, 2015 [SD] Supporting Document Mandatory Technical Document Evaluation Activities for Network Device cPP 1.0 February 27, 2015 Allied Telesis x930 Series Switches Security Target Page 82 of 89 Annex A Algorithm Validation Requirements FCS_CKM.1.1 Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. Key Generation for FIPS PUB 186-4 RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include: a) Random Primes: • Provable primes • Probable primes b) Primes with Conditions: • Primes p1, p2, q1, q2, p and q shall all be provable primes • Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes • Primes p1, p2, q1, q2, p and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Key Generation for Elliptic Curve Cryptography (ECC) FIPS 186-4 ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-384and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct).The evaluator shall obtain in response a set of 10 PASS/FAIL values. Key Generation for Finite-Field Cryptography (FFC) The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. Allied Telesis x930 Series Switches Security Target Page 83 of 89 The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p: • Primes q and p shall both be provable primes • Primes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator g: • Generator g constructed through a verifiable process • Generator g constructed through an unverifiable process. The Key generation specifies 2 ways to generate the private key x: • len(q) bit output of RBG where 1 <=x <= q-1 • len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1<= x<=q-1. The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm: • g != 0,1 • q divides p-1 • g^q mod p = 1 • g^x mod p = y for each FFC parameter set and key pair. FCS_CKM.2.1 Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE using the applicable tests below. SP800-56A Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role-key confirmation type combination, the Allied Telesis x930 Series Switches Security Target Page 84 of 89 tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information field OI and TOE id fields. If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret. The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MACtags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the other info and TOE id fields. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors. SP800-56B Key Establishment Scheme Testing The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes. If the TOE acts as a sender, the following assurance activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: a) To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any Allied Telesis x930 Series Switches Security Target Page 85 of 89 additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector. If the TOE acts as a receiver, the following assurance activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: a) To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector. b) The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. Diffie-Hellman Group 14 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. FCS_COP.1.1(1) AES-CBC Known Answer Tests There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. Allied Telesis x930 Series Switches Security Target Page 86 of 89 KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all-zeros key, and the other five shall be encrypted with a 256-bit all-zeros key. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption. KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be 128-bit keys, and the other five shall be 256-bit keys To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption. KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the two sets of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second set shall have 256 256-bit keys. Key I in each set shall have the leftmost i bits be ones and the rightmost N-I bits be zeros, for I in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128-bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key. KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from AES-CBC encryption of the given plaintext using a 128-bit key value of all zeros with an IV of all zeros and using a 256-bit key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128]. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption. AES-CBC Multi-Block Message Test The evaluator shall test the encrypt functionality by encrypting an I-block message where 1 < i <=10. The evaluator shall choose a key, an IV and plaintext message of length I blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length I blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests Allied Telesis x930 Series Switches Security Target Page 87 of 89 The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT = CT[i-1] The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. AES-GCM Test The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths: 128 bit and 256 bit keys a) Two plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported. b) Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported. c) Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested. The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5- tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the valuator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. FCS_COP.1.1(2) ECDSA Algorithm Tests ECDSA FIPS 186-4 Signature Generation Test Allied Telesis x930 Series Switches Security Target Page 88 of 89 For each supported NIST curve (i.e., P-256, P-384 and P-521) and SHA function pair, the evaluator shall generate 10 1024-bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation. ECDSA FIPS 186-4 Signature Verification Test For each supported NIST curve (i.e., P-256, P-384 and P-521) and SHA function pair, the evaluator shall generate a set of 10 1024-bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values. RSA Signature Algorithm Tests Signature Generation Test The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/SHA combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages. The evaluator shall verify the correctness of the TSF’s signature using a known good implementation and the associated public keys to verify the signatures. Signature Verification Test The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another party’s valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure. The evaluator shall use these test vectors to emulate the signature verification test using the corresponding parameters and verify that the TOE detects these errors. FCS_COP.1.1(3) The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented testmacs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP. Short Messages Test - Bit-oriented Mode The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Short Messages Test - Byte-oriented Mode The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators Allied Telesis x930 Series Switches Security Target Page 89 of 89 compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test - Bit-oriented Mode The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm (e.g. 512 bits for SHA-256). The length of the ith message is m+ 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Selected Long Messages Test - Byte-oriented Mode The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm (e.g. 512 bits for SHA-256). The length of the ith message is m+ 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. Pseudorandomly Generated Messages Test This test is for byte-oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF.