Aruba, a Hewlett Packard Enterprise Company ClearPass Policy Manager (NDcPP10/AuthSrvEP10) Security Target

Transcription

1 Aruba, a Hewlett Packard Enterprise Company ClearPass Policy Manager (NDcPP10/AuthSrvEP10) Security Target Version 1.1 6/08/2018 Prepared for: Aruba, a Hewlett Packard Enterprise Company 3333 Scott Blvd. Santa Clara, CA Prepared By:

2 1. SECURITY TARGET INTRODUCTION SECURITY TARGET REFERENCE TOE REFERENCE TOE OVERVIEW TOE DESCRIPTION TOE Architecture TOE Documentation CLAIMS CONFORMANCE RATIONALE SECURITY OBJECTIVES SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT EXTENDED COMPONENTS DEFINITION SECURITY REQUIREMENTS TOE SECURITY FUNCTIONAL REQUIREMENTS Security audit (FAU) Communication (FCO) Cryptographic support (FCS) Identification and authentication (FIA) Security management (FMT) Protection of the TSF (FPT) TOE access (FTA) Trusted path/channels (FTP) TOE SECURITY ASSURANCE REQUIREMENTS Development (ADV) Guidance documents (AGD) Life-cycle support (ALC) Tests (ATE) Vulnerability assessment (AVA) TOE SUMMARY SPECIFICATION SECURITY AUDIT COMMUNICATION CRYPTOGRAPHIC SUPPORT IDENTIFICATION AND AUTHENTICATION SECURITY MANAGEMENT PROTECTION OF THE TSF TOE ACCESS TRUSTED PATH/CHANNELS LIST OF TABLES Table 1 TOE Security Functional Components Table 2 Auditable Events Table 3 Assurance Components Table 4 Cryptographic Functions Page 2 of 39

3 1. Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is ClearPass Policy Manager provided by Aruba, a Hewlett Packard Enterprise Company. The TOE is being evaluated as a network infrastructure authentication server device. The Security Target contains the following additional sections: Conformance Claims (Section 2) Security Objectives (Section 3) Extended Components Definition (Section 4) Security Requirements (Section 5) TOE Summary Specification (Section 6) Conventions The following conventions have been applied in this document: Security Functional Requirements Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement. o o o o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a letter placed at the end of the component. For example FDP_ACC.1a and FDP_ACC.1b indicate that the ST includes two iterations of the FDP_ACC.1 requirement, a and b. Assignment: allows the specification of an identified parameter. Assignments are indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection would be identified in italics and with embedded bold brackets (e.g., [[selectedassignment]]). Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]). Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and strike-through, for deletions (e.g., all objects or some big things ). Other sections of the ST Other sections of the ST use bolding to highlight text of special interest, such as captions. 1.1 Security Target Reference ST Title Aruba, a Hewlett Packard Enterprise Company ClearPass Policy Manager (NDcPP10/AuthSrvEP10) Security Target ST Version Version 1.1 ST Date 06/08/ TOE Reference TOE Identification Aruba, a Hewlett Packard Enterprise Company ClearPass Policy Manager version running in one of the following appliances: C1000, C2000, or C3000. Page 3 of 39

4 TOE Developer Aruba, a Hewlett Packard Enterprise Company Evaluation Sponsor Aruba, a Hewlett Packard Enterprise Company 1.3 TOE Overview The Target of Evaluation (TOE) is Aruba, a Hewlett Packard Enterprise Company ClearPass Policy Manager. 1.4 TOE Description The ClearPass Policy Manager platform provides role- and device-based network access control for employees, contractors and guests across any wired, wireless and VPN infrastructure. ClearPass implements RADIUS services, as well as profiling, onboarding, guest access, and health checks facilitating centralized management of network access policies. ClearPass provides user and device authentication based on 802.1X, non-802.1x and web portal access methods. Multiple authentication protocols like PEAP, EAP-FAST, EAP-TLS, and EAP-TTLS can be used concurrently to strengthen security in any environment. Attributes from multiple identity stores such as Microsoft Active Directory, LDAP-compliant directory, ODBC-compliant SQL database, token servers and internal databases can be used within a single policy for fine-grained control. Additional information about the supported network access control capabilities can be found in the ClearPass Policy Manager data sheet ( however, for the purpose of evaluation, ClearPass will be treated as a network infrastructure authentication server device offering authentication services, FIPS certified cryptographic functions, security auditing, secure administration, trusted updates, self-tests, and secure connections to other servers (e.g., to transmit audit records) TOE Architecture The ClearPass Policy Manager is available either as a hardware or virtual network appliance and is designed to support a wide range of network, wireless and security protocols to support a wide range of clients. However, the evaluation is limited to the hardware network appliances and the secure communication protocols specifically identified below. There are three versions of the ClearPass Policy Manager designed to support 500, 5000, or client devices. Each is deployed on a different commodity hardware platform that differ in CPU performance (e.g., number of cores), available memory, disk performance and storage capacity, and power consumption/supply. C1000: UNICOM Engineering S-1200 R4 o o o Intel Atom C2758 CPU (64-bit, 8-cores, 2.4Ghz) 8GB memory/ 1TB SATA hard disk 7 RJ-45 GbE LAN ports C2000: HPE DL20 Gen9 o o o Intel Xeon E3-1240v5 CPU (64-bit, 4-cores/8-threads, 3.5Ghz) 16GB memory/raid 1 with two 1TB SATA disk drives 1Gb 332i Ethernet Adapter 2 Ports per controller C3000: HPE DL360 Gen9 o o o Two Intel Xeon E5-2620v3 CPUs (64-bit, 6-cores/12-threads, 2.4Ghz) 64GB memory/raid 10 with six 600GB SAS disk drives 1Gb 331i Ethernet Adapter 4 Ports per controller Page 4 of 39

5 While ClearPass Policy Manager products can be configured as a collection of devices operating in a cluster sharing a common security policy, the TOE configuration subject to this evaluation is limited to a single ClearPass Policy Manager device. The collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 (NDcPP10) does not allow distributed TOEs. Each ClearPass Policy Manager device is a rack-mountable appliance with one or more Intel Pentium or Xeon CPUs running a version of CentOS 6.7 to host the applications designed to provide the network access control capabilities summarized above. ClearPass includes a version of Aruba Linux Cryptomodule that is used to perform cryptographic functions. This module is based on CryptoComply Server Engine version 2.1 and supports of the implementations of IPsec using StrongSwan, TLS/HTTPS using Apache, and SSH using OpenSSH used to secure the communication channels (for remote administrator, exporting audit events and communicating with NAS servers) Physical Boundaries The ClearPass evaluated configuration includes one of the following devices: C1000: Aruba ClearPass Policy Manager 500 hardware platform supporting a maximum of 500 authenticated devices. C2000: Aruba ClearPass Policy Manager 5K hardware platform supporting a maximum of 5,000 authenticated devices. C3000: Aruba ClearPass Policy Manager 25K hardware platform supporting a maximum of 25,000 authenticated devices Logical Boundaries This section summarizes the security functions provided by ClearPass Policy Manager: Security audit Communication Cryptographic support Identification and authentication Security management Protection of the TSF TOE access Trusted path/channels Security audit The TOE is designed to be able to generate logs for a wide range of security relevant events. The TOE can be configured to store the logs locally so they can be accessed by an administrator or alternately to send the logs to a designated syslog server Communication The TOE includes an Aruba Linux Cryptographic Module that provides key management, random bit generation, encryption/decryption, digital signature and secure hashing and key-hashing features in support of higher level cryptographic protocols including IPsec, SSH, and TLS/HTTPS. Page 5 of 39

6 Cryptographic support The TOE supports a wide variety of network access control functions. While implementing its network access control functions, the TOE ensures that it doesn t inadvertently reuse network or management data. This is accomplished primarily by clearing and zero-padding of memory structures and packet buffers when allocated Identification and authentication The TOE requires administrators to be identified and authenticated before they can use functions mediated by the TOE. Administrators can be defined locally with user names and passwords or can alternately be defined in the context of local RADIUS services. Regardless, of how the administrator is defined, they have to provide the proper user credentials when logging in to establish a session and perform security management functions. Note that the TOE performs network access control functions that are initiated by the TOE based on its configuration (e.g., to monitor network activity or scan network entities) or may be initiated outside the TOE (e.g., to request user authentication RADIUS services). Many of these functions to not require user identification or authentication, but they also do not yield any capability to perform security management functions on the TOE Security management The TOE provides Command Line (CLI) commands (locally via a serial console or remotely via SSH) and a Webbased Graphical User Interface (Web GUI) to access the available functions to manage the TOE security functions and network access control functions. Security management commands are limited to authorized users (i.e., administrators) only after they have been correctly identified and authenticated. The security management functions are controlled through the use of Admin Privileges that can be assigned to TOE users Protection of the TSF The TOE implements a number of features design to protect itself to ensure the reliability and integrity of its security features. It protects particularly sensitive data such as stored passwords and private cryptographic keys so that they are not accessible even by an administrator. It also provides its own timing mechanism to ensure that reliable time information is available (e.g., for audit records). The TOE includes functions to perform self-tests so that it might detect when it is failing. It also includes mechanisms so that the TOE itself can be updated while ensuring that the updates will not introduce malicious or other unexpected changes in the TOE TOE access The TOE can be configured to display an informative banner when an administrator establishes an interactive session and subsequently will enforce an administrator-defined inactivity timeout value after which the inactive session (local or remote) will be terminated Trusted path/channels The TOE protects interactive communication with administrators using a console and SSHv2 for CLI access and TLS/HTTPS for WebGUI access. In each case, both the integrity and disclosure protection is ensured via the secure protocol. If the negotiation of a secure session fails or if the user cannot be authenticated for remote administration, the attempted session will not be established. The TOE protects communication with network peers, such as a syslog server, using IPsec connections to prevent unintended disclosure or modification of logs. Page 6 of 39

7 1.4.2 TOE Documentation The following administrator and user guidance are available: Common Criteria Configuration Guidance Aruba ClearPass Policy Manager 6.7.3, June 2018 (Admin Guide) Page 7 of 39

8 2. Claims This TOE is conformant to the following CC specifications: Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September Part 2 Extended Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September Package Claims: Part 3 Conformant 2.1 Conformance Rationale collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 (NDcPP10) with the following NIAP Technical Decisions applied: TD0090, TD0094, TD0095, TD0096, TD0111, TD0112, TD0113, TD0114, TD0115, TD0116, TD0117, TD0125, TD0126, TD0130, TD0143, TD0150, TD0151, TD0152, TD0153, TD0154, TD0155, TD0156, TD0160, TD0164, TD0165, TD0167, TD0168, TD0169, TD0170, TD0181, TD0182, TD0183, TD0184, TD0185, TD0186, TD0187, TD0188, TD0189, TD0199, TD0200, TD0201, TD0223, TD0224, TD0225, TD0226, TD0227, TD0228, and TD0235. Network Device Collaborative Protection Profile (NDcPP)/Application Software Protection Profile (App PP) Extended Package (EP) for Authentication Servers, Version 1.0, 7 August 2015 (AuthSrvEP10) with the following NIAP Technical Decisions applied: TD0171 and TD0174. The ST conforms to the NDcPP10/AuthSrvEP10. As explained previously, the security problem definition, security objectives, and security requirements have been drawn from the PP. Page 8 of 39

9 3. Security Objectives The Security Problem Definition may be found in the NDcPP10/AuthSrvEP10 and this section reproduces only the corresponding Security Objectives for the operational environment for reader convenience. The NDcPP10/AuthSrvEP10 offers additional information about the identified security objectives, but that has not been reproduced here and the NDcPP10/AuthSrvEP10 should be consulted if there is interest in that material. In general, the NDcPP10/AuthSrvEP10 has defined Security Objectives appropriate for a network infrastructure authentication server device and as such are applicable to the Aruba Networks ClearPass Policy Manager TOE. 3.1 Security Objectives for the Operational Environment 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. OE.NAS Authentication requests that are provided to the TOE for validation are centrally collected by a NAS and transmitted to the TOE through this component. 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.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the 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. Page 9 of 39

10 4. Extended Components Definition All of the extended requirements in this ST have been drawn from the NDcPP10/AuthSrvEP10. The NDcPP10/AuthSrvEP10 defines the following extended requirements and since they are not redefined in this ST the NDcPP10/AuthSrvEP10 should be consulted for more information in regard to those CC extensions. Extended SFRs: FAU_STG_EXT.1: Protected Audit Event Storage FAU_STG_EXT.3: Display warning for local storage space FCS_EAP-TLS_EXT.1: Extended: Extensible Authentication Protocol - Transport Layer Security (EAP- TLS) FCS_HTTPS_EXT.1: HTTPS Protocol FCS_IPSEC_EXT.1: IPsec Protocol FCS_RADIUS_EXT.1: Extended: RADIUS FCS_RBG_EXT.1: Random Bit Generation FCS_SSHS_EXT.1: SSH Server Protocol FCS_TLSS_EXT.2: TLS Server Protocol with mutual authentication FIA_PMG_EXT.1: Password Management FIA_PSK_EXT.1: Extended: Pre-Shared Key Composition FIA_UAU_EXT.2: Password-based Authentication Mechanism FIA_UIA_EXT.1: User Identification and Authentication FIA_X509_EXT.1: X.509 Certificate Validation FIA_X509_EXT.2: X.509 Certificate Authentication FIA_X509_EXT.3: X.509 Certificate Requests FPT_APW_EXT.1: Protection of Administrator Passwords FPT_SKP_EXT.1: Protection of TSF Data (for reading of all symmetric keys) FPT_TST_EXT.1: TSF testing FPT_TUD_EXT.1: Trusted update FTA_SSL_EXT.1: TSF-initiated Session Locking Page 10 of 39

11 5. Security Requirements This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort. The SFRs have all been drawn from the NDcPP10/AuthSrvEP10. The refinements and operations already performed in the NDcPP10/AuthSrvEP10 are not identified (e.g., highlighted) here, rather the requirements have been copied from the NDcPP10/AuthSrvEP10 and any residual operations have been completed herein. Of particular note, the NDcPP10/AuthSrvEP10 made a number of refinements and completed some of the SFR operations defined in the Common Criteria (CC) and that PP should be consulted to identify those changes if necessary. The SARs are also drawn from the NDcPP10/AuthSrvEP10. However, the SARs are effectively refined since requirement-specific 'Assurance Activities' are defined in the NDcPP10/AuthSrvEP10 that serve to ensure corresponding evaluations will yield practical and consistent. The NDcPP10/AuthSrvEP10 should be consulted for the assurance activity definitions. 5.1 TOE Security Functional Requirements The following table identifies the SFRs that are satisfied by Aruba Networks ClearPass Policy Manager TOE. Requirement Class FAU: Security audit FCO: Communication FCS: Cryptographic support FIA: Identification and authentication Requirement Component FAU_GEN.1: Audit Data Generation FAU_GEN.2: User identity association FAU_STG.1: Protected audit trail storage FAU_STG_EXT.1: Protected Audit Event Storage FAU_STG_EXT.3: Display warning for local storage space FCO_NRO.1: Selective Proof of Origin FCO_NRR.1: Selective Proof of Receipt FCS_CKM.1: Cryptographic Key Generation FCS_CKM.2: Cryptographic Key Establishment 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_EAP-TLS_EXT.1: Extended: Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) FCS_HTTPS_EXT.1: HTTPS Protocol FCS_IPSEC_EXT.1: IPsec Protocol FCS_RADIUS_EXT.1: Extended: RADIUS FCS_RBG_EXT.1: Random Bit Generation FCS_SSHS_EXT.1: SSH Server Protocol FCS_TLSS_EXT.2: TLS Server Protocol with mutual authentication FIA_AFL.1: Authentication Failure Handling FIA_PMG_EXT.1: Password Management FIA_PSK_EXT.1: Extended: Pre-Shared Key Composition FIA_UAU.7: Protected Authentication Feedback FIA_UAU_EXT.2: Password-based Authentication Mechanism FIA_UIA_EXT.1: User Identification and Authentication FIA_X509_EXT.1: X.509 Certificate Validation Page 11 of 39

12 FMT: Security management FPT: Protection of the TSF FTA: TOE access FTP: Trusted path/channels FIA_X509_EXT.2: X.509 Certificate Authentication FIA_X509_EXT.3: X.509 Certificate Requests FMT_MOF.1(1): Management of security functions behaviour - TrustedUpdate FMT_MTD.1(1): Management of TSF Data FMT_SMF.1: Specification of Management Functions FMT_SMF.1(1): Specification of Management Functions FMT_SMR.2: Restrictions on Security Roles FPT_APW_EXT.1: Protection of Administrator Passwords FPT_SKP_EXT.1: Protection of TSF Data (for reading of all symmetric keys) FPT_STM.1: Reliable Time Stamps FPT_TST_EXT.1: TSF testing FPT_TUD_EXT.1: Trusted update FTA_SSL.3: TSF-initiated Termination FTA_SSL.4: User-initiated Termination FTA_SSL_EXT.1: TSF-initiated Session Locking FTA_TAB.1: Default TOE Access Banners FTA_TSE.1: TOE Session Establishment FTP_ITC.1: Inter-TSF trusted channel FTP_ITC.1(1): Inter-TSF Trusted Channel FTP_TRP.1: Trusted Path Table 1 TOE Security Functional Components Security audit (FAU) Audit Data Generation (FAU_GEN.1) 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; 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]; and d) Specifically defined auditable events listed in Table 2 Auditable Events. Requirement Auditable Events Additional Content FAU_GEN.1 None None FAU_GEN.2 None None FAU_STG.1 None None FAU_STG_EXT.1 None None FAU_STG_EXT.3 Warning about low storage space for None FCO_NRO.1 audit events. Client request for which the TOE does not have a shared secret Identity of the client, contents of EAPresponse (if present). Page 12 of 39

13 FCO_NRR.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_EAP- TLS_EXT.1 Protocol failures Establishment of a TLS session If failure occurs, record a descriptive reason for the failure FCS_HTTPS_EXT.1 Failure to establish a HTTPS Session. Reason for failure. FCS_IPSEC_EXT.1 Failure to establish an IPsec SA. Reason for failure. FCS_RADIUS_EXT.1 Protocol failures Success/Failure of authentication If failure occurs, record a descriptive reason for the failure FCS_RBG_EXT.1 None None FCS_SSHS_EXT.1 Failure to establish an SSH session. Successful SSH rekey. Reason for failure. Non-TOE endpoint of connection (IP Address). FCS_TLSS_EXT.2 Failure to establish a TLS Session. Reason for failure. FIA_AFL.1 The reaching of the threshold for the unsuccessful authentication attempts. Disabling an account due to the threshold being reached FIA_PMG_EXT.1 None None FIA_PSK_EXT.1 None None FIA_UAU.7 None None The claimed identity of the user attempting to gain access or the IP where the attempts originated. FIA_UAU_EXT.2 All use of identification and Origin of the attempt (e.g., IP address). authentication mechanism. FIA_UIA_EXT.1 All use of identification and authentication mechanism. Provided user identity, origin of the attempt (e.g., IP address). FIA_X509_EXT.1 Unsuccessful attempt to validate a Reason for failure. certificate. FIA_X509_EXT.2 None None FIA_X509_EXT.3 None None FMT_MOF.1(1) Any attempt to initiate a manual update. None FMT_MTD.1(1) All management activities of TSF data. None FMT_SMF.1 None None FMT_SMF.1(1) None None FMT_SMR.2 None None FPT_APW_EXT.1 None None FPT_SKP_EXT.1 None None 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). FPT_TST_EXT.1 None None FPT_TUD_EXT.1 Initiation of update; result of the update None attempt (success or failure). FTA_SSL.3 The termination of a remote session by None the session locking mechanism. FTA_SSL.4 The termination of an interactive session. None FTA_SSL_EXT.1 Any attempts at unlocking of an interactive session. None Page 13 of 39

14 FTA_TAB.1 None None FTA_TSE.1 Denial of a session establishment due to the session establishment mechanism Reason for denial, origin of establishment attempt. FTP_ITC.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. attempt. FTP_ITC.1(1) FTP_TRP.1 Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions Initiation of the trusted path. Termination of the trusted path. Failure of the trusted path functions. Table 2 Auditable Events Identification of the initiator and target of failed trusted channels establishment Identification of the initiator and target of failed trusted channels establishment attempt. Identification of the claimed user identity. 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 2 Auditable Events User identity association (FAU_GEN.2) 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 Protected audit trail storage (FAU_STG.1) FAU_STG.1.1 FAU_STG.1.2 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. The TSF shall be able to prevent unauthorised modifications to the stored audit records in the audit trail Protected Audit Event Storage (FAU_STG_EXT.1) 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 to FTP_ITC.1. 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: [audit records older than admin configured days (default value 7) are removed daily]] when the local storage space for audit data is full Display warning for local storage space (FAU_STG_EXT.3) FAU_STG_EXT.3.1 The TSF shall generate a warning to inform the user before the local space to store audit data is used up and/or the TOE will lose audit data due to insufficient local space. Page 14 of 39

15 5.1.2 Communication (FCO) Selective Proof of Origin (FCO_NRO.1) FCO_NRO.1.1 FCO_NRO.1.2 FCO_NRO.1.3 The TSF shall be able to generate evidence of origin for transmitted RADIUS Access-Request packets at the request of the recipient. The TSF shall be able to relate the Message Authenticator of the originator of the information, and the Access-Request of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of origin of information to recipient given the evidence of origin information is presented in the Access-Request packet in a manner consistent with RFC Selective Proof of Receipt (FCO_NRR.1) FCO_NRR.1.1 FCO_NRR.1.2 FCO_NRR.1.3 The TSF shall be able to generate evidence of receipt for received RADIUS Access-Request packets at the request of the originator. The TSF shall be able to relate the Identifier, Response Authenticator of the recipient of the information, and the response packet of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of receipt of information to originator given [a secure communication channel is available] Cryptographic support (FCS) Cryptographic Key Generation (FCS_CKM.1) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ - RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.3, - ECC schemes using 'NIST curves' [P-256, P-384] that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.4, - FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.1] Cryptographic Key Establishment (FCS_CKM.2) FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ - RSA-based key establishment schemes that meets the following: NIST Special Publication B, 'Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography', - Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication A, 'Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography', - Finite field-based key establishment schemes that meets the following: NIST Special Publication A, 'Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography']. Page 15 of 39

16 Cryptographic Key Destruction (FCS_CKM.4) FCS_CKM.4.1 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 a part of the TSF that [logically addresses the storage location of the key and performs a [single] -pass] overwrite consisting of [zeroes, a new value of the key]] that meets the following: No Standard. (TD0130 applied) Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(1)) FCS_COP.1(1).1 The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [CBC, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO , [CBC as specified in ISO 10116, GCM as specified in ISO 19772] Cryptographic Operation (Signature Generation and Verification) (FCS_COP.1(2)) FCS_COP.1(2).1 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 bits], - Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256 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 RSASSAPKCS2v1_5, ISO/IEC , 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, and [no other curves], ISO/IEC , Section 6.4] Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) FCS_COP.1(3).1 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 : Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) FCS_COP.1(4).1 The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384] and cryptographic key sizes [key size equal to digest size] and message digest sizes [160, 256, 384] bits that meet the following: ISO/IEC :2011, Section 7 'MAC Algorithm 2' Extended: Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) (FCS_EAP- TLS_EXT.1) FCS_EAP-TLS_EXT.1.1 The TSF shall implement EAP-TLS protocol as specified in RFC 5216 with [TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246)], and no other TLS version, and support the following ciphersuites: Page 16 of 39

17 Mandatory Ciphersuites in accordance with RFC 3268: - TLS_RSA_WITH_AES_128_CBC_SHA Optional Ciphersuites: [ - TLS_RSA_WITH_AES_256_CBC_SHA, - TLS_DHE_RSA_WITH_AES_128_CBC_SHA, - TLS_DHE_RSA_WITH_AES_256_CBC_SHA, - TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246, - TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246, - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289, - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5430, - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5430]. FCS_EAP-TLS_EXT.1.2 The TOE shall generate random values used in the EAP-TLS exchange using the RBG specified in FCS_RBG_EXT.1. FCS_EAP-TLS_EXT.1.3 The TSF shall request a certificate from the client, requiring client authentication. FCS_EAP-TLS_EXT.1.4 The TSF shall verify that the client certificate presented includes the Client Authentication purpose (OID ) in the extended KeyUsage field and the Key Agreement bit is set in the KeyUsage field (OID ). FCS_EAP-TLS_EXT.1.5 The TSF shall use X509 v3 certificates as specified in FIA_X509_EXT.1. FCS_EAP-TLS_EXT.1.6 The TSF shall allow an authorized administrator to configure the list of algorithm suites that may be proposed and accepted during the EAP-TLS exchanges. FCS_EAP-TLS_EXT.1.7 The TSF shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [secp256r1, secp384r1] and no other curves HTTPS Protocol (FCS_HTTPS_EXT.1) FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS. FCS_HTTPS_EXT.1.3 The TSF shall establish the connection only if [the peer presents a valid certificate during handshake, the peer initiates handshake]. (TD0125 applied) IPsec Protocol (FCS_IPSEC_EXT.1) FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches anything that is otherwise unmatched, and discards it. FCS_IPSEC_EXT.1.3 The TSF shall implement [transport mode, tunnel mode]. (TD0160 applied) FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms [AES-CBC-128 (specified by RFC 3602), AES-CBC-256 (specified by RFC 3602)] (TD0225 applied) together with a Secure Hash Algorithm (SHA)-based HMAC. Page 17 of 39

18 FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [ - IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs 2407, 2408, 2409, RFC 4109, [RFC 4304 for extended sequence numbers], and [RFC 4868 for hash functions], - IKEv2 as defined in RFC 5996 and [with mandatory support for NAT traversal as specified in RFC 5996, section 2.23], and [RFC 4868 for hash functions]]. FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv1, IKEv2] protocol uses the cryptographic algorithms [AES-CBC-128 (as specified in RFC 3602), AES-CBC-256 (as specified in RFC 3602)]. (TD0225 applied) FCS_IPSEC_EXT.1.7 The TSF shall ensure that [ - IKEv1 Phase 1 SA lifetimes can be configured by an Security Administrator based on [length of time, where the time values can configured within [up to 24] hours], - IKEv2 SA lifetimes can be configured by an Security Administrator based on [length of time, where the time values can configured within [up to 24] hours]]. FCS_IPSEC_EXT.1.8 The TSF shall ensure that [ - IKEv1 Phase 2 SA lifetimes can be configured by a Security Administrator based on [length of time, where the time values can be configured within [up to 8] hours], - IKEv2 Child SA lifetimes can be configured by a Security Administrator based on [length of time, where the time values can be configured within [up to 8] hours]]. FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key exchange ('x' in g^x mod p) using the random bit generator specified in FCS_RBG_EXT.1, and having a length of at least [192, 224, 256, or 384] bits. FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv1, IKEv2] exchanges of length [[224, 256, or 384 bits (for DH Groups 14, 19, and 20, respectively)]]. FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Groups(s) [14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit Random ECP)]. (TD0224 applied) FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv1 Phase 1, IKEv2 IKE_SA] connection is greater than or equal to the strength of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the [IKEv1 Phase 2, IKEv2 CHILD_SA] connection. FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using [RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys]. FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented identifier in the received certificate matches the configured reference identifier, where the presented and reference identifiers are of the following types: [IP address, Fully Qualified Domain Name (FQDN)] and [no other reference identifier type]. (TD0223 applied) Extended: RADIUS (FCS_RADIUS_EXT.1) FCS_RADIUS_EXT.1.1 The TSF shall implement the RADIUS protocol as specified in RFC 2865 for communication with a NAS. FCS_RADIUS_EXT.1.2 The TSF shall implement RADIUS encapsulated EAP, as specified in RFC Page 18 of 39

19 FCS_RADIUS_EXT.1.3 The RADIUS extension for EAP (RFC 2869) shall support the use of EAP-TLS for authentication as specified in RFC Random Bit Generation (FCS_RBG_EXT.1) 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 [software-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 SSH Server Protocol (FCS_SSHS_EXT.1) FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and [no other RFCs]. 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. FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [256K] bytes in an SSH transport connection are 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 (TD0189 applied): [aes128-cbc, aes256- cbc]. FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses [ssh-rsa] and [no other public key algorithms] as its public key algorithm(s) and rejects all other public key algorithms. FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [hmac-sha1, hmac-sha2-256] and [no other MAC algorithms] as its MAC algorithm(s) and rejects all other MAC algorithm(s). FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1] and [no other methods] are the only allowed key exchange methods used for the SSH protocol. 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. (TD0167 applied) TLS Server Protocol with mutual authentication (FCS_TLSS_EXT.2) FCS_TLSS_EXT.2.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: Mandatory Ciphersuites: - TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 Optional Ciphersuites: [ - TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268, - TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268, - TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268, Page 19 of 39

20 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492, - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492, - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492, - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492, - TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246, - TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246, - TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246, - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289, - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289, - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289, - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289, - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289]. FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [none]. (TD0156 applied) FCS_TLSS_EXT.2.3 The TSF shall (TD0226 applied) [perform RSA key establishment with key size [2048 bits], generate EC Diffie-Hellman parameters over NIST curves [secp256r1, secp384r1] and no other curves, generate Diffie-Hellman parameters of size [2048 bits]]. FCS_TLSS_EXT.2.4 The TSF shall support mutual authentication of TLS clients using X.509v3 certificates. FCS_TLSS_EXT.2.5 The TSF shall not establish a trusted channel if the peer certificate is invalid. FCS_TLSS_EXT.2.6 The TSF shall not establish a trusted channel if the distinguished name (DN) or Subject Alternative Name (SAN) contained in a certificate does not match the expected identifier for the peer Identification and authentication (FIA) Authentication Failure Handling (FIA_AFL.1) FIA_AFL.1.1 FIA_AFL.1.2 Refinement: The TSF shall detect when an Administrator configurable positive integer of successive unsuccessful authentication attempts occur related to administrators attempting to authenticate remotely. When the defined number of unsuccessful authentication attempts has been met, the TSF shall [prevent the offending remote administrator from successfully authenticating until [a reset action] is taken by a local Administrator, prevent the offending remote administrator from successfully authenticating until an Administrator defined time period has elapsed] Password Management (FIA_PMG_EXT.1) 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: ['!', '@', '#', '$', '%', '^', '&', '*', ' (', ')', [?_=.,+-<>/]] ; b) Minimum password length shall be settable by the Security Administrator, and shall support passwords of 15 characters or greater. Page 20 of 39

21 Extended: Pre-Shared Key Composition (FIA_PSK_EXT.1) FIA_PSK_EXT.1.1 The TSF shall be able to use pre-shared keys for [IPsec] and RADIUS. FIA_PSK_EXT.1.2 The TSF shall be able to accept text-based pre-shared keys that: - are 22 characters and [ [up to 128 characters]]; - are composed of any combination of upper and lower case letters, numbers, and special characters (that include: '!', '@', '#', '$', '%', '^', '&', '*', '(', and ')') Protected Authentication Feedback (FIA_UAU.7) 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 Password-based Authentication Mechanism (FIA_UAU_EXT.2) FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [none] to perform administrative user authentication User Identification and Authentication (FIA_UIA_EXT.1) 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; - [[process RADIUS, Web, and other authentication requests from external entities]] FIA_UIA_EXT.1.2 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 X.509 Certificate Validation (FIA_X509_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, a Certificate Revocation List (CRL) as specified in RFC 5759]. - 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 ) in the extendedkeyusage field. o Server certificates presented for TLS shall have the Server Authentication purpose (idkp 1 with OID ) in the extendedkeyusage field. o Client certificates presented for TLS shall have the Client Authentication purpose (idkp 2 with OID ) in the extendedkeyusage field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID ) in the extendedkeyusage field. Page 21 of 39

22 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 X.509 Certificate Authentication (FIA_X509_EXT.2) FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [IPsec], and [TLS as per FTP_TRP.1]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [not accept the certificate, accept the certificate] X.509 Certificate Requests (FIA_X509_EXT.3) FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name, Organization, Organizational Unit, Country]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response Security management (FMT) Management of security functions behaviour - TrustedUpdate (FMT_MOF.1(1)) FMT_MOF.1(1).1 The TSF shall restrict the ability to enable the functions to perform manual update to Security Administrators Management of TSF Data (FMT_MTD.1(1)) FMT_MTD.1(1).1 The TSF shall restrict the ability to manage the TSF data to Security Administrators Specification of Management Functions (FMT_SMF.1) 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 [digital signature] capability prior to installing those updates (Per TD0090); - [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, - Ability to configure the cryptographic functionality]. 1 When configured for OCSP or CRLs are configured for the applicable certificates, the TOE will reject connections if the revocation status cannot be determined. When configured for CRL, but a CRL is not configured for the applicable certificate, the connection will be accepted. Page 22 of 39

23 Specification of Management Functions (FMT_SMF.1(1)) FMT_SMF.1(1).1 The TSF shall be capable of performing the following management functions: - Ability to configure the RADIUS shared secret - Ability to define an authorized NAS - Ability to enable, disable, and determine and modify the behavior of all the security functions of the TOE identified in this EP to the administrator - [Ability to configure the IPsec functionality] Restrictions on Security Roles (FMT_SMR.2) FMT_SMR.2.1 FMT_SMR.2.2 FMT_SMR.2.3 The TSF shall maintain the roles: - Security Administrator. The TSF shall be able to associate users with roles. 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 Protection of the TSF (FPT) Protection of Administrator Passwords (FPT_APW_EXT.1) 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 Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys Reliable Time Stamps (FPT_STM.1) FPT_STM.1.1 The TSF shall be able to provide reliable time stamps TSF testing (FPT_TST_EXT.1) FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on)] to demonstrate the correct operation of the TSF: [ Known Answer Tests: - Software integrity - HMAC SHA1; - HMAC - One KAT per SHA1, SHA256, SHA384 and SHA512 Per IG 9.3, this testing covers SHA POST requirements; - AES GCM - Separate encrypt and decrypt, 256 key length; - AES CMAC - Sign and verify CBC mode, 128, 256 key lengths; - RSA - Sign and verify using 2048 bit key, SHA 256, PKCS#1; - DRBG - CTR_DRBG: AES, 256 bit with and without derivation function; - ECC CDH - Shared secret calculation per SP A , IG 9.6; Pair-wise Consistency Test: - ECDSA Keygen, sign, verify using P-244, K-233 and SHA512]. Page 23 of 39