NetMotion Mobility®
12.14
Security Target
Evaluation Assurance Level (EAL): EAL 4+
Doc No: 2181-001-D102
Version: 0.15
15 October 2021
NetMotion Software, Inc.
1505 Westlake Ave N. Suite 500
Seattle, WA, USA
98109
Prepared by:
EWA-Canada, An Intertek Company
1223 Michael Street North, Suite 200
Ottawa, Ontario, Canada
K1J 7T2
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page i of iv
DOCUMENT HISTORY
Rev. Issue Date Description Author Reviewer
0.1draft 29 April 2020
Initial draft for
developer review
Tim Condly Iain Holness
0.1 19 May 2020
Updated Developer
Comments
Initial Draft for
Evaluation
Tim Condly
0.2 23 June 2020
Addressed evaluator
ORs
Tim Condly Iain Holness
0.3 31 August 2020
Updated client
platforms
Tim Condly
0.4 11 November 2020
Updated OS platform
versions, CAVP certs,
and removed CMVP
references
Tim Condly
0.5 19 February 2021
Addressed evaluator
comments
Updated TOE version
and Android version
Tim Condly
0.6 30 March 2021 Update TOE Version Ben Buttera Dawn Adams
0.7 10 May 2021 Update Build Number Ben Buttera Dawn Adams
0.8 17 May 2021
Addressed Evaluator
Concerns
Ben Buttera Dawn Adams
0.9 28 May 2021
Addressed Evaluator
ORs
Ben Buttera Dawn Adams
0.10 16 August 2021
Addressed Evaluator
ORs
Ben Buttera Dawn Adams
0.11 19 August 2021
Addressed Evaluator
ORs
Ben Buttera Dawn Adams
0.12 9 September 2021
Addressed Evaluator
ORs
Ben Buttera Dawn Adams
0.13
17 September
2021
Version updated
Dawn
Adams
Ben Buttera
0.14
29 September
2021
Addressed comments
Dawn
Adams
Ben Buttera
0.15 12 October 2021 Addressed ORs Ben Buttera Dawn Adams
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page ii of iv
CONTENTS
1 SECURITY TARGET INTRODUCTION.............................................1
1.1 DOCUMENT ORGANIZATION.............................................................1
1.2 SECURITY TARGET REFERENCE ........................................................ 2
1.3 TOE REFERENCE.............................................................................2
1.4 TOE OVERVIEW ..............................................................................2
TOE Environment ...........................................................................3
1.5 TOE DESCRIPTION..........................................................................6
Physical Scope ...............................................................................6
TOE Delivery .................................................................................7
Logical Scope.................................................................................7
Functionality Excluded from the Evaluated Configuration.....................8
2 CONFORMANCE CLAIMS...............................................................9
2.1 COMMON CRITERIA CONFORMANCE CLAIM........................................ 9
2.2 PROTECTION PROFILE CONFORMANCE CLAIM .................................... 9
2.3 PACKAGE CLAIM.............................................................................9
2.4 CONFORMANCE RATIONALE.............................................................9
3 SECURITY PROBLEM DEFINITION..............................................10
3.1 THREATS ..................................................................................... 10
3.2 ORGANIZATIONAL SECURITY POLICIES........................................... 10
3.3 ASSUMPTIONS ............................................................................. 11
4 SECURITY OBJECTIVES..............................................................12
4.1 SECURITY OBJECTIVES FOR THE TOE.............................................. 12
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ......... 13
4.3 SECURITY OBJECTIVES RATIONALE ................................................ 14
Security Objectives Rationale Related to Threats..............................15
Security Objectives Rationale Related to Assumptions.......................17
5 EXTENDED COMPONENTS DEFINITION......................................20
5.1 SECURITY FUNCTIONAL REQUIREMENTS ......................................... 20
5.2 SECURITY ASSURANCE REQUIREMENTS .......................................... 20
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page iii of iv
6 SECURITY REQUIREMENTS ........................................................21
6.1 CONVENTIONS ............................................................................. 21
6.2 SECURITY FUNCTIONAL REQUIREMENTS ......................................... 21
Security Audit (FAU).....................................................................22
Cryptographic Support (FCS) .........................................................23
User Data Protection (FDP)............................................................27
Identification and Authentication (FIA)............................................28
Security Management (FMT) ..........................................................29
Protection of the TSF (FPT)............................................................29
6.3 SECURITY ASSURANCE REQUIREMENTS .......................................... 30
6.4 SECURITY REQUIREMENTS RATIONALE ........................................... 31
Security Functional Requirements Rationale.....................................31
SFR Rationale Related to Security Objectives ...................................32
Dependency Rationale ..................................................................35
Security Assurance Requirements Rationale.....................................37
7 TOE SUMMARY SPECIFICATION.................................................39
7.1 SECURITY AUDIT.......................................................................... 39
7.2 CRYPTOGRAPHIC SUPPORT............................................................ 41
Use of Cryptographic Primitives......................................................42
7.3 USER DATA PROTECTION .............................................................. 43
PEAP MS-CHAPv2 Authentication....................................................43
EAP-TLS Authentication.................................................................44
7.4 IDENTIFICATION AND AUTHENTICATION......................................... 45
7.5 SECURITY MANAGEMENT............................................................... 46
7.6 PROTECTION OF THE TSF .............................................................. 46
8 TERMINOLOGY AND ACRONYMS ................................................47
8.1 TERMINOLOGY ............................................................................. 47
8.2 ACRONYMS .................................................................................. 47
LIST OF TABLES
Table 1 - TOE-Supporting Hardware and Software ......................................... 4
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page iv of iv
Table 2 - Operational Environment Hardware and Software ............................ 4
Table 3 - Cryptographic Modules in the Operational Environment..................... 5
Table 4 – Logical Scope of the TOE ..............................................................8
Table 5 – Threats .................................................................................... 10
Table 6 – Assumptions ............................................................................. 11
Table 7 – Security Objectives for the TOE................................................... 12
Table 8 – Security Objectives for the Operational Environment...................... 13
Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions ....... 14
Table 10 – Summary of Security Functional Requirements............................ 22
Table 11 - Cryptographic Operations (Windows).......................................... 25
Table 12 - Cryptographic Operations (iOS and macOS) ................................ 26
Table 13 - Cryptographic Operations (Android)............................................ 27
Table 14 - Management of TSF Data .......................................................... 29
Table 15 – Security Assurance Requirements .............................................. 31
Table 16 – Mapping of SFRs to Security Objectives ...................................... 32
Table 17 – Functional Requirement Dependencies ....................................... 37
Table 18 - Activity Log Information............................................................ 40
Table 19 - Event Log Information .............................................................. 40
Table 20 - Cryptographic Primitives Usage.................................................. 42
Table 21 – Terminology............................................................................ 47
Table 22 – Acronyms ............................................................................... 49
LIST OF FIGURES
Figure 1 - NetMotion Mobility 12.14 .............................................................3
Figure 2 - NetMotion Mobility 12.14 TOE Boundary ........................................ 6
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 1 of 49
1 SECURITY TARGET INTRODUCTION
This Security Target (ST) defines the scope of the evaluation in terms of the
assumptions made, the intended environment for the Target of Evaluation
(TOE), the Information Technology (IT) security functional and assurance
requirements to be met, and the level of confidence (evaluation assurance level)
to which it is asserted that the TOE satisfies its IT security requirements. This
document forms the baseline for the Common Criteria (CC) evaluation.
1.1 DOCUMENT ORGANIZATION
Section 1, ST Introduction, provides the Security Target reference, the Target
of Evaluation reference, the TOE overview and the TOE description.
Section 2, Conformance Claims, describes how the ST conforms to the
Common Criteria and Packages. The ST does not conform to a Protection
Profile.
Section 3, Security Problem Definition, describes the expected environment
in which the TOE is to be used. This section defines the set of threats that are
relevant to the secure operation of the TOE, organizational security policies with
which the TOE must comply, and secure usage assumptions applicable to this
analysis.
Section 4, Security Objectives, defines the set of security objectives to be
satisfied by the TOE and by the TOE operating environment in response to the
problem defined by the security problem definition.
Section 5, Extended Components Definition, defines the extended
components which are then detailed in Section 6.
Section 6, Security Requirements, specifies the security functional and
assurance requirements that must be satisfied by the TOE and the IT
environment.
Section 7, TOE Summary Specification, describes the security functions that
are included in the TOE to enable it to meet the IT security functional
requirements.
Section 8 Terminology and Acronyms, defines the acronyms and
terminology used in this ST.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 2 of 49
1.2 SECURITY TARGET REFERENCE
ST Title: NetMotion Mobility®
12.14 Security Target
ST Version: 0.15
ST Date: 15 October 2021
1.3 TOE REFERENCE
TOE
Identification:
NetMotion Mobility®
12.14
• NetMotion Mobility Server 12.14.09178
• NetMotion Mobility 12.12 Client for Windows 10
(12.12.16943)
• NetMotion Mobility 12.12 Client for Android (12.12.16943)
• NetMotion Mobility 12.13 Client for macOS (12.13.23250)
• NetMotion Mobility 12.13 Client for iOS (12.13.05677)
TOE Developer: NetMotion Software, Inc.
TOE Type: Virtual Private Network (VPN)
Note: To satisfy the cryptographic requirements, the Android client will be running the
NetMotion Mobility 12.12 software in the evaluated configuration of the TOE. This client
software is fully compatible with the NetMotion Mobility Server 12.14 software.
1.4 TOE OVERVIEW
The TOE is NetMotion Mobility 12.14, a client/server‐based software Virtual
Private Network (VPN) that secures communications between the enterprise
network and the mobile environment. NetMotion Mobility allows TCP/IP network
applications to operate reliably and confidentially, without modification, over
wireless connections. NetMotion Mobility ensures that only authorized users are
granted access to protected resources, and that all communications are
protected using validated cryptographic standards.
When a mobile device goes out of range or suspends operation, NetMotion
Mobility maintains the session status and resumes the protected session when
the device returns to service. If the mobile device returns to service at a
different point on the network or connects from a new location, the Mobility
server relays data to the new location, even if it is on a different subnet or a
different network.
The TOE is managed via the Mobility Console, which is a web‐based
configuration and management application used by an administrator to configure
settings, monitor server status and client connections, monitor activity or event
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 3 of 49
logs1
, and troubleshoot problems. The Mobility Console is part of the Mobility
Server. Figure 1 identifies the TOE components in the evaluated configuration.
Figure 1 - NetMotion Mobility 12.14
TOE Environment
1.4.1.1 Required Non-TOE Components
The following hardware and software components are required to support the
operation of the TOE in the evaluated configuration.
TOE Component Required Software Required Hardware
NetMotion Mobility 12.14
Server, version 1809
Windows Server 2019 General Purpose Computing
Platform with x64‐compatible
dual‐core processor, 2.0 GHz, 16
GB RAM
NetMotion Mobility 12.12
Windows Client, version
1909
Windows 10 General Purpose Computing
Platform
NetMotion Mobility 12.13
iOS Client
iOS 13.6.1 iPad, iPhone (Apple devices with
Apple A8 to A12X CPUs)
1
An event log is a binary file updated by any Mobility component that logs event
messages.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 4 of 49
TOE Component Required Software Required Hardware
NetMotion Mobility 12.13
macOS Client
macOS 10.15 Mac mini, iMac, MacPro or
MacBook hardware (Intel CPUs)
NetMotion Mobility 12.12
Android Client
Android 11 General Purpose Android device
Table 1 - TOE-Supporting Hardware and Software
1.4.1.2 Required Operational Environment Components
The following environmental components are required for operation of the TOE
in the evaluated configuration.
Component Required Software Required Hardware
Management Console Windows 10 with Microsoft
Edge 52 or later
General Purpose Computing
Platform
RADIUS Authentication
Server (provided as a
service to the TOE)
Software supporting PEAP
MS-CHAPv2 and EAP-TLS
General Purpose Computing
hardware that meets the
requirements of the
authentication server
Public Key Infrastructure
(provided as a service to
the TOE)
Dependent upon the
authentication server
General Purpose Computing
hardware that meets the
requirements of the
authentication server
Firewall Dependent on the selected
appliance
General Purpose Firewall
appliance
Table 2 - Operational Environment Hardware and Software
The operational environment must provide an authentication server. For the
purposes of the evaluation, end-user authentication is performed using a
RADIUS-based authentication server and an implementation of the PEAP MS-
CHAPv2 or EAP-TLS protocols.
NTLMv2 over HTTPS is used to authenticate administrative users to the Mobility
Console for the purposes of managing the TOE. Both the authentication server
and the management console computer are located on a trusted internal
network. Physical access to the management console computer must be limited
to authorized personnel. A firewall must be in place to ensure that the Mobility
Console can only be accessed from the internal network. This configuration
allows NTLMv2 over HTTPS to provide sufficient security to support the
authentication of administrative users.
Support for NTLM authentication of administrators is provided by the Windows
infrastructure in the operational environment. In order to support the
implementation of PEAP MS-CHAPv2 or EAP-TLS, one or more RADIUS
authentication servers are required. Additionally, the use of EAP-TLS requires
that users be issued certificates. These may be issued in any number of ways,
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 5 of 49
either from within the organization, or externally. A Public Key Infrastructure
(PKI) is required to issue certificates.
In the evaluated configuration, a firewall must be implemented to protect the
internal resources from the external network, which includes the Mobility Server
and authentication server. The only access allowed from the wireless access
point to the internal network is through a Mobility-protected VPN connection.
Note that for authentication, an encrypted tunnel is established between the
Mobility Client and the authentication server. The ciphersuites are negotiated
between the client operating system and the authentication server. Once
authenticated, a VPN tunnel is established between the Mobility Client and the
Mobility Server. The ciphersuites used are negotiated between the Mobility Client
and the Mobility Server.
The connections between the Mobility Server and the authentication servers are
protected by the operational environment. These components may be physically
secured in a server room and may communicate on the same Local Area
Network (LAN) segment.
1.4.1.3 Cryptographic Components
The TOE calls cryptographic modules implemented within the server (Windows
Server 2019) and client platforms (Windows 10, iOS 13, macOS 10.15 and
Android 11) to perform cryptographic operations. The implementation of the
cryptographic primitives and related key management are part of the
operational environment and are not covered in the evaluation. Table 3 identifies
the cryptographic modules for each platform:
Platform Cryptographic Module
Windows Server 2019 1809 Microsoft Kernel Mode Cryptographic
Primitives Library: Version 10.0.17763
Windows 10 1909 Microsoft Kernel Mode Cryptographic
Primitives Library: Version 10.0.18363
Apple iOS 13.6.1 Apple CoreCrypto Kernel Module V10.0 for
ARM: Version 10.0
Apple macOS Catalina 10.15 Apple CoreCrypto Kernel Module V10.0 for
Intel: Version 10.0
Android 11 OpenSSL FIPS Object Module SE: Version
2.0.122
Table 3 - Cryptographic Modules in the Operational Environment
The TOE is a software-only TOE.
2
Since no suitable cryptographic module exists in the Android operating system, the
OpenSSL FIPS Object Module software is delivered to the device with the NetMotion
client software.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 6 of 49
1.5 TOE DESCRIPTION
Physical Scope
The TOE is NetMotion Mobility 12.14 and is comprised of the following
components:
• NetMotion Mobility 12.14 Server
• NetMotion Mobility 12.12 Client for Windows
• NetMotion Mobility 12.13 Client for Apple iOS
• NetMotion Mobility 12.13 Client for macOS
• NetMotion Mobility 12.12Client for Android
Figure 2 identifies the TOE Boundary.
Figure 2 - NetMotion Mobility 12.14 TOE Boundary
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 7 of 49
TOE Delivery
1.5.2.1 Mobility Server and Windows Client
The NetMotion Mobility Server and Windows Client software are delivered to the
customer via secure download. From the NetMotion Software website, customers
are directed to a secure portal protected by TLS. Upon successful log in,
customers can download the following executables:
• NetMotion Mobility 12.14 Server
o Mobility_Server_12.14_Win2016_release.exe
• NetMotion Mobility 12.12 Windows Client
o Mobility_xg_client_12.12_Win10_x64_release.exe
Customers can access the NetMotion Wireless portal at:
http://www.netmotionwireless.com/customerportal
1.5.2.2 Android, iOS, and macOS Client
The NetMotion Mobility Client software for Android, iOS and macOS devices is
available via download from their respective app stores. Customers can
download the following Mobility Client files:
• NetMotion Mobility 12.12 Android Client
o MobilityClient.apk
• NetMotion Mobility 12.13 iOS Client
o MobilityXgiOS.ipa
• NetMotion Mobility 12.13 macOS Client
o Mobility.app
1.5.2.3 TOE Guidance
The TOE guidance documentation is provided in Hypertext Markup Language
(HTML) format and is available to customers at:
https://help.netmotionsoftware.com/support/docs/MobilityXG/1210/help/mobilit
yhelp.htm#page/Mobility%20Server/intro.01.02.html
The following Common Criteria Guidance Supplement is also available to
customers, in Portable Document Format (PDF), upon request:
• NetMotion Mobility®
12.14 Common Criteria Guidance Supplement
o NetMotion_Mobility_12_EAL4_AGD0.6.pdf
Logical Scope
The logical boundary of the TOE includes all interfaces and functions within the
physical boundary. The logical boundary of the TOE may be broken down by the
security function classes described in Section 6. Table 4 summarizes the logical
scope of the TOE.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 8 of 49
Functional Classes Description
Security Audit The TOE generates audit records for security events. Only
those roles that have been granted specific access to the
audit trail are able to view the audit records. For the purpose
of this evaluation, only users in the Administrator role have
been granted this access.
Cryptographic Support The TOE supports secure communications between TOE
components. This encrypted traffic prevents modification and
disclosure of user information. Cryptographic functionality is
provided by FIPS 140‐2 validated modules in the operating
systems of the server and client components. Cryptography is
also supported for the authentication of users.
User Data Protection The TOE provides an information flow security policy. The
security policy limits access to internal protected resources
based on policy settings. The TOE provides a secure
connection between mobile users and the internal network.
Traffic is protected from disclosure and modification.
Identification and
Authentication
The TOE verifies that users are identified and authenticated
before permitting access. Additionally, administrators must be
identified and authenticated before access to administrative
functions is permitted.
Security Management The TOE provides security management functions through the
Mobility Console. Administrators manage users, information
flow policies, and audit records.
Protection of the TSF Reliable timestamps are provided in support of TOE functions,
including the generation of audit records.
Table 4 – Logical Scope of the TOE
Functionality Excluded from the Evaluated
Configuration
The following features are excluded from this evaluation:
• The data publisher
• NetMotion Republication Services
• Web Services API
• Unattended authentication mode
• Mobility Client API
• Mobility Event Viewer (on the Mobility Client)
• Mobility Network Access Control Module
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 9 of 49
2 CONFORMANCE CLAIMS
2.1 COMMON CRITERIA CONFORMANCE CLAIM
This Security Target claims to be conformant to Version 3.1 of Common Criteria
for Information Technology Security Evaluation according to:
• Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model; CCMB-2017-04-001, Version 3.1,
Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components; CCMB-2017-04-002, Version 3.1,
Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components CCMB-2017-04-003, Version 3.1,
Revision 5, April 2017
As follows:
• CC Part 2 conformant
• CC Part 3 conformant
The Common Methodology for Information Technology Security Evaluation,
Version 3.1, Revision 5, April 2017 has been taken into account.
2.2 PROTECTION PROFILE CONFORMANCE
CLAIM
This ST does not claim conformance of the TOE with any Protection Profile (PP).
2.3 PACKAGE CLAIM
This Security Target claims conformance to Evaluation Assurance Level 4
augmented with ALC_FLR.2 Flaw Reporting Procedures.
2.4 CONFORMANCE RATIONALE
This ST does not claim conformance of the TOE with any PP, therefore a
conformance rationale is not applicable.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 10 of 49
3 SECURITY PROBLEM DEFINITION
3.1 THREATS
Table 5 lists the threats addressed by the TOE. The threat agents are considered
to be unauthorized users with public knowledge of how the TOE operates, and
who possess the skills and resources to alter TOE configuration settings, or
parameters, or both. The threat agents do not have physical access to the TOE.
Mitigation to the threats is through the objectives identified in Section 4.1 -
Security Objectives for the TOE.
Threat Description
T.ACCESS An unauthorized individual on an external network may access and
exploit protected application data resources on an internal network.
T.NOAUTH An unauthorized individual may gain access to the TOE security
management functions and use this to allow unauthorized access to
application data protected by the TOE.
T.SENSDATA An unauthorized individual may be able to view or alter sensitive
application data passed between a client and a server.
T.UNAUTH An unauthorized user may gain access to the TOE and exploit system
privileges to gain access to TOE security functions and application
data.
Table 5 – Threats
Application data refers to the data that passes between the end user and the
server when the end user accesses the application remotely. The application
may be any client/server application written for an IP network. Application data
includes, but is not limited to, documents, spreadsheets, images, and XML data.
Application data is considered to be at risk when it is transmitted on an external
public network.
3.2 ORGANIZATIONAL SECURITY POLICIES
There are no Organizational Security Policies applicable to this TOE.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 11 of 49
3.3 ASSUMPTIONS
The assumptions required to ensure the security of the TOE are listed in Table 6.
Assumption Description
A.AUTH The operational environment provides authentication services to
the TOE.
A.CERTIFICATE A PKI is available to issue certificates to users and servers. Root
trust exists for the certificate chain.
A.INTERNAL The internal network and its assets are protected from
unauthorized access. A firewall must be in place to ensure that
only authorized connections from Mobility Clients to the Mobility
Server are permitted.
A.MANAGE A management console computer is available on the internal
protected network for the purposes of managing the TOE.
Administrators will access the Mobility Console only from a
management console computer on the internal network.
A.NOEVIL Authorized administrators are non-hostile and follow all
administrative guidance.
A.OS The services, including cryptographic services, provided by the
underlying operating system work correctly, and the operating
system does not introduce any negative side effects to the TSF.
A.PHYSICAL The server resources of the TOE will be located within controlled
access facilities, which will prevent unauthorized physical access.
A.SECCOM The communications between the TOE’s Mobility Server and the
authentication services, and between the TOE’s Mobility Server and
the management console computer are secured on an internal
network.
Table 6 – Assumptions
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 12 of 49
4 SECURITY OBJECTIVES
The purpose of the security objectives is to address the security concerns and to
show which security concerns are addressed by the TOE, and which are
addressed by the environment. Threats may be addressed by the TOE or the
security environment or both. Therefore, the CC identifies two categories of
security objectives:
• Security objectives for the TOE
• Security objectives for the environment
4.1 SECURITY OBJECTIVES FOR THE TOE
This section identifies and describes the security objectives that are to be
addressed by the TOE.
Security Objective Description
O.ACCESS The TOE must regulate the flow of information from users on
an external network to resources on an internal network, and
must ensure that rules for granting access are enforced.
O.ACCOUNT Users must be accountable for their use of the TOE and
authorized administrators must be accountable for their use of
TOE security management functions.
O.AUDIT The TOE must record security relevant events, the date and
time the events occurred, and provide a means to read this
information.
O.ENCRYPT The TOE must protect the confidentiality and integrity of
information that flows between distributed TOE components.
O.IDENTIFY The TOE must ensure that users are identified and
authenticated using an approved authentication mechanism
prior to allowing access to TOE functions and data.
O.SECFUN The TOE must provide functionality that enables authorized
administrators authenticated in the operational environment
to manage the security functions of the TOE, and must ensure
that only authorized administrators are able to access this
functionality.
Table 7 – Security Objectives for the TOE
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 13 of 49
4.2 SECURITY OBJECTIVES FOR THE
OPERATIONAL ENVIRONMENT
This section identifies and describes the security objectives that are to be
addressed by the IT environment or by non-technical or procedural means.
Security Objective Description
OE.ADMIN Authorized administrators are carefully screened during the
selection process. All selected administrators are trained to
appropriately install, configure, and maintain the TOE in its
evaluated configuration according to the TOE guidance
documentation.
OE.CONSOLEOS The operating system on the management console computer
that supports access to the Mobility Console will provide user
authentication services.
OE.IDENTAUTH The operational environment provides authentication services
based on standard PEAP MS-CHAPv2 and EAP-TLS protocols,
supported by trusted certificates.
OE.INTNETWORK The operational environment will protect the internal network
and its assets from access by unauthorized external entities
through use of a firewall.
OE.PHYSICAL Those responsible for the TOE must ensure that those parts of
the TOE critical to the enforcement of security are protected
from any physical attack.
OE.SECCOM The operational environment will protect the communications
between the TOE’s Mobility server and the authentication
servers, and between the TOE’s Mobility Console on the
Mobility server and the management console computer on a
protected internal network.
OE.SUPPORT The underlying operating system provides the correct services
(including cryptographic services) to the TOE without
introducing negative side effects on the TSF.
Table 8 – Security Objectives for the Operational Environment
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 14 of 49
4.3 SECURITY OBJECTIVES RATIONALE
The following table maps the security objectives to the assumptions, threats,
and organizational policies identified for the TOE.
T.ACCESS
T.NOAUTH
T.SENSDATA
T.UNAUTH
A.ATUH
A.CERTIFICATE
A.INTNETWORK
A.MANAGE
A.NOEVIL
A.OS
A.PHYSICAL
A.SECCOM
O.ACCESS X
O.ACCOUNT X
O.AUDIT X
O.ENCRYPT X
O.IDENTIFY X X X
O.SECFUN X
OE.ADMIN X
OE.CONSOLEOS X
OE.IDENTAUTH X X X
OE.INTNETWORK X
OE.PHYSICAL X
OE.SECCOM X X
OE.SUPPORT X
Table 9 – Mapping Between Objectives, Threats, OSPs, and Assumptions
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 15 of 49
Security Objectives Rationale Related to
Threats
The security objectives rationale related to threats traces the security objectives
for the TOE and the Operational Environment back to the threats addressed by
the TOE.
Threat:
T.ACCESS
An unauthorized individual on an external network may access and
exploit protected application data resources on an internal network.
Objectives: O.ACCESS The TOE must regulate the flow of information from
users on an external network to resources on an
internal network, and must ensure that rules for
granting access are enforced.
O.IDENTIFY The TOE must ensure that users are identified and
authenticated using an approved authentication
mechanism prior to allowing access to TOE functions
and data.
Rationale: O.ACCESS counters this threat by ensuring that the rules for access to
protected resources are enforced.
O.IDENTIFY ensures that users are identified and authenticated before
gaining access to the TOE, thereby mitigating the risk of unauthorized
access to protected resources.
Threat:
T.NOAUTH
An unauthorized individual may gain access to the TOE security
management functions and use this to allow unauthorized access to
application data protected by the TOE.
Objectives: O.ACCOUNT Users must be accountable for their use of the TOE
and authorized administrators must be accountable
for their use of TOE security management
functions.
O.AUDIT The TOE must record security relevant events, the
date and time the events occurred, and provide a
means to read this information.
O.IDENTIFY The TOE must ensure that users are identified and
authenticated using an approved authentication
mechanism prior to allowing access to TOE
functions and data.
OE.IDENTAUTH The operational environment provides
authentication services based on standard PEAP
MS-CHAPv2 and EAP-TLS protocols, supported by
trusted certificates.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 16 of 49
Rationale: O.ACCOUNT ensures that users are held accountable for their use of
the TOE.
O.AUDIT ensures that the audit records supporting accountability are
recorded, time stamped, and may be read using the TOE.
O.IDENTIFY ensures that users are identified and authenticated prior
to being allowed access to TOE functions.
OE.IDENTAUTH ensures that the operational environment identifies
and authenticates users, and provides this information to the TOE in
support of the TOE objectives.
Threat:
T.SENSDATA
An unauthorized individual may be able to view or alter sensitive
application data passed between a client and a server.
Objectives: O.ENCRYPT The TOE must protect the confidentiality and integrity
of information that flows between distributed TOE
components.
Rationale: O.ENCRYPT ensures that data that flows between components may
not be read or altered by an unauthorized individual.
Threat:
T.UNAUTH
An unauthorized user may gain access to the TOE and exploit system
privileges to gain access to TOE security functions and application
data.
Objectives: O.IDENTIFY The TOE must ensure that users are identified and
authenticated using an approved authentication
mechanism prior to allowing access to TOE
functions and data.
O.SECFUN The TOE must provide functionality that enables
authorized administrators authenticated in the
operational environment to manage the security
functions of the TOE, and must ensure that only
authorized administrators are able to access this
functionality.
OE.CONSOLEOS The operating system on the management console
computer that supports access to the Mobility
Console will provide user authentication services.
Rationale: O.IDENTIFY ensures that users are identified and authenticated using
an approved authentication mechanism before gaining access, thereby
mitigating the risk of bypass of TOE security.
O.SECFUN ensures that only authorized administrators are able to
access TOE security management functionality.
OE.CONSOLEOS ensures that the operational environment provides
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 17 of 49
authentication services in support of Mobility Console access.
Security Objectives Rationale Related to
Assumptions
The security objectives rationale related to assumptions traces the security
objectives for the operational environment back to the assumptions for the
TOE’s operational environment.
Assumption:
A.AUTH
The operational environment provides authentication services to the
TOE.
Objectives: OE.IDENTAUTH The operational environment provides
authentication services based on standard PEAP
MS-CHAPv2 and EAP-TLS protocols, supported by
trusted certificates.
Rationale: OE.IDENTAUTH supports this assumption by ensuring that the
operational environment provides authentication services.
Assumption:
A.CERTIFICATE
A PKI is available to issue certificates to users and servers. Root
trust exists for the certificated chain.
Objectives: OE.IDENTAUTH The operational environment provides
authentication services based on standard PEAP
MS-CHAPv2 and EAP-TLS protocols, supported
by trusted certificates.
Rationale: OE.IDENTAUTH supports this assumption by ensuring that trusted
certificates are available to support authentication.
Assumption:
A.INTERNAL
The internal network and its assets are protected from unauthorized
access. A firewall must be in place to ensure that only authorized
connections from Mobility Clients to the Mobility Server are
permitted.
Objectives: OE.INTNETWORK The operational environment will protect the
internal network and its assets from access by
unauthorized external entities through use of a
firewall.
Rationale: OE.INTNETWORK supports this assumption by ensuring that the
operational environment includes a firewall to protect the internal
network and its assets against unauthorized access.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 18 of 49
Assumption:
A.MANAGE
A management console computer is available on the internal
protected network for the purposes of managing the TOE.
Administrators will access the Mobility Console only from a
management console computer on the internal network.
Objectives: OE.SECCOM The operational environment will protect the
communications between the TOE’s Mobility server
and the authentication servers, and between the
TOE’s Mobility Console on the Mobility server and the
management console computer on a protected
internal network.
Rationale: OE.SECCOM supports this assumption by ensuring that
communications between the TOE and administrators using the
management console computer and between the TOE and the
authentication server are protected.
Assumption:
A.NOEVIL
Authorized administrators are non-hostile and follow all
administrative guidance.
Objectives: OE.ADMIN Authorized administrators are carefully screened during
the selection process. All selected administrators are
trained to appropriately install, configure, and maintain
the TOE in its evaluated configuration according to the
TOE guidance documentation.
Rationale: OE.ADMIN upholds the assumption A.NOEVIL by providing carefully
selected administrators with the training required to be able to follow
the administrative guidance.
Assumption:
A.OS
The services, including cryptographic services, provided by the
underlying operating system work correctly, and the operating
system does not introduce any negative side effects to the TSF.
Objectives: OE.SUPPORT The underlying operating system provides the correct
services (including cryptographic services) to the TOE
without introducing negative side effects on the TSF.
Rationale: OE.SUPPORT upholds the assumption A.OS by providing reliable
services, including cryptographic services, to the TOE without the
introduction of negative side effects.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 19 of 49
Assumption:
A.PHYSICAL
The server resources of the TOE will be located within controlled
access facilities, which will prevent unauthorized physical access.
Objectives: OE.PHYSICAL Those responsible for the TOE must ensure that
those parts of the TOE critical to the enforcement
of security are protected from any physical attack.
Rationale: OE.PHYSICAL ensures that TOE server resources are protected
from physical attack, thereby supporting the assumption of
protection of the resources.
Assumption:
A.SECCOM
The communications between the TOE’s Mobility Server and the
authentication services, and between the TOE’s Mobility Server and
the management console computer are secured on an internal
network.
Objectives: OE.SECCOM The operational environment will protect the
communications between the TOE’s Mobility server
and the authentication servers, and between the
TOE’s Mobility Console on the Mobility server and the
management console computer on a protected
internal network.
Rationale: OE.SECCOM ensures that communications between the TOE (Mobility
server) and the authentication servers, and between the TOE
(Mobility Console on the Mobility server) and the management
console computer are appropriately protected, as required by the
assumption A.SECCOM.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 20 of 49
5 EXTENDED COMPONENTS DEFINITION
5.1 SECURITY FUNCTIONAL REQUIREMENTS
This ST does not include extended Security Functional Requirements.
5.2 SECURITY ASSURANCE REQUIREMENTS
This ST does not include extended Security Assurance Requirements.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 21 of 49
6 SECURITY REQUIREMENTS
Section 6 provides security functional and assurance requirements that must be
satisfied by a compliant TOE. These requirements consist of functional
components from Part 2 of the CC and an Evaluation Assurance Level (EAL) that
contains assurance components from Part 3 of the CC.
6.1 CONVENTIONS
The CC permits four types of operations to be performed on functional
requirements: selection, assignment, refinement, and iteration. These
operations, when performed on requirements that derive from CC Part 2, are
identified in this ST in the following manner:
• Selection: Indicated by surrounding brackets, e.g., [selected item].
• Assignment: Indicated by surrounding brackets and italics, e.g., [assigned
item].
• Refinement: Refined components are identified by using bold for
additional information, or strikeout for deleted text.
• Iteration: Indicated by assigning a number in parenthesis to the end of
the functional component identifier as well as by modifying the functional
component title to distinguish between iterations, e.g., ‘FDP_ACC.1(1),
Subset access control (administrators)’ and ‘FDP_ACC.1(2) Subset access
control (devices)’.
6.2 SECURITY FUNCTIONAL REQUIREMENTS
The security functional requirements for this ST consist of the following
components from Part 2 of the CC, summarized in Table 10.
Class Identifier Name
Security Audit (FAU) FAU_GEN.1 Audit data generation
FAU_SAR.1 Audit review
Cryptographic Support
(FCS)
FCS_CKM.1(1) Cryptographic key generation (AES)
FCS_CKM.1(2) Cryptographic key generation (RSA)
FCS_CKM.1(3) Cryptographic key generation (ECDH)
FCS_CKM.1(4) Cryptographic key generation (DH)
FCS_CKM.4 Cryptographic key Destruction
FCS_COP.1(1) Cryptographic operation (Windows)
FCS_COP.1(2) Cryptographic operation (iOS and macOS)
FCS_COP.1(3) Cryptographic operation (Android)
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 22 of 49
Class Identifier Name
User Data Protection
(FDP)
FDP_IFC.1 Subset information flow control
FDP_IFF.1 Simple security attributes
FDP_ITT.1 Basic internal transfer protection
Identification and
Authentication (FIA)
FIA_UAU.2 User authentication before any action
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.2 User identification before any action
Security Management
(FMT)
FMT_MTD.1 Management of TSF data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
Protection of the TSF
(FPT)
FPT_STM.1 Reliable time stamps
Table 10 – Summary of Security Functional Requirements
Security Audit (FAU)
6.2.1.1 FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1 The TSF 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) [establishment of an encrypted session, client connection events,
administrator logon to the Mobility Console].
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions
of the functional components included in the PP/ST, [device name].
6.2.1.2 FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide [Administrators] with the capability to read [all
audit information] from the audit records.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 23 of 49
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the
user to interpret the information.
Cryptographic Support (FCS)
6.2.2.1 FCS_CKM.1(1) Cryptographic key generation (AES)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution,
or FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(1) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [Counter mode
Deterministic Random Bit Generator (CTR-DRBG)] and specified
cryptographic key sizes [128 or 256 bit] that meet the following: [NIST
Special Publication 800-90A].
6.2.2.2 FCS_CKM.1(2) Cryptographic key generation (RSA)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution,
or FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(2) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [Deterministic
Random Bit Generator (DRBG)] and specified cryptographic key sizes
[2048 bit] that meet the following: [NIST Special Publication 800-90A].
6.2.2.3 FCS_CKM.1(3) Cryptographic key generation (ECDH)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution,
or FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(3) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [Random Bit
Generator (RBG)] and specified cryptographic key sizes [p-256, p-384
and p-521] that meet the following: [FIPS 186-4 as referenced in NIST
Special Publication 800-56A].
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 24 of 49
6.2.2.4 FCS_CKM.1(4) Cryptographic key generation (DH)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution,
or FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1(4) The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [Random Bit
Generator (RBG)] and specified cryptographic key sizes [112, 128 bits]
that meet the following: [FIPS 186-4 as referenced in NIST Special
Publication 800-56A].
6.2.2.5 FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [zeroization] that meets the
following: [FIPS 140-2 zeroization standards].
6.2.2.6 FCS_COP.1(1) Cryptographic operation (Windows)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation] FCS_CKM.4 Cryptographic
key destruction
FCS_COP.1.1(1) The TSF shall perform [the cryptographic operations in Table 11] in
accordance with a specified cryptographic algorithm [in Table 11] and
cryptographic key sizes [in Table 11] that meet the following: [list of
standards in Table 11].
Operation Algorithm Key Size
(bits)
CAVP Certificate Standard
Encryption and
Decryption
AES CBC
AES GCM
128, 256 C211
C1363
FIPS 197
SP 800-38A
SP 800-38D
Key Agreement in
support of VPN
EC DH p-256, p-384,
p-521
C211
C1363
NIST SP800-56A
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 25 of 49
Operation Algorithm Key Size
(bits)
CAVP Certificate Standard
Secure Hash SHA-256
SHA-384
Not applicable C211
C1363
FIPS 180-4
Keyed-Hash
Message
Authentication
Code (HMAC)
HMAC 256, 384 C211
C1363
FIPS 198-1
Asymmetric
cryptography
RSA
(RSASSA-
PKCS1_V1_5)
2048 C211
C1363
PKCS#1 v1.5
FIPS 186-4
Table 11 - Cryptographic Operations (Windows)
Application note: FCS_COP.1(1) applies to TOE components installed on Windows
Server 2019 1809 and Windows 10 64-bit version using the Microsoft Kernel Mode
Cryptographic Primitives Library (CNG.SYS) Software Version: 10.0.17763. AES GCM is
only used in conjunction with user authentication.
6.2.2.7 FCS_COP.1(2) Cryptographic operation (iOS and macOS)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation] FCS_CKM.4 Cryptographic
key destruction
FCS_COP.1.1(2) The TSF shall perform [the cryptographic operations in Table 12] in
accordance with a specified cryptographic algorithm [in Table 12] and
cryptographic key sizes [in Table 12] that meet the following: [list of
standards in Table 12].
Operation Algorithm Key Size
(bits)
CAVP Certificate Standard
Encryption and
Decryption
AES CBC
AES GCM
128, 256 For iOS: A6, A7, A8, A10,
A11, A13, A14, A15
For macOS: A7, A8, A10,
A11, A13, A15, A19, A20,
A21, A23, A24, A25, A28,
A31
FIPS 197
SP 800-38A
SP 800-38D
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 26 of 49
Operation Algorithm Key Size
(bits)
CAVP Certificate Standard
Key Agreement
in support of
VPN
EC DH P-256, P-
384
For iOS: A8
For macOS: A8
NIST SP800-56A
Secure Hash SHA-256 Not
applicable
For iOS: A8, A9, A12,
A17, A18
For macOS: A8, A22,
A26, A27, A29, A30, A32,
A33, A34
FIPS 180-4
Keyed-Hash
Message
Authentication
Code (HMAC)
HMAC 384 For iOS: A8, A9, A16,
A18
For macOS: A8, A22,
A26, A27, A29, A30, A32,
A33, A34
FIPS 198-1
Asymmetric
cryptography
RSA
(RSASSA-
PKCS1_V1_5)
2048 For iOS: A8, A9, A18
For macOS: A8, A22,
A26, A27, A30, A33, A34
PKCS#1 v1.5
FIPS 186-4
Table 12 - Cryptographic Operations (iOS and macOS)
Application note: FCS_COP.1(2) applies to TOE components installed on iOS 13.6.1, or
Apple macOS 10.15. AES GCM is only used in conjunction with user authentication.
6.2.2.8 FCS_COP.1(3) Cryptographic operation (Android)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation] FCS_CKM.4 Cryptographic
key destruction
FCS_COP.1.1(3) The TSF shall perform [the cryptographic operations in Table 13] in
accordance with a specified cryptographic algorithm [in Table 13] and
cryptographic key sizes [in Table 13] that meet the following: [list of
standards in Table 13].
Operation Algorithm Key Size
(bits)
CAVP
Certificate
Standard
Encryption and
Decryption
AES CBC
AES GCM
128, 256 A1868 FIPS 197
SP 800-38A
SP 800-38D
Key Agreement in
support of VPN
EC DH p-384 A1868 NIST SP800-56A
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 27 of 49
Operation Algorithm Key Size
(bits)
CAVP
Certificate
Standard
Secure Hash SHA-256
SHA-384
Not applicable A1868 FIPS 180-4
Keyed-Hash
Message
Authentication
Code (HMAC)
HMAC 256, 384 A1868 FIPS 198-1
Asymmetric
cryptography
RSA
(RSASSA-
PKCS1_V1_5)
2048 A1868 PKCS#1 v1.5
FIPS 186-4
Table 13 - Cryptographic Operations (Android)
Application note: FCS_COP.1(3) applies to TOE components installed on Android 11
using the OpenSSL FIPS Object Module SE, Software Version 2.0.12. AES GCM is only
used in conjunction with user authentication.
User Data Protection (FDP)
6.2.3.1 FDP_IFC.1 Subset information flow control
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1 The TSF shall enforce the [Secure Information Flow Control SFP] on
[Subjects: Mobility client users
Information: application data3
Operations: send, receive].
6.2.3.2 FDP_IFF.1 Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1 The TSF shall enforce the [Secure Information F low C ontrol SFP]
based on the following types of subject and information security
attributes:
[Subjects: Mobility client users
Subject attributes: identity, authentication status
Information: application data
Information attributes: none].
3
Application data refers to the data that passes between the end user and the server
when the end user accesses the application remotely.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 28 of 49
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following
rules hold: [The mobility client user is successfully identified and
authenticated, and is an authorized user in the NetMotion Mobility
implementation].
FDP_IFF.1.3 The TSF shall enforce the [no additional information flow control SFP
rules].
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the
following rules: [no additional rules].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following
rules: [no additional rules].
6.2.3.3 FDP_ITT.1 Basic internal transfer protection
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ITT.1.1 The TSF shall enforce the [Secure Information Flow Control SFP] to
prevent the [disclosure, modification] of user data when it is transmitted
between physically-separated parts of the TOE.
Application Note: ‘User data’ refers to the application data described in FDP_IFC.1 and
FDP_IFF.1.
Identification and Authentication (FIA)
6.2.4.1 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
6.2.4.2 FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide [PEAP MS-CHAPv2, EAP-TLS] to support user
authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[the authentication mechanism utilized for that particular
implementation].
6.2.4.3 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies.
FIA_UID.2.1 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 29 of 49
Security Management (FMT)
6.2.5.1 FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1 The TSF shall restrict the ability to [perform the functions listed in Table
14] the [data listed in Table 14] to [Administrators].
Data Allowed Actions
Secure Information Flow Control Data Change_default, query, modify, delete
Audit Logs Query, clear
User Account Attributes Query, modify, delete
Table 14 - Management of TSF Data
6.2.5.2 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
[a. Create, delete, modify, and view information flow security policy data
that permits user access;
b. Review the audit logs; and
c. Query, modify, and delete user information].
6.2.5.3 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [Administrator and Mobility Client
User].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Protection of the TSF (FPT)
6.2.6.1 FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 30 of 49
6.3 SECURITY ASSURANCE REQUIREMENTS
The assurance requirements are summarized in the following table.
Assurance Class
Assurance Components
Identifier Name
Development (ADV) ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
Guidance Documents
(AGD)
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Life-Cycle Support
(ALC)
ALC_CMC.4
Production support, acceptance
procedures and automation
ALC_CMS.4 Problem tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_FLR.2 Flaw reporting procedures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
Security Target
Evaluation (ASE)
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
Tests (ATE) ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 31 of 49
Assurance Class
Assurance Components
Identifier Name
Vulnerability
Assessment (AVA)
AVA_VAN.3 Focused vulnerability analysis
Table 15 – Security Assurance Requirements
6.4 SECURITY REQUIREMENTS RATIONALE
Security Functional Requirements Rationale
The following table provides a mapping between the SFRs and Security
Objectives.
O.ACCESS
O.ACCOUNT
O.AUDIT
O.ENCRYPT
O.IDENTIFY
O.SECFUN
FAU_GEN.1 X X
FAU_SAR.1 X
FCS_CKM.1(1) X
FCS_CKM.1(2) X
FCS_CKM.1(3) X
FCS_CKM.1(4) X
FCS_CKM.4 X
FCS_COP.1(1) X
FCS_COP.1(2) X
FCS_COP.1(3) X
FDP_IFC.1 X
FDP_IFF.1 X
FDP_ITT.1 X
FIA_UAU.2 X X X
FIA_UAU.5 X
FIA_UID.2 X X X X
FMT_MTD.1 X
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 32 of 49
O.ACCESS
O.ACCOUNT
O.AUDIT
O.ENCRYPT
O.IDENTIFY
O.SECFUN
FMT_SMF.1 X
FMT_SMR.1 X
FPT_STM.1 X X
Table 16 – Mapping of SFRs to Security Objectives
SFR Rationale Related to Security Objectives
The following rationale traces each SFR back to the Security Objectives for the
TOE.
Objective:
O.ACCESS
The TOE must regulate the flow of information from users on an
external network to resources on an internal network, and must
ensure that rules for granting access are enforced.
Security
Functional
Requirements:
FDP_IFC.1 Subset information flow control
FDP_IFF.1 Simple security attributes
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
Rationale: FDP_IFC.1 meets this objective by identifying the Secure
Information Flow Control SFP between TOE users on an external
network, to the application data resources on an internal network
to which the TOE controls access.
FDP_IFF.1 builds on FDP_IFC.1 by identifying the user attributes
and the secure information flow control rules. It meets the
O.ACCESS objective by enforcing the rules for the information flow
between TOE users on an external network, to the TOE controlled
resources on an internal network.
FIA_UAU.2 supports this objective by ensuring that the user
information required to enforce the Secure Information Flow
Control SFP is available.
FIA_UID.2 supports this objective by ensuring that the user
information required to enforce the Secure Information Flow
Control SFP is available.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 33 of 49
Objective:
O.ACCOUNT
Users must be accountable for their use of the TOE and authorized
administrators must be accountable for their use of TOE security
management functions.
Security
Functional
Requirements:
FAU_GEN.1 Audit data generation
FIA_UID.2 User identification before any action
FPT_STM.1 Reliable time stamps
Rationale: FAU_GEN.1 meets objective by ensuring that audit records are
produced with sufficient detail to hold users accountable for their
actions related to the use of the TOE, including use of the TOE
security management functions.
FIA_UID.2 supports this objective by identifying users so they may
be held accountable for their use of the TOE.
FPT_STM.1 supports this objective by ensuring that audit records
are produced with a reliable time stamp to hold users accountable
for their actions related to the use of the TOE, including the use of
the TOE security management functions.
Objective:
O.AUDIT
The TOE must record security relevant events, the date and time
the events occurred, and provide a means to read this information.
Security
Functional
Requirements:
FAU_GEN.1 Audit data generation
FAU_SAR.1 Audit review
FPT_STM.1 Reliable time stamps
Rationale: FAU_GEN.1 meets this objective by ensuring that security relevant
events are recorded.
FAU_SAR.1 meets this objective by providing a means to read the
records for security relevant events.
FPT_STM.1 supports this objective by providing a time stamp for all
auditable events.
Objective:
O.ENCRYPT
The TOE must protect the confidentiality and integrity of
information that flows between distributed TOE components.
Security
Functional
Requirements:
FCS_CKM.1(1) Cryptographic key generation (AES)
FCS_CKM.1(2) Cryptographic key generation (RSA)
FCS_CKM.1(3) Cryptographic key generation (ECDH)
FCS_CKM.1(4) Cryptographic key generation (DH)
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 34 of 49
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1(1) Cryptographic operation (Windows)
FCS_COP.1(2) Cryptographic operation (iOS and macOS)
FCS_COP.1(3) Cryptographic operation (Android)
FDP_ITT.1 Basic internal transfer protection
Rationale: The FCS_CKM.1 claims support this objective by ensuring that
cryptographic keys are appropriately generated to support the use
of the encryption that provides confidentiality and integrity of the
information that flows between distributed TOE components, and
between the TOE and authentication services in the operational
environment.
FCS_CKM.4 supports this objective by ensuring that encryption
keys are properly destroyed, mitigating the risk of improper use,
and thereby supporting the confidentiality and integrity of the
information that flows between distributed TOE components, and
between the TOE and authentication services in the operational
environment.
The FCS_COP.1 claims support this objective by providing the
encryption services that ensure the confidentiality and integrity of
the information that flows between distributed TOE components,
and between the TOE and authentication services in the operational
environment.
FDP_ITT.1 supports this objective by ensuring that the
confidentiality and integrity of data is preserved as it passes
between parts of the TOE.
Objective:
O.IDENTIFY
The TOE must ensure that users are identified and authenticated
using an approved authentication mechanism prior to allowing
access to TOE functions and data.
Security
Functional
Requirements:
FIA_UAU.2 User authentication before any action
FIA_UAU.5 Multiple authentication mechanisms
FIA_UID.2 User identification before any action
Rationale: FIA_UAU.2 meets this objective by ensuring that users are
authenticated prior to being allowed access to TOE functions and
data.
FIA_UAU.5 meets this objective by ensuring that users are
authenticated using an approved authentication mechanism before
being granted access to TOE functions or data.
FIA_UID.2 meets this objective by ensuring that users are
identified prior to being allowed access to TOE functions and data.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 35 of 49
Objective:
O.SECFUN
The TOE must provide functionality that enables authorized
administrators authenticated in the operational environment to
manage the security functions of the TOE, and must ensure that
only authorized administrators are able to access this functionality.
Security
Functional
Requirements:
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
FMT_MTD.1 Management of TSF data
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Rationale: FIA_UAU.2 meets this objective by ensuring that only authorized
administrators may access security management functionality.
FIA_UID.2 meets this objective by ensuring that only authorized
administrators may access security management functionality.
FMT_MTD.1 meets this objective by ensuring that only authorized
administrators have access to security management functions.
FMT_SMF.1 meets this objective by providing the functionality that
enables authorized administrators to manage the security functions
of the TOE.
FMT_SMR.1 meets this objective by providing the roles that are
used to ensure that only authorized administrators are able to
access security management functions.
Dependency Rationale
Table 17 identifies the Security Functional Requirements from Part 2 of the CC
and their associated dependencies. It also indicates whether the ST explicitly
addresses each dependency.
SFR Dependency
Dependency
Satisfied
Rationale
FAU_GEN.1 FPT_STM.1 
FAU_SAR.1 FAU_GEN.1 
FCS_CKM.1(1) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1(1),
FCS_COP.1(2), and
FCS_COP.1(3)
FCS_CKM.4 
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 36 of 49
SFR Dependency
Dependency
Satisfied
Rationale
FCS_CKM.1(2) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1(1),
FCS_COP.1(2), and
FCS_COP.1(3)
FCS_CKM.4 
FCS_CKM.1(3) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1(1),
FCS_COP.1(2), and
FCS_COP.1(3)
FCS_CKM.4 
FCS_CKM.1(4) FCS_CKM.2 or
FCS_COP.1
 Satisfied by FCS_COP.1(1),
FCS_COP.1(2), and
FCS_COP.1(3)
FCS_CKM.4 
FCS_CKM.4 FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
 Satisfied by FCS_CKM.1(1),
FCS_CKM.1(2),
FCS_CKM.1(3), and
FCS_CKM.1(4)
FCS_COP.1(1) FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
 Satisfied by FCS_CKM.1(1),
FCS_CKM.1(2), and
FCS_CKM.1(3)
FCS_CKM.4 
FCS_COP.1(2) FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
 Satisfied by FCS_CKM.1(1),
FCS_CKM.1(2), and
FCS_CKM.1(3)
FCS_CKM.4 
FCS_COP.1(3) FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
 Satisfied by FCS_CKM.1(1),
FCS_CKM.1(2), and
FCS_CKM.1(3)
FCS_CKM.4 
FDP_IFC.1 FDP_IFF.1 
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 37 of 49
SFR Dependency
Dependency
Satisfied
Rationale
FDP_IFF.1 FDP_IFC.1 
FMT_MSA.3  FMT_MSA.3 is not included
because there are no
configurable security
attributes associated with the
Secure Information Flow
Control SFP, and therefore, no
default values provided by the
TOE. The security attributes
for the Secure Information
Flow Control SFP are Mobility
client user identity, which is
provided by the user, and
authentication status, which is
provided by the authentication
server.
FDP_ITT.1 FDP_ACC.1 or
FDP_IFC.1
 Satisfied by FDP_IFC.1
FIA_UAU.2 FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FIA_UAU.5 None N/A
FIA_UID.2 None N/A
FMT_MTD.1 FMT_SMR.1 
FMT_SMF.1 
FMT_SMF.1 None N/A
FMT_SMR.1 FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FPT_STM.1 None N/A
Table 17 – Functional Requirement Dependencies
Security Assurance Requirements Rationale
The TOE assurance requirements for this ST consist of the requirements
corresponding to the EAL 4 level of assurance, as defined in the CC Part 3,
augmented by the inclusion of Flaw reporting procedures (ALC_FLR.2). EAL 4
was chosen because it is based upon good commercial development practices
with thorough functional testing. EAL 4 provides customers with a moderate
level of independently assured security in a conventional commercial TOE. The
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 38 of 49
threat of malicious attacks is not greater than low, the security environment
provides physical protection, and the TOE itself offers a very limited, purpose‐
built interface. The developer is claiming the ALC_FLR.2 augmentation since
there are a number of areas where current practices and procedures exceed the
minimum requirements for EAL 4.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 39 of 49
7 TOE SUMMARY SPECIFICATION
This section provides a description of the security functions and assurance
measures of the TOE that meet the TOE security requirements.
7.1 SECURITY AUDIT
The activity log records connection events. The log file is written in a comma-
delimited format (CSV). The activity log records the following information.
Event Event Description Audit Record
Connect The Mobility client connects
to the Mobility server
• Date and time the connection was
made
• Device Name
• User Name
• Virtual IP assigned by the Mobility
server
• Point of Presence (PoP) address of the
Mobility client device at its current
location
• The number of bytes sent and
received during the connection period
Disconnect The Mobility client was
disconnected from the
Mobility server.
• Date/Time
• Device Name
• User Name
• Reason for disconnect
Unreachable The Mobility server could not
reach a client device that
was connected to the server.
An unreachable state occurs
when the following occurs:
• A client’s network
connection fails
• The device leaves the
area network and no
other network is available
• The device goes into
standby or hibernation.
• The server receives no
confirmation from the
client device that it must
disconnect from the
server.
• Date and time the client was
unavailable
• Device Name
• User Name
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 40 of 49
Event Event Description Audit Record
Reachable The Mobility client that was
unreachable has
reconnected.
• Date and time when the connection
was re-established
• Device Name
• User Name
Roaming A Mobility client moved to a
different network or the
network connection
changed.
• Date and time of when the connection
change was made
• Device Name
• User Name
• Virtual IP assigned by the Mobility
server
• PoP address of the Mobility client
device at its current location
• The number of bytes sent and
received during the connection period
Table 18 - Activity Log Information
The activity log page displays the connection events, and automatically
refreshes the display as it records new events.
The event log collects information on events that occur on the server, including:
• All decisions on requests for information flow
• When an encrypted session is established
• Startup and shutdown of audit function (as indicated by startup/shutdown
of TOE)
• Administrator logon
The event log is a binary file updated by Mobility components. By default,
Mobility events are logged to nmevent.nel in the Windows folder. They may be
viewed using the Mobility Console. The event log records the following
information.
Event Description
Type The message types include Trace, Debug, Information, Warning and
Error. An administrator may specify which event types are logged.
Date/Time This is the date and time of the event.
Source This is the module that produced the event.
Data This is the event log message.
Table 19 - Event Log Information
TOE Security Functional Requirements addressed: FAU_GEN.1, FAU_SAR.1.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 41 of 49
7.2 CRYPTOGRAPHIC SUPPORT
Mobility encrypts data transmitted between the Mobility server and the Mobility
client using FIPS-validated cryptographic algorithms. The cryptographic
algorithms and corresponding Cryptographic Algorithm Validation Program
(CAVP) certificates are identified in Table 11 (Windows), Table 12 (iOS and
macOS) and Table 13 (Android).
The Microsoft and Apple cryptographic modules pre-exist in their respective
operating systems. Since no suitable cryptographic module exists in the Android
operating system, the OpenSSL FIPS Object Module software is delivered to the
device with the NetMotion client software.
For the Mobility Server, keys are created by the cryptographic module in the
Windows Server 2019 operating system, in accordance with the security policy.
Likewise, for Mobility Client on Windows, the keys are created by the
cryptographic module in the Windows 10 operating system, in accordance with
the security policies. Windows uses a NIST SP800-90A DRBG (CTR_DRBG) for
symmetric and asymmetric keys in the CNG.SYS library.
For Mobility Client on iOS, the keys are created by the cryptographic module in
the iOS operating system, in accordance with the security policy. iOS uses a
NIST SP800-90A DRBG (CTR_DRBG) for symmetric and asymmetric key
generation.
For Mobility Client on macOS, the keys are created by the cryptographic module
in the macOS operating system, in accordance with the security policy. MacOS
uses a NIST SP800-90A DRBG (CTR_DRBG) for symmetric and asymmetric key
generation.
For Mobility Client on Android, symmetric keys are generated using a Counter
Mode Deterministic Random Bit Generator (CTR_DRBG) (using AES) in the
OpenSSL library. This DRBG has been validated in accordance with NIST Special
Publication 800-90, Recommendation for Random Number generation Using
Deterministic Random Bit Generators. Asymmetric keys are generated in
accordance with FIPS 186-4.
Elliptic Curve Diffie-Hellman (ECDH) using NIST approved curves is used for key
agreement operations in support of the establishment of a VPN tunnel. Each
party generates an ephemeral key pair. Diffie-Hellman Key Agreement (DH) is
used by each of the mobile devices in support of PEAP MS-CHAPv2
authentication. DH is implemented in accordance with NIST SP-800-56A for
Finite Field Cryptography (FFC), and provides 112 or 128 bits of security
strength.
For all of the operating systems, the keys are zeroized by the cryptographic
module in accordance with FIPS 140-2 zeroization standards. Calls are made by
the Mobility component to the cryptographic module in support of all
cryptographic operations. All cryptographic operations are completed using CAVP
validated algorithms.
The Mobility server determines the algorithm used to encrypt client connections.
In the evaluated configuration, only FIPS 140-2 validated cryptographic modules
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 42 of 49
are permitted. The client cannot negotiate a lower encryption level. If a client
does not support the encryption method set on the server, it cannot connect and
posts a message in the client event log.
If a client accepts the requested encryption method, but then tries to establish
an unencrypted connection or a connection using a different encryption method,
the Mobility server disconnects the session and posts a warning in the server
event log.
Use of Cryptographic Primitives
The following table identifies the usage of the claimed cryptographic primitives.
Function Supporting Algorithms
PEAP MS-CHAPv2
Authentication
Diffie Hellman Key Agreement and ECDH P-384, P-256
RSA
AES CBC 128, 256; AES GCM 128, 256
SHA-256, SHA 384
EAP-TLS ECDH P-384, P-256
AES CBC 128, 256; AES GCM 128, 256
RSA
SHA-256, SHA-384
HMAC 256, HMAC 384
Encrypted Tunnel ECDH P-384, P-521
AES CBC 128, 256
SHA-256, SHA-384
HMAC 256, HMAC 384
Table 20 - Cryptographic Primitives Usage
The National Institute of Standards and Technology (NIST) curve P-256 is used
for authentication by Windows, iOS and macOS clients. P-521 is used to
establish the Mobility encrypted tunnel for the Windows client, and P-384 is used
by the iOS and macOS clients. The Android client uses P-384.
TOE Security Functional Requirements addressed: FCS_CKM.1(1),
FCS_CKM.1(2), FCS_CKM.1(3), FCS_CKM.1(4), FCS_CKM.4, FCS_COP.1(1),
FCS_COP.1(2), FCS_COP.1(3).
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 43 of 49
7.3 USER DATA PROTECTION
The TOE enforces the Secure Information Flow Control SFP between the Mobility
Server and the Mobility Client by means of end-user authentication. For the
purposes of the evaluation, the TOE uses a RADIUS (RFC 2865) based
authentication server and a standards compliant implementation of the PEAP
MS-CHAPv2 or EAP-TLS.
When the Mobility Server is configured to use RADIUS for authentication, it acts
as a Network Access Server (NAS) in the RADIUS security system.
Authentication is performed using a database that supports the PEAP MS-
CHAPv2 format, such as Microsoft Active Directory (AD) (PEAPv0, draft-
josefsson-pppext-eap-tls-eap-06).
Although standards compliance is claimed, modern RADIUS authenticators do
not enforce use of the mandatory ciphersuite in PEAP. Cisco RADIUS servers
disable RC4 by default and Microsoft allows use of RC4 to be disabled. In the
evaluated configuration, use of RC4 and MD5 must be disabled. However, it
should be noted that even without this configuration, Mobility will default to
PEAP authentication using a ciphersuite with RSA, AES 256 and SHA 384.
PEAP MS-CHAPv2 Authentication
Protected Extensible Authentication Protocol (PEAP) is used in the evaluated
configuration in support of user login. PEAP encapsulates the Extensible
Authentication Protocol (EAP) within an encrypted and authenticated Transport
Layer Security (TLS) tunnel. The inner authentication protocol is Microsoft’s
Challenge Handshake Authentication Protocol Version 2 (RFC 2759).
The encrypted tunnel is set up as follows:
Step 1 – PEAP Stage 1
The client contacts the Mobility Server. The authentication server presents its
certificate. The client verifies that the certificate is valid, was signed by a
Certification Authority (CA) trusted by the client, and was issued to a known
server. The client and authentication server continue to establish a TLS tunnel,
using a crypto suite that is supported by both the client and the authentication
server. This step uses Diffie-Hellman (DH) key agreement to set up the outer
tunnel.
Step 2 – PEAP Stage 2
A PEAP MS-CHAPv2 exchange occurs within the tunnel to authenticate the user
using a challenge response (this exchange is described in RFC 2759). The user is
authenticated to the authentication server.
Step 3 – Elliptic Curve Diffie-Hellman (ECDH)
ECDH key agreement occurs between the Mobility client and the Mobility server
to create the symmetric keys that will be used to encrypt the session. This
exchange is authenticated using HMAC-MD5 and the key generated during the
PEAP MS-CHAPv2 exchange (RFC 2548 paragraph 2.4.1).
Step 4 – Encrypted tunnel
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 44 of 49
Data passes between the client and the application server, through the Mobility
server. The data is encrypted with the symmetric keys between the client and
the mobility server.
EAP-TLS Authentication
The other user authentication option is Extensible Authentication Protocol
Transport Layer Security (EAP-TLS) (RFC 5216). This is very similar to the PEAP
implementation, except that user certificates are presented instead of a
username and password.
The encrypted tunnel is set up as follows:
Step 1 – EAP Stage 1
The client contacts the authentication server. The authentication server presents
its certificate. The client verifies that the certificate is valid, was signed by a
Certification Authority (CA) trusted by the client, and was issued to a known
server.
Step 2 – EAP Stage 2
The user presents a user certificate which may be verified by the authentication
server. The user certificate may be installed on a smart card, or in the user’s
personal certificate store. A password may be required to access the user
certificate.
Step 3 – Elliptic Curve Diffie-Hellman (ECDH)
ECDH key agreement occurs between the Mobility client and the Mobility server
to create the symmetric keys that will be used to encrypt the session. This
exchange is authenticated using HMAC-MD5 and the key generated during the
EAP-TLS exchange (RFC 5216 paragraph 2.3 Master Session Key (MSK)).
Step 4 – Encrypted tunnel
Data passes between the client and the application server, through the Mobility
server. The data is encrypted with the symmetric keys between the client and
the mobility server.
Once the Authentication server confirms that the user is identified and
authenticated, the Mobility Server allows data to flow from the Mobility Client,
through the Mobility Server to the protected internal resource. The Mobility
client secures all the application data destined for the TCP/IP network stack,
including TCP, UDP and ICMP ping using a VPN tunnel between the Mobility
client and the Mobility server. This ensures that the confidentiality and integrity
of any data is protected using FIPS-140-2 validated cryptographic modules.
Local traffic such as loopback traffic and data destined for local applications is
not sent through the encrypted tunnel.
TOE Security Functional Requirements addressed: FDP_IFC.1, FDP_IFF.1,
FDP_ITT.1.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 45 of 49
7.4 IDENTIFICATION AND AUTHENTICATION
Users of the Mobility Console must provide Windows credentials that are valid
for an account on the Mobility server operating system or in the domain in which
the server participates. The Mobility Console user enters a username and
password, which are verified in the operating system. The user is only granted
access to the Mobility Console if the username and password are correct, and
the user is a member of a group which has a Mobility Console role.
Users of the Mobility Client must be identified and authenticated before being
allowed access to protected resources, as described in Section 0. The
authentication mechanism may be either PEAP MS-CHAPv2 or EAP-TLS. Users
will authenticate using the mechanism that has been implemented in their
environment.
Administrators authenticate to the Mobility Server from the management
console computer. Both the authentication server and the management console
computer are located on a trusted internal network.
TOE Security Functional Requirements addressed: FIA_UAU.2, FIA_UAU.5,
FIA_UID.2.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 46 of 49
7.5 SECURITY MANAGEMENT
The Mobility Console provides the functionality to manage NetMotion Mobility.
This functionality includes:
• Creating, deleting, modifying and viewing the information flow security
policy rules that permit or deny information flows, and changing default
values for, querying, modifying and deleting the data required to establish
those rules;
• Reviewing and clearing audit logs; and
• Querying, modifying and deleting user account attributes.
Users of the Mobility Console must be a member of the Administrator group or
be made an administrator on the Mobility Console. The Mobility server is
installed with the built-in Administrator role, which is assigned to the
Administrators group in Active Directory. To access the Mobility Console, users
must provide Windows credentials that are valid for an account on the Mobility
server or in the domain in which the server participates.
Mobility Client Users do not have access to Mobility Console functions.
TOE Security Functional Requirements addressed: FMT_MTD.1, FMT_SMF.1,
FMT_SMR.1.
7.6 PROTECTION OF THE TSF
All events on the Mobility server are logged and stamped with the date and
time, which is retrieved from the operating system. All log timestamps are
written as yyyyMMdd and hh:mm:ss.
Both IPv4 and IPv6 addressing are supported.
TOE Security Functional Requirements addressed: FPT_STM.1.
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 47 of 49
8 TERMINOLOGY AND ACRONYMS
8.1 TERMINOLOGY
The following terminology is used in this ST:
Term Description
Activity log The activity log records connection events and is written in a
comma-delimited format for export and analysis. To view the
activity log, the administrator opens the Mobility Console and
selects the ‘Activity log’ link at the top of the page.
Application data Application data refers to the data that passes between the end
user and the server when the end user accesses the application
remotely. The application may be any client/server application
written for an IP network. Application data includes, but is not
limited to, documents, spreadsheets, images, and XML data.
Application data is considered to be at risk when it is transmitted on
an external public network.
Event log The event log is a binary file updated by any Mobility component
that logs event messages. By default, events are logged to
nmevent.nel in the Windows folder. To view the event log, the
administrator opens the Mobility Console and selects the ‘Event log’
link at the top of the page.
Management
Console
Computer
This is the hardware that supports use of the Mobility Console
through a browser. It is not part of the TOE.
Mobility Console The Mobility Console is a web-based configuration and management
utility that an administrator can use to configure settings, create
and apply client policies, monitor server status and client
connections, monitor activity or event logs, and troubleshoot
problems. It is part of the TOE.
Table 21 – Terminology
8.2 ACRONYMS
The following acronyms are used in this ST:
Acronym Definition
AD Active Directory
AES Advanced Encryption Standard
API Application Programming Interface
CA Certification Authority
CAVP Cryptographic Algorithm Validation Program
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 48 of 49
Acronym Definition
CBC Cipher Block Chaining
CC Common Criteria
CSEC Swedish Certification Body for IT Security
CSV Comma separated values
CTR-DRBG Counter mode Deterministic Random Bit Generator
DH Diffie-Hellman
DRBG Deterministic Random Bit Generator
EAL Evaluation Assurance Level
EAP Extensible Authentication Protocol
ECDH Elliptic Curve Diffie-Hellman
FFC Finite Field Cryptography
FIPS Federal Information Processing Standards
GB Gigabyte
GCM Galois/Counter Mode
HMAC Hash Message Authentication Code
HTTPS Hypertext transfer protocol secure
ICMP Internet Control Message Protocol
IP Internet Protocol
IT Information Technology
LAN Local Area Network
MS-CHAP Microsoft Challenge-Handshake Authentication Protocol
MSK Master Session Key
NAS Network Access Server
NIST National Institute of Standards and Technology (USA)
NTLM NT LAN Manager (Windows Challenge/Response authentication
protocol)
PEAP Protected Extensible Authentication Protocol
PKCS1 Public-Key Cryptography Standard #1 for RSA key pairs
PKI Public Key Infrastructure
NetMotion Mobility®
12.14
Security Target
Doc No: 2181-001-D102 Version: 0.15 Date: 15 October 2021 Page 49 of 49
Acronym Definition
PoP Point of Presence
PP Protection Profile
RADIUS Remote Authentication Dial In User Service
RAM Random Access Memory
RBG Random Bit Generator
RSASSA RSA Signature Scheme with Appendix
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
ST Security Target
TCP/IP Transmission Control Protocol / Internet Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functionality
UDP User Datagram Protocol
USA United States of America
VPN Virtual Private Network
Table 22 – Acronyms