1
Protection Profile for General Purpose Operating Systems/Protection
Profile for Mobile Device Fundamentals/Protection Profile for
Application Software Extended Package (EP) for Virtual Private
Network (VPN) Clients
Version: 2.0
2017-06-26
National Information Assurance Partnership
2
Table of Contents
1 Introduction ................................................................................................................... 4
1.1 Overview ............................................................................................................................4
1.2 Terms .................................................................................................................................4
1.2.1 Common Criteria Terms........................................................................................................4
1.2.2 Technology Terms.................................................................................................................4
1.3 Compliant Targets of Evaluation ..........................................................................................6
1.3.1 TOE Boundary .......................................................................................................................6
1.4 Use Cases............................................................................................................................8
2 Conformance Claims..................................................................................................... 11
3 Security Problem Description........................................................................................ 12
3.1 Threats .............................................................................................................................12
3.2 Assumptions .....................................................................................................................14
3.3 Organizational Security Policies .........................................................................................14
4 Security Objectives ....................................................................................................... 15
4.1 Security Objectives for the TOE..........................................................................................15
4.2 Security Objectives for the Operational Environment.........................................................15
4.3 Security Objectives Rationale ............................................................................................15
5 Security Requirements.................................................................................................. 16
5.1 GPOS PP Security Functional Requirements Direction.........................................................16
5.1.1 Applicable Unmodified SFRs ...............................................................................................16
5.1.2 Applicable Modified SFRs....................................................................................................17
5.1.3 Additional SFRs....................................................................................................................19
5.2 MDF PP Security Functional Requirements Direction..........................................................23
5.2.1 Applicable Unmodified SFRs ...............................................................................................23
5.2.2 Applicable Modified SFRs ....................................................................................................24
5.2.3 Additional SFRs....................................................................................................................27
5.3 App PP Security Functional Requirements Direction...........................................................28
5.3.1 Applicable Unmodified SFRs ...............................................................................................28
5.3.2 Applicable Modified SFRs....................................................................................................29
5.3.3 Additional SFRs....................................................................................................................32
5.4 TOE Security Functional Requirements...............................................................................35
5.4.1 Cryptographic Support (FCS)...............................................................................................35
5.4.2 User Data Protection (FDP).................................................................................................52
5.4.3 Security Management (FMT) ..............................................................................................53
5.4.4 Protection of the TSF (FPT) .................................................................................................54
5.5 TOE Security Assurance Requirements...............................................................................56
A. Optional Requirements................................................................................................. 57
B. Selection-Based Requirements...................................................................................... 58
B.1 Cryptographic Support (FCS)..............................................................................................58
3
C. Objective Requirements ............................................................................................... 62
C.1 Security Audit (FAU)..........................................................................................................62
C.2 User Data Protection (FDP)................................................................................................66
D. Entropy Documentation and Assessment...................................................................... 68
E. References ................................................................................................................... 69
F. Acronyms ..................................................................................................................... 70
4
1 Introduction
1.1 Overview
The scope of this Extended Package (EP) is to describe the security functionality of a virtual private
network (VPN) client in terms of [CC] and to define functional and assurance requirements for such
products. This EP is not complete in itself, but rather extends any of the Protection Profile for General
Purpose Operating Systems (GPOS PP), the Protection Profile for Mobile Device Fundamentals (MDF PP),
or the Protection Profile for Application Software (App PP). This is because a VPN client may be a specific
type of stand-alone software application or a built-in component of an operating system, whether
desktop or mobile.
1.2 Terms
The following sections provide both Common Criteria and technology terms used in this EP.
1.2.1 Common Criteria Terms
Common Criteria
(CC)
Common Criteria for Information Technology Security Evaluation.
Common Evaluation
Methodology (CEM)
Common Evaluation Methodology for Information Technology Security
Evaluation.
Extended Package
(EP)
An implementation-independent set of security requirements for a specific
subset of products described by a PP.
Protection Profile
(PP)
An implementation-independent set of security requirements for a category
of products.
Security Assurance
Requirement (SAR)
A requirement for how the TOE’s proper implementation of the SFRs is
verified by an evaluator.
Security Functional
Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST) A set of implementation-dependent security requirements for a specific
product.
Target of Evaluation
(TOE)
The product under evaluation. In this case, a network device with Enterprise
Session Controller capabilities.
TOE Security
Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary
Specification (TSS)
A description of how a TOE satisfies the SFRs in a ST.
1.2.2 Technology Terms
Administrator A user that has administrative privilege to configure the TOE in privileged
mode.
5
Authentication
Server
An entity designed to facilitate the authentication of an entity (user or client)
that attempts to access a protected network.
Authorized An entity granted access privileges to an object, system or system entity.
Critical Security
Parameter (CSP)
Security related information, e.g. secret and private cryptographic keys, and
authentication data such as passwords and PINs, whose disclosure or
modification can compromise the security of a cryptographic module.
Entropy Source This cryptographic function provides a seed for a random number generator
by accumulating the outputs from one or more noise sources. The
functionality includes a measure of the minimum work required to guess a
given output and tests to ensure that the noise sources are operating
properly.
FIPS Approved
Cryptographic
Function
A security function (e.g., cryptographic algorithm, cryptographic key
management technique, or authentication technique) that is either: 1)
specified in a Federal Information Processing Standard (FIPS), or 2) adopted in
a FIPS and specified either in an appendix to the FIPS or in a document
referenced by the FIPS.
IT Environment Hardware and software that are outside the TOE boundary that support the
TOE functionality and security policy.
Operational
Environment
The environment in which the TOE is operated.
Private Network A network that is protected from access by unauthorized users or entities.
Privileged Mode A TOE operational mode that allows a user to perform functions that require
IT Environment administrator privileges.
Public Network A network that is visible to all users and entities and does not protect against
unauthorized access (e.g. internet).
Threat Agent An entity that tries to harm an information system through destruction,
disclosure, modification of data, and/or denial of service.
Unauthorized User An entity (device or user) who has not been authorized by an authorized
administrator to access the TOE or private network.
Unprivileged Mode A TOE operational mode that only provides VPN client functions for the VPN
Client user.
VPN Client The TOE; allows remote users to use client computers to establish an
encrypted IPsec tunnel across an unprotected public network to a private
network
VPN Client User A user operating the TOE in unprivileged mode.
6
VPN Gateway A component that performs encryption and decryption of IP packets as they
cross the boundary between a private network and a public network
1.3 Compliant Targets of Evaluation
The TOE defined by this EP is the VPN client, a software application that runs on a physical or virtual host
platform, used to establish a secure IPsec connection between that host platform and a remote system.
The VPN client is intended to be located outside or inside of a private network, and establishes a secure
tunnel to an IPsec peer. For the purposes of this EP, IPsec peers are defined as:
 VPN gateways,
 Other VPN clients, and/or
 An IPsec-capable network device (supporting IPsec for the purposes of management).
The tunnel provides confidentiality, integrity, and data authentication for information that travels across
a less trusted (sometimes public) network. All VPN clients that comply with this document will support
IPsec.
This EP extends the GPOS PP when the VPN client is installed on an operating system that is discussed in
that PP (e.g., Windows, Mac OS, Linux). This EP extends the MDF PP when the VPN client is installed on a
self-contained mobile device that is bundled with an operating system (e.g. Android, BlackBerry OS, iOS,
Windows Mobile). This EP extends the App PP when the VPN client is provided by a third party and is a
standalone application that is not a bundled part of an operating system or mobile device.
As an EP of any of these PPs, it is expected that the content of this EP and the chosen base PP be
appropriately combined in the context of each product-specific Security Target. This EP has been
specifically defined such that there should be no difficulty or ambiguity in doing so. When this EP is
used, conformant TOEs are obligated to implement the functionality required in the claimed ‘base’ PP
with the additional functionality defined in this EP in response to the threat environment discussed
subsequently herein. An ST must identify the applicable versions of the EP chosen and this EP in its
conformance claims.
1.3.1 TOE Boundary
The TOE defined by this EP is purely a software solution executing on a “platform” (some sort of
operating system running on hardware). Depending on the base PP claimed as part of the TOE, the
platform may also be part of the TOE or it may be an environmental component that the TOE vendor has
no control over. Regardless of whether or not the platform itself is within the scope of the evaluation,
the VPN client itself will rely on the platform for its execution domain and proper usage. The vendor is
expected to provide sufficient installation and configuration instructions to identify an Operational
Environment with the necessary features and to provide instructions for how to configure it correctly.
The EP contains requirements that must be met by the TOE. Depending on the base PP that is claimed,
there may be some variation in the applicable requirements. This is because a given base PP may include
one or more requirements that the VPN client can inherit but are not shared amongst each possible
base PP.
7
This is somewhat different than other PPs, but addresses most implementations of VPN clients where
some part of the functionality of the IPsec tunnel is provided by the platform. In terms of the
cryptographic primitives (random bit generation, encryption/decryption, key generation, etc.) it is
actually desirable that a well-tested implementation in the platform is used rather than trying to
implement these functions in each client.
Requirements that can be satisfied by either the TOE or the platform are identified in Section 5 by text
such as “The [selection: TSF, TOE platform] shall…”. The ST author will make the appropriate selection
based on where that element is implemented. It is allowable for some elements in a component to be
implemented by the TOE, while other elements in that same component be implemented by the
platform (requirements on the usage of X.509 certificates is an example of where this might be the case,
where using the information contained in the certificates and the implementation of revocation
checking may be done by the TOE, but storage and protection of the certificates may be done by the
platform). Note that in the cases where this EP is used to extend the GPOS PP or MDF PP, “the TOE”
includes both the VPN client and the platform. In this case, it is appropriate to indicate that the TOE
satisfies this requirement. However, the ST author should make it clear, for each of these components,
which are implemented by the VPN client portion of the TOE versus the platform portion.
For these requirements, there are two sets of assurance activities. Assurance activities will differ based
on where the function that meets the requirement is implemented. In most cases, requirements
implemented by the platform will require that the evaluator examine documents pertaining to the
platform (generally the ST), while requirements implemented by the TOE may require examination of
the TSS, examination of the Operational Guidance, and/or execution of evaluator testing. For
requirements implemented by the platform there may also be requirements that the evaluators
examine the interfaces used by the TOE to access these functions on the platform to ensure that the
functionality being invoked to satisfy the requirements of this EP is the same functionality that was
evaluated.
Given the degree of coupling between a VPN client and its underlying platform, it is expected that the
client will be tested on each platform claimed in the ST. In cases where the platforms are simply
different versions of the same operating system (provided by the same platform vendor), an equivalency
argument may be made in lieu of testing on each version. The argument would have to demonstrate
that the client interacts in exactly the same way with the versions of the OS - e.g., same APIs are used
with the same parameters, the network stack is modified with exactly the same kernel modules. The
evaluator uses the operational guidance to configure the TOE and underlying platform.
A TOE that conforms to this EP will implement the Internet Engineering Task Force (IETF) Internet
Protocol Security (IPsec) Security Architecture for the Internet Protocol, RFC 4301, as well as the IPsec
Encapsulating Security Payload (ESP) protocol. IPsec ESP is specified in RFC 2406 and RFC 4303. The IPsec
VPN client will support ESP in either tunnel mode, transport mode, or both modes.
The IPsec VPN client will use either the Internet Key Exchange (IKE)v1 protocol as defined in RFCs 2407,
2408, 2409, 4109 or the IKEv2 protocol as specified in RFCs 7296 (with mandatory support for NAT
traversal as specified in section 2.23), and 4307 to authenticate and establish session keys with the VPN
entities.
8
In order to show that the TSF implements the RFCs correctly, the evaluator shall perform the assurance
activities documented in this EP. In future versions of this EP, assurance activities may be augmented, or
new ones introduced that cover more aspects of RFC compliance than is currently described in this
publication.
The IPsec VPN client enables encryption of all information that flows between itself and its IPsec peer.
The VPN client serves as an endpoint for an IPsec VPN connection and performs a number of
cryptographic functions related to establishing and maintaining that connection. If the cryptography
used to perform endpoint authentication, generate keys, and encrypt information is sufficiently robust
and the implementation has no critical design mistakes, an adversary will be unable to exhaust the
encryption key space to obtain the data. Compliance with IPsec standards, use of a properly seeded
Random Bit Generator (RBG), and secure authentication factors will ensure that access to the
transmitted information cannot be obtained with less work than a full exhaust of the key space. Any
plaintext secret and private keys or other cryptographic security parameters will be zeroized when no
longer in use to prevent disclosure of security critical data.
1.4 Use Cases
A VPN client allows users on the TOE platform to establish secure IPsec communications, providing
confidentiality, integrity, and protection of data, across a less trusted network in order to secure data in
transit. This Protection Profile defines three use cases for VPN clients. A conformant TOE will implement
one or more of the use cases specified below:
[USE CASE 1] TOE to VPN Gateway
A VPN client allows users on the TOE platform to establish an encrypted IPsec tunnel across a
less trusted, often unprotected public, network to a private network (see Figure 1). In this case,
the TOE provides encryption/decryption of network packets as they leave/arrive the VPN client’s
underlying platform. IP packets crossing from the private network to the public network will be
encrypted if their destination is a remote access VPN client supporting the same VPN policy as
the source network.
The TOE is responsible for encrypting the packets that are intended to be received by the target
on the private network and then encapsulating these packets in a way that allows the VPN
gateway to securely receive them and forward them to their final destination.
9
Public
Network
Private
Network
VPN Gateway
Gateway
Server
Endpoint
System
VPN Client
(TOE)
Figure 1: TOE to VPN Gateway
[USE CASE 2] TOE to VPN Client
A VPN client may additionally or alternatively allow a client computer to connect directly to
another computer running a VPN client (see Figure 2). In this case, the functionality of the VPN
client is to connect directly to another endpoint system in order to facilitate communications
directly to that system.
IPsec transport mode is used for end-to-end communications. In this use case, the content of
the packet data (payload) is encrypted but the original IP header is preserved. Inherent to this
use case, when two peers are communicating directly, is the disclosure of the
source/destination of the packets. Users should take into consideration any security risks
associated with this disclosure when architecting their networks in line with this use case.
Network
VPN Client
Remote
Host
Endpoint
System
VPN Client
(TOE)
Figure 2: TOE to VPN Client
[USE CASE 3] TOE to IPsec-capable Network Device
Similar to Use Case 2 above, a VPN client TOE can also be used to establish a secure connection
to an IPsec-capable network device using IPsec, similar to how SSH can be used. In this case,
where a network device is being managed remotely over an IPsec connection, the network
device itself must contain IPsec functionality to act as the peer for the connection (see Figure 3).
10
While this will behave functionally the same way as the scenario described by Use Case 2, the
user of the TOE in Use Case 3 is a network administrator who is assumed to have administrative
access to the network device they are connecting to.
Public
Network
IPsec
implementation
Network
Device
Management
Workstation
VPN Client
(TOE)
Figure 3: TOE to IPsec-capable Network Device
Regardless of the specific usage of the TOE, the focus of the Security Functional Requirements in this EP
is on the following fundamental aspects of a VPN client:
• Authentication of the IPsec peer;
• Cryptographic protection of data in transit; and
• Implementation of services.
A VPN client can establish VPN connectivity either to a VPN gateway with traffic bound for a remote
endpoint in the private network that is protected by the VPN gateway (Use Case 1), to a VPN client peer
residing on a remote endpoint in the same network as the TOE (Use Case 2), and/or to a network device
with IPsec capability for the purposes of managing that device (Use Case 3). In the first case, the entire
IP packet is encapsulated and a new header is applied so that the gateway can route the packet to its
intended destination. This is known as tunnel mode. In the latter two cases, the original IP header is
preserved and only the payload is encrypted. This is known as transport mode.
Beyond the implementation differences specified by these use cases, the remaining security
functionality is expected to be implemented by all VPN clients, regardless of whether it supports one or
more of the use cases. Regardless of the intended use case, VPN endpoints authenticate each other to
ensure they are communicating with an authorized external IT entity. Authentication of IPsec peers is
performed as part of the Internet Key Exchange (IKE) negotiation. The IKE negotiation uses a pre-existing
public key infrastructure for authentication and can optionally use a pre-shared key. When IKE
completes, an IPsec tunnel secured with Encapsulating Security Payload (ESP) is established.
It is assumed that the VPN client is implemented properly and contains no critical design mistakes. The
VPN client relies on the system or device on which it is installed for its proper execution. The vendor is
required to provide configuration guidance (AGD_PRE, AGD_OPE) to correctly install and administer the
client machine and the TOE for every operational environment supported.
11
2 Conformance Claims
Conformance Statement
To be conformant to this EP, an ST must demonstrate Exact Conformance, a subset of Strict
Conformance as defined in [CC] Part 1 (ASE_CCL). The ST must include all components in this EP that
are:
 Unconditional (which are always required)
 Selection-based (which are required when certain selections are chosen in the unconditional
requirements)
and may include components that are
 Optional
 Objective.
Unconditional requirements are found in the main body of the document (Section 5), while
appendices contain the selection-based, optional, and objective requirements. The ST may iterate
any of these components but it must not introduce any additional component (e.g. from CC Part 2 or
3) that is not defined in either the GPOS PP, MDF PP, or App PP (which this EP extends), or in this EP
itself.
CC Conformance Claims
This EP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1,
Revision 4 [CC].
PP Claim
This EP does not claim conformance to any Protection Profile. Note that this EP extends any of the
GPOS PP, MDF PP, or App PP, which means that it relies on these PPs to provide some set of ‘base’
functionality which is then expanded upon by this EP. This however does not imply that the EP itself
is conformant to either of these PPs.
Package Claim
This EP does not claim conformance to any packages.
12
3 Security Problem Description
The security problem is described in terms of the threats that the TOE is expected to address,
assumptions about its operational environment, and any organizational security policies that the TOE is
expected to enforce.
This EP is written to address the situation in which a user accesses a private network (e.g. the user’s
office network) or terminal endpoint (e.g. a network device) using a less trusted network (such as a
public Wi-Fi network or local-area network). Protection of network packets is desired as they traverse a
public network. To protect the data in-transit from disclosure and modification, a VPN is created to
establish secure communications. The VPN client provides one end of the secure VPN tunnel and
performs encryption and decryption of network packets in accordance with a VPN security policy
negotiated between the VPN client (TOE) and its IPsec peer.
The proper installation and configuration of the VPN client is critical to its correct operation such that
proper handling of the TOE by an administrator is also addressed.
Note that as an EP, all threats, assumptions, and OSPs defined in the base PP will also apply to a TOE
unless otherwise specified, depending on which of the base PP it extends. The Security Functional
Requirements defined in this EP will mitigate the threats that are defined in the EP but may also mitigate
some threats defined in the base PPs in more comprehensive detail due to the specific capabilities
provided by a VPN client.
3.1 Threats
T.UNAUTHORIZED_ACCESS
This EP does not include requirements that can protect against an insider threat. Authorized
users are not considered hostile or malicious and are trusted to follow appropriate guidance.
Only authorized personnel should have access to the system or device that contains the IPsec
VPN client. Therefore, the primary threat agents are the unauthorized entities that try to gain
access to the protected network (in cases where tunnel mode is used) or to plaintext data that
traverses the public network (regardless of whether transport mode or tunnel mode is used).
The endpoint of the network communication can be both geographically and logically distant
from the TOE, and can pass through a variety of other systems. These intermediate systems may
be under the control of the adversary, and offer an opportunity for communications over the
network to be compromised.
Plaintext communication over the network may allow critical data (such as passwords,
configuration settings, and user data) to be read and/or manipulated directly by intermediate
systems, leading to a compromise of the TOE or to the secured environmental system(s) that the
TOE is being used to facilitate communications with. IPsec can be used to provide protection for
this communication; however, there are myriad options that can be implemented for the
protocol to be compliant to the protocol specification listed in the RFC. Some of these options
can have negative impacts on the security of the connection. For instance, using a weak
encryption algorithm (even one that is allowed by the RFC, such as DES) can allow an adversary
to read and even manipulate the data on the encrypted channel, thus circumventing
countermeasures in place to prevent such attacks. Further, if the protocol is implemented with
13
little-used or non-standard options, it may be compliant with the protocol specification but will
not be able to interact with other, diverse equipment that is typically found in large enterprises.
Even though the communication path is protected, there is a possibility that the IPsec peer
could be duped into thinking that a malicious third-party user or system is the TOE. For instance,
a middleman could intercept a connection request to the TOE, and respond to the request as if
it were the TOE. In a similar manner, the TOE could also be duped into thinking that it is
establishing communications with a legitimate IPsec peer when in fact it is not. An attacker
could also mount a malicious man-in-the-middle-type of attack, in which an intermediate
system is compromised, and the traffic is proxied, examined, and modified by this system. This
attack can even be mounted via encrypted communication channels if appropriate
countermeasures are not applied. These attacks are, in part, enabled by a malicious attacker
capturing network traffic (for instance, an authentication session) and “playing back” that traffic
in order to fool an endpoint into thinking it was communicating with a legitimate remote entity.
T.TSF_CONFIGURATION
Configuring VPN tunnels is a complex and time-consuming process, and prone to errors if the
interface for doing so is not well-specified or well-behaved. The inability to configure certain
aspects of the interface may also lead to the mis-specification of the desired communications
policy or use of cryptography that may be desired or required for a particular site. This may
result in unintended weak or plaintext communications while the user thinks that their data are
being protected. Other aspects of configuring the TOE or using its security mechanisms (for
example, the update process) may also result in a reduction in the trustworthiness of the VPN
client.
T.UNAUTHORIZED_UPDATE
Since the most common attack vector used involves attacking unpatched versions of software
containing well-known flaws, updating the VPN client is necessary to ensure that changes to
threat environment are addressed. Timely application of patches ensures that the client is a
“hard target”, thus increasing the likelihood that product will be able to maintain and enforce its
security policy. However, the updates to be applied to the product must be trustable in some
manner; otherwise, an attacker can write their own “update” that instead contains malicious
code of their choosing, such as a rootkit, bot, or other malware. Once this “update” is installed,
the attacker then has control of the system and all of its data.
Methods of countering this threat typically involve hashes of the updates, and potentially
cryptographic operations (e.g., digital signatures) on those hashes as well. However, the validity
of these methods introduces additional threats. For instance, a weak hash function could result
in the attacker being able to modify the legitimate update in such a way that the hash remained
unchanged. For cryptographic signature schemes, there are dependencies on
1) the strength of the cryptographic algorithm used to provide the signature, and
2) the ability of the end user to verify the signature (which typically involves checking a
hierarchy of digital signatures back to a root of trust (a certificate authority)).
14
If a cryptographic signature scheme is weak, then it may be compromised by an attacker and the
end user will install a malicious update, thinking that it is legitimate. Similarly, if the root of trust
can be compromised, then a strong digital signature algorithm will not stop the malicious
update from being installed (the attacker will just create their own signature on the update
using the compromised root of trust, and the malicious update will then be installed without
detection).
T.USER_DATA_REUSE
Data traversing the TOE could inadvertently be sent to a different user; since these data may be
sensitive, this may cause a compromise that is unacceptable. The specific threat that must be
addressed concerns user data that is retained by the TOE in the course of processing network
traffic that could be inadvertently re-used in sending network traffic to a user other than that
intended by the sender of the original network traffic.
T.TSF_FAILURE
Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g.,
memory management, privileged modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex
mechanisms, resulting in a compromise of the TSF.
3.2 Assumptions
These assumptions are made on the operational environment in order to be able to ensure that the
security functionality specified in the EP can be provided by the TOE. If the TOE is placed in an
operational environment that does not meet these assumptions, the TOE may no longer be able to
provide all of its security functionality.
A.NO_TOE_BYPASS
Information cannot flow onto the network to which the VPN client's host is connected without
passing through the TOE.
A.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is assumed
to be provided by the environment.
A.TRUSTED_CONFIG
Personnel configuring the TOE and its operational environment will follow the applicable
security configuration guidance.
3.3 Organizational Security Policies
This EP defines no additional organizational security policies beyond those defined in the supported
base PPs.
15
4 Security Objectives
4.1 Security Objectives for the TOE
This EP defines no additional TOE security objectives beyond those specified in the base PPs.
4.2 Security Objectives for the Operational Environment
The Operational Environment of the TOE implements technical and procedural measures to assist the
TOE in correctly providing its security functionality (which is defined by the security objectives for the
TOE). This section defines the security objectives that are to be addressed by the IT domain or by non-
technical or procedural means. As indicated above, if requirements supporting an objective on the TOE
(in the previous table) are implemented in whole or in part by the platform, the ST should indicate this
by an entry in this table with that objective.
OE.NO_TOE_BYPASS
Information cannot flow onto the network to which the VPN client's host is connected without
passing through the TOE.
OE.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is assumed
to be provided by the environment.
OE.TRUSTED_CONFIG
Personnel configuring the TOE and its operational environment will follow the applicable
security configuration guidance.
4.3 Security Objectives Rationale
The security objectives for the Operational Environment are identical to the assumptions made about
the TOE’s Operational Environment. This EP does not define any TOE objectives or organizational
security policies so no additional correspondence is applicable.
16
5 Security Requirements
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 4, 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:
 Assignment is indicated with italicized text.
 Refinement is made by EP author and indicated with bold text.
 Selection is 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 functionality and/or a
sequential number in parentheses, e.g. (1).
 Extended SFRs is 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 EP and the ST author must use the text as written.
5.1 GPOS PP Security Functional Requirements Direction
If this EP is extending the GPOS PP, the VPN client is expected to rely on some of the security functions
implemented by the operating system as a whole and evaluated against the base PP. If a TOE claiming
conformance to this EP is using the GPOS PP as the claimed base PP, 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.4.
5.1.1 Applicable Unmodified SFRs
The SFRs listed in this section are defined in the GPOS PP and relevant to the secure operation of the
VPN client. When testing the TOE, it is necessary to ensure these SFRs are tested specifically in
conjunction with the VPN client portion of the TOE, either directly or as a dependency to the IPsec
functionality. The ST author may complete all selections and assignments in these SFRs without any
additional restrictions.
 FCS_CKM_EXT.3
 FCS_COP.1(2)
 FCS_COP.1(3)
 FCS_COP.1(4)
 FCS_RBG_EXT.1
 FIA_X509_EXT.1
 FPT_TUD_EXT.2
17
5.1.2 Applicable Modified SFRs
The SFRs listed in this section are defined in the GPOS PP and relevant to the secure operation of the
VPN client. Unlike the SFRs listed in the previous section, it is necessary for the ST author to complete
selections and/or assignments for these SFRs in a specific manner in order to ensure that the
functionality provided by the OS is consistent with the functionality required by the VPN client in order
for it to conform to this EP.
FCS_CKM.1(1) Cryptographic Key Generation
FCS_CKM.1.1(1) The OS shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm:
 ECC schemes using “NIST curves” P-256, P-384, and [selection: P-521, no
other curves] that meet the following: FIPS PUB 186-4, “Digital Signature
Standard (DSS)”, Appendix B.4;
 FFC schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.1;
[selection:
 RSA schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: [selection: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.3];
 No other key generation methods].
Application Note: This SFR is functionally identical to what is defined in the GPOS PP except that
FFC and ECC key generation have been made mandatory in support of IPsec due
to the mandated support for DH groups 14, 19, and 20 in FCS_IPSEC_EXT.1.8.
RSA remains present as a selection since it may be used by facets of the OS TOE
that are not specifically related to VPN client functionality.
Assurance Activity
Refer to the assurance activity for FCS_CKM.1(1) in the GPOS PP.
FCS_CKM.2(1) Cryptographic Key Establishment
FCS_CKM.2.1(1) The OS shall implement functionality to perform cryptographic key
establishment in accordance with a specified key establishment method:
 RSA-based key establishment schemes that meets the following: NIST
Special Publication 800-56B, “Recommendation for Pair-Wise Key
Establishment Schemes using Integer Factorization Cryptography”;
 Elliptic curve-based key establishment schemes that meets the following:
NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and
implementing “NIST curves” P-256, P-384, and [selection: P-521, no other
curves] as defined in FIPS PUB 186-4, “Digital Signature Standard”, and
18
[selection:
 Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”,
 Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3
].
Application Note: This SFR differs from its definition in the GPOS PP by moving elliptic curve-based
key establishment schemes from selectable to mandatory (due to the mandated
support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8). It also provides the
ability to claim either NIST SP 800-56A or RFC 3526 for key establishment using
finite field cryptography. One of these two claims must be made in support of DH
group 14 in FCS_IPSEC_EXT.1.8. The use of RSA is not explicitly mandated by the
VPN client but it is mandatory in the GPOS PP as a prerequisite to implementing
TLS, which is why it remains mandatory here.
Assurance Activity
For all key establishment schemes that conform to NIST SP 800-56A or 800-
56B, refer to the assurance activity for FCS_CKM.2(1) in the GPOS PP.
If “Key establishment scheme using Diffie-Hellman group 14…” is selected,
the evaluator shall ensure that the TSS describes how the implementation
meets RFC 3526 Section 3. The evaluator shall also verify the correctness of
the TSF’s implementation of Diffie-Hellman group 14 by using a known good
implementation for each protocol selected in FTP_ITC_EXT.1 and FTP_TRP.1
in the GPOS PP that uses Diffie-Hellman group 14. Note that because a TOE
that conforms to this EP must implement IPsec, the tested protocols shall
include IPsec at minimum.
FCS_COP.1(1) Cryptographic Operation (Encryption and Decryption)
FCS_COP.1.1(1) The OS shall perform encryption/decryption services for data in accordance with
a specified cryptographic algorithm
 AES-XTS (as defined in NIST SP 800-38E) mode;
 AES-CBC (as defined in NIST SP 800-38A) mode:
 AES-GCM (as defined in NIST SP 800-38D)
and [selection:
 AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C, and IEEE 802.11-
2012);
 AES Key Wrap (KW) (as defined in NIST SP 800-38F);
 AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F);
 AES-CCM (as defined in NIST SP 800-38C);
 AES-CCMP-256 (as defined in NIST SP 800-38C and IEEE 802.11ac-2013);
19
 AES-GCMP-256 (as defined in NIST SP 800-38D and IEEE 802.11ac-2013);
 No other modes
] and cryptographic key sizes [128-bit, 256-bit].
Application Note: This SFR is identical to what is defined in the GPOS PP except that support for
GCM mode is mandatory in order to address the requirements for
FCS_IPSEC_EXT.1. In addition, both 128-bit and 256-bit for key sizes must be
selected in order to meet the requirements for FCS_IPSEC_EXT.1.
Assurance Activity
Refer to the assurance activity for FCS_COP.1(1) in the GPOS PP.
5.1.3 Additional SFRs
This section lists additional SFRs that must be added to the TOE boundary in order to implement the
functionality required by this EP when the GPOS PP is claimed as the base PP.
FCS_CKM.1/VPN Cryptographic Key Generation (IKE)
FCS_CKM.1.1/VPN The [selection: VPN client, OS] shall generate asymmetric cryptographic keys
used for IKE peer authentication in accordance with: [selection:
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA
schemes;
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for
ECDSA schemes and implementing “NIST curves”, P-256, P-384, and
[selection: P-521, no other curves]]
and specified cryptographic key sizes equivalent to, or greater than, a
symmetric key strength of 112 bits.
Application Note: 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 entities during the IKE
(either v1 or v2) key exchange. While it is required that the public key be
associated with an identity in an X.509v3 certificate, this association is not
required to be performed by the TOE, and instead is expected to be performed by
a Certificate Authority in the Operational Environment.
As indicated in FCS_IPSEC_EXT.1, the TOE is required to implement support for
RSA or ECDSA (or both) for authentication.
See NIST Special Publication 800-57, “Recommendation for Key Management”
for information about equivalent key strengths.
Assurance Activity
TSS
20
The evaluator shall examine the TSS to verify that it describes how the key
generation functionality is invoked.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
FCS_CKM_EXT.2 Cryptographic Key Storage
FCS_CKM_EXT.2.1 The [selection: VPN client, OS] shall store persistent secrets and private keys
when not in use in OS-provided key storage.
Application Note: This requirement ensures that persistent secrets (credentials, secret keys) and
private keys are stored securely when not in use. If some secrets/keys are
manipulated by the VPN client and others are manipulated by the OS, then both
of the selections can be specified by the ST author.
Assurance Activity
TSS
Regardless of whether this requirement is met by the VPN client or the OS,
the evaluator will check the TSS to ensure that it lists each persistent secret
(credential, secret key) and private key needed to meet the requirements in
the ST. For each of these items, the evaluator will confirm that the TSS lists
for what purpose it is used, and how it is stored.
The evaluator shall review the TSS for to determine that it makes a case that,
for each item listed as being manipulated by the VPN client, it is not written
unencrypted to persistent memory, and that the item is stored by the OS.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
FIA_X509_EXT.3 X.509 Certificate Use and Management
FIA_X509_EXT.3.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec exchanges, and [selection: digital signatures for
FPT_TUD_EXT.1, integrity checks for FPT_TST_EXT.1, no additional uses].
Assurance Activity
21
This requirement is tested through assurance activities for FCS_IPSEC_EXT.1,
(conditionally) FPT_TUD_EXT.1, and (conditionally) FPT_TST_EXT.1.
FIA_X509_EXT.3.2 When a connection to determine the validity of a certificate cannot be
established, the [selection: VPN client, OS] shall [selection: allow the
administrator to choose whether to accept the certificate in these cases, accept
the certificate, not accept the certificate].
Application Note: Oftentimes a connection must be established to perform a verification of the
revocation status of a certificate - either to download a CRL or to perform OCSP.
The selection is used to describe the behavior in the event that such a connection
cannot be established (for example, due to a network error). The behavior of the
TOE in these cases is described by the second selection. If the TOE has
determined the certificate valid according to all other rules in FIA_X509_EXT.1,
the behavior indicated in the second selection shall determine the validity. The
TOE must not accept the certificate if it fails any of the other validation rules in
FIA_X509_EXT.1. If the administrator-configured option is selected by the ST
Author, the ST Author must also make the appropriate selection in FMT_SMF.1.
Assurance Activity
TSS
The evaluator shall check the TSS to ensure that it describes whether the VPN
client or the OS implements the certificate validation functionality, how the
VPN client/OS chooses which certificates to use, and any necessary
instructions in the administrative guidance for configuring the OS so that
desired certificates can be used.
The evaluator shall examine the TSS to confirm that it describes the behavior
of the client/OS when a connection cannot be established during the validity
check of a certificate used in establishing a trusted channel.
AGD
If the requirement that the administrator is able to specify the default action,
then the evaluator shall ensure that the operational guidance contains
instructions on how this configuration action is performed.
Test
The evaluator shall perform the following test regardless of whether the
certificate validation functionality is implemented by the VPN client or by the
OS:
Test 1: The evaluator shall demonstrate that using a valid certificate that
requires certificate validation checking to be performed in at least some part
by communicating with a non-TOE IT entity. The evaluator shall then
manipulate the environment so that the TOE is unable to verify the validity of
22
the certificate, and observe that the action selected in FIA_X509_EXT.3.2 is
performed. If the selected action is administrator-configurable, then the
evaluator shall follow the operational guidance to determine that all
supported administrator-configurable options behave in their documented
manner.
FIA_X509_EXT.3.3 The [selection: VPN client, OS] shall not establish an SA if a certificate or
certificate path is deemed invalid.
Assurance Activity
This requirement is tested as part of FCS_IPSEC_EXT.1.11.
FTP_ITC.1 Inter-TSF Trusted Channel
FTP_ITC.1.1 The [selection: VPN client, OS] shall use IPsec to provide a trusted
communication channel between itself and [selection: a remote VPN gateway,
a remote VPN client, a remote IPsec-capable network device] that is logically
distinct from other communication channels and provides assured identification
of its end points and protection of the channel data from disclosure and
detection of modification of the channel data.
FTP_ITC.1.2 The [selection: VPN client, OS] shall permit [the TSF] to initiate communication
via the trusted channel.
FTP_ITC.1.3 The [selection: VPN client, OS] shall initiate communication via the trusted
channel [for all traffic traversing that connection].
Application Note: The intent of the above requirement is to demonstrate that IPsec can be used to
establish remote communications in transport and/or tunnel mode.
The requirement implies that not only are communications protected when they
are initially established, but also on resumption after an outage. It may be the
case that some part of the TOE setup involves manually setting up tunnels to
protect other communication, and if after an outage the TOE attempts to re-
establish the communication automatically with (the necessary) manual
intervention, there may be a window created where an attacker might be able to
gain critical information or compromise a connection.
Assurance Activity
TSS
The evaluator shall examine the TSS to determine that it describes the details
of the TOE connecting to a VPN gateway and/or VPN client and/or IPsec-
capable network device in terms of the cryptographic protocols specified in
the requirement, along with TOE-specific options or procedures that might
not be reflected in the specification. The evaluator shall also confirm that all
23
protocols listed in the TSS are specified and included in the requirements in
the ST.
AGD
The evaluator shall confirm that the operational guidance contains
instructions for establishing the connection to a VPN gateway and/or VPN
client and/or IPsec-capable network device, and that it contains recovery
instructions should a connection be unintentionally broken.
Test
The evaluator shall perform the following tests:
Test 1: The evaluators shall ensure that the TOE is able to initiate
communications with a VPN gateway and/or VPN client and/or IPsec-capable
network device using the protocols specified in the requirement, setting up the
connections as described in the operational guidance and ensuring that
communication is successful.
Test 2: The evaluator shall ensure, for each communication channel with an
IPsec peer, the channel data is not sent in plaintext.
Test 3: The evaluator shall ensure, for each communication channel with an
IPsec peer, modification of the channel data is detected by the TOE.
Test 4: The evaluators shall physically interrupt the connection from the TOE
to the IPsec peer. The evaluators shall ensure that subsequent communications
are appropriately protected, at a minimum in the case of any attempts to
automatically resume the connection or connect to a new access point.
Further assurance activities are associated with requirements for
FCS_IPSEC_EXT.1.
5.2 MDF PP Security Functional Requirements Direction
In cases where the TOE is a software application and this EP is used to extend the MDF PP, it is necessary
for the ST author to make certain selections or assignments and to include certain optional
requirements in order to provide the functionality required by the EP. This section provides instructions
on what claims need to be made in the base PP in order to claim conformance to this EP.
Full assurance activities are not repeated for the requirements in this section that are references to the
MDF PP; only the additional testing needed to supplement what has already been captured in the MDF
PP is included.
5.2.1 Applicable Unmodified SFRs
The SFRs listed in this section are defined in the MDF PP and relevant to the secure operation of the VPN
client. When testing the TOE, it is necessary to ensure these SFRs are tested specifically in conjunction
24
with the VPN client portion of the TOE, either directly or as a dependency to the IPsec functionality. The
ST author may complete all selections and assignments in these SFRs without any additional restrictions.
 FCS_CKM_EXT.4
 FCS_COP.1(2)
 FCS_COP.1(3)
 FCS_COP.1(4)
 FCS_STG_EXT.2
 FCS_RBG_EXT.1
 FIA_X509_EXT.1
 FPT_TUD_EXT.1
 FTP_ITC_EXT.1
5.2.2 Applicable Modified SFRs
The SFRs listed in this section are defined in the MDF PP and relevant to the secure operation of the VPN
client. Unlike the SFRs listed in the previous section, it is necessary for the ST author to complete
selections and/or assignments for these SFRs in a specific manner in order to ensure that the
functionality provided by the mobile device is consistent with the functionality required by the VPN
client in order for it to conform to this EP.
FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm
 [ECC schemes] using [“NIST curves” P-256, P-384 and [P-521, no other
curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature
Standard (DSS)”, Appendix B.4], [Curve25519 schemes that meet the
following: [RFC 7748]];
 [FFC schemes] using cryptographic key sizes of [2048-bit or greater] that
meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.1];
[selection:
 [RSA schemes] using cryptographic key sizes of [2048-bit or greater] that
meet [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3];
 no other key generation methods].
Application Note: This SFR is functionally identical to what is defined in the MDF PP except that FFC
and ECC key generation have been made mandatory in support of IPsec due to
the mandated support for DH groups 14, 19, and 20 in FCS_IPSEC_EXT.1.8, and
support for P-256 is made mandatory due to its use in DH group 19. Curve25519
schemes are included to satisfy FDP_DAR_EXT.2.2 in the MDF PP; these schemes
are not used in support of IPsec. RSA remains present as a selection since it may
be used by facets of the MDF TOE that are not specifically related to VPN client
functionality.
25
Assurance Activity
Refer to the assurance activity for FCS_CKM.1 in the MDF PP.
FCS_CKM.2(1) Cryptographic Key Establishment
FCS_CKM.2.1(1) The TSF shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method:
 [RSA-based key establishment schemes] that meets the following: [NIST
Special Publication 800-56B, “Recommendation for Pair-Wise Key
Establishment Schemes Using Integer Factorization Cryptography”];
 [Elliptic curve-based key establishment schemes] that meets the following:
[NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”]; and
[selection:
 [Finite field-based key establishment schemes] that meets the following:
[NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”],
 Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3
].
Application Note: This SFR differs from its definition in the MDF PP by moving elliptic curve-based
key establishment schemes from selectable to mandatory (due to the mandated
support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8). It also provides the
ability to claim either NIST SP 800-56A or RFC 3526 for key establishment using
finite field cryptography. One of these two claims must be made in support of DH
group 14 in FCS_IPSEC_EXT.1.8. The use of RSA is not explicitly mandated by the
VPN client but it is mandatory in the MDF PP, which is why it remains mandatory
here.
Assurance Activity
For all key establishment schemes that conform to NIST SP 800-56A or 800-
56B, refer to the assurance activity for FCS_CKM.2(1) in the MDF PP.
If “Key establishment scheme using Diffie-Hellman group 14…” is selected,
the evaluator shall ensure that the TSS describes how the implementation
meets RFC 3526 Section 3. The evaluator shall also verify the correctness of
the TSF’s implementation of Diffie-Hellman group 14 by using a known good
implementation for each protocol selected in FTP_ITC_EXT.1 in the MDF PP
that uses Diffie-Hellman group 14. Note that because a TOE that conforms to
this EP must implement IPsec, the tested protocols shall include IPsec at
minimum.
26
FCS_COP.1(1) Cryptographic Operation
FCS_COP.1.1(1) The TSF shall perform [encryption/decryption] in accordance with a specified
algorithm
 AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A),
 AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-
2012),
 AES-GCM (as defined in NIST SP 800-38D), and
[selection:
 AES Key Wrap (KW) (as defined in NIST SP 800-38F),
 AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F),
 AES-CCM (as defined in NIST SP 800-38C),
 AES-XTS (as defined in NIST SP 800-38E),
 AES-CCMP-256 (as defined in NIST SP 800-38C and IEEE 802.11ac-2013),
 AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013),
 no other modes]
and cryptographic key sizes 128-bit key sizes and [256-bit key sizes].
Application Note: This SFR is identical to what is defined in the MDF PP except that support for
GCM mode and support for 256-bit key sizes are both mandatory in order to
address the requirements for FCS_IPSEC_EXT.1.
Assurance Activity
Refer to the assurance activity for FCS_COP.1(1) in the MDF PP.
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication IPsec, and [selection: TLS, HTTPS, DTLS, no other protocols], and
[selection: code signing for system software updates, code signing for mobile
applications, code signing for integrity verification, [assignment: other uses], no
additional uses].
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [selection: allow the administrator to choose whether to
accept the certificate in these cases, allow the user to choose whether to accept
the certificate in the these cases, accept the certificate, not accept the
certificate].
Application Note: This SFR is identical to what is defined in the MDF PP except that support for
IPsec is mandated. Since the original SFR did not explicitly require at least one of
TLS, HTTPS, or DTLS to be selected, “no other protocols” has also been added as
a selection in the event that IPsec is the only protocol for which the TOE uses
X.509v3 certificates for authentication.
27
Assurance Activity
Refer to the assurance activity for FIA_X509_EXT.2 in the MDF PP.
FTP_ITC_EXT.1 Trusted Channel Communication
FTP_ITC_EXT.1.1 The TSF shall use 802.11-2012, 802.1X, EAP-TLS, IPsec, and [selection: TLS, DTLS,
HTTPS, no other protocols] to provide a communication channel between itself
and another trusted IT product that is logically distinct from other
communication channels, provides assured identification of its end points,
protects channel data from disclosure, and detects modification of the channel
data.
FTP_ITC_EXT.1.2 The TSF shall permit the TSF to initiate communication via the trusted channel.
FTP_ITC_EXT.1.3 The TSF shall initiate communication via the trusted channel for wireless access
point connections, administrative communication, configured enterprise
connections, and [selection: OTA updates, no other connections].
Application Note: This SFR is identical to what is defined in the base PP except that support for
IPsec is mandated. Additionally, since the base PP requires ‘at least one of’ the
selected protocols which previously included IPsec, ‘no other protocols’ is now
available as an option in the selection.
Assurance Activity
Refer to the assurance activity for FTP_ITC_EXT.1 in the MDF PP.
5.2.3 Additional SFRs
This section lists additional SFRs that must be added to the TOE boundary in order to implement the
functionality required by this EP when the MDF PP is claimed as the base PP.
FCS_CKM.1/VPN Cryptographic Key Generation (IKE)
FCS_CKM.1.1/VPN The [selection: VPN client, OS] shall generate asymmetric cryptographic keys
used for IKE peer authentication in accordance with: [selection:
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for RSA
schemes;
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for
ECDSA schemes and implementing “NIST curves”, P-256, P-384 and
[selection: P-521, no other curves]]
and specified cryptographic key sizes equivalent to, or greater than, a
symmetric key strength of 112 bits.
Application Note: 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 entities during the IKE
(either v1 or v2) key exchange. While it is required that the public key be
associated with an identity in an X509v3 certificate, this association is not
28
required to be performed by the TOE, and instead is expected to be performed by
a Certificate Authority in the Operational Environment.
As indicated in FCS_IPSEC_EXT.1, the TOE is required to implement support for
RSA or ECDSA (or both) for authentication.
See NIST Special Publication 800-57, “Recommendation for Key Management”
for information about equivalent key strengths.
Assurance Activity
TSS
The evaluator shall examine the TSS to verify that it describes how the key
generation functionality is invoked.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
5.3 App PP Security Functional Requirements Direction
If this EP is extending the App PP, the VPN client is expected to rely on the security functions
implemented by the application as a whole and evaluated against the base PP. If a TOE claiming
conformance to this EP is using the App PP as the claimed base PP, 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 3.2 above.
5.3.1 Applicable Unmodified SFRs
The SFRs listed in this section are defined in the App PP and relevant to the secure operation of the VPN
client. When testing the TOE, it is necessary to ensure these SFRs are tested specifically in conjunction
with the VPN client portion of the TOE, either directly or as a dependency to the IPsec functionality. The
ST author may complete all selections and assignments in these SFRs without any additional restrictions.
 FIA_X509_EXT.1
 FPT_TUD_EXT.1
Additionally, the following selection-based SFRs may or may not be implemented by the TOE but can be
included without restrictions if the TOE provides these functions:
 FCS_COP.1(2)
 FCS_COP.1(3)
 FCS_COP.1(4)
29
5.3.2 Applicable Modified SFRs
The SFRs listed in this section are defined in the App PP and relevant to the secure operation of the VPN
client. Unlike the SFRs listed in the previous section, it is necessary for the ST author to complete
selections and/or assignments for these SFRs in a specific manner in order to ensure that the
functionality provided by the application is consistent with the functionality required by the VPN client
in order for it to conform to this EP.
FCS_CKM.1(1) Cryptographic Asymmetric Key Generation
FCS_CKM.1.1(1) The application shall generate asymmetric cryptographic keys in accordance
with a specified cryptographic key generation algorithm
 [ECC schemes] using [“NIST curves” P-256, P-384 and [selection: P-521, no
other curves]] that meet the following: [FIPS PUB 186-4, “Digital Signature
Standard (DSS)”, Appendix B.4];
 [FFC schemes] using cryptographic key sizes of [2048-bit or greater] that
meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.1];
[selection:
 [RSA schemes] using cryptographic key sizes of [2048-bit or greater] that
meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.3];
 no other key generation methods].
Application Note: This SFR is selection-based in the App PP depending on the selection made in
FCS_CKM_EXT.1. Because key generation services (whether implemented by the
TOE or invoked from the platform) are required for IPsec, this SFR is mandatory
for any TOE that claims conformance to this EP.
This SFR is functionally identical to what is defined in the App PP except that FFC
and ECC key generation have been made mandatory in support of IPsec due to
the mandated support for DH groups 14, 19, and 20 in FCS_IPSEC_EXT.1.8. RSA
remains present as a selection since it may be used by facets of the Application
Software TOE that are not specifically related to VPN client functionality.
Assurance Activity
Refer to the assurance activity for FCS_CKM.1(1) in the App PP.
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The application shall [selection: invoke platform-provided functionality,
implement functionality] to perform cryptographic key establishment in
accordance with a specified cryptographic key establishment method:
30
 [RSA-based key establishment schemes] that meets the following: [NIST
Special Publication 800-56B, “Recommendation for Pair-Wise Key
Establishment Schemes Using Integer Factorization Cryptography”],
 [Elliptic curve-based key establishment schemes] that meets the following:
[NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”]; and
[selection:
 [Finite field-based key establishment schemes] that meets the following:
[NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”],
 Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3
].
Application Note: This SFR differs from its definition in the App PP by moving elliptic curve-based
key establishment schemes from selectable to mandatory (due to the mandated
support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8). It also provides the
ability to claim either NIST SP 800-56A or RFC 3526 for key establishment using
finite field cryptography. One of these two claims must be made in support of DH
group 14 in FCS_IPSEC_EXT.1.8. The use of RSA is not explicitly mandated by the
VPN client but it is mandatory in the App PP, which is why it remains mandatory
here.
Assurance Activity
For all key establishment schemes that conform to NIST SP 800-56A or 800-
56B, refer to the assurance activity for FCS_CKM.2 in the App PP.
If “Key establishment scheme using Diffie-Hellman group 14…” is selected,
the evaluator shall ensure that the TSS describes how the implementation
meets RFC 3526 Section 3. The evaluator shall also verify the correctness of
the TSF’s implementation of Diffie-Hellman group 14 by using a known good
implementation for each protocol selected in FTP_DIT_EXT.1 in the App PP
that uses Diffie-Hellman group 14. Note that because a TOE that conforms to
this EP must implement IPsec, the tested protocols shall include IPsec at
minimum.
FCS_CKM_EXT.1 Cryptographic Key Generation Services
FCS_CKM_EXT.1.1 The application shall [selection: invoke platform-provided functionality for
asymmetric key generation, implement asymmetric key generation].
Application Note: This SFR is selection-based in the App PP but is mandatory for a TOE that claims
conformance to this EP because asymmetric key generation services are required
for IPsec. The selection for “generate no asymmetric cryptographic keys” has
31
been removed for this EP because a VPN Client TOE will either perform its own
key generation or interface with the underlying platform to provide this service
(either of which causes FCS_CKM.1(1) to be claimed).
Assurance Activity
This SFR is evaluated in conjunction with FCS_CKM.1(1) in the App PP.
FCS_COP.1(1) Cryptographic Operation – Encryption/Decryption
FCS_COP.1.1(1) The application shall perform encryption/decryption in accordance with a
specified cryptographic algorithm
• AES-CBC (as defined in NIST SP 800-38A) mode; and
• [AES-GCM (as defined in NIST SP 800-38D)]
and cryptographic key sizes 128-bit key sizes and [256-bit key sizes].
Application Note: This SFR is identical to what is defined in the App PP except that support for GCM
mode and support for 256-bit key sizes are both mandatory in order to address
the requirements for FCS_IPSEC_EXT.1. Therefore, the relevant selections have
already been completed.
This SFR is selection-based in the App PP and is still selection-based for this EP
since the application’s underlying platform can still provide cryptographic
services on behalf of the TOE.
Assurance Activity
Refer to the assurance activity for FCS_COP.1(1) in the App PP.
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1 The application shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec and [selection: HTTPS, TLS, DTLS, no other protocols].
FIA_X509_EXT.2.2 When the application cannot establish a connection to determine the validity of
a certificate, the application shall [selection: allow the administrator to choose
whether to accept the certificate in these cases, accept the certificate, not
accept the certificate].
Application Note: This SFR is identical to what is defined in the App PP except that mandatory
support for IPsec is added. Additionally, because this SFR is selection-based in
the App PP but is mandatory for VPN client usage, the ‘no other protocols’
selection item has been added in the case that IPsec is the TOE’s only use of
certificates.
Assurance Activity
Refer to the assurance activity for FIA_X509_EXT.2 in the App PP.
32
FTP_DIT_EXT.1 Protection of Data in Transit
FTP_DIT_EXT.1.1 The application shall [encrypt all transmitted sensitive data with IPsec and
[selection: HTTPS, TLS, DTLS, no other protocols]] between itself and another
trusted IT product.
Application Note: This SFR is identical to what is defined in the App PP except that mandatory
support for IPsec is added and the ST author is forced to select the ‘encrypt all
transmitted sensitive data’ option. However, since it is possible that a
conformant TOE may not use any encryption protocols other than IPsec, “no
other protocols” is provided as a selectable option in the list of supported
protocols.
Assurance Activity
Refer to the assurance activity for FTP_DIT_EXT.1 in the App PP.
5.3.3 Additional SFRs
This section lists additional SFRs that must be added to the TOE boundary in order to implement the
functionality required by this EP when the App PP is claimed as the base PP.
FCS_CKM_EXT.2 Cryptographic Key Storage
FCS_CKM_EXT.2.1 The [selection: TOE, TOE platform] shall store persistent secrets and private keys
when not in use in platform-provided key storage.
Application Note: This requirement ensures that persistent secrets and private keys are stored
securely when not in use. This differs from FCS_STO_EXT.1 in the base PP, which
only applies to secure storage of administrative credentials. If some secrets/keys
are manipulated by the TOE and others are manipulated by the platform, then
both of the selections can be specified by the ST author.
Assurance Activity
TSS
Regardless of whether this requirement is met by the TOE or the TOE
platform, the evaluator will check the TSS to ensure that it lists each
persistent secret (credential, secret key) and private key needed to meet the
requirements in the ST. For each of these items, the evaluator will confirm
that the TSS lists for what purpose it is used, and how it is stored. The
evaluator then performs the following actions:
Persistent secrets and private keys manipulated by the platform
For each platform listed in the ST, the evaluator shall examine the ST of the
platform to ensure that the persistent secrets and private keys listed as being
stored by the platform in the VPN client ST are identified as being protected
in that platform's ST.
33
Persistent secrets and private keys manipulated by the TOE
The evaluator reviews the TSS for to determine that it makes a case that, for
each item listed as being manipulated by the TOE, it is not written
unencrypted to persistent memory, and that the item is stored by the
platform.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
FCS_CKM_EXT.4 Protection of Data in Transit
FCS_CKM_EXT.4.1 The [selection: TOE, TOE platform] shall zeroize all plaintext secret and private
cryptographic keys and CSPs when no longer required.
Application Note: Any security related information (such as keys, authentication data, and
passwords) must be zeroized when no longer in use to prevent the disclosure or
modification of security critical data.
The zeroization indicated above applies to each intermediate storage area for
plaintext key/CSP (i.e., any storage, such as memory buffers, that is included in
the path of such data) upon the transfer of the key/CSP to another location.
In practice, the TOE will not implement all of the functionality associated with
the requirement, since if it performs zeroization at all it will be by invoking
platform interfaces to perform the storage location clear/overwrite function. The
ST author should select "TOE" when, for at least one of the keys needed to meet
the requirements of this PP, the TOE manipulates (reads, writes) the data
identified in the requirement and thus needs to ensure that those data are
cleared. In these cases, it is sufficient for the TOE to invoke the correct
underlying functions of the host to perform the zeroization--it does not imply
that the TOE has to include a kernel-mode memory driver to ensure the data are
zeroized.
In the likely event that some of the data are manipulated by the TOE and other
data are manipulated entirely by the platform, the ST author shall select both
options and make it clear in the TSS the entity responsible (TOE, TOE platform)
for performing the zeroization.
Assurance Activity
TSS
The evaluator shall ensure that all plaintext secret and private cryptographic
keys and CSPs (whether manipulated by the TOE or exclusively by the
34
platform) are identified in the VPN Client ST's TSS, and that they are
accounted for by the assurance activities in this section.
Requirement met by the platform
The evaluator shall check to ensure the TSS describes each of the secret keys
(keys used for symmetric encryption), private keys, and CSPs used to generate
key that are not otherwise covered by the FCS_CKM_EXT.4 requirement
levied on the TOE.
For each platform listed in the ST, the evaluator shall examine the TSS of the
ST of the platform to ensure that each of the secret keys, private keys, and
CSPs used to generate key listed above are covered.
Requirement met by the TOE
The evaluator shall check to ensure the TSS describes when each of the
plaintext keys are cleared (e.g., system power off, disconnection of an IPsec
connection, when no longer needed by the VPN channel per the protocol);
and the type of clearing procedure that is performed (cryptographic erase,
overwrite with zeros, overwrite three or more times by a different alternating
pattern, overwrite with random pattern, or block erase). If different types of
memory are used to store the materials to be protected, the evaluator shall
check to ensure that the TSS describes the clearing procedure in terms of the
memory in which the data are stored (for example, "secret keys stored on
flash are cleared by overwriting once with zeros, while secret keys stored on
the internal persistent storage device are cleared by overwriting three times
with a random pattern that is changed before each write").
AGD
There are no AGD assurance activities for this requirement.
Test
For each key clearing situation described in the TSS, the evaluator shall repeat
the following test.
Test 1: The evaluator shall utilize appropriate combinations of specialized
operational environment and development tools (debuggers, simulators, etc.)
for the TOE and instrumented TOE builds to test that keys are cleared
correctly, including all intermediate copies of the key that may have been
created internally by the TOE during normal cryptographic processing with
that key.
Cryptographic TOE implementations in software shall be loaded and exercised
under a debugger to perform such tests. The evaluator shall perform the
following test for each key subject to clearing, including intermediate copies
of keys that are persisted encrypted by the TOE:
35
1. Load the instrumented TOE build in a debugger.
2. Record the value of the key in the TOE subject to clearing.
3. Cause the TOE to perform a normal cryptographic processing with
the key from #1.
4. Cause the TOE to clear the key.
5. Cause the TOE to stop the execution but not exit.
6. Cause the TOE to dump the entire memory footprint of the TOE
into a binary file.
7. Search the content of the binary file created in #4 for instances of
the known key value from #1.
The test succeeds if no copies of the key from #1 are found in step #7 above
and fails otherwise.
The evaluator shall perform this test on all keys, including those persisted in
encrypted form, to ensure intermediate copies are cleared.
5.4 TOE Security Functional Requirements
The following section describes the SFRs that must be satisfied by any TOE that claims conformance to
this EP. These SFRs must be claimed regardless of whether the base PP is the GPOS PP, the MDF PP, or
the App PP.
5.4.1 Cryptographic Support (FCS)
FCS_IPSEC_EXT.1 IPsec
In order to show that the TSF implements the RFCs in accordance with the requirements of this EP, the
evaluator shall perform the assurance activities listed below. In future versions of this EP, assurance
activities may be augmented, or new ones introduced that cover more aspects of RFC compliance than
are currently described in this publication.
The TOE is required to use the IPsec protocol to establish connections used to communicate with an
IPsec peer.
Packet Capture Device
Device
Traffic Generator
TOE Endpoint
36
The evaluators shall minimally create a test environment equivalent to the test environment illustrated
above. It is expected that the traffic generator is used to construct network packets and will provide the
evaluator with the ability manipulate fields in the ICMP, IPv4, IPv6, UDP, and TCP packet headers. The
evaluators must provide justification for any differences in the test environment.
In the following elements of the FCS_IPSEC_EXT.1 component, it is allowable for some or all of the
individual elements to be implemented by the platform on which the VPN client operates. If the TOE
extends the App PP, the ST author will indicate whether the TOE or TOE platform implements the VPN
functionality through the selections in the components of this SFR. If the TOE extends the GPOS PP or
MDF PP, all IPsec functionality will be implemented by the TOE. In this case, the ST author must identify
in the TSS which functions are implemented by the VPN client portion of the TOE versus the underlying
operating system or mobile device.
If the configuration is to be performed on the platform, the evaluators shall ensure that the "operational
guidance" for each platform in the VPN client ST contains the appropriate information (either through
reference in the platform's ST, or by information contained in the VPN client ST). All tests must be
performed by the evaluators using the VPN client and a representative sample of platforms listed in the
VPN client ST.
FCS_IPSEC_EXT.1.1 The [selection: TOE, TOE platform] shall implement the IPsec architecture as
specified in RFC 4301.
Application Note: RFC 4301 calls for an IPsec implementation to protect IP traffic through the use
of a Security Policy Database (SPD). The SPD is used to define how IP packets are
to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec
services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The
SPD can be implemented in various ways, including router access control lists,
firewall rulesets, a "traditional" SPD, etc. Regardless of the implementation
details, there is a notion of a "rule" that a packet is "matched" against and a
resulting action that takes place.
While there must be a means to order the rules, a general approach to ordering
is not mandated, as long as the TOE can distinguish the IP packets and apply the
rules accordingly. There may be multiple SPDs (one for each network interface),
but this is not required.
A VPN gateway fully implements the IPsec capability and provides an
administrative interface to establish and populate an SPD. A VPN client, on the
other hand, may fully implement the IPsec functionality, or it may rely on the
underlying platform to implement aspects, including the SPD. A VPN client is not
required to provide an administrative interface to create or maintain an SPD. As
an alternative, a client may provide an application, such as a VPN gateway, a
means to establish and populate the SPD.
Assurance Activity
37
TSS
The evaluator shall examine the TSS and determine that it describes how the
IPsec capabilities are implemented and how a packet is processed, e.g., what
takes place at the platform and what takes place within the client. The TSS
will detail the relationship between the client and the underlying platform,
including which aspects are implemented by the client, and those that are
provided by the underlying platform. The TSS describes how the client
interacts with the platforms network stack (e.g., does the client insert itself
within the stack via kernel mods, does the client simply invoke APIs to gain
access to network services).
If the SPD is implemented by the client, then the TSS describes how the SPD is
implemented and the rules for processing both inbound and outbound
packets in terms of the IPsec policy. The TSS describes the rules that are
available and the resulting actions available after matching a rule. The TSS
describes how the available rules and actions form the SPD using terms
defined in RFC 4301 such as BYPASS (e.g., no encryption), DISCARD (e.g., drop
the packet), and PROTECT (e.g., encrypt the packet) actions defined in RFC
4301.
As noted in section 4.4.1 of RFC 4301, the processing of entries in the SPD is
non-trivial and the evaluator shall determine that the description in the TSS is
sufficient to determine which rules will be applied given the rule structure
implemented by the TOE. For example, if the TOE allows specification of
ranges, conditional rules, etc., the evaluator shall determine that the
description of rule processing (for both inbound and outbound packets) is
sufficient to determine the action that will be applied, especially in the case
where two different rules may apply. This description shall cover both the
initial packets (that is, no SA is established on the interface or for that
particular packet) as well as packets that are part of an established SA. If the
SPD is implemented by the underlying platform, then the TSS describes how
the client interacts with the platform to establish and populate the SPD,
including the identification of the platform's interfaces that are used by the
client.
AGD
The evaluator shall examine the operational guidance to verify it describes
how the SPD is created and configured. If there is an administrative interface
to the client, then the guidance describes how the administrator specifies
rules for processing a packet. The description includes all three cases - a rule
that ensures packets are encrypted/decrypted, dropped, and allowing a
packet to flow in plaintext. The evaluator shall determine that the description
in the operational guidance is consistent with the description in the TSS, and
that the level of detail in the operational guidance is sufficient to allow the
38
administrator to set up the SPD in an unambiguous fashion. This includes a
discussion of how ordering of rules impacts the processing of an IP packet.
If the client is configured by an external application, such as the VPN gateway,
then the operational guidance should indicate this and provide a description
of how the client is configured by the external application. The description
should contain information as to how the SPD is established and set up in an
unambiguous fashion. The description should also include what is
configurable via the external application, how ordering of entries may be
expressed, as well as the impacts that ordering of entries may have on the
packet processing.
In either case, the evaluator ensures the description provided In the TSS is
consistent with the capabilities and description provided in the operational
guidance.
Test
Depending on the implementation, the evaluator may be required to use a
VPN gateway or some form of application to configure the client and
platform. For Test 2, the evaluator is required to choose an application that
allows for the configuration of the full set of capabilities of the VPN client (in
conjunction with the platform). For example, if the client provides a robust
interface that allows for specification of wildcards, subnets, etc., it is
unacceptable for the evaluator to choose a VPN Gateway that only allows for
specifying a single fully qualified IP addresses in the rule.
The evaluator shall perform the following tests:
Test 1: The evaluator shall configure an SPD on the client that is capable of
the following: dropping a packet, encrypting a packet, and allowing a packet
to flow in plaintext. The selectors used in the construction of the rule shall be
different such that the evaluator can generate a packet and send packets to
the client with the appropriate fields (fields that are used by the rule - e.g.,
the IP addresses, TCP/UDP ports) in the packet header. The evaluator
performs both positive and negative test cases for each type of rule. The
evaluator observes via the audit trail, and packet captures that the TOE
exhibited the expected behavior: appropriate packets were dropped, allowed
through without modification, was encrypted by the IPsec implementation.
Test 2: The evaluator shall devise several tests that cover a variety of
scenarios for packet processing. These scenarios must exercise the range of
possibilities for SPD entries and processing modes as outlined in the TSS and
operational guidance. Potential areas to cover include rules with overlapping
ranges and conflicting entries, inbound and outbound packets, and packets
that establish SAs as well as packets that belong to established SAs. The
evaluator shall verify, via the audit trail and packet captures, for each
39
scenario that the expected behavior is exhibited, and is consistent with both
the TSS and the operational guidance.
FCS_IPSEC_EXT.1.2 The [selection: TOE, TOE platform] shall implement [selection: tunnel mode,
transport mode].
Application Note: If the TOE is used to connect to a VPN gateway for the purposes of establishing a
secure connection to a private network, the ST author is expected to select
tunnel mode. If the TOE uses IPsec to establish an end-to-end connection to
another IPsec VPN Client, the ST author is expected to select transport mode. If
the TOE uses IPsec to establish a connection to a specific endpoint device for the
purpose of secure remote administration, the ST author is expected to select
transport mode.
Assurance Activity
TSS
The evaluator shall check the TSS to ensure it states that the VPN can be
established to operate in tunnel mode and/or transport mode (as selected).
The evaluator shall confirm that the operational guidance contains
instructions on how to configure the connection in each mode selected.
AGD
If both transport mode and tunnel mode are implemented, the evaluator
shall review the operational guidance to determine how the use of a given
mode is specified.
Test
The evaluator shall perform the following test(s) based on the selections
chosen:
Test 1 [conditional]: If tunnel mode is selected, the evaluator uses the
operational guidance to configure the TOE/platform to operate in tunnel
mode and also configures a VPN gateway to operate in tunnel mode. The
evaluator configures the TOE/platform and the VPN gateway to use any of
the allowable cryptographic algorithms, authentication methods, etc. to
ensure an allowable SA can be negotiated. The evaluator shall then initiate a
connection from the client to connect to the VPN GW peer. The evaluator
observes (for example, in the audit trail and the captured packets) that a
successful connection was established using the tunnel mode.
Test 2 [conditional]: If transport mode is selected, the evaluator uses the
operational guidance to configure the TOE/platform to operate in transport
mode and also configures an IPsec peer to accept IPsec connections using
transport mode. The evaluator configures the TOE/platform and the endpoint
device to use any of the allowed cryptographic algorithms, authentication
40
methods, etc. to ensure an allowable SA can be negotiated. The evaluator
then initiates a connection from the TOE/platform to connect to the remote
endpoint. The evaluator observes (for example, in the audit trail and the
captured packets) that a successful connection was established using the
transport mode.
Test 3 [conditional]: If both tunnel mode and transport mode are selected,
the evaluator shall perform both Test 1 and Test 2 above, demonstrating that
the TOE can be configured to support both modes.
Test 4 [conditional]: If both tunnel mode and transport mode are selected,
the evaluator shall modify the testing for FCS_IPSEC_EXT.1 to include the
supported mode for SPD PROTECT entries to show that they only apply to
traffic that is transmitted or received using the indicated mode.
FCS_IPSEC_EXT.1.3 The [selection: TOE, TOE platform] shall have a nominal, final entry in the SPD
that matches anything that is otherwise unmatched, and discards it.
Assurance Activity
TSS
The evaluator shall examine the TSS to verify that the TSS provides a
description of how a packet is processed against the SPD and that if no
“rules” are found to match, that a final rule exists, either implicitly or
explicitly, that causes the network packet to be discarded.
AGD
The evaluator checks that the operational guidance provides instructions on
how to construct or acquire the SPD and uses the guidance to configure the
TOE/platform for the following tests.
Test
The evaluator shall perform the following test:
Test 1: The evaluator shall configure the SPD such that it has entries that
contain operations that DISCARD, PROTECT, and (if applicable) BYPASS
network packets. The evaluator may use the SPD that was created for
verification of FCS_IPSEC_EXT.1.1. The evaluator shall construct a network
packet that matches a BYPASS entry and send that packet. The evaluator
should observe that the network packet is passed to the proper destination
interface with no modification. The evaluator shall then modify a field in the
packet header; such that it no longer matches the evaluator-created entries
(there may be a “TOE/platform created” final entry that discards packets that
do not match any previous entries). The evaluator sends the packet, and
observes that the packet was not permitted to flow to any of the TOE’s
interfaces.
41
FCS_IPSEC_EXT.1.4 The [selection: TOE, TOE platform] shall implement the IPsec protocol ESP as
defined by RFC 4303 using the cryptographic algorithms AES-GCM-128, AES-
GCM-256 as specified in RFC 4106, [selection: AES-CBC-128, AES-CBC-256 (both
specified by RFC 3602) together with a Secure Hash Algorithm (SHA)-based
HMAC, no other algorithms].
Application Note: If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself.
Assurance Activity
TSS
The evaluator shall examine the TSS to verify that the algorithms AES-GCM-
128 and AES-GCM-256 are implemented. If the ST author has selected either
AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies
the TSS describes these as well. In addition, the evaluator ensures that the
SHA-based HMAC algorithm conforms to the algorithms specified in
FCS_COP.1(4) Cryptographic Operations (for keyed-hash message
authentication).
AGD
The evaluator checks the operational guidance to ensure it provides
instructions on how the TOE is configured to use the algorithms selected in
this component and whether this is performed through direct configuration,
defined during initial installation, or defined by acquiring configuration
settings from an environmental component.
Test
Test 1: The evaluator shall configure the TOE/platform as indicated in the
operational guidance configuring the TOE/platform to using each of the AES-
GCM-128, and AES-GCM-256 algorithms, and attempt to establish a
connection using ESP. If the ST Author has selected either AES-CBC-128 or
AES-CBC-256, the TOE/platform is configured to use those algorithms and the
evaluator attempts to establish a connection using ESP for those algorithms
selected.
FCS_IPSEC_EXT.1.5 The [selection: TOE, TOE platform] shall implement the protocol: [selection:
 IKEv1, using Main Mode for Phase I exchanges, as defined in RFCs 2407,
2408, 2409, RFC 4109, [selection: no other RFCs for extended sequence
numbers, RFC 4304 for extended sequence numbers], [selection: no other
RFCs for hash functions, RFC 4868 for hash functions], and [selection:
support for XAUTH, no support for XAUTH];
42
 IKEv2 as defined in RFCs 7296 (with mandatory support for NAT traversal as
specified in section 2.23), 4307, and [selection: no other RFCs for hash
functions, RFC 4868 for hash functions]].
Assurance Activity
TSS
The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are
implemented. If IKEv1 is implemented, the evaluator shall verify that the TSS
indicates whether or not XAUTH is supported, and that aggressive mode is
not used for IKEv1 Phase 1 exchanges (i.e. only main mode is used). It may be
that these are configurable options.
AGD
The evaluator shall check the operational guidance to ensure it instructs the
administrator how to configure the TOE/platform to use IKEv1 and/or IKEv2
(as selected), and uses the guidance to configure the TOE/platform to
perform NAT traversal for the test below. If XAUTH is implemented, the
evaluator shall verify that the operational guidance provides instructions on
how it is enabled or disabled.
If the TOE supports IKEv1, the evaluator shall verify that the operational
guidance either asserts that only main mode is used for Phase 1 exchanges, or
provides instructions for disabling aggressive mode.
Test
Test 1: The evaluator shall configure the TOE/platform so that it will perform
NAT traversal processing as described in the TSS and RFC 7296, section 2.23.
The evaluator shall initiate an IPsec connection and determine that the NAT is
successfully traversed. If XAUTH is supported, the evaluator shall verify that
this test can be repeated with XAUTH both enabled and disabled in the
manner specified by the operational guidance.
Test 2 [conditional]: If the TOE supports IKEv1, the evaluator shall perform
any applicable operational guidance steps to disable the use of aggressive
mode and then attempt to establish a connection using an IKEv1 Phase 1
connection in aggressive mode. This attempt should fail. The evaluator shall
show that the TOE/platform will reject a VPN gateway from initiating an IKEv1
Phase 1 connection in aggressive mode. The evaluator should then show that
main mode exchanges are supported.
FCS_IPSEC_EXT.1.6 The [selection: TOE, TOE platform] shall ensure the encrypted payload in the
[selection: IKEv1, IKEv2] protocol uses the cryptographic algorithms AES-CBC-
128, AES-CBC-256 as specified in RFC 6379 and [selection: AES-GCM-128, AES-
GCM-256 as specified in RFC 5282, no other algorithm].
43
Application Note: If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself.
Assurance Activity
TSS
The evaluator shall ensure the TSS identifies the algorithms used for
encrypting the IKEv1 and/or IKEv2 payload, and that the algorithms AES-CBC-
128, AES-CBC-256 are specified, and if others are chosen in the selection of
the requirement, those are included in the TSS discussion.
AGD
The evaluator checks the operational guidance to ensure it provides
instructions on how the TOE is configured to use the algorithms selected in
this component and whether this is performed through direct configuration,
defined during initial installation, or defined by acquiring configuration
settings from an environmental component.
Test
The evaluator shall use the operational guidance to configure the
TOE/platform (or to configure the Operational Environment to have the TOE
receive configuration) to perform the following test for each ciphersuite
selected:
Test 1: The evaluator shall configure the TOE/platform to use the ciphersuite
under test to encrypt the IKEv1 and/or IKEv2 payload and establish a
connection with a peer device, which is configured to only accept the payload
encrypted using the indicated ciphersuite. The evaluator will confirm the
algorithm was that used in the negotiation. The evaluator will confirm that
the connection is successful by confirming that data can be passed through
the connection once it is established. For example, the evaluator may connect
to a webpage on the remote network and verify that it can be reached.
FCS_IPSEC_EXT.1.7 The [selection: TOE, TOE platform] shall ensure that [selection: IKEv2 SA lifetimes
can be configured by [selection: an Administrator, VPN Gateway] based on
[selection: number of packets/number of bytes, length of time], IKEv1 SA
lifetimes can be configured by an [selection: an Administrator, VPN Gateway]
based on [selection: number of packets/number of bytes, length of time], IKEv1
SA lifetimes are fixed based on [selection: number of packets/number of bytes,
length of time]]. If length of time is used, it must include at least one option that
is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
Application Note: The ST author is afforded a selection based on the version of IKE in their
implementation. There is a further selection within this selection that allows the
ST Author to specify which entity is responsible for “configuring” the life of the
44
SA. An implementation that allows an administrator to configure the client or a
VPN gateway that pushes the SA lifetime down to the client are both acceptable.
As far as SA lifetimes are concerned, the TOE can limit the lifetime based on the
number of bytes transmitted, or the number of packets transmitted. Either
packet-based or volume-based SA lifetimes are acceptable; the ST author makes
the appropriate selection to indicate which type of lifetime limits are supported.
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or
both, depending on the selection in FCS_IPSEC_EXT.1.5. The IKEv1 requirement
can be accomplished either by providing Authorized Administrator-configurable
lifetimes (with appropriate instructions in documents mandated by AGD_OPE),
or by “hard coding” the limits in the implementation. For IKEv2, there are no
hardcoded limits, but in this case it is required than an administrator be able to
configure the values. In general, instructions for setting the parameters of the
implementation, including lifetime of the SAs, should be included in the
operational guidance generated for AGD_OPE. It is appropriate to refine the
requirement in terms of number of MB/KB instead of number of packets, as long
as the TOE is capable of setting a limit on the amount of traffic that is protected
by the same key (the total volume of all IPsec traffic protected by that key).
Assurance Activity
TSS
There are no TSS assurance activities for this requirement.
AGD
The evaluator shall check the operational guidance to ensure it provides
instructions on how the TOE configures the values for SA lifetimes. In
addition, the evaluator shall check that the guidance has the option for either
the Administrator or VPN Gateway to configure Phase 1 SAs if time-based
limits are supported. Currently there are no values mandated for the number
of packets or number of bytes, the evaluator shall simply check the
operational guidance to ensure that this can be configured if selected in the
requirement.
Test
When testing this functionality, the evaluator needs to ensure that both sides
are configured appropriately. From the RFC “A difference between IKEv1 and
IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the
SA is responsible for enforcing its own lifetime policy on the SA and rekeying
the SA when necessary. If the two ends have different lifetime policies, the
end with the shorter lifetime will end up always being the one to request the
rekeying. If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in redundant
45
SAs). To reduce the probability of this happening, the timing of rekeying
requests SHOULD be jittered.”
Each of the following tests shall be performed for each version of IKE selected
in the FCS_IPSEC_EXT.1.5 protocol selection:
Test 1 [conditional]: The evaluator shall configure a maximum lifetime in
terms of the # of packets (or bytes) allowed following the operational
guidance. The evaluator shall establish an SA and determine that once the
allowed # of packets (or bytes) through this SA is exceeded, the connection is
closed.
Test 2 [conditional]: The evaluator shall construct a test where a Phase 1 SA is
established and attempted to be maintained for more than 24 hours before it
is renegotiated. The evaluator shall observe that this SA is closed or
renegotiated in 24 hours or less. If such an action requires that the TOE be
configured in a specific way, the evaluator shall implement tests
demonstrating that the configuration capability of the TOE works as
documented in the operational guidance.
Test 3 [conditional]: The evaluator shall perform a test similar to Test 2 for
Phase 2 SAs, except that the lifetime will be 8 hours or less instead of 24
hours or less.
Test 4 [conditional]: If a fixed limit for IKEv1 SAs is supported, the evaluator
shall establish an SA and observe that the connection is closed after the fixed
traffic and/or time value is reached.
FCS_IPSEC_EXT.1.8 The [selection: TOE, TOE platform] shall ensure that all IKE protocols implement
DH groups 14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit Random
ECP), and [selection: 5 (1536-bit MODP), 24 (2048-bit MODP with 256-bit POS),
15 (3072-bit MODP), no other DH groups].
Application Note: The selection is used to specify additional DH groups supported. This applies to
IKEv1 and IKEv2 exchanges. It should be noted that if any additional DH groups
are specified, they must comply with the requirements (in terms of the
ephemeral keys that are established) listed in FCS_CKM.1.
Since the implementation may allow different Diffie-Hellman groups to be
negotiated for use in forming the SAs, the assignments in FCS_IPSEC_EXT.1.9
and FCS_IPSEC_EXT.1.10 may contain multiple values. For each DH group
supported, the ST author consults Table 2 in 800-57 to determine the “bits of
security” associated with the DH group. Each unique value is then used to fill in
the assignment (for 1.9 they are doubled; for 1.10 they are inserted directly into
the assignment). For example, suppose the implementation supports DH group
14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2,
the bits of security value for group 14 is 112, and for group 20 it is 192. For
FCS_IPSEC_EXT.1.9, then, the assignment would read “[224, 384]” and for
46
FCS_IPSEC_EXT.1.10 it would read “[112, 192]” (although in this case the
requirement should probably be refined so that it makes sense mathematically).
Assurance Activity
TSS
The evaluator shall check to ensure that the DH groups specified in the
requirement are listed as being supported in the TSS. If there is more than
one DH group supported, the evaluator checks to ensure the TSS describes
how a particular DH group is specified/negotiated with a peer.
AGD
There are no AGD assurance activities for this requirement.
Test
The evaluator shall perform the following test:
Test 1: For each supported DH group, the evaluator shall test to ensure that
all supported IKE protocols can be successfully completed using that
particular DH group.
FCS_IPSEC_EXT.1.9 The [selection: TOE, TOE platform] shall generate the secret value x used in the
IKE Diffie-Hellman key exchange (“x” in gx
mod p) using the random bit
generator specified in FCS_RBG_EXT.1, and having a length of at least
[assignment: (one or more) number(s) of bits that is at least twice the “bits of
security” value associated with the negotiated Diffie-Hellman group as listed in
Table 2 of NIST SP 800-57, Recommendation for Key Management – Part 1:
General] bits.
Assurance Activity
TSS
The evaluator shall check to ensure that, for each DH group supported, the
TSS describes the process for generating "x" (as defined in
FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS
indicates that the random number generated that meets the requirements in
this EP is used, and that the length of "x" and the nonces meet the
stipulations in the requirement.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
47
FCS_IPSEC_EXT.1.10 The [selection: TOE, TOE platform] shall generate nonces used in IKE exchanges
in a manner such that the probability that a specific nonce value will be
repeated during the life a specific IPsec SA is less than 1 in 2^[assignment: (one
or more) “bits of security” value(s) associated with the negotiated Diffie-Hellman
group as listed in Table 2 of NIST SP 800-57, Recommendation for Key
Management – Part 1: General] .
Assurance Activity
Assurance activities for this element are tested through assurance activities
for FCS_IPSEC_EXT.1.9.
FCS_IPSEC_EXT.1.11 The [selection: TOE, TOE platform] shall ensure that all IKE protocols perform
peer authentication using a [selection: RSA, ECDSA] that use X.509v3 certificates
that conform to RFC 4945 and [selection: Pre-shared Keys, no other method].
Application Note: At least one public-key-based Peer Authentication method is required in order to
conform to this EP; 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
(for example, 2409 specifies three authentication methods using public keys;
each one supported will be described in the TSS).
Assurance Activity
TSS
The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used
to perform peer authentication.
If pre-shared keys are chosen in the selection, the evaluator shall check to
ensure that the TSS describes how pre-shared keys are established and used
in authentication of IPsec connections. The description in the TSS shall also
indicate how pre-shared key establishment is accomplished for
TOEs/platforms that can generate a pre-shared key as well as TOEs/platforms
that simply use a pre-shared key.
The evaluator shall ensure that the TSS describes how the TOE compares the
peer’s presented identifier to the reference identifier. This description shall
include whether the certificate presented identifier is compared to the ID
payload presented identifier, which field(s) of the certificate are used as the
presented identifier (DN, Common Name, or SAN), and, if multiple fields are
supported, the logical order comparison. If the ST author assigned an
additional identifier type, the TSS description shall also include a description
of that type and the method by which that type is compared to the peer’s
presented certificate.
48
AGD
The evaluator shall check that the operational guidance describes how pre-
shared keys are to be generated and established.
The evaluator ensures the operational guidance describes how to set up the
TOE/platform to use the cryptographic algorithms RSA and/or ECDSA.
In order to construct the environment and configure the TOE/platform for the
following tests, the evaluator will ensure that the operational guidance also
describes how to configure the TOE/platform to connect to a trusted CA, and
ensure a valid certificate for that CA is loaded into the TOE/platform as a
trusted CA.
The evaluator shall also ensure that the operational guidance includes the
configuration of the reference identifier(s) for the peer.
Test
For efficiency’s sake, the testing that is performed here has been combined
with the testing for FIA_X509_EXT.2.1 (for IPsec connections),
FCS_IPSEC_EXT.1.12, FCS_IPSEC_EXT.1.13 and FIA_X509_EXT.2.3. The
following tests shall be repeated for each peer authentication protocol
selected in the FCS_IPSEC_EXT.1.11 selection above:
Test 1: The evaluator shall have the TOE/platform generate a public-private
key pair, and submit a CSR (Certificate Signing Request) to a CA (trusted by
both the TOE/platform and the peer VPN used to establish a connection) for
its signature. The values for the DN (Common Name, Organization,
Organizational Unit, and Country) will also be passed in the request.
Alternatively, the evaluator may import to the TOE/platform a previously
generated private key and corresponding certificate.
Test 2: The evaluator shall use a certificate signed using the RSA or ECDSA
algorithm to authenticate the remote peer during the IKE exchange. This test
ensures the remote peer has the certificate for the trusted CA that signed the
TOE’s certificate and it will do a bit-wise comparison on the DN. This bit-wise
comparison of the DN ensures that not only does the peer have a certificate
signed by the trusted CA, but the certificate is from the DN that is expected.
The evaluator will configure the TOE/platform to associate a certificate (e.g.,
a certificate map in some implementations) with a VPN connection. This is
what the DN is checked against.
Test 3: The evaluator shall test that the TOE/platform can properly handle
revoked certificates – conditional on whether CRL or OCSP is selected; if both
are selected, and then a test is performed for each method. For this draft of
the EP, the evaluator has to only test one up in the trust chain (future drafts
may require to ensure the validation is done up the entire chain). The
49
evaluator shall ensure that a valid certificate is used, and that the SA is
established. The evaluator then attempts the test with a certificate that will
be revoked (for each method chosen in the selection) to ensure when the
certificate is no longer valid that the TOE/platform will not establish an SA.
Test 4 [conditional]: The evaluator shall test that given a signed certificate
from a trusted CA, that when the DN does not match – any of the four fields
can be modified such that they do not match the expected value, that an SA
does not get established.
Test 5 [conditional]: The evaluator shall generate a pre-shared key and use it,
as indicated in the operational guidance, to establish an IPsec connection
with the VPN GW peer. If the generation of the pre-shared key is supported,
the evaluator shall ensure that establishment of the key is carried out for an
instance of the TOE/platform generating the key as well as an instance of the
TOE/platform merely taking in and using the key.
For each supported identifier type (excluding DNs), the evaluator shall repeat
the following tests:
Test 6: For each field of the certificate supported for comparison, the
evaluator shall configure the peer’s reference identifier on the TOE (per the
administrative guidance) to match the field in the peer’s presented certificate
and shall verify that the IKE authentication succeeds.
Test 7: For each field of the certificate support for comparison, the evaluator
shall configure the peer’s reference identifier on the TOE (per the
administrative guidance) to not match the field in the peer’s presented
certificate and shall verify that the IKE authentication fails.
The following tests are conditional:
Test 8 [conditional]: If, according to the TSS, the TOE supports both Common
Name and SAN certificate fields and uses the preferred logic outlined in the
Application Note, the tests above with the Common Name field shall be
performed using peer certificates with no SAN extension. Additionally, the
evaluator shall configure the peer’s reference identifier on the TOE to not
match the SAN in the peer’s presented certificate but to match the Common
Name in the peer’s presented certificate, and verify that the IKE
authentication fails.
Test 9 [conditional]: If the TOE supports DN identifier types, the evaluator
shall configure the peer’s reference identifier on the TOE (per the
administrative guidance) to match the subject DN in the peer’s presented
certificate and shall verify that the IKE authentication succeeds. To
demonstrate a bit-wise comparison of the DN, the evaluator shall change a
50
single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and
verify that the IKE authentication fails.
Test 10 [conditional]: If the TOE supports both IPv4 and IPv6 and supports IP
address identifier types, the evaluator must repeat test 1 and 2 with both
IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall
verify that the TOE verifies that the IP header matches the identifiers by
setting the presented identifiers and the reference identifier with the same IP
address that differs from the actual IP address of the peer in the IP headers
and verifying that the IKE authentication fails.
Test 11 [conditional]: If, according to the TSS, the TOE performs comparisons
between the peer’s ID payload and the peer’s certificate, the evaluator shall
repeat the following test for each combination of supported identifier types
and supported certificate fields (as above). The evaluator shall configure the
peer to present a different ID payload than the field in the peer’s presented
certificate and verify that the TOE fails to authenticate the IKE peer.
FCS_IPSEC_EXT.1.12 The TSF shall not establish an SA if the [selection: IP address, Fully Qualified
Domain Name (FQDN), user FQDN, Distinguished Name (DN)] and [selection: no
other reference identifier type, [assignment: other supported reference identifier
types]] contained in a certificate does not match the expected value(s) for the
entity attempting to establish a connection.
Application Note: The TOE must support at least one of the following identifier types: IP address,
Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN).
In the future, the TOE will be required to support all of these identifier types. The
TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP
versions supported by the TOE in general. The ST author may assign additional
supported identifier types in the second selection.
Assurance Activity
Assurance activities for this element are tested through assurance activities
for FCS_IPSEC_EXT.1.11.
FCS_IPSEC_EXT.1.13 The TSF shall not establish an SA if the presented identifier does not match the
configured reference identifier of the peer.
Application Note: At this time, only the comparison between the presented identifier in the peer’s
certificate and the peer’s reference identifier is mandated by the testing below.
However, in the future, this requirement will address two aspects of the peer
certificate validation: 1) comparison of the peer’s ID payload to the peer’s
certificate which are both presented identifiers, as required by RFC 4945 and 2)
verification that the peer identified by the ID payload and the certificate is the
peer expected by the TOE (per the reference identifier). At that time, the TOE will
be required to demonstrate both aspects (i.e. that the TOE enforces that the
51
peer’s ID payload matches the peer’s certificate which both match configured
peer reference identifiers).
Excluding the DN identifier type (which is necessarily the Subject DN in the peer
certificate), the TOE may support the identifier in either the Common Name or
Subject Alternative Name (SAN) or both. If both are supported, the preferred
logic is to compare the reference identifier to a presented SAN, and only if the
peer’s certificate does not contain a SAN, to fall back to a comparison against
the Common Name. In the future, the TOE will be required to compare the
reference identifier to the presented identifier in the SAN only, ignoring the
Common Name.
The configuration of the peer reference identifier is addressed by FMT_SMF.1.1.
Assurance Activity
Assurance activities for this element are tested through assurance activities
for FCS_IPSEC_EXT.1.12.
FCS_IPSEC_EXT.1.14 The [selection: TOE, TOE platform, VPN Gateway] shall be able to ensure by
default that the strength of the symmetric algorithm (in terms of the number of
bits in the key) negotiated to protect the [selection: IKEv1 Phase 1, IKEv2 IKE_SA]
connection is greater than or equal to the strength of the symmetric algorithm
(in terms of the number of bits in the key) negotiated to protect the [selection:
IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
Application Note: If "VPN Gateway" is selected, then "Test 2" below may be omitted from the
evaluation. Test 1, 3, and 4 shall be performed regardless of the selection.
If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself.
The ST author chooses either or both of the IKE selections based on what is
implemented by the TOE. Obviously, the IKE version(s) chosen should be
consistent not only in this element, but with other choices for other elements in
this component. While it is acceptable for this capability to be configurable, the
default configuration in the evaluated configuration (either "out of the box" or
by configuration guidance in the AGD documentation) must enable this
functionality.
Assurance Activity
TSS
The evaluator shall check that the TSS describes the potential strengths (in
terms of the number of bits in the symmetric key) of the algorithms that are
allowed for the IKE and ESP exchanges. The TSS shall also describe the checks
that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites
to ensure that the strength (in terms of the number of bits of key in the
52
symmetric algorithm) of the negotiated algorithm is less than or equal to that
of the IKE SA this is protecting the negotiation.
AGD
There are no AGD assurance activities for this requirement.
Test
The evaluator follows the guidance to configure the TOE/platform to perform
the following tests.
Test 1: This test shall be performed for each version of IKE supported. The
evaluator shall successfully negotiate an IPsec connection using each of the
supported algorithms and hash functions identified in the requirements.
Test 2 [conditional]: This test shall be performed for each version of IKE
supported. The evaluator shall attempt to establish an SA for ESP that selects
an encryption algorithm with more strength than that being used for the IKE
SA (i.e., symmetric algorithm with a key size larger than that being used for
the IKE SA). Such attempts should fail.
Test 3: This test shall be performed for each version of IKE supported. The
evaluator shall attempt to establish an IKE SA using an algorithm that is not
one of the supported algorithms and hash functions identified in the
requirements. Such an attempt should fail.
Test 4: This test shall be performed for each version of IKE supported. The
evaluator shall attempt to establish an SA for ESP (assumes the proper
parameters where used to establish the IKE SA) that selects an encryption
algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should
fail.
5.4.2 User Data Protection (FDP)
FDP_RIP.2 Full Residual Information Protection
FDP_RIP.2.1 The [selection: TOE, TOE platform] shall enforce that any previous information
content of a resource is made unavailable upon the [selection: allocation of the
resource to, deallocation of the resource from] all objects.
Application Note: This requirement ensures, for example, that protocol data units (PDUs) are not
padded with residual information such as cryptographic key material. The ST
author uses the selection to specify when previous information is made
unavailable.
Assurance Activity
TSS
53
Requirement met by the platform
The evaluator shall examine the TSS to verify that it describes (for each
supported platform) the extent to which the client processes network packets
and addresses the FDP_RIP.2 requirement.
Requirement met by the TOE
“Resources” in the context of this requirement are network packets being
sent through (as opposed to “to”, as is the case when a security administrator
connects to the TOE) the TOE. The concern is that once a network packet is
sent, the buffer or memory area used by the packet still contains data from
that packet, and that if that buffer is re-used, those data might remain and
make their way into a new packet. The evaluator shall check to ensure that
the TSS describes packet processing to the extent that they can determine
that no data will be reused when processing network packets. The evaluator
shall ensure that this description at a minimum describes how the previous
data are zeroized/overwritten, and at what point in the buffer processing this
occurs.
AGD
There are no AGD assurance activities for this requirement.
Test
There are no test assurance activities for this requirement.
5.4.3 Security Management (FMT)
The TOE is not required to maintain a separate management role. It is, however, required to provide
functionality to configure certain aspects of TOE operation that should not be available to the general
user population. It is possible for the TOE, TOE Platform, or VPN Gateway to provide this functionality.
The client itself has to be configurable - whether it is from the EUD or from a VPN gateway.
FMT_SMF.1(1)/VPN Specification of Management Functions (VPN)
FMT_SMF.1.1(1)/VPN The TSF shall be capable of performing the following management functions:
[[selection:
• Specify VPN gateways to use for connections,
• Specify IPsec VPN Clients to use for connections,
• Specify IPsec-capable network devices to use for connections],
• Specify client credentials to be used for connections,
• Configure the reference identifier of the peer
• [assignment: any additional management functions]].
Application Note: Several of the management functions defined above correspond to the use cases
of the TOE as follows:
54
• “Specify VPN gateways to use for connections” – Use Case 1
• “Specify IPsec VPN Clients to use for connections” – Use Case 2 (specifically
refers to different end points to use for client-to-client connections)
• “Specify IPsec-capable network devices to use for connections” – Use Case 3
Selections appropriate for the use case(s) supported by the TOE should be
claimed. "Client credentials" will include the client certificate used for IPsec
authentication, and may also include a username/password.
For TOEs that support only IP address and FQDN identifier types, configuration
of the reference identifier may be the same as configuration of the peer’s name
for the purposes of connection.
If there are additional management functions performed by the TOE (including
those specified in FCS_IPSEC_EXT.1), they should be added in the assignment.
Assurance Activity
TSS
The evaluator shall check to ensure the TSS describes the client credentials
and how they are used by the TOE.
AGD
The evaluator shall check to make sure that every management function
mandated in the ST for this requirement are described in the operational
guidance and that the description contains the information required to
perform the management duties associated with each management function.
Test
The evaluator shall test the TOE’s ability to provide the management
functions by configuring the TOE according to the operational guidance and
testing each management activity listed in the Security Target.
The evaluator shall ensure that all management functions claimed in the ST
can be performed by completing activities described in the AGD. Note that
this may be performed in the course of completing other testing.
5.4.4 Protection of the TSF (FPT)
FPT_TST_EXT.1 TSF Self Test
FPT_TST_EXT.1.1 The [selection: TOE, TOE platform] shall run a suite of self tests during initial
start-up (on power on) to demonstrate the correct operation of the TSF.
FPT_TST_EXT.1.2 The [selection: TOE, TOE platform] shall provide the capability to verify the
integrity of stored TSF executable code when it is loaded for execution through
55
the use of the [assignment: cryptographic services provided either by the portion
of the TOE described by the base PP or by the operational environment].
Application Note: While the TOE is typically a software package running in the IT Environment, it is
still capable of performing the self-test activities required above. It should be
understood, however, that there is a significant dependency on the host
environment in assessing the assurance provided by the tests mentioned above
(meaning that if the host environment is compromised, the self-tests will not be
meaningful).
Cryptographic verification of the integrity is required, but the method by which
this can be accomplished is specified in the ST in the assignment. The ST author
will fill in the assignment with references to the cryptographic functions used to
perform the integrity checks; this will include hashing and may potentially
include digital signatures signed using X.509 certificates. If the TSF provides the
cryptographic services used to verify updates, all relevant FCS_COP requirements
will be identified in the assignment by the ST author.
Assurance Activity
Except for where it is explicitly noted, the evaluator is expected to check the
following information regardless of whether the functionality is implemented
by the TOE or by the TOE platform.
TSS
The evaluator shall examine the TSS to ensure that it details the self-tests that
are run by the TSF on start-up; this description should include an outline of
what the tests are actually doing (e.g., rather than saying "memory is tested",
a description similar to "memory is tested by writing a value to each memory
location and reading it back to ensure it is identical to what was written" shall
be used). The evaluator shall ensure that the TSS makes an argument that the
tests are sufficient to demonstrate that the TSF is operating correctly. If some
of the tests are performed by the TOE platform, the evaluator shall check the
TSS to ensure that those tests are identified, and that the ST for each
platform contains a description of those tests. Note that the tests that are
required by this component are those that support security functionality in
this EP, which may not correspond to the set of all self-tests contained in the
platform STs.
The evaluator shall examine the TSS to ensure that it describes how the
integrity of stored TSF executable code is cryptographically verified when it is
loaded for execution. The evaluator shall ensure that the TSS makes an
argument that the tests are sufficient to demonstrate that the integrity of
stored TSF executable code has not been compromised. The evaluator shall
check to ensure that the cryptographic requirements listed are consistent with
the description of the integrity verification process.
56
The evaluator also ensures that the TSS (or the operational guidance)
describes the actions that take place for successful (e.g. hash verified) and
unsuccessful (e.g., hash not verified) cases. For checks implemented entirely
by the platform, the evaluator ensures that the operational guidance for the
TOE references or includes the platform-specific guidance for each platform
listed in the ST.
AGD
The evaluator also ensures that the TSS (or the operational guidance)
describes the actions that take place for successful (e.g. hash verified) and
unsuccessful (e.g., hash not verified) cases. For checks implemented entirely
by the platform, the evaluator ensures that the operational guidance for the
TOE references or includes the platform-specific guidance for each platform
listed in the ST.
Test
The evaluator shall perform the following tests:
Test 1: The evaluator performs the integrity check on a known good TSF
executable and verifies that the check is successful.
Test 2: The evaluator modifies the TSF executable, performs the integrity
check on the modified TSF executable and verifies that the check fails.
5.5 TOE Security Assurance Requirements
This EP does not define any SARs beyond those defined within the base PPs to which it can claim
conformance. It is important to note that a TOE that is evaluated against this EP is inherently evaluated
against the GPOS PP, MDF PP, or App PP as well. These PPs both include a number of Assurance
Activities associated with both Security Functional Requirements (SFRs) and SARs. Additionally, this EP
includes a number of SFR-based Assurance Activities that similarly refine the SARs of the base PPs. The
evaluation laboratory will evaluate the TOE against the chosen base PP and supplement that evaluation
with the necessary SFRs that are taken from this EP.
57
A. Optional Requirements
As indicated in the introduction to this EP, the baseline requirements (those that must be performed by
the TOE or its underlying platform) are contained in the body of this EP. Additionally, there are three
other types of requirements specified in Appendices A, B, and C.
The first type (in this Appendix) are requirements that can be included in the ST, but do not have to be in
order for a TOE to claim conformance to this EP. The second type (in Appendix B) are requirements
based on selections in the body of the EP: if certain selections are made, then additional requirements in
that appendix will need to be included. The third type (in Appendix C) are components that are not
required in order to conform to this EP, but will be included in the baseline requirements in future
versions of this EP, so adoption by VPN Client vendors is encouraged. Note that the ST author is
responsible for ensuring that requirements that may be associated with those in Appendix A, Appendix
B, and/or Appendix C but are not listed (e.g., FMT-type requirements) are also included in the ST.
No optional requirements have been identified at this time.
58
B. Selection-Based Requirements
As indicated in the introduction to this EP, the baseline requirements (those that must be performed by
the TOE or its underlying platform) are contained in the body of this EP. There are additional
requirements based on selections in the body of the EP: if certain selections are made, then additional
requirements below will need to be included.
B.1 Cryptographic Support (FCS)
The TOE may support pre-shared keys for use in the IPsec protocol, and may use pre-shared keys in
other protocols as well. There are two types of pre-shared keys that must be supported by the TOE, as
specified in the requirements below. The first type is referred to as “text-based pre-shared keys”, which
refer to pre-shared keys that are entered by users as a string of characters from a standard character
set, similar to a password. Such pre-shared keys must be conditioned so that the string of characters is
transformed into a string of bits, which is then used as the key.
The second type is referred to as “bit-based pre-shared keys” (for lack of a standard term); this refers to
keys that are either generated by the TSF on a command from the administrator, or input in "direct
form" by an administrator. "Direct form" means that the input is used directly as the key, with no
"conditioning" as was the case for text-based pre-shared keys. An example would be a string of hex
digits that represent the bits that comprise the key.
The requirements below mandate that the TOE must support both text-based and bit-based pre-shared
keys, although generation of the bit-based pre-shared keys may be done either by the TOE or in the
operational environment.
FIA_PSK_EXT.1 Pre-Shared Key Composition
FIA_PSK_EXT.1.1 The [selection: TOE, TOE platform] shall be able to use pre-shared keys for IPsec.
FIA_PSK_EXT.1.2 The [selection: TOE, TOE platform] shall be able to accept text-based pre-shared
keys that:
 are 22 characters and [selection: [assignment: other supported lengths], no
other lengths];
 composed of any combination of upper and lower case letters, numbers,
and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”,
“(“, “)”, and [selection: no other special characters, [assignment: list of
additional supported special characters]]).
FIA_PSK_EXT.1.3 The [selection: TOE, TOE platform] shall condition the text-based pre-shared
keys by using [selection: SHA-1, SHA-256, SHA-512, [assignment: method of
conditioning text string]], [selection: be able to [selection: accept, generate using
the random bit generator specified in FCS_RBG_EXT.1] bit-based pre-shared
keys, perform no other conditioning].
Application Note: “TOE platform” is to be selected if the TOE claims conformance to the App PP. In
the OS and MDF cases, the underlying platform is still part of the TOE, so “TOE”
59
is to be selected regardless of whether it is implemented by the VPN client itself
or by the underlying operating system or mobile device.
For the length of the text-based pre-shared keys, a common length (22
characters) is required to help promote interoperability. If other lengths are
supported they should be listed in the assignment; this assignment can also
specify a range of values (e.g., "lengths from 5 to 55 characters") as well.
For FIA_PSK_EXT.1.3, the ST author fills in the method by which the text string
entered by the administrator is “conditioned” into the bit string used as the key.
This can be done by using one of the specified hash functions, or some other
method through the assignment statement. If “bit-based pre-shared keys” is
selected, the ST author specifies whether the TSF merely accepts bit-based pre-
shared keys, or is capable of generating them. If it generates them, the
requirement specified that they must be generated using the RBG specified by
the requirements. If the TOE does not use bit-based pre-shared keys, the second
selection should be completed with “perform no other conditioning,” as text-
based pre-shared keys would then be the only type used.
Assurance Activity
TSS
The evaluator shall also examine the TSS to ensure it describes the process by
which the bit-based pre-shared keys are generated (if the TOE supports this
functionality), and confirm that this process uses the RBG specified in
FCS_RBG_EXT.1.
Requirement met by the platform
For each platform listed in the ST, the evaluator shall examine the ST of the
platform to ensure that the functions associated with pre-shared keys
claimed in that platform's ST contains the same functions specified in the VPN
Client's ST. If the TOE does not perform any management or input of the pre-
shared keys then no further activity is required.
Requirement met by the TOE
The evaluator shall examine the TSS to ensure that it states that text-based
pre-shared keys of 22 characters are supported. The evaluator shall also
confirm that the TSS states the conditioning that takes place to transform the
text-based pre-shared key from the key sequence entered by the user (e.g.,
ASCII representation) to the bit string used by IPsec, and that this
conditioning is consistent with the FIA_PSK_EXT.1.3.
AGD
If the TOE supports bit-based pre-shared keys, the evaluator shall confirm the
operational guidance contains instructions for either entering bit-based pre-
60
shared keys for each protocol identified in the requirement, or generating a
bit-based pre-shared key (or both). The evaluator shall also examine the TSS
to ensure it describes the process by which the bit-based pre-shared keys are
generated (if the TOE supports this functionality), and confirm that this
process uses the RBG specified in FCS_RBG_EXT.1.
The evaluator shall check that any management functions related to pre-
shared keys that are performed by the TOE are specified in the operational
guidance.
Requirement met by the TOE
The evaluator shall examine the operational guidance to determine that it
provides guidance on the composition of strong text-based pre-shared keys,
and (if the selection indicates keys of various lengths can be entered) that it
provides information on the merits of shorter or longer pre-shared keys. 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.1.2.
Test
The evaluator shall perform the following tests:
Test 1: The evaluator shall compose a pre-shared key of 22 characters that
contains a combination of the allowed characters in accordance with the
operational guidance, and demonstrates that a successful protocol
negotiation can be performed with the key.
Test 2 [conditional]: If the TOE supports pre-shared keys of multiple lengths,
the evaluator shall repeat Test 1 using the minimum length; the maximum
length; and invalid lengths that are below the minimum length, above the
maximum length, null length, empty length, or zero length. The minimum and
maximum length tests should be successful, and the invalid lengths must be
rejected by the TOE.
Test 3 [conditional]: If the TOE supports but does not generate bit-based pre-
shared keys, the evaluator shall obtain a bit-based pre-shared key of the
appropriate length and enter it per the instructions in the operational
guidance. The evaluator shall then demonstrate that a successful protocol
negotiation can be performed with the key.
Test 4 [conditional]: If the TOE does generate bit-based pre-shared keys, the
evaluator shall generate a bit-based pre-shared key of the appropriate length
and use it according to the instructions in the operational guidance. The
evaluator shall then demonstrate that a successful protocol negotiation can
be performed with the key.
61
62
C. Objective Requirements
This section is reserved for requirements that are not currently prescribed by this EP but are expected to
be included in future versions of the EP. Vendors planning on having evaluations performed against future
products are encouraged to plan for these objective requirements to be met.
C.1 Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The TSF and [selection: TOE Platform, no other component] shall be able to
generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) All administrative actions;
d) [Specifically defined auditable events listed in Table C-1].
Requirement Auditable Events Additional Audit Record Contents
FAU_SEL.1 All modifications to the audit
configuration that occur while the audit
collection functions are operating.
None.
FCS_IPSEC_EXT.1 Decisions to DISCARD or BYPASS network
packets processed by the TOE.
Failure to establish an IPsec SA.
Establishment/Termination of an IPsec
SA.
Presumed identity of source subject.
Identity of destination subject.
Transport layer protocol, if
applicable.
Source subject service identifier, if
applicable.
The entry in the SPD that applied to
the decision.
Reason for failure.
Non-TOE endpoint of connection (IP
address) for both successes and
failures.
FDP_RIP.2 None.
FIA_PSK_EXT.1 Failure of the randomization process. None.
FMT_SMF.1 Success or failure of management
function.
None.
FPT_TUD_EXT.1 Initiation of the update.
Any failure to verify the integrity of the
update.
No additional information.
63
Table C-1 – Auditable Events
Application Note: In the case of "a", the audit functions referred to are those provided by the TOE.
For example, in the case that the TOE was a stand-alone executable, auditing
the startup and the shutdown of the TOE itself would be sufficient to meet the
requirements of this clause.
In the case where the TOE platform is responsible for some audit functions, the
ST author should identify which auditable events are generated by the TSF and
which are generated by the TOE platform.
Many auditable aspects of the SFRs included in this document deal with
administrative actions. Item c above requires all administrative actions to be
auditable, so no additional specification of the auditability of these actions is
present in Table 9. While the TOE itself does not need to provide the ability to
perform I&A for an administrator, this requirement implies that the TOE possess
the capability to audit the events described by the base PP as "administrative
actions" (primarily dealing with configuration of the functionality provided by
the TOE). It is expected that the AGD guidance detail the steps needed to ensure
the audit data generated by the TOE is integrated with the audit capabilities of
the underlying IT environment.
The auditable events defined in Table D-1 are for the SFRs that are explicitly
defined in this EP. For any SFRs that are included as part of the TOE based on the
claimed base PP, it is expected that any applicable auditable events defined for
those SFRs in the base PP are also claimed as part of the TSF. These auditable
events only apply if the client actually performs these functions. If the platform
performs any of these actions, then the platform is responsible for performing
the auditing, not the TSF.
FAU_GEN.1.2 The TSF and [selection: TOE Platform, no other component] shall record within
each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the EP/ST, [information specified in
column three of Table C-1].
Application Note: As with the previous component, the ST author should update Table 2 with any
additional information generated. "Subject identity" in the context of this
requirement could either be the administrator's user id or the affected network
interface, for example.
Assurance Activity
TSS
64
The evaluator shall examine the TSS to determine that it describes the
auditable events and the component that is responsible for each type of
auditable event.
AGD
The evaluator shall check the operational guidance and ensure that it lists all
of the auditable events and provides a format for audit records. Each audit
record format type must be covered, along with a brief description of each
field. The evaluator shall check to make sure that every audit event type
mandated by the EP is described and that the description of the fields
contains the information required in FAU_GEN.1.2, and the additional
information specified in Table C-1.
The evaluator shall in particular ensure that the operational guidance is clear
in relation to the contents for failed cryptographic events. In Table D-1,
information detailing the cryptographic mode of operation and a name or
identifier for the object being encrypted is required. The evaluator shall
ensure that name or identifier is sufficient to allow an administrator
reviewing the audit log to determine the context of the cryptographic
operation (for example, performed during a key negotiation exchange,
performed when encrypting data for transit) as well as the non-TOE endpoint
of the connection for cryptographic failures relating to communications with
other IT systems.
The evaluator shall also make a determination of the administrative actions
that are relevant in the context of this EP. The TOE may contain functionality
that is not evaluated in the context of this EP because the functionality is not
specified in an SFR. This functionality may have administrative aspects that
are described in the operational guidance. Since such administrative actions
will not be performed in an evaluated configuration of the TOE, the evaluator
shall examine the operational guidance and make a determination of which
administrative commands, including subcommands, scripts, and configuration
files, are related to the configuration (including enabling or disabling) of the
mechanisms implemented in the TOE that are necessary to enforce the
requirements specified in the EP, which thus form the set of “all
administrative actions”. The evaluator may perform this activity as part of the
activities associated with ensuring the AGD_OPE guidance satisfies the
requirements.
Test
The evaluator shall test the TOE’s ability to correctly generate audit records
by having the TOE generate audit records in accordance with the assurance
activities associated with the functional requirements in this EP. Additionally,
the evaluator shall test that each administrative action applicable in the
65
context of this EP is auditable. When verifying the test results, the evaluator
shall ensure the audit records generated during testing match the format
specified in the administrative guide, and that the fields in each audit record
have the proper entries.
Note that the testing here can be accomplished in conjunction with the
testing of the security mechanisms directly. For example, testing performed
to ensure that the administrative guidance provided is correct verifies that
AGD_OPE.1 is satisfied and should address the invocation of the
administrative actions that are needed to verify the audit records are
generated as expected.
FAU_SEL.1 Selective Audit
FAU_SEL.1.1 The [selection: TSF, TOE Platform] shall be able to select the set of events to be
audited from the set of all auditable events based on the following attributes:
[event type, [success of auditable security events, failure of auditable security
events], [assignment: list of additional attributes that audit selectivity is based
upon]].
Application Note: The intent of this requirement is to identify all criteria that can be selected to
trigger an audit event. This can be configured through an interface on the client
for a user/administrator to invoke, or it could be an interface that the VPN
gateway uses to instruct the client on which events are to be audited. For the ST
author, the assignment is used to list any additional criteria or “none”. The
auditable event types are listed in Table C-1.
The intent of the first selection is to allow for the case where the underlying
platform is responsible for some audit log generation functionality.
Assurance Activity
TSS
There are no TSS assurance activities for this SFR.
AGD
The evaluator shall review the administrative guidance to ensure that the
guidance itemizes all event types, as well as describes all attributes that are
to be selectable in accordance with the requirement, to include those
attributes listed in the assignment. The administrative guidance shall also
contain instructions on how to set the pre-selection, or how the VPN gateway
will configure the client, as well as explain the syntax (if present) for multi-
value pre-selection. The administrative guidance shall also identify those
audit records that are always recorded, regardless of the selection criteria
currently being enforced.
66
Test
The evaluator shall perform the following tests:
Test 1: For each attribute listed in the requirement, the evaluator shall devise
a test to show that selecting the attribute causes only audit events with that
attribute (or those that are always recorded, as identified in the
administrative guidance) to be recorded.
Test 2 [conditional]: If the TSF supports specification of more complex audit
pre-selection criteria (e.g., multiple attributes, logical expressions using
attributes) then the evaluator shall devise tests showing that this capability is
correctly implemented. The evaluator shall also, in the test plan, provide a
short narrative justifying the set of tests as representative and sufficient to
exercise the capability.
C.2 User Data Protection (FDP)
FDP_IFC_EXT.1 Subset Information Flow Control
FDP_IFC_EXT.1.1 The TSF shall ensure that all IP traffic (other than IP traffic required to establish
the VPN connection) flow through the IPsec VPN client.
Application Note: This requirement is used when the VPN client is able to enforce the requirement
through its own components. This generally will have to be done through using
hooks provided by the platform such that the TOE is able to ensure that no IP
traffic can flow through other network interfaces.
Assurance Activity
TSS
The evaluator shall verify that the TSS section of the ST describes the routing
of IP traffic through processes on the TSF when a VPN client is enabled. The
evaluator shall ensure that the description indicates which traffic does not go
through the VPN and which traffic does and that a configuration exists for
each baseband protocol in which only the traffic identified by the ST author
as necessary for establishing the VPN connection (IKE traffic and perhaps
HTTPS or DNS traffic) is not encapsulated by the VPN protocol (IPsec). The ST
author shall also identify in the TSS section any differences in the routing of IP
traffic when using any supported baseband protocols (e.g. WiFi or, LTE).
AGD
The evaluator shall verify that the following is addressed by the
documentation:
67
 The description above indicates that if a VPN client is enabled, all
configurations route all IP traffic (other than IP traffic required to
establish the VPN connection) through the VPN client.
 The AGD guidance describes how the user and/or administrator can
configure the TSF to meet this requirement.
Test
The evaluator shall perform the following test:
Step 1 - The evaluator shall use the platform to enable a network connection
without using IPsec. The evaluator shall use a packet sniffing tool between
the platform and an Internet-connected network. The evaluator shall turn on
the sniffing tool and perform actions with the device such as navigating to
websites, using provided applications, accessing other Internet resources
(Use Case 1), accessing another VPN client (Use Case 2), or accessing an IPsec-
capable network device (Use Case 3). The evaluator shall verify that the
sniffing tool captures the traffic generated by these actions, turn off the
sniffing tool, and save the session data.
Step 2 - The evaluator shall configure an IPsec VPN client that supports the
routing specified in this requirement, and if necessary, configure the device to
perform the routing specified as described in the AGD guidance. The
evaluator shall turn on the sniffing tool, establish the VPN connection, and
perform the same actions with the device as performed in the first step. The
evaluator shall verify that the sniffing tool captures traffic generated by these
actions, turn off the sniffing tool, and save the session data.
Step 3 - The evaluator shall examine the traffic from both step one and step
two to verify that all IP traffic, aside from and after traffic necessary for
establishing the VPN (such as IKE, DNS, and possibly HTTPS), is encapsulated
by IPsec.
Step 4 - The evaluator shall attempt to send packets to the TOE outside the
VPN connection and shall verify that the TOE discards them.
68
D. Entropy Documentation and Assessment
The TOE does not require any additional supplementary information to describe its entropy source(s)
beyond the requirements outlined in the claimed base PP. As with other base PP requirements, the only
additional requirement is that the entropy documentation also applies to the specific VPN client
capabilities of the TOE in addition to the functionality required by the claimed base PP(s).
69
E. References
Identifier Title
[CC] Common Criteria for Information Technology Security Evaluation –
 Part 1: Introduction and General Model, CCMB-2012-09-001, Version 3.1 Revision
4, September 2012
 Part 2: Security Functional Components, CCMB-2012-09-002, Version 3.1 Revision
4, September 2012
 Part 3: Security Assurance Components, CCMB-2012-09-003, Version 3.1 Revision
4, September 2012
[GPOS
PP]
 Protection Profile for General Purpose Operating Systems, Version 4.1, March
2016
[MDF PP]  Protection Profile for Mobile Device Fundamentals, Version 3.0, June 2016
[App PP]  Protection Profile for Application Software, Version: 1.2, April 2016
70
F. Acronyms
Acronym Meaning
AES Advanced Encryption Standard
AF Authorization factor
AS Authorization subsystem
CAVS Cryptographic Algorithm Validation System
CC Common Criteria
CCTL Common Criteria Testing Laboratory
CM Configuration management
COTS Commercial Off-The-Shelf
CMVP Cryptographic Module Validation Program
DRBG Deterministic Random Bit Generator
DoD Department of Defense
EAL Evaluation Assurance Level
ES Encryption Subsystem
FIPS Federal Information Processing Standards
ISSE Information System Security Engineer
IT Information Technology
OSP Organizational Security Policy
PP Protection Profile
PUB Publication
RBG Random Bit Generator
SAR Security Assurance Requirement
SF Security Function
SFR Security Functional Requirement
ST Security Target
TOE Target of Evaluation
TSF TOE Security Function
71
TSFI TOE Security Function Interface
TSS TOE Summary Specification