1.3 National Information Assurance Partnership 2023-08-16 VPN, VPN Gateway, VPN GW, IPsec 1.3 2023-08-16 Incorporation of NIAP Technical Decisions, TC feedback 1.2 2022-03-31 Format conversion, incorporation of NIAP Technical Decisions, TC feedback 1.1 2020-06-18 Compatibility with CPP_ND_V2.2E, incorporation of NIAP Technical Decisions TDs Applied 1.0 2019-09-17 Initial publication The scope of this Protection Profile Module (PP-Module) is to describe the security functionality of a virtual private network (VPN) gateway in terms of and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs: collaborative Protection Profile for Network Devices, Version 2.2E (NDcPP or CPP_ND_V2.2E) This Base-PP is valid because a VPN gateway is a device at the edge of a private network that terminates an IPsec tunnel, which provides device authentication, confidentiality, and integrity of information traversing a public or untrusted network. This is functionality that typically will be implemented by a network device. A Target of Evaluation (TOE) that conforms to a PP-Configuration containing this PP-Module may be a ‘Distributed TOE’ as defined in the NDcPP; however, the VPN gateway functionality described in this PP-Module should be in a single TOE component. This PP-Module does not prohibit the TOE from implementing other security functionality in a distributed manner. For example, a TOE may have a centralized device that performs VPN gateway and other security functionality (such as intrusion prevention) with a number of distributed nodes that help in the enforcement of the secondary functionality. A VPN use case where the VPN gateway is establishing VPN connectivity with endpoint VPN clients as opposed to other infrastructure devices (e.g., site-to-site). The process by which an edge network device determines if traffic bound to or from its external network is passed to its destination or dropped. A type of network device that resides at the edge of a private network and permits the establishment of VPN connectivity from computers residing in an external network. A mechanism for overlaying a cryptographically secured network over distributed wide-area networks. This PP-Module specifically addresses network gateway devices that terminate IPsec VPN tunnels. A compliant VPN gateway is a device composed of hardware and software that is connected to two or more distinct networks and has an infrastructure role in the overall enterprise network. In particular, a VPN gateway establishes a secure tunnel that provides an authenticated and encrypted path to one or more other sites and thereby decreases the risk of exposure of information transiting an untrusted network. The baseline requirements of this PP-Module are those determined necessary for a multi-site VPN gateway device. A compliant TOE may also contain the ability to act as a headend for remote clients. Because this capability is optional, the remote client-based requirements have been included in Appendix A. The physical boundary for a TOE that conforms to this PP-Module is a hardware appliance that also provides generalized network device functionality, such as auditing, identification and authentication, and cryptographic services for network communications. The TOE’s logical boundary includes all functionality required by the claimed Base-PP as well as the VPN functionality and related capabilities that are defined in this PP-Module. Any functionality that is provided by the network device that is not relevant to the security requirements defined by this PP-Module or the Base-PP is considered to be outside the scope of the TOE. This PP-Module defines two potential use cases for the VPN gateway TOE, defined below. The first use case will always be applicable for a TOE that conforms to this PP-Module. The second use case defines an optional deployment for the TOE that accompanies the first use case. The VPN gateway is part of the functionality that is provided by a general network device appliance, such as a router or switch, or a device that is dedicated solely to providing multi-site VPN gateway functionality. The VPN gateway provides the ability to act as a headend for remote clients.

This PP-Module inherits exact conformance as required from the specified Base-PPs and as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017). The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module: collaborative Protection Profile Module for Stateful Traffic Filter Firewalls v1.4 + Errata 20200625 PP-Module for Intrusion Protection Systems, v1.0 This PP-Module is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5 [CC]. This PP-Module does not claim conformance to any PP. This PP-Module does not claim conformance to any packages.

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about its operational environment (OE), and any organizational security policies that the TOE is expected to enforce.

The following threats defined in this PP-Module extend the threats defined by the Base-PP. Devices on a protected network may be exposed to threats presented by devices located outside the protected network that may attempt to modify the data without authorization. If known malicious external devices are able to communicate with devices on the protected network or if devices on the protected network can communicate with those external devices then the data contained in the communications may be susceptible to a loss of integrity. The TOE’s ability to provide address filtering helps mitigate the threat of data integrity violations by reducing the amount of potentially malicious network traffic that could potentially exploit the threat. The TOE’s ability to authenticate entities requesting network access helps mitigate the threat of integrity violations by establishing or exchanging keys that are used to maintain data integrity. The modification of data without authorization can be prevented by cryptography that ensures the confidentiality and integrity of the data. The TOE's ability to protect against unauthorized modifications to itself helps ensure that its functionality cannot be altered in such a way that it fails to maintain integrity of its communications. The TOE’s ability to provide port filtering helps mitigate the threat of data integrity violations by reducing the amount of potentially malicious network traffic that could potentially exploit the threat. Devices located outside the protected network may seek to exercise services located on the protected network that are intended to only be accessed from inside the protected network or only accessed by entities using an authenticated path into the protected network. Devices located outside the protected network may, likewise, offer services that are inappropriate for access from within the protected network. From an ingress perspective, VPN gateways can be configured so that only those network servers intended for external consumption by entities operating on a trusted network (e.g., machines operating on a network where the peer VPN gateways are supporting the connection) are accessible and only via the intended ports. This serves to mitigate the potential for network entities outside a protected network to access network servers or services intended only for consumption or access inside a protected network. From an egress perspective, VPN gateways can be configured so that only specific external services (e.g., based on destination port) can be accessed from within a protected network, or moreover are accessed via an encrypted channel. For example, access to external mail services can be blocked to enforce corporate policies against accessing uncontrolled email servers, or, that access to the mail server must be done over an encrypted link. The TOE’s address filtering capability helps mitigate the threat of network access by limiting unauthorized reconnaissance activities that can be performed outside the protected network. The TOE’s ability to authenticate entities requesting network access mitigates unauthorized network access by ensuring that unauthenticated connections cannot access the protected network. The TOE’s use of cryptography prevents unauthorized network access by encrypting data transmitted to and from an entity on an untrusted network that is accessing a protected resource. The TOE's ability to protect against unauthorized modifications to itself helps ensure that its functionality cannot be altered in such a way that it permits network access that it would ordinarily disallow. The TOE’s port filtering capability helps mitigate the threat of network access by limiting unauthorized reconnaissance activities that can be performed outside the protected network. Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to conduct unauthorized activities. If known malicious external devices are able to communicate with devices on the protected network, or if devices on the protected network can establish communications with those external devices (e.g., as a result of a phishing episode or by inadvertent responses to email messages), then those internal devices may be susceptible to the unauthorized disclosure of information. From an infiltration perspective, VPN gateways serve not only to limit access to only specific destination network addresses and ports within a protected network, but whether network traffic will be encrypted or transmitted in plaintext. With these limits, general network port scanning can be prevented from reaching protected networks or machines, and access to information on a protected network can be limited to that obtainable from specifically configured ports on identified network nodes (e.g., web pages from a designated corporate web server). Additionally, access can be limited to only specific source addresses and ports so that specific networks or network nodes can be blocked from accessing a protected network thereby further limiting the potential disclosure of information. From an exfiltration perspective, VPN gateways serve to limit how network nodes operating on a protected network can connect to and communicate with other networks limiting how and where they can disseminate information. Specific external networks can be blocked altogether or egress could be limited to specific addresses or ports. Alternately, egress options available to network nodes on a protected network can be carefully managed in order to, for example, ensure that outgoing connections are encrypted to further mitigate inappropriate disclosure of data through packet sniffing. The TOE’s address filtering capability helps mitigate the threat of network disclosure by limiting unauthorized reconnaissance activities that can be performed outside the protected network. The TOE's ability to protect against unauthorized modifications to itself helps ensure that its functionality cannot be altered to allow unauthorized disclosure of protected network traffic. The TOE’s port filtering capability helps mitigate the threat of network access by limiting unauthorized reconnaissance activities that can be performed outside the protected network. Devices located outside the protected network, while permitted to access particular public services offered inside the protected network, may attempt to conduct inappropriate activities while communicating with those allowed public services. Certain services offered from within a protected network may also represent a risk when accessed from outside the protected network. From an ingress perspective, it is generally assumed that entities operating on external networks are not bound by the use policies for a given protected network. Nonetheless, VPN gateways can log policy violations that might indicate violation of publicized usage statements for publicly available services. From an egress perspective, VPN gateways can be configured to help enforce and monitor protected network use policies. As explained in the other threats, a VPN gateway can serve to limit dissemination of data, access to external servers, and even disruption of services – all of these could be related to the use policies of a protected network and as such are subject in some regards to enforcement. Additionally, VPN gateways can be configured to log network usages that cross between protected and external networks and as a result can serve to identify potential usage policy violations. The TOE’s ability to provide address filtering helps mitigate the threat of network misuse by reducing the amount of potentially malicious network traffic that could potentially exploit the threat. The TOE’s use of cryptography prevents network misuse by ensuring that an unauthorized attacker cannot inject their own actions into the protected network. The TOE's ability to protect against unauthorized modifications to itself helps ensure that its functionality to detect potential misuse of network resources is not compromised. The TOE’s ability to provide port filtering helps mitigate the threat of network misuse by reducing the amount of potentially malicious network traffic that could potentially exploit the threat. The TOE’s system monitoring function helps mitigate the threat of network misuse by providing a method to detect when potential misuse is occurring. The TOE implements a management interface that allows for authorized usage of the TOE so that unprivileged users do not have the ability to misuse its functions. If an unauthorized individual successfully gains access to the system, the adversary may have the opportunity to conduct a “replay” attack. This method of attack allows the individual to capture packets traversing throughout the network and send the packets at a later time, possibly unknown by the intended receiver. Traffic is subject to replay if it meets the following conditions: Cleartext: an attacker with the ability to view unencrypted traffic can identify an appropriate segment of the communications to replay as well in order to cause the desired outcome No integrity: alongside cleartext traffic, an attacker can make arbitrary modifications to captured traffic and replay it to cause the desired outcome if the recipient has no means to detect these The TOE’s ability to enforce authentication helps mitigate replay attacks by making it more difficult for an attacker to impersonate a valid entity. The TOE’s use of cryptography prevents replay attacks by ensuring that network data that is modified and retransmitted will not be parsed as valid traffic. The TOE's ability to protect against unauthorized modifications to itself helps ensure that it always enforces requirements for confidentiality and integrity of network traffic in the intended manner.

This PP-Module defines assumptions that extend those defined in the supported Base-PP. All assumptions for the OE of the Base-PP also apply to this PP-Module. A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module. It is assumed that the TOE is connected to distinct networks in a manner that ensures that the TOE's security policies will be enforced on all applicable network traffic flowing among the attached networks. The Base-PP does not define where in a particular network architecture a network device must be deployed since it is designed to be generic to various types of network devices. This PP-Module defines the expected architectural deployment specifically for WLAN AS network devices. The OE objective OE.CONNECTIONS is realized through A.CONNECTIONS. To address the issues associated with unauthorized disclosure of information, inappropriate access to services, misuse of services, disruption or denial of services, and network-based reconnaissance, compliant TOE’s will implement packet filtering capability. That capability will restrict the flow of network traffic between protected networks and other attached networks based on network addresses of the network nodes originating (source) or receiving (destination) applicable network traffic as well as on established connection information. Addressed by: FPF_RUL_EXT.1, FTA_VCM_EXT.1 (optional) FPF_RUL_EXT.1 This SFR supports the objective by requiring the TSF to filter network traffic based on network address information. FTA_VCM_EXT.1 (optional) This SFR supports the objective by optionally allowing the TOE to assign a private IP address to a VPN client so that traffic bound for an alternative address can be flagged as invalid. To further address the issues associated with unauthorized disclosure of information, a compliant TOE’s authentication ability (IPSec) will allow a VPN peer to establish VPN connectivity with another VPN peer and ensure that any such connection attempt is both authenticated and authorized. VPN endpoints authenticate each other to ensure they are communicating with an authorized external IT entity. Addressed by: FCS_IPSEC_EXT.1 (refined from Base-PP), FIA_X509_EXT.1/Rev (from Base-PP), FIA_X509_EXT.2 (refined from Base-PP), FIA_X509_EXT.3 (from Base-PP), FTP_ITC.1/VPN, FPF_MFA_EXT.1 (optional), FTA_SSL.3/VPN (optional), FTA_TSE.1 (optional), FCS_EAP_EXT.1 (selection-based), FIA_HOTP_EXT.1 (selection-based), FIA_PSK_EXT.1 (selection-based), FIA_PSK_EXT.2 (selection-based), FIA_PSK_EXT.3 (selection-based), FIA_TOTP_EXT.1 (selection-based) FCS_IPSEC_EXT.1 (refined from Base-PP) This SFR supports the objective by requiring the TOE's implementation of IPsec to include requirements for how the VPN client is authenticated. FIA_X509_EXT.1/Rev (from Base-PP) This SFR supports the objective by requiring the TOE to implement X.509 validation functions so that it can authenticate remote entities that assert their identity using X.509 certificates. FIA_X509_EXT.2 (refined from Base-PP) This SFR supports the objective by requiring the TOE to implement X.509 authentication functions so that it can authenticate remote entities that assert their identity using X.509 certificates. FIA_X509_EXT.3 (from Base-PP) This SFR supports the objective by requiring the TOE to have the ability to generate a certificate request so that it can be issued an X.509 certificate that allows the TSF to offer proof of its own authenticity to external entities. FTP_ITC.1/VPN This SFR supports the objective by requiring the TOE to use an IPsec trusted channel to communicate with external entities so that these entities may be authenticated. FTA_SSL.3/VPN (optional) This SFR supports the objective by optionally allowing the TSF to terminate inactive VPN sessions so that an unattended session cannot be used to bypass authentication mechanisms. FTA_TSE.1 (optional) This SFR supports the objective by optionally defining alternative mechanisms to determine the validity of a subject to reject unauthorized or impersonated authentication attempts FPF_MFA_EXT.1 (optional) This SFR supports the objective by optionally enforcing a multifactor authentication requirement on an IPsec connection. FCS_EAP_EXT.1 (selection-based) This SFR supports the objective by optionally using an external authentication server to facilitate EAP-TLS or EAP-TTLS. FIA_HOTP_EXT.1 (selection-based) This SFR supports the objective by optionally defining the implementation of HOTP as an authentication mechanism. FIA_PSK_EXT.1 (selection-based) This SFR supports the objective by optionally supporting the use of pre-shared keys. FIA_PSK_EXT.2 (selection-based) This SFR supports the objective by optionally specifying whether the TOE generates its own pre-shared keys or accepts them from an external source. FIA_PSK_EXT.3 (selection-based) This SFR supports the objective by optionally defining the composition and use of password-based pre-shared keys used for authentication. FIA_TOTP_EXT.1 (selection-based) This SFR supports the objective by optionally defining the implementation of TOTP as an authentication mechanism. To address the issues associated with unauthorized disclosure of information, inappropriate access to services, misuse of services, disruption of services, and network-based reconnaissance, compliant TOE’s will implement cryptographic capabilities. These capabilities are intended to maintain confidentiality and allow for detection and modification of data that is transmitted outside of the TOE. Addressed by: FCS_COP.1/DataEncryption (refined from Base-PP), FCS_IPSEC_EXT.1 (refined from Base-PP), FCS_CKM.1/IKE, FCS_EAP_EXT.1 (selection-based), FIA_PSK_EXT.1 (selection-based), FIA_PSK_EXT.2 (selection-based) FCS_COP.1/DataEncryption (refined from Base-PP) This SFR supports the objective by requiring the TOE to implement AES in a specified manner. FCS_IPSEC_EXT.1 (refined from Base-PP) This SFR supports the objective by requiring the TOE to implement the IPsec protocol in a specified manner FCS_CKM.1/IKE This SFR supports the objective by requiring the TOE to generate cryptographic keys used for Internet Key Exchange (IKE) in a specified manner. FCS_EAP_EXT.1 (selection-based) This SFR supports the objective by optionally using an MSK computed by an external authentication server via the EAP-TLS or EAP-TTLS method. FIA_PSK_EXT.1 (selection-based) This SFR supports the objective by supporting a mechanism by which PSKs can be used to fortify encryption. FIA_PSK_EXT.2 (selection-based) This SFR supports the objective by optionally specifying whether the TOE generates its own pre-shared keys or accepts them from an external source.. There may be instances where the TOE’s hardware malfunctions or the integrity of the TOE’s software is compromised, the latter being due to malicious or non-malicious intent. To address the concern of the TOE operating outside of its hardware or software specification, the TOE will shut down upon discovery of a problem reported via the self-test mechanism and provide signature-based validation of updates to the TSF. Addressed by: FPT_TST_EXT.1 (refined from Base-PP), FPT_TUD_EXT.1 (refined from Base-PP), FPT_FLS.1/SelfTest, FPT_TST_EXT.3 FPT_TST_EXT.1 (refined from Base-PP) This SFR supports the objective by requiring the TOE to execute self-tests that allow the TSF to determine if it is in a failed state. FPT_TUD_EXT.1 (refined from Base-PP) This SFR supports the objective by requiring the TOE to validate software updates before applying them to reduce the risk of the TOE entering a failed state. FPT_FLS.1/SelfTest This SFR supports the objective by requiring the TOE to preserve a secure state if a self-test failure is detected. FPT_TST_EXT.3 This SFR supports the objective by requiring the TOE to verify the integrity of its executable code to ensure that it will operate in a known state. To further address the issues associated with unauthorized disclosure of information, etc., a compliant TOE’s port filtering capability will restrict the flow of network traffic between protected networks and other attached networks based on the originating (source) or receiving (destination) port (or service) identified in the network traffic as well as on established connection information. Addressed by: FPF_RUL_EXT.1 FPF_RUL_EXT.1 This SFR supports the objective by requiring the TSF to filter network traffic based on port information. To address the issues of administrators being able to monitor the operations of the VPN gateway, it is necessary to provide a capability to monitor system activity. Compliant TOEs will implement the ability to log the flow of network traffic. Specifically, the TOE will provide the means for administrators to configure packet filtering rules to ‘log’ when network traffic is found to match the configured rule. As a result, matching a rule configured to ‘log’ will result in informative event logs whenever a match occurs. In addition, the establishment of security associations (SAs) is auditable, not only between peer VPN gateways, but also with certification authorities (CAs). Addressed by: FAU_GEN.1/VPN, FPF_RUL_EXT.1 FAU_GEN.1/VPN This SFR supports the objective by requiring the TOE to generate security-relevant audit events related to VPN gateway functionality. FPF_RUL_EXT.1 This SFR supports the objective by requiring the TOE to have the ability to log network traffic that matches certain characteristics. TOEs will provide the functions necessary for an administrator to configure the packet filtering rules, as well as the cryptographic aspects of the IPsec protocol that are enforced by the TOE. Addressed by: FMT_MTD.1/CryptoKeys (refined from Base-PP), FMT_SMF.1/VPN FMT_MTD.1/CryptoKeys (refined from Base-PP) This SFR supports the objective by requiring the TOE to implement a key management function and ensure that only authorized users can use it. FMT_SMF.1/VPN This SFR supports the objective by specifying the management functions required specifically for VPN gateway functionality.

This PP-Module defines environmental security objectives that extend those defined in the supported Base-PP. All objectives for the OE of the Base-PP also apply to this PP-Module. OE.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-PP and not the PP-Module. The TOE is connected to distinct networks in a manner that ensures that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks.

The Security Functional Requirements (SFRs) included in this section are derived from Part 2 of the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5, with additional extended functional components. The CC defines operations on Security Functional Requirements: assignments, selections, assignments within selections and refinements. This document uses the following font conventions to identify the operations defined by the CC: Assignments are indicated with italicized text. Refinements made by the PP-Module author are indicated with bold text for added or substituted text and strikethrough text for removed text. Refinements are only applied to significant technical changes to existing SFRs; minor presentation changes with no technical impact (such as British vs American spelling differences) are not marked as refinements. Refinements are also indicated when an operation is added or substituted for an existing operation (e.g., the PP-Module completes an assignment in such a way that it introduces a selection into the assignment). Note that for SFRs that are defined either in CC Part 2 or in this PP-Module’s Extended Components Definition, the refinement operation is used to indicate deviations from the defined component. For Base-PP SFRs that are modified by this PP-Module, the refinement operation is used to indicate deviations from the Base-PP’s definition of the SFR (i.e., if the Base-PP refined an SFR and that change is not affected by this PP-Module, it is not shown here as a refinement). Selections are indicated with italicized text. Iteration is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the iteration, e.g., ‘/VPN’ for an SFR relating to VPN gateway functionality. Extended SFRs are identified by having a label “EXT” after the SFR name. Note that selections and assignments to be completed by the ST author are preceded with “selection:” and “assignment:”. If text is italicized and does not include either of these, it means that the selection or assignment has already been completed in this PP-Module and the ST author must use the text as written. https://www.niap-ccevs.org/profile/Info.cfm?PPID=447&id=447 In a PP-Configuration that includes the NDcPP, the VPN gateway is expected to rely on some of the security functions implemented by the network device as a whole and evaluated against the Base-PP. In this case, the following sections describe any modifications that the ST author must make to the SFRs defined in the Base-PP in addition to what is mandated by section 5.2.

This PP-Module restricts the Base-PP SFR to a subset of existing permissible functionality and does not introduce any new behavior. This SFR has been modified from its definition in the NDcPP to support this PP-Module’s IPsec requirements by mandating support for at least one of CBC or GCM modes and at least one of 128-bit or 256-bit key sizes at minimum. Other selections may be made by the ST author but they are not required for conformance to this PP-Module. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to require the ST author to make certain selections, but these selections are all part of the original definition of the SFR so no new behavior is defined by the PP-Module. This PP-Module restricts the Base-PP SFR to a subset of existing permissible functionality and does not introduce any new behavior. This element is unchanged from its definition in the Base-PP. This element is unchanged from its definition in the Base-PP. The selection of supported modes is expected to be performed according to RFC 4301. This element has been modified from its definition in the NDcPP by mandating either 128 or 256 bit key sizes for AES-CBC or AES-GCM, thereby disallowing for the sole selection of 192 bit key sizes. When an AES-CBC algorithm is selected, at least one SHA-based HMAC must also be chosen. If only an AES-GCM algorithm is selected, then a SHA-based HMAC is not required since AES-GCM satisfies both confidentiality and integrity functions. IPsec may use a truncated version of the SHA-based HMAC functions contained in the selections. Where a truncated output is used, this is described in the TSS. This element is unchanged from its definition in the Base-PP. This element is changed from its definition in the Base-PP to remove AES-GCM-192, which is not recommended. AES-CBC implementation for IPsec is specified in RFC 3602. AES-GCM implementation for IPsec is specified in RFC 5282. This element is unchanged from its definition in the Base-PP. This element is unchanged from its definition in the Base-PP. This element is unchanged from its definition in the Base-PP. This element is unchanged from its definition in the Base-PP. This element has been modified from its definition in the NDcPP by mandating DH groups 19 and 20, both of which are selectable in the original definition of the element. Any groups other than 19 and 20 may be selected by the ST author but they are not required for conformance to this PP-Module. This element is unchanged from its definition in the Base-PP. At least one public-key-based Peer Authentication method is required in order to conform to this PP-Module; one or more of the public key schemes is chosen by the ST author to reflect what is implemented. The ST author also ensures that appropriate FCS requirements reflecting the algorithms used (and key generation capabilities, if provided) are listed to support those methods. Note that the TSS will elaborate on the way in which these algorithms are to be used. If “IKEv1” is selected, “no other method” must be chosen in the third selection. If a selection with “EAP-TLS” or “EAP-TTLS” is chosen, the selection-based requirement FCS_EAP_EXT.1 must be claimed. When an EAP method is used, verification occurs via an external authentication server. Though EAP-TTLS involves PSKs, FIA_PSK_EXT.1 is not claimed because PSK requirements for EAP-TTLS are addressed instead via the Authentication Server PP. EAP-based authentication is not supported for IKEv1. If “pre-shared keys that conform to RFC 8784” is chosen, the selection-based requirement FIA_PSK_EXT.1 must be claimed. Since certificates are required for authentication, IKEv1 does not support PSKs, as PSK-based authentication and certificate-based authentication are mutually exclusive in IKEv1. Note that IKEv1 will be removed in a future version of this document. Multifactor support can be achieved via traffic filtering in accordance with FPF_MFA_EXT.1. It is acceptable for different use cases to leverage different selections. If this is the case, it must be identified. This SFR is modified from its definition in the Base-PP by adding new selections for IKE versions and authentication methods. This PP-Module requires DN to be supported for certificate reference identifiers at minimum. Other selections may be made by the ST author but they are not required for conformance to this PP-Module. In addition to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document the following activities apply: All existing activities regarding "Pre-shared keys" apply to all selections including pre-shared keys. If any selection with "Pre-shared keys" is included, the evaluator shall check to ensure that the TSS describes how the selection works in conjunction with the authentication of IPsec connections. If any selection with “Pre-shared Keys” is selected, the evaluator shall check that the operational guidance describes any configuration necessary to enable any selected authentication mechanisms. There are no additional testing activities. Session establishment with peer Entire packet contents of packets transmitted/received during session establishment

This PP-Module does not modify the Base-PP SFR; it only mandates the inclusion of the SFR because a conformant TOE will always require this functionality that is only conditional in the Base-PP. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec. This PP-Module restricts the Base-PP SFR to a subset of existing permissible functionality and does not introduce any new behavior. The Base-PP allows the ST author to specify the TSF’s use of X.509 certificates. Because this PP-Module mandates IPsec functionality, the SFR has been refined to force the inclusion of it. Other functions specified by the Base-PP may be chosen without restriction. This element is unchanged from its definition in the Base-PP. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to support its use for IPsec at a minimum. The evaluator shall ensure that all evaluation of this SFR is performed against its use in IPsec communications as well as any other supported usage. This PP-Module does not modify the Base-PP SFR; it only mandates the inclusion of the SFR because a conformant TOE will always require this functionality that is only conditional in the Base-PP. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec.

This PP-Module applies the key management functionality already defined in the Base-PP specifically to functionality related to VPN gateways. This SFR, defined in the NDcPP as selection-based, is mandated for inclusion in this PP-Module because the refinements to FMT_SMF.1 mandate its inclusion. Note that it is also refined to refer specifically to keys and certificates used for VPN operation. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec.

This PP-Module refines the Base-PP SFR to mandate a specific type of self-test. This is consistent with the Base-PP because the execution of this self-test is already implied by the Base-PP through its entropy requirements. This SFR is modified from its definition in the NDcPP by requiring noise source health tests to be performed regardless of what other testing is claimed. It is expected that the behavior of this testing will be described in the entropy documentation. Other self-tests may be defined at the ST author’s discretion; note that the Application Note in the NDcPP regarding what other self-tests are expected is still applicable here. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module requires a particular self-test to be performed, but this self-test is still evaluated using the same methods specified in the Supporting Document. This PP-Module restricts the Base-PP SFR to a subset of existing permissible functionality and does not introduce any new behavior. This element is unchanged from its definition in the Base-PP. This element is unchanged from its definition in the Base-PP. The NDcPP provides an option for how firmware/software updates can be verified but this PP-Module requires the digital signature method to be selected at minimum. Note that all other options specified in the NDcPP for this component are permitted so it is possible for the TSF to use code signing certificates to validate updates, in which case FPT_TUD_EXT.2 from the Base-PP is also included in the ST. If X.509 certificates are used to verify the integrity of an update, the certificates must conform to FIA_X509_EXT.1/Rev. Therefore, certificates that do not (or only partially) conform to FIA_X509_EXT.1/REV are not allowed as a means to authenticate firmware/software updates. NDcPP states the ST author may use X.509 certificates that do not meet FIA_X509_EXT.1/Rev. This applies to trust anchors as they can be encoded as certificates. Even when they are encoded as certificates, the trust anchor must be protected by another mechanism that ensures its integrity and binds it to the 'code-signing' context. Trust anchors do not need to be validated according to FIA_X509_EXT.1, even if they are encoded as certificates; instead they need to be validated as trust anchors. FIA_X509_EXT.1/Rev does not require revocation checking of certificates designated as trust store elements. The integrity of trust store elements depends on administrative controls for loading and managing trust stores and functional integrity checks that are described in other SFRs. So, if the certificate used to verify the update is a trust store element (self-signed and specifically trusted for verifying updates, with the integrity of this special purpose certificate protected by administrative controls and TOE integrity protections), then revocation checking is not required. However, if the certificate is issued by a trusted root CA, or by a certificate authority which chains to a trusted root CA, then revocation checking is required for all elements of the certificate chain except the trusted root CA, and the TOE must be able to obtain fresh revocation information from an external source. There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to mandate that a particular selection be chosen, but this selection is part of the original definition of the SFR so no new behavior is defined by the PP-Module.

When this PP-Module is used to extend the NDcPP, the TOE type for the overall TOE is still a network device. The TOE boundary is simply extended to include VPN gateway functionality that is provided by the network device. The threats, assumptions, and organizational security policies (OSPs) defined by this PP-Module (see sections 3.1 through 3.3) supplement those defined in the NDcPP as follows: The threat of data integrity compromise is a specific example of the T.WEAK_CRYPTOGRAPHY threat defined in the Base-PP. The threat of a malicious entity accessing protected network resources without authorization is a specific example of the T.UNTRUSTED_COMMUNICATION_CHANNELS threat defined in the Base-PP. Exposure of network devices due to insufficient protection is a specific example of the T.UNTRUSTED_COMMUNICATION_CHANNELS threat defined in the Base-PP. Depending on the specific nature of the misuse of network resources, this threat is a specific manifestation of either the T.UNTRUSTED_COMMUNICATION_CHANNELS or T.WEAK_AUTHENTICATION_ENDPOINTS threat defined in the Base-PP. A replay attack is mentioned in the Base-PP as a specific type of attack based on the T.UNTRUSTED_COMMUNICATION_CHANNELS threat. This assumption defines the TOE’s placement in a network such that it is able to perform its required security functionality. The Base-PP does not define any assumptions about the TOE’s architectural deployment so there is no conflict here. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. The Base-PP does not define any TOE objectives so PP-Module objectives do not conflict with it. This objective intends for the TOE to be connected to environmental networks in such a way that its primary functionality can be appropriately enforced. There is no inconsistency here with respect to the Base-PP because the Base-PP does not define any restrictions on how a network device is connected to its environment.

: Auditable Events for Mandatory SFRs

This SFR adds new auditable events for the TOE that relate to the functionality that is introduced by the PP-Module. The "Start-up and shutdown of the audit functions" event is identical to the event defined in the Base-PP's iteration of FAU_GEN.1. The TOE is not required to have two separate events for this behavior if there is only a single audit stream that which all audit events use. If the TOE does maintain a separate logging facility for VPN gateway-related behavior, then this event must be addressed for it. Note that if the audit functions cannot be started and stopped separately from the TOE itself, then auditing the start-up and shutdown of the TOE is sufficient to address this. The ST author only needs to include the auditable events that correspond to the SFRs claimed in the ST. The TOE is not required to generate auditable events for selection-based or optional SFRs that it does not claim. The evaluator shall examine the TSS to verify that it describes the audit mechanisms that the TOE uses to generate audit records for VPN gateway behavior. If any audit mechanisms the TSF uses for this are not used to generate audit records for events defined by FAU_GEN.1 in the Base-PP, the evaluator shall ensure that any VPN gateway-specific audit mechanisms also meet the relevant functional claims from the Base-PP. For example, FAU_STG_EXT.1 requires all audit records to be transmitted to the OE over a trusted channel. This includes the audit records that are required by FAU_GEN.1/VPN. Therefore, if the TOE has an audit mechanism that is only used for VPN gateway functionality, the evaluator shall ensure that the VPN gateway related audit records meet this requirement, even if the mechanism used to generate these audit records does not apply to any of the auditable events defined in the Base-PP. The evaluator shall examine the operational guidance to verify that it identifies all security-relevant auditable events claimed in the ST and includes sample records of each event type. If the TOE uses multiple audit mechanisms to generate different sets of records, the evaluator shall verify that the operational guidance identifies the audit records that are associated with each of the mechanisms such that the source of each audit record type is clear. The evaluator shall test the audit functionality by performing actions that trigger each of the claimed audit events and verifying that the audit records are accurate and that their format is consistent with what is specified in the operational guidance. The evaluator may generate these audit events as a consequence of performing other tests that would cause these events to be generated.

This PP-Module specifies a method of key generation that is not defined in the Base-PP. This is used for functionality defined in the Base-PP (IKE) that this PP-Module chooses to represent in greater detail. The keys that are required to be generated by the TOE through this requirement are intended to be used for the authentication of the VPN peers during the IKE (either v1 or v2) key exchange. FCS_CKM.1 in the Base-PP is intended to be used for mechanisms required by the SFRs in the Base-PP. While it is required that the public key be associated with an identity in an X509v3 certificate, this association is not required to be performed by the TOE, and instead is expected to be performed by a CA in the OE. As indicated in FCS_IPSEC_EXT.1, the TOE is required to implement RSA, ECDSA, or both for peer authentication. The generated key strength of 2048-bit RSA keys need to be equivalent to, or greater than, a symmetric key strength of 112 bits. See NIST Special Publication 800-57, “Recommendation for Key Management” for information about equivalent key strengths. The evaluator shall check to ensure that the TSS describes how the key-pairs are generated. In order to show that the TSF implementation complies with FIPS PUB 186-4, the evaluator shall ensure that the TSS contains the following information: The TSS shall list all sections of Appendix B to which the TOE complies For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not," "should," and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE For each applicable section of Appendix B, any omission of functionality related to "shall" or “should” statements shall be described Any TOE-specific extensions, processing that is not included in the Appendices, or alternative implementations allowed by the Appendices that may impact the security requirements the TOE is to enforce shall be described. The evaluator shall check that the operational guidance describes how the key generation functionality is invoked, and describes the inputs and outputs associated with the process for each signature scheme supported. The evaluator shall also check that guidance is provided regarding the format and location of the output of the key generation process. For FFC Schemes using “safe-prime” groups: Testing for FFC Schemes using safe-prime groups is done as part of testing in FCS_CKM.2. For all other selections: The evaluator shall perform the corresponding tests for FCS_CKM.1 specified in the NDcPP SD, based on the selections chosen for this SFR. If IKE key generation is implemented by a different algorithm than the NDcPP key generation function, the evaluator shall ensure this testing is performed using the correct implementation.

This SFR defines management functions that are specific to the functionality required by this PP-Module and were therefore not already defined in the Base-PP iteration of it. This SFR defines additional management functions for the TOE beyond what is defined in the Base-PP as FMT_SMF.1. The TOE may have all management functionality implemented in the same logical interface; it is not necessary for “network device management” and “VPN gateway management” to be implemented in separate interfaces. The evaluator shall examine the TSS to confirm that all management functions specified in FMT_SMF.1/VPN are provided by the TOE. As with FMT_SMF.1 in the Base-PP, the evaluator shall ensure that the TSS identifies what logical interfaces are used to perform these functions and that this includes a description of the local administrative interface. The evaluator shall examine the operational guidance to confirm that all management functions specified in FMT_SMF.1/VPN are provided by the TOE. As with FMT_SMF.1 in the Base-PP, the evaluator shall ensure that the operational guidance identifies what logical interfaces are used to perform these functions and that this includes a description of the local administrative interface. The evaluator tests management functions as part of performing other test EAs. No separate testing for FMT_SMF.1/VPN is required unless one of the management functions in FMT_SMF.1.1/VPN has not already been exercised under any other SFR. All administrative actions No additional information.

This class contains families that describe packet filtering behavior. Packet filtering refers to the notion that network traffic that is transmitted through the TOE (i.e., the source and destination of the traffic is not the TOE but the TOE is on the routing path between these two entities) can be treated differently by the TSF based on attributes associated with the traffic. As this class is defined solely to contain an extended component defined for this PP-Module, it has two families, FPF_MFA_EXT and FPF_RUL_EXT. This family defines the requirements for the rules that are used to perform packet filtering of network traffic. This SFR defines specific behavior for the processing of network traffic, specifically which communications channel is used based on certain attributes of the traffic. The Base-PP does not apply any constraints on how usage of a trusted channel is controlled so this does not contradict anything presented in the Base-PP. requires the TSF to enforce a given set of packet filtering rules in an administrator-defined order against one or more TOE interfaces. The following actions could be considered for the management functions in FMT: Ability to configure the TOE’s packet filtering functionality (i.e., the operations to be performed on network traffic based on configured attributes, the interfaces that these are associated with, and the order in which they are applied). The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: Application of rules configured with the ‘log’ operation (including source and destination address, source and destination port, and transport layer protocol value). No dependencies. The evaluator shall verify that the TSS provide a description of the TOE’s initialization and startup process, which clearly indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that packets cannot flow during this process. The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity such as a process or task) involved in processing the network packets and describes the safeguards that would prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component, such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets. The operational guidance associated with this requirement is assessed in the subsequent test EAs. The evaluator shall perform the following tests: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would otherwise be denied by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization. The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would be permitted by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization and is only permitted once initialization is complete. Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test EAs. This element identifies the protocols and references the protocol definitions that serve to define to what extent the network traffic can be interpreted by the TOE when importing (receiving network traffic or ingress) and exporting (sending–or forming to be sent–network traffic or egress). While the protocol formatting specified in the RFCs is still used, many RFCs define behaviors which are no longer considered safe to follow. For example, RFC 792 defined the “Redirect” Internet Control Message Protocol (ICMP) type, which is not considered safe to honor when it might come from an adversary; the “source quench” message, which is insecure because its source cannot be validated. It also identifies the various attributes that are applicable when constructing rules to be enforced by this requirement – the applicable interface is a property of the TOE and the rest of the identified attributes are defined in the associated RFCs. Note that the Protocol is the IPv4 field (in IPv6 this field is called the “next header”) that identifies the applicable protocol, such as TCP, UDP, ICMP, etc. Also, ‘Interface’ identified above is the external port where the applicable network traffic was received or alternately will be sent. There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4. This element defines the operations that can be associated with rules used to match network traffic. There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4. This element identifies where rules can be assigned. Specifically, a conforming TOE must be able to assign filtering rules specific to each of its available and identifiable distinct network interfaces that handle layer 3 and 4 network traffic. Identifiable means the interface is unique and identifiable within the TOE, and does not necessarily require the interface to be visible from the network perspective (e.g., does not need to have an IP address assigned to it). A distinct network interface is one or more physical connections that share a common logical path into the TOE. For example, the TOE might have a small form-factor pluggable (SFP) port supporting SFP modules that expose a number of physical network ports, but since a common driver is used for all external ports they can be treated as a single distinct network interface. Note that there could be a separate ruleset for each interface or alternately a shared ruleset that somehow associates rules with specific interfaces. The evaluator shall verify that the TSS describes a packet filtering policy that can use the following fields for each identified protocol, and that the RFCs identified for each protocol are supported: IPv4 (RFC 791) source address destination address protocol IPv6 (RFC 8200) source address destination address next header (protocol) TCP (RFC 793) source port destination port UDP (RFC 768) source port destination port The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer (e.g., third party interoperability testing, protocol compliance testing). The evaluator shall verify that each rule can identify the following actions: permit, discard, and log. The evaluator shall verify that the TSS identifies all interface types subject to the packet filtering policy and explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used), they can be treated collectively as a distinct network interface. The evaluator shall verify that the operational guidance identifies the following protocols as being supported and the following attributes as being configurable within packet filtering rules for the associated protocols: IPv4 (RFC 791) destination address protocol IPv6 (RFC 8200) source address destination address next header (protocol) TCP (RFC 793) source port destination port UDP (RFC 768) source port destination port The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit, discard, and log. The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces. The guidance may describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH, and TLS) that are processed by the TOE. The evaluator shall ensure that it is made clear what protocols were not considered as part of the TOE evaluation. The evaluator shall perform the following tests: The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be created that permit, discard, and log packets for each of the following attributes: IPv4 Destination Address Protocol IPv6 Source address Destination Address Next Header (Protocol) TCP Source Port Destination Port UDP Source Port Destination Port The evaluator shall repeat Test 1 above for each distinct network interface type supported by the TOE to ensure that packet filtering rules can be defined for all supported types. Note that these test activities should be performed in conjunction with those of FPF_RUL_EXT.1.6 where the effectiveness of the rules is tested; here the evaluator is just ensuring the guidance is sufficient and the TOE supports the administrator creating a ruleset based on the above attributes. The test activities for FPF_RUL_EXT.1.6 define the combinations of protocols and attributes required to be tested. If those combinations are configured manually, that will fulfill the objective of these test activities, but if those combinations are configured otherwise (e.g., using automation), these test activities may be necessary in order to ensure the guidance is correct and the full range of configurations can be achieved by a TOE administrator. This element requires that an administrator is able to define the order in which configured filtering rules are processed for matches. The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of default rules, determination of whether a packet is part of an established session, and application of administrator defined and ordered ruleset. The evaluator shall verify that the operational guidance describes how the order of packet filtering rules is determined and provides the necessary instructions so that an administrator can configure the order of rule processing. The evaluator shall perform the following tests: The evaluator shall devise two equal packet filtering rules with alternate operations – permit and discard. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation. The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator shall test both orders to ensure that the first is enforced regardless of the specificity of the rule. This element requires that the behavior is always to deny network traffic when no rules apply. The evaluator shall verify that the TSS describes the process for applying packet filtering rules and also that the behavior (either by default, or as configured by the administrator) is to discard packets when there is no rule match. The evaluator shall verify the TSS describes when the IPv4 and IPv6 protocols supported by the TOE differ from the full list provided in the RFC Values for IPv4 and IPv6 table. The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate instructions to configure the behavior to discard packets with no matching rules. The evaluator shall verify that the operational guidance describes the range of IPv4 and IPv6 protocols supported by the TOE. The evaluator shall perform the following tests: The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied. The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged. The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied. The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied. The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged. The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are dropped (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied. The evaluator shall configure the TOE to permit and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged. The evaluator shall configure the TOE to discard and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. The evaluator shall configure the TOE to permit and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Here the evaluator shall ensure that the UDP port 500 (IKE) is included in the set of tests. The evaluator shall configure the TOE to discard and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Again, the evaluator shall ensure that UDP port 500 is included in the set of tests. The following table identifies the RFC defined values for the protocol fields for IPv4 and IPv6 to be used in configuring and otherwise testing packet filtering rule definition and enforcement: ProtocolDefined Attributes IPv4 Transport Layer Protocol 1 - Internet Control Message Transport Layer Protocol 2 - Internet Group Management Transport Layer Protocol 3 - Gateway-to-Gateway Transport Layer Protocol 4 - IP in IP (encapsulation) Transport Layer Protocol 5 - Stream Transport Layer Protocol 6 - Transmission Control Transport Layer Protocol 7 - UCL Transport Layer Protocol 8 - Exterior Gateway Protocol Transport Layer Protocol 9 - Any private interior gateway Transport Layer Protocol 10 - BBN RCC Monitoring Transport Layer Protocol 11 - Network Voice Protocol Transport Layer Protocol 12 - PUP Transport Layer Protocol 13 - ARGUS Transport Layer Protocol 14 - EMCON Transport Layer Protocol 15 - Cross Net Debugger Transport Layer Protocol 16 - Chaos Transport Layer Protocol 17 - User Datagram Transport Layer Protocol 18 - Multiplexing Transport Layer Protocol 19 - DCN Measurement Subsystems Transport Layer Protocol 20 - Host Monitoring Transport Layer Protocol 21 - Packet Radio Measurement Transport Layer Protocol 22 - XEROX NS IDP Transport Layer Protocol 23 - Trunk-1 Transport Layer Protocol 24 - Trunk-2 Transport Layer Protocol 25 - Leaf-1 Transport Layer Protocol 26 - Leaf-2 Transport Layer Protocol 27 - Reliable Data Protocol Transport Layer Protocol 28 - Internet Reliable Transaction Transport Layer Protocol 29 - ISO Transport Protocol Class 4 Transport Layer Protocol 30 - Bulk Data Transfer Protocol Transport Layer Protocol 31 - MFE Network Services Protocol Transport Layer Protocol 32 - MERIT Internodal Protocol Transport Layer Protocol 33 - Sequential Exchange Protocol Transport Layer Protocol 34 - Third Party Connect Protocol Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol Transport Layer Protocol 36 - XTP Transport Layer Protocol 37 - Datagram Delivery Protocol Transport Layer Protocol 38 - IDPR Control Message Transport Protocol Transport Layer Protocol 39 - TP++ Transport Protocol Transport Layer Protocol 40 - IL Transport Protocol Transport Layer Protocol 41 - Simple Internet Protocol Transport Layer Protocol 42 - Source Demand Routing Protocol Transport Layer Protocol 43 - SIP Source Route Transport Layer Protocol 44 - SIP Fragment Transport Layer Protocol 45 - Inter-Domain Routing Protocol Transport Layer Protocol 46 - Reservation Protocol Transport Layer Protocol 47 - General Routing Encapsulation Transport Layer Protocol 48 - Mobile Host Routing Protocol Transport Layer Protocol 49 - BNA Transport Layer Protocol 50 - SIPP Encap Security Payload Transport Layer Protocol 51 - SIPP Authentication Header Transport Layer Protocol 52 - Integrated Net Layer Security TUBA Transport Layer Protocol 53 - IP with Encryption Transport Layer Protocol 54 - NBMA Next Hop Resolution Protocol Transport Layer Protocol 61 - Any host internal protocol Transport Layer Protocol 62 - CFTP Transport Layer Protocol 63 - Any local network Transport Layer Protocol 64 - SATNET and Backroom EXPAK Transport Layer Protocol 65 - Kryptolan Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol Transport Layer Protocol 67 - Internet Pluribus Packet Core Transport Layer Protocol 68 - Any distributed file system Transport Layer Protocol 69 - SATNET Monitoring Transport Layer Protocol 70 - VISA Protocol Transport Layer Protocol 71 - Internet Packet Core Utility Transport Layer Protocol 72 - Computer Protocol Network Executive Transport Layer Protocol 73 - Computer Protocol Heart Beat Transport Layer Protocol 74 - Wang Span Network Transport Layer Protocol 75 - Packet Video Protocol Transport Layer Protocol 76 - Backroom SATNET Monitoring Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary Transport Layer Protocol 78 - WIDEBAND Monitoring Transport Layer Protocol 79 - WIDEBAND EXPAK Transport Layer Protocol 80 - ISO Internet Protocol Transport Layer Protocol 81 - VMTP Transport Layer Protocol 82 - SECURE-VMTP Transport Layer Protocol 83 - VINES Transport Layer Protocol 84 - TTP Transport Layer Protocol 85 - NSFNET-IGP Transport Layer Protocol 86 - Dissimilar Gateway Protocol Transport Layer Protocol 87 - TCF Transport Layer Protocol 88 - IGRP Transport Layer Protocol 89 - OSPFIGP Transport Layer Protocol 90 - Sprite RPC Protocol Transport Layer Protocol 91 - Locus Address Resolution Protocol Transport Layer Protocol 92 - Multicast Transport Protocol Transport Layer Protocol 93 - AX.25 Frames Transport Layer Protocol 94 - IP-within-IP Encapsulation Protocol Transport Layer Protocol 95 - Mobile Internetworking Control Protocol Transport Layer Protocol 96 - Semaphore Communications Security Protocol Transport Layer Protocol 97 - Ethernet-within-IP Encapsulation Transport Layer Protocol 98 - Encapsulation Header Transport Layer Protocol 99 - Any private encryption scheme Transport Layer Protocol 100 - GMTP IPv6 Transport Layer Protocol 1 - Internet Control Message Transport Layer Protocol 2 - Internet Group Management Transport Layer Protocol 3 - Gateway-to-Gateway Transport Layer Protocol 4 - IPv4 encapsulation Transport Layer Protocol 5 - Stream Transport Layer Protocol 6 - Transmission Control Transport Layer Protocol 7 - CBT Transport Layer Protocol 8 - Exterior Gateway Protocol Transport Layer Protocol 9 - Any private interior gateway Transport Layer Protocol 10 - BBN RCC Monitoring Transport Layer Protocol 11 - Network Voice Protocol Transport Layer Protocol 12 - PUP Transport Layer Protocol 13 - ARGUS Transport Layer Protocol 14 - EMCON Transport Layer Protocol 15 - Cross Net Debugger Transport Layer Protocol 16 - Chaos Transport Layer Protocol 17 - User Datagram Transport Layer Protocol 18 - Multiplexing Transport Layer Protocol 19 - DCN Measurement Subsystems Transport Layer Protocol 20 - Host Monitoring Transport Layer Protocol 21 - Packet Radio Measurement Transport Layer Protocol 22 - XEROX NS IDP Transport Layer Protocol 23 - Trunk-1 Transport Layer Protocol 24 - Trunk-2 Transport Layer Protocol 25 - Leaf-1 Transport Layer Protocol 26 - Leaf-2 Transport Layer Protocol 27 - Reliable Data Protocol Transport Layer Protocol 28 - Internet Reliable Transaction Transport Layer Protocol 29 - Transport Protocol Class 4 Transport Layer Protocol 30 - Bulk Data Transfer Protocol Transport Layer Protocol 31 - MFE Network Services Protocol Transport Layer Protocol 32 - MERIT Internodal Protocol Transport Layer Protocol 33 - Datagram Congestion Control Protocol Transport Layer Protocol 34 - Third Party Connect Protocol Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol Transport Layer Protocol 36 - XTP Transport Layer Protocol 37 - Datagram Delivery Protocol Transport Layer Protocol 38 - IDPR Control Message Transport Protocol Transport Layer Protocol 39 - TP++ Transport Protocol Transport Layer Protocol 40 - IL Transport Protocol Transport Layer Protocol 41 - IPv6 encapsulation Transport Layer Protocol 42 - Source Demand Routing Protocol Transport Layer Protocol 43 - Intentionally blank Transport Layer Protocol 44 - Intentionally blank Transport Layer Protocol 45 - Inter-Domain Routing Protocol Transport Layer Protocol 46 - Reservation Protocol Transport Layer Protocol 47 - General Routing Encapsulation Transport Layer Protocol 48 - Dynamic Source Routing Protocol Transport Layer Protocol 49 - BNA Transport Layer Protocol 50 - Intentionally Blank Transport Layer Protocol 51 - Intentionally Blank Transport Layer Protocol 52 - Integrated Net Layer Security Transport Layer Protocol 53 - IP with Encryption Transport Layer Protocol 54 - NBMA Address Resolution Protocol Transport Layer Protocol 55 - Mobility Transport Layer Protocol 56 - Transport Layer Security Protocol using Kryptonet key management Transport Layer Protocol 57 - SKIP Transport Layer Protocol 58 - ICMP for IPv6 Transport Layer Protocol 59 - No Next Header for IPv6 Transport Layer Protocol 60 - Intentionally Blank Transport Layer Protocol 61 - Any host internal protocol Transport Layer Protocol 62 - CFTP Transport Layer Protocol 63 - Any local network Transport Layer Protocol 64 - SATNET and Backroom EXPAK Transport Layer Protocol 65 - Kryptolan Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol Transport Layer Protocol 67 - Internet Pluribus Packet Core Transport Layer Protocol 68 - Any distributed file system Transport Layer Protocol 69 - SATNET Monitoring Transport Layer Protocol 70 - VISA Protocol Transport Layer Protocol 71 - Internet Packet Core Utility Transport Layer Protocol 72 - Computer Protocol Network Executive Transport Layer Protocol 73 - Computer Protocol Heart Beat Transport Layer Protocol 74 - Wang Span Network Transport Layer Protocol 75 - Packet Video Protocol Transport Layer Protocol 76 - Backroom SATNET Monitoring Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary Transport Layer Protocol 78 - WIDEBAND Monitoring Transport Layer Protocol 79 - WIDEBAND EXPAK Transport Layer Protocol 80 - ISO Internet Protocol Transport Layer Protocol 81 - VMTP Transport Layer Protocol 82 - SECURE-VMTP Transport Layer Protocol 83 - VINES Transport Layer Protocol 84 - TTP Transport Layer Protocol 85 - Internet Protocol Traffic Manager Transport Layer Protocol 86 - NSFNET-IGP Transport Layer Protocol 87 - Dissimilar Gateway Protocol Transport Layer Protocol 88 - TCF Transport Layer Protocol 89 - EIGRP Transport Layer Protocol 90 - OSPFIGP Transport Layer Protocol 91 - Sprite RPC Protocol Transport Layer Protocol 92 - Locus Address Resolution Protocol Transport Layer Protocol 93 - Multicast Transport Protocol Transport Layer Protocol 94 - AX.25 Frames Transport Layer Protocol 95 - IP-within-IP Encapsulation Protocol Transport Layer Protocol 96 - Mobile Internetworking Control Pro. Transport Layer Protocol 97 - Semaphore Communications Sec. Pro. Transport Layer Protocol 98 - Ethernet-within-IP Encapsulation Transport Layer Protocol 99 - Encapsulation Header Transport Layer Protocol 100 - GMTP Transport Layer Protocol 101 - Ipsilon Flow Management Protocol Transport Layer Protocol 102 - PNNI over IP Transport Layer Protocol 103 - Protocol Independent Multicast Transport Layer Protocol 104 - ARIS Transport Layer Protocol 105 - SCPS Transport Layer Protocol Transport Layer Protocol 106 - QNX Transport Layer Protocol 107 - Active Networks Transport Layer Protocol 108 - Payload Compression Protocol Transport Layer Protocol 109 - Sitara Networks Protocol Transport Layer Protocol 110 - Compaq Peer Protocol Transport Layer Protocol 111 - IPX in IP Transport Layer Protocol 112 - Virtual Router Redundancy Protocol Transport Layer Protocol 113 - PGM Reliable Transport Protocol Transport Layer Protocol 114 - Any 0-hop protocol Transport Layer Protocol 115 - Layer Two Tunneling Protocol Transport Layer Protocol 116 - D-II Data Exchange (DDX) Transport Layer Protocol 117 - Interactive Agent Transfer Protocol Transport Layer Protocol 118 - Schedule Transfer Protocol Transport Layer Protocol 119 - SpectraLink Radio Protocol Transport Layer Protocol 120 - UTI Transport Layer Protocol 121 - Simple Message Protocol Transport Layer Protocol 122 - SM Transport Layer Protocol 123 - Performance Transparency Protocol Transport Layer Protocol 124 - ISIS over IPv4 Transport Layer Protocol 125 - FIRE Transport Layer Protocol 126 - Combat Radio Transport Protocol Transport Layer Protocol 127 - Combat Radio User Datagram Transport Layer Protocol 128 - SSCOPMCE Transport Layer Protocol 129 - IPLT Transport Layer Protocol 130 - Secure Packet Shield Transport Layer Protocol 131 - Private IP Encapsulation within IP Transport Layer Protocol 132 - Stream Control Transmission Protocol Transport Layer Protocol 133 - Fibre Channel Transport Layer Protocol 134 - RSVP-E2E-IGNORE Transport Layer Protocol 135 - Mobility Header Transport Layer Protocol 136 - UDPLite Transport Layer Protocol 137 - MPLS-in-IP Transport Layer Protocol 138 - MANET Protocols Transport Layer Protocol 139 - Host Identity Protocol Transport Layer Protocol 140 - Shim6 Protocol Transport Layer Protocol 141 - Wrapped Encapsulating Security Payload Transport Layer Protocol 142 - Robust Header Compression : RFC Values for IPv4 and IPv6 Application of rules configured with the 'log' operation Source and destination addresses Source and destination ports Transport layer protocol

The Base-PP already requires the TOE to specify the self-tests that are performed. This PP-Module simply goes one step further and requires the TSF to behave in a certain way upon failure of those self-tests. This SFR defines the expected TSF response to failures of the self-tests defined in the Base-PP. The evaluator shall ensure the TSS describes how the TOE ensures a shutdown upon a self-test failure, a failed integrity check of the TSF executable image, or a failed health test of the noise source. If there are instances when a shutdown does not occur, (e.g., a failure is deemed non-security relevant), the evaluator shall ensure that those cases are identified and a rationale is provided that supports the classification and justifies why the TOE’s ability to enforce its security policies is not affected in any such instance. The evaluator shall verify that the operational guidance provides information on the self-test failures that can cause the TOE to shut down and how to diagnose the specific failure that has occurred, including possible remediation steps if available. There are no test EAs for this component. This family is defined in the Base-PP. This PP-Module augments the extended family by adding one additional component, FPT_TST_EXT.3. This new component and its impact on the extended family’s component leveling are shown below; reference the Base-PP for all other definitions for this family. This PP-Module adds to the self-testing requirements from the Base-PP by mandating that a specific self-test be performed and that it be performed in a certain manner. This does not conflict with the Base-PP because the method used to perform the self-test is a cryptographic function already mandated by the Base-PP. requires the TSF to specify the methods by which self-testing is performed in addition to identifying the self-tests that are executed and the circumstances in which this execution occurs. No specific management functions are identified. There are no auditable events foreseen. No dependencies. This requirement expands upon the self-test requirements defined in the NDcPP by specifying the method by which one of the self-tests is to be performed. “Stored TSF executable code” refers to the entire software image of the device and not just the code related to the VPN gateway functionality defined by this PP-Module. The evaluator shall verify that the TSS describes the method used to perform self-testing on the TSF executable code, and that this method is consistent with what is described in the SFR. There are no guidance EAs for this component. There are no test EAs for this component.

This PP-Module iterates a Base-PP SFR to refer to an interface that is unique to the PP-Module. This does not affect the ability of the Base-PP iteration of the SFR to be satisfied. The FTP_ITC.1 requirement in the Base-PP relates to other trusted channel functions. This iteration is specific to IPsec VPN communications. The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications. The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications. The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications. Additional testing for IPsec is covered in FCS_IPSEC_EXT.1. Initiation of the trusted channel No additional information. Termination of the trusted channel No additional information. Failure of the trusted channel functions Identification of the initiator and target of failed trusted channel establishment attempt

: Auditable Events for Strictly Optional SFRs

The TOE may support multifactor authentication by blocking all other traffic after connection is established until secondary authentication is validated. Components in this family describe the requirements for multifactor authentication filtering when using the VPN client. This SFR relates specifically to the handling of traffic that is used for the establishment of IPsec connections. defines the use and composition of multifactor authentication filtering. No specific management functions are identified. There are no auditable events foreseen. If "verify" is selected, FIA_PSK_EXT.1 must be claimed. The evaluator shall examine the TSS to verify that it describes how authentication packets are identified and how all other traffic is blocked until secondary authentication is successful. If the selection “verify” is included, the evaluator shall examine the TSS and verify it describes each authentication factor supported. If the selection “verify via an external authentication server” is included, the evaluator shall examine the TSS and verify it describes how the factors are forwarded to the authentication server. The evaluator shall confirm other traffic is denied until verification is received by the authentication server. The evaluator shall examine the operational guidance to verify that it provides instructions to the administrator on how to configure the secondary authentication factors and any additional details necessary for filtering all other traffic. If the selection “verify via an external authentication server” is included, the evaluator shall examine the operational guidance to verify that it provides instructions to the administrator on how to integrate the authentication server. For each accepted authentication factor, the evaluator shall configure the TOE in accordance with the operational guidance. The evaluator shall attempt to connect and verify other traffic is rejected per the filtering rules. The evaluator shall then provide the authentication factor and confirm it is accepted and that traffic is no longer blocked.

: Auditable Events for Selection-based SFRs

Components in this family describe the requirements for EAP-TLS/TTLS. This SFR defines the use of EAP-TLS/TTLS; the Base-PP already defines requirements for TLS so potential support for EAP-TLS is consistent with functionality that the Base-PP already expects the TOE may have. defines the use of EAP-TLS/TTLS. No specific management functions are identified. There are no auditable events foreseen. FCS_IPSEC_EXT.1 IPsec Protocol This SFR covers the EAP requirements for a client connection to an authentication server. In particular, authentication server functionality implemented in the same device, rather than in an external device, is covered under the Authentication Server PP-Module, and is out of scope for this PP-Module. The MSK derived from EAP is distinct from the PSK. The MSK is substituted in for the IKEv2 shared secret in the AUTH computations. The evaluator shall verify that the TSS describes the use of EAP options for each of the selected peer authentication mechanisms, and that the TSF supports EAP messaging for mutually authenticated TLS between the peer and the authentication server. The evaluator shall verify that the guidance documents describe any configurable features of the EAP or TLS functionality, including instructions for configuration of the authenticators and registration processes for clients. Testing for TLS functionality is in accordance with the TLS package. For each supported EAP method claimed in FCS_EAP_EXT.1.1 and for each authentication method claimed in FCS_EAP_EXT.1.3, the evaluator shall perform the following tests: The evaluator shall follow the operational guidance to configure the TSF to use the EAP method claimed. The evaluator shall follow the operational guidance to configure the TSF to use the authentication method claimed and, for EAP-TTLS, establish a trusted channel with an authentication server that requests the method, and register the peer as a TLS client with appropriate key material required for the authentication method. The evaluator shall establish a VPN session using a test peer with a valid certificate and, for EAP-TTLS, configured to provide a correct value for the configured authenticator. The evaluator shall observe that the TSF sends EAP messages to the peer and authentication server to transfer the TLS handshake messages, and after the TSF receives the EAP-success message, that the VPN session between the peer and TSF is successfully established. The evaluator shall follow the operational guidance to configure the TSF to use a supported EAP method, establish a trusted channel with an authentication server that requests the method and register the peer as a TLS client with key material required for a supported authentication method. The evaluator shall cause the test client to respond to an IKEv2 exchange with EAP-request, but to compute the shared secret after a successful EAP exchange using the non-EAP method. The evaluator shall initiate a VPN session between the test client and the TSF and observe that the TSF aborts the session.

The TOE may support pre-shared keys for use in the IPsec protocol, and may use pre-shared keys in other protocols as well. PSK in the context of this document refers to generated values, memorized values subject to conditioning, one-time passwords, and combinations as described in FIA_PSK_EXT.1.2. Components in this family define requirements for the use of HMAC-Based One-Time password authentication, including generation methods and usage restrictions. This SFR relates to use of pre-shared keys, which is behavior that only applies to the establishment of IPsec connections. defines the implementation of HOTP. No specific management functions are identified. There are no auditable events foreseen. FCS_COP.1 Cryptographic Operation The selection FIA_HOTP_EXT.1.4 must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. In FIA_HOTP_EXT.1.5 the ST author may either provide a configurable character length of at least 6 or a preset size between 6 and 10. In FIA_HOTP_EXT.1.6 the ST author may select throttle requests, account lockout, or both. The HOTP seed and all derived values are considered secret keys for purposes of protection. The evaluator shall verify the TSS describes how the HOTP is input into the client and how that value is sent to the server. The evaluator shall confirm the TSS describes how the TOE complies with the RFC. The evaluator shall confirm the TSS describes how the HOTP seed is generated and ensure it aligns with FCS_RBG_EXT.1. The evaluator shall confirm the TSS describes how the HOTP seed is protected and ensure it aligns with the storage requirements of the Base-PP. The evaluator shall confirm the TSS describes how a new HOTP seed is assigned for each client and how each client is uniquely identified. The evaluator shall confirm the TSS describes how the HOTP seed is conditioned into an HOTP hash and verify it matches the selection in FIA_HOTP_EXT.1.4. The evaluator shall confirm the TSS describes how the HOTP hash is truncated and verify it matches the selection in FIA_HOTP_EXT.1.5. The evaluator shall confirm the TSS describes how the TOE handles multiple incoming invalid requests and verify it provides an anti-hammer mechanism that matches the selections made in FIA_HOTP_EXT.1.6. The evaluator shall confirm the TSS describes how the TOE handles resynchronization and how it rejects attempts outside of the look-ahead window selected in FIA_TOTP_EXT.1.7. The evaluator shall confirm the TSS describes how the TOE counter is incremented after each successful authentication. The evaluator shall verify the operational guidance contains any configuration necessary to enable HOTP. The evaluator shall verify the operational guidance contains all configuration guidance for setting any administrative value that is configurable in the FIA_HOTP_EXT.1 requirements. The evaluator shall configure the TOE to use a supported HOTP factor then: Attempt to establish a connection using that factor. The evaluator shall verify the client prompts the user for the HOTP before initiating the connection. The evaluator shall verify the server validates the HOTP or receives confirmation from an authentication server before establishing the channel. Attempt to establish a connection using a factor from a different client. The test passes if the client fails to connect. Attempt multiple connections outside the limits set in FIA_HOTP_EXT.1.6 and verify the remediation is triggered. The test passes if remediation is triggered as defined in the selections and assignments. Attempt to use an HOTP that is outside of the value allowed for resynchronization. The test passes if the client fails to connect. Attempt to connect with a valid HOTP, disconnect and attempt to authenticate again with the same HOTP value. The test passes if the client connects the first time and fails to connect the second time. If the HOTP generated is duplicated the test may be repeated. This family defines requirements for what the TSF defines or generates as an acceptably strong pre-shared key for authentication. This SFR defines the use of pre-shared keys, which is behavior that only relates to the establishment of IPsec connections. defines the use and composition of pre-shared keys used for IPsec. No specific management functions are identified. There are no auditable events foreseen. FCS_IPSEC_EXT.1 IPsec Protocol If “IKEv2” is selected, then the corresponding IKEv2 selection must be made in FCS_IPSEC_EXT.1.13. If “multifactor authentication filtering” is selected, then “verify” should be selected in FPF_MFA_EXT.1.2. This requirement is included if “pre-shared keys that conform to RFC 8784” is selected in FCS_IPSEC_EXT.1.13, or if “verify” is selected in FPF_MFA_EXT.1.2. If these selections are made in both FCS_IPSEC_EXT.1.13 and FPF_MFA_EXT.1.2, the TSF must satisfy the appropriate FIA_PSK_EXT.1 selections for each. If any selection including "generated bit-based" is chosen, then FIA_PSK_EXT.2 must be included. If “pre-shared keys that conform to RFC 8784” is selected in FCS_IPSEC_EXT.1.13, a generated, bit-based PSK must be used. If any selection including Password-based keys is chosen, then FIA_PSK_EXT.3 must be included. If any selection including HMAC-based one-time password keys is chosen, then FIA_HOTP_EXT.1 must be included. If any selection including time-based one-time password is chosen, then FIA_TOTP_EXT.1 must be included. The evaluator shall confirm that the TSS states which pre-shared key selections are supported for IKEv2 per FCS_IPSEC_EXT.1.13 and FPF_MFA_EXT.1.1. The evaluator shall examine the operational guidance to determine that it provides guidance to administrators on how to configure all selected pre-shared key options if any configuration is required. The evaluator shall also perform the following tests for each protocol (or instantiation of a protocol, if performed by a different implementation on the TOE). For each mechanism selected in FIA_PSK_EXT.1.2 the evaluator shall attempt to establish a connection and confirm that the connection requires the selected factors in the PSK to establish the connection. This SFR relates to use of pre-shared keys, which is behavior that only applies to the establishment of IPsec connections. defines the use and composition of generated pre-shared keys used for IPsec. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST: Failure of the randomization process FIA_PSK_EXT.1 Pre-Shared Key Composition Generated PSKs are expected to be shared between components via an out of band mechanism. This requirement is selection dependent on FIA_PSK_EXT.1. If "generate" is selected, the evaluator shall confirm that this process uses the RBG specified in FCS_RBG_EXT.1 and the output matches the size selected in FIA_PSK_EXT.2.1. The evaluator shall confirm the operational guidance contains instructions for entering generated pre-shared keys for each protocol identified in the FIA_PSK_EXT.1.1. [conditional] If generate was selected the evaluator shall generate a pre-shared key and confirm the output matches the size selected in FIA_PSK_EXT.2.1. This SFR relates to use of pre-shared keys, which is behavior that only applies to the establishment of IPsec connections. defines the use and composition of password-based pre-shared keys used for IPsec. No specific management functions are identified. The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the PP/ST: Failure of the randomization process FIA_PSK_EXT.1 Pre-Shared Key Composition For FIA_PSK_EXT.3.1, the ST author assigns the maximum size of the PSK it supports; it must support at least 64 characters or a length defined by the platform. For FIA_PSK_EXT.3.2, the ST author assigns any other supported characters; if there are no other supported characters, they should select "no other characters." For FIA_PSK_EXT.3.3, the ST author selects the parameters based on the PBKDF used by the TSF. For FIA_PSK_EXT.3.4 If the minimum length is settable, then the ST author chooses "a value settable by the administrator." If the minimum length is not settable, the ST author fills in the assignment with the minimum length the PSK must be. This requirement is to ensure bounds work properly. For FIA_PSK_EXT.3.7, the ST author may select one, both, or neither of the functions in alignment with NIST SP 800-63b. This requirement is selection dependent on FIA_PSK_EXT.1. The evaluator shall examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are used. Support for length: The evaluator shall check to ensure that the TSS describes the allowable ranges for PSK lengths, and that at least 64 characters or a length defined by the platform may be specified by the user. Support for character set: The evaluator shall check to ensure that the TSS describes the allowable character set and that it contains the characters listed in the SFR. Support for PBKDF: The evaluator shall examine the TSS to ensure that the use of PBKDF2 is described and that the key sizes match that described by the ST author. The evaluator shall check that the TSS describes the method by which the PSK is first encoded and then fed to the hash algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself. For the NIST SP 800-132-based conditioning of the PSK, the required evaluation activities will be performed when doing the evaluation activities for the appropriate requirements (FCS_COP.1/KeyedHash). The evaluator shall confirm that the minimum length is described. The ST author shall provide a description in the TSS regarding the salt generation. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1. [conditional] If password strength meter or password denylist is selected, the evaluator shall examine the TSS to ensure any password checking functionality provided by the TSF is described and contains details on how the function operates. The evaluator shall confirm the operational guidance contains instructions for entering bit-based pre-shared keys for each protocol identified in the requirement, or generating a bit-based pre-shared key (or both). The evaluator shall confirm that any management functions related to pre-shared keys that are performed by the TOE are specified in the operational guidance. The guidance must specify the allowable characters for pre-shared keys, and that list must include, at minimum, the same items contained in FIA_PSK_EXT.3.2. The evaluator shall confirm the operational guidance contains any necessary instructions for enabling and configuring password checking functionality. Support for Password/Passphrase characteristics: In addition to the analysis above, the evaluator shall also perform the following tests on a TOE configured according to the Operational Guidance: The evaluator shall compose a pre-shared key of at least 64 characters that contains a combination of the allowed characters in accordance with the FIA_PSK_EXT.1.3 and verify that a successful protocol negotiation can be performed with the key. [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length and invalid lengths that are below the minimum length, above the maximum length, null length, empty length, or zero length. The minimum test should be successful, and the invalid lengths must be rejected by the TOE. [conditional]: If the TOE initiates connections, initiate and establish a remote connection, disconnect from the connection, verify that the PSK is required when initiating the connection a second time. [conditional]: If the TOE supports a password meter, the evaluator shall enter a password and verify the password checker responds per the description in the TSS. [conditional]: If the TOE supports a password denylist, the evaluator shall enter a denylisted password and verify that the password is rejected or flagged as such. Components in this family define requirements for the use of Time-Based One-Time password authentication, including generation methods and usage restrictions. This SFR relates to use of pre-shared keys, which is behavior that only applies to the establishment of IPsec connections. defines the implementation of TOTP. No specific management functions are identified. There are no auditable events foreseen. FPT_STM.1 Reliable Time Stamps The selection FIA_TOTP_EXT.1.4 must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. In FIA_TOTP_EXT.1.5 the ST author may either provide a configurable character length of at least 6 or a preset size between 6 and 10. In FIA_TOTP_EXT.1.6 the ST author may select throttle requests, account lockout, or both. The TOTP seed and all derived values are considered secret keys for purposes of protection. The evaluator shall verify the TSS describes how the TOTP is input into the client and how that value is sent to the server. The evaluator shall confirm the TSS describes how the TOE complies with the RFC. The evaluator shall confirm the TSS describes how the TOTP seed is generated and ensure it aligns with FCS_RBG_EXT.1. The evaluator shall confirm the TSS describes how the TOTP seed is protected and ensure it aligns with the storage requirements of the Base-PP. The evaluator shall confirm the TSS describes how a new TOTP seed is assigned for each client and how each client is uniquely identified. The evaluator shall confirm the TSS describes how the TOTP seed is conditioned into a TOTP hash and verify it matches the selection in FIA_TOTP_EXT.1.4. The evaluator shall confirm the TSS describes how the TOTP hash is truncated and verify it matches the selection in FIA_TOTP_EXT.1.5. The evaluator shall confirm the TSS describes how the TOE handles multiple incoming requests and verify it provides an anti-hammer mechanism that matches the selections made in FIA_TOTP_EXT.1.6. The evaluator shall confirm the TSS describes how the TOE sets a time-step value and verify it matches the selections in the ST. The evaluator shall confirm the TSS describes how the TOE handles drift and resynchronization and verify it matches the selections. The evaluator shall ensure the TSS describes how time is kept and whether drift is calculated and recorded. If drift is recorded, the evaluator shall ensure that the TSS describes how this is done. The evaluator shall verify the operational guidance contains any configuration necessary to enable TOTP. The evaluator shall verify the operational guidance contains all configuration guidance for setting any administrative value that is configurable in the FIA_TOTP_EXT.1 requirements. The evaluator shall configure the TOE to use a supported TOTP factor then: Attempt to establish a connection using that factor. The evaluator shall verify the client prompts the user for the TOTP before initiating the connection. The evaluator shall verify the server validates the TOTP or receives confirmation from an authentication server before establishing the channel. Attempt to establish a connection using a factor from a different client. The test passes if the client fails to connect. Attempt multiple connections outside the limits set in FIA_TOTP_EXT.1.6 and verify the remediation is triggered. The test passes if remediation is triggered as defined in the selections and assignments. Attempt to use a TOTP that is outside of the value allowed for resynchronization. The test passes if the client fails to connect. Attempt to connect with a valid TOTP, disconnect and attempt to authenticate again with the same TOTP. The test passes if the client connects the first time and fails to connect the second time. If the TOTP generated is duplicated the test may be repeated.

: Auditable Events for Implementation-Based SFRs

This section contains requirements that may be optionally selected by the ST author for a “headend” VPN gateway device. The requirements in the main body of this PP-Module are those determined necessary for a multi-site VPN gateway appliance. Another application of a VPN appliance is in an architecture that is intended to serve mobile users, by providing a secure means in which a remote client may access a trusted network. These devices provide the capability to manage remote VPN clients (e.g., assigning IP addresses, managing client sessions) that are not necessarily found in VPN gateways that are limited to providing a secure communication path between trusted networks. Rather than mandate that all VPN gateways provide this mobility aspect, the requirements below are specified as an option. What this means is that multi-site VPN gateways do not have to provide these capabilities, but those devices wishing to serve the mobility community should implement the optional requirements from this Appendix in addition to all mandatory and selection-based requirements that apply to them. This SFR refers to a specific condition under which a trusted channel is terminated by the TSF. The Base-PP supports termination of trusted channels and does not mandate this be done in any particular method. This requirement exists in the NDcPP; however, it is intended to address a remote administrative interactive session. Here, the requirement applies to a VPN client that has established an SA. After some configurable time period without any activity, the connection between the VPN headend and client is terminated. The evaluator shall examine the TSS to verify that it describes the ability of the TSF to terminate an inactive VPN client session. The evaluator shall examine the operational guidance to verify that it provides instructions to the administrator on how to configure the time limit for termination of an active VPN client session. The evaluator shall perform the following tests: The evaluator shall follow the steps provided in the operational guidance to set the inactivity timer for five minutes. The evaluator shall then connect a VPN client to the TOE, let it sit idle for four minutes and fifty seconds, and observe that the VPN client is still connected at this time by performing an action that would require VPN access. The evaluator shall then disconnect the client, reconnect it, wait five minutes and ten seconds, attempt the same action, and observe that it does not succeed. The evaluator shall then verify using audit log data that the VPN client session lasted for exactly five minutes. The evaluator shall configure the inactivity timer to ten minutes and repeat Test 1, adjusting the waiting periods and expected audit log data accordingly. This SFR refers to a specific condition under which a trusted channel is terminated by the TSF. The Base-PP supports termination of trusted channels and does not mandate this be done in any particular method. For this PP-Module, “location” is defined as the client’s IP address. The evaluator shall examine the TSS to verify that it describes the methods by which the TSF can deny the establishment of an otherwise valid remote VPN client session (e.g., client credential is valid, not expired, not revoked, etc.), including day, time, and IP address at a minimum. The evaluator shall review the operational guidance to determine that it provides instructions for how to enable an access restriction that will deny VPN client session establishment for each attribute described in the TSS. The evaluator shall perform the following tests: The evaluator shall successfully connect a remote VPN client to the TOE and then disconnect it, noting the IP address from which the client connected. The evaluator shall follow the steps described in the operational guidance to prohibit that IP address from connecting, attempt to reconnect using the same VPN client, and observe that it is not successful. The evaluator shall successfully connect a remote VPN client to the TOE and then disconnect it. The evaluator shall follow the steps described in the operational guidance to prohibit the VPN client from connecting on a certain day (whether this is a day of the week or specific calendar date), attempt to reconnect using the same VPN client, and observe that it is not successful. The evaluator shall successfully connect a remote VPN client to the TOE and then disconnect it. The evaluator shall follow the steps described in the operational guidance to prohibit the VPN client during a range of times that includes the time period during which the test occurs, attempt to reconnect using the same VPN client, and observe that it is not successful. (conditional, the "other attributes" assignment has been selected and completed with one or more additional attributes) For any other attributes that are identified in FTA_TSE.1, the evaluator shall conduct a test similar to the previous three tests to demonstrate the enforcement of each of these attributes. The evaluator shall demonstrate a successful remote client VPN connection, configure the TSF to deny that connection based on the attribute, and demonstrate that a subsequent connection attempt is unsuccessful. This family defines requirements for how the TSF interacts with VPN clients in its OE. This SFR refers to network addressing, which is outside the scope of the Base-PP and therefore not prohibited by it. requires the TSF to assign private (internal) IP addresses to VPN clients that successfully establish IPsec connections with it. No specific management functions are identified. There are no auditable events foreseen. FCS_IPSEC_EXT.1 IPsec Protocol [FTP_ITC.1 Inter-TSF Trusted Channel, or FTP_TRP.1 Trusted Path] For this requirement, the private IP address is one that is internal to the trusted network for which the TOE is the headend. The evaluator shall check the TSS to verify that it asserts the ability of the TSF to assign a private IP address to a connected VPN client. There are no guidance EAs for this component. The evaluator shall connect a remote VPN client to the TOE and record its IP address as well as the internal IP address of the TOE. The evaluator shall verify that the two IP addresses belong to the same network. The evaluator shall disconnect the remote VPN client and verify that the IP address of its underlying platform is no longer part of the private network identified in the previous step.

All SFR dependencies in this PP-Module are addressed by appropriate SFRs, either from elsewhere in the PP-Module or inherited from the Base-PP. The TOE does not require any additional supplementary information to describe its entropy sources beyond the requirements outlined in the Base-PP. As with other Base-PP requirements, the only additional requirement is that the entropy documentation also applies to the specific VPN gateway capabilities of the TOE in addition to the functionality required by the claimed Base-PP. NDcPP collaborative Protection Profile for Network Devices, Version 2.2E, March 2020 ND-SD Supporting Document - Mandatory Technical Document - Evaluation Activities for Network Device cPP, Version 2.2, December 2019