Page 1 of 92
Vision Series Network Packet Broker v5.3.0
Security Target
Version 1.4
July 2020
Document prepared by
www.lightshipsec.com
Ixia, A Keysight Business Security Target
Page 2 of 92
Document History
Version Date Author Description
1.0 17 Apr 2020 L Turner Release for certification.
1.1 22 Apr 2020 M Kanasani Address lab observations.
1.2 22 June 2020 L Turner Publish for certification.
1.3 6 July 2020 L Turner Address certification observations.
1.4 20 Jul 2020 L Turner Update CAVP
Ixia, A Keysight Business Security Target
Page 3 of 92
Table of Contents
1 Introduction...........................................................................................................................5
1.1 Overview ........................................................................................................................5
1.2 Identification...................................................................................................................5
1.3 Conformance Claims......................................................................................................5
1.4 Terminology ...................................................................................................................7
2 TOE Description....................................................................................................................8
2.1 Type ...............................................................................................................................8
2.2 Usage.............................................................................................................................8
2.3 Security Functions..........................................................................................................9
2.4 Physical Scope.............................................................................................................10
2.5 Logical Scope...............................................................................................................12
3 Security Problem Definition...............................................................................................13
3.1 Threats.........................................................................................................................13
3.2 Assumptions.................................................................................................................14
3.3 Organizational Security Policies...................................................................................15
4 Security Objectives ............................................................................................................15
5 Security Requirements.......................................................................................................17
5.1 Conventions .................................................................................................................17
5.2 Extended Components Definition.................................................................................17
5.3 Functional Requirements .............................................................................................17
5.4 Assurance Requirements.............................................................................................32
6 TOE Summary Specification..............................................................................................33
6.1 Security Audit...............................................................................................................33
6.2 Cryptographic Support .................................................................................................33
6.3 Identification and Authentication ..................................................................................36
6.4 Security Management ..................................................................................................38
6.5 Protection of the TSF ...................................................................................................39
6.6 TOE Access .................................................................................................................41
6.7 Trusted Path/Channels ................................................................................................42
7 Rationale..............................................................................................................................43
7.1 Conformance Claim Rationale .....................................................................................43
7.2 Security Objectives Rationale ......................................................................................43
7.3 Security Requirements Rationale.................................................................................43
Annex A: Extended Components Definition.............................................................................46
Security Audit (FAU) .................................................................................................................46
Cryptographic Support (FCS) ...................................................................................................51
Identification and Authentication (FIA) ......................................................................................76
User Identification and Authentication (FIA_UIA_EXT) ............................................................77
User authentication (FIA_UAU_EXT) .......................................................................................78
Authentication using X.509 certificates (FIA_X509_EXT).........................................................79
Protection of the TSF (FPT)......................................................................................................82
Protection of Administrator Passwords (FPT_APW_EXT)........................................................83
TSF Self-Test (FPT_TST_EXT)................................................................................................84
Trusted Update (FPT_TUD_EXT).............................................................................................85
Time stamps (FPT_STM_EXT).................................................................................................89
TOE Access (FTA)....................................................................................................................90
Ixia, A Keysight Business Security Target
Page 4 of 92
Communication (FCO) ..............................................................................................................91
List of Tables
Table 1: Evaluation identifiers .........................................................................................................5
Table 2: NIAP Technical Decisions.................................................................................................5
Table 3: Terminology.......................................................................................................................7
Table 4: CAVP Certificates............................................................................................................10
Table 5: TOE models ....................................................................................................................10
Table 6: Threats ............................................................................................................................13
Table 7: Assumptions....................................................................................................................14
Table 8: Organizational Security Policies......................................................................................15
Table 9: Security Objectives for the Operational Environment......................................................15
Table 10: Summary of SFRs.........................................................................................................17
Table 11: Audit Events ..................................................................................................................19
Table 12: Assurance Requirements..............................................................................................32
Table 13: HMAC Characteristics...................................................................................................34
Table 14: Keys ..............................................................................................................................39
Table 15: Passwords.....................................................................................................................40
Table 16: NDcPP SFR Rationale ..................................................................................................43
Ixia, A Keysight Business Security Target
Page 5 of 92
1 Introduction
1.1 Overview
1 This Security Target (ST) defines the Ixia, A Keysight Business Vision Series
Network Packet Broker v5.3.0 Target of Evaluation (TOE) for the purposes of
Common Criteria (CC) evaluation.
2 Ixia Network Packet Brokers are at the heart of all Ixia Visibility solutions. Their main
function is to aggregate, load balance and filter network traffic before it’s processed
by network security and performance monitoring tools.
1.2 Identification
Table 1: Evaluation identifiers
Target of Evaluation Ixia, A Keysight Business Vision Series Network Packet Broker
v5.3.0
Build: 5.3.0.22
Security Target Ixia, A Keysight Business Vision Series Network Packet Broker
v5.3.0 Security Target, v1.4
1.3 Conformance Claims
3 This ST supports the following conformance claims:
a) CC version 3.1 revision 5
b) CC Part 2 extended
c) CC Part 3 conformant
d) collaborative Protection Profile for Network Devices, v2.1
e) NIAP Technical Decisions per Table 2
Table 2: NIAP Technical Decisions
TD # Name Rationale if n/a
TD0395 NIT Technical Decision for Different Handling of TLS1.1
and TLS1.2
FCS_TLSS_EXT.2 not
claimed.
TD0396 NIT Technical Decision for FCS_TLSC_EXT.1.1, Test 2
TD0397 NIT Technical Decision for Fixing AES-CTR Mode Tests
TD0398 NIT Technical Decision for FCS_SSH*EXT.1.1 RFCs for
AES-CTR
SSH not claimed.
TD0399 NIT Technical Decision for Manual installation of CRL
(FIA_X509_EXT.2)
TD0400 NIT Technical Decision for FCS_CKM.2 and elliptic
curve-based key establishment
Ixia, A Keysight Business Security Target
Page 6 of 92
TD # Name Rationale if n/a
TD0401 NIT Technical Decision for Reliance on external servers
to meet SFRs
TD0402 NIT Technical Decision for RSA-based FCS_CKM.2
Selection
TD0407 NIT Technical Decision for handling Certification of
Cloud Deployments
TOE is not a cloud
deployment.
TD0408 NIT Technical Decision for local vs. remote administrator
accounts
TD0409 NIT decision for Applicability of FIA_AFL.1 to key-based
SSH authentication
SSH not claimed.
TD0410 NIT technical decision for Redundant assurance
activities associated with FAU_GEN.1
TD0411 NIT Technical Decision for FCS_SSHC_EXT.1.5, Test 1
– Server and client side seem to be confused
SSH not claimed.
TD0412 NIT Technical Decision for FCS_SSHS_EXT.1.5 SFR
and AA discrepancy
SSH not claimed.
TD0423 NIT Technical Decision for Clarification about application
of RfI#201726rev2
TD0424 NIT Technical Decision for NDcPP v2.1 Clarification –
FCS_SSHC/S_EXT1.5
SSH not claimed.
TD0425 NIT Technical Decision for Cut-and-paste Error for
Guidance AA
TD0447 NIT Technical Decision for Using ‘diffie-hellman-group-
exchange-sha256’ in FCS_SSHC/S_EXT.1.7
SSH not claimed.
TD0450 NIT Technical Decision for RSA-based ciphers and the
Server Key Exchange message
TD0451 NIT Technical Decision for ITT Comm UUID Reference
Identifier
TD0453 NIT Technical Decision for Clarify authentication
methods SSH clients can use to authenticate SSH se
SSH not claimed.
TD0475 NIT Technical Decision for Separate traffic consideration
for SSH rekey
SSH not claimed.
TD0477 NIT Technical Decision for Clarifying FPT_TUD_EXT.1
Trusted Update
Ixia, A Keysight Business Security Target
Page 7 of 92
TD # Name Rationale if n/a
TD0478 NIT Technical Decision for Application Notes for
FIA_X509_EXT.1 iterations
TD0480 NIT Technical Decision for Granularity of audit events
TD0481 NIT Technical Decision for FCS_(D)TLSC_EXT.X.2 IP
addresses in reference identifiers
TD0482 NIT Technical Decision for Identification of usage of
cryptographic schemes
TD0483 NIT Technical Decision for Applicability of
FPT_APW_EXT.1
TD0484 NIT Technical Decision for Interactive sessions in
FTA_SSL_EXT.1 & FTA_SSL.3
1.4 Terminology
Table 3: Terminology
Term Definition
CC Common Criteria
EAL Evaluation Assurance Level
NDcPP collaborative Protection Profile for Network Devices
NFV Network Functions Virtualization
PP Protection Profile
SDN Software-Defined Networking
TOE Target of Evaluation
TSF TOE Security Functionality
RU Rack Unit
CRC Cyclic Redundancy Check
Ixia, A Keysight Business Security Target
Page 8 of 92
2 TOE Description
2.1 Type
4 The TOE is a network device.
2.2 Usage
2.2.1 Deployment
5 Figure 1 shows an example deployment of the TOE (Network Packet Broker). Usage
is as follows:
a) Capture network traffic by tapping network links.
b) Through non-production network links, traffic flows to the Network Packet
Broker where duplicate data is removed and filtered.
c) Performance and monitoring tools then receive the most appropriate data
stream, tailored specifically for that tool.
Figure 1: Example TOE deployment
Ixia, A Keysight Business Security Target
Page 9 of 92
2.2.2 Trusted Paths and Channels
6 The TOE’s trusted paths and channels within the scope of evaluation are shown in
Figure 2.
Figure 2: TOE Trusted Paths and Channels
7 The TOE trusted paths and channels are as follows:
a) Serial Console. Administrative interface via direct serial connection.
b) GUI/WebAPI. Administrative web GUI/WebAPI via HTTPS.
c) Logs. Logs sent to syslog via TLS.
d) NTP. NTP communications are make use of SHA-1 message digests.
2.3 Security Functions
8 The TOE provides the following security functions:
a) Protected Communications. The TOE protects the integrity and
confidentiality of communications as noted in section 2.2 above.
b) Secure Administration. The TOE enables secure management of its security
functions, including:
i) Administrator authentication with passwords
ii) Configurable password policies
iii) Role Based Access Control
iv) Access banners
v) Management of critical security functions and data
vi) Protection of cryptographic keys and passwords
Ixia, A Keysight Business Security Target
Page 10 of 92
c) Trusted Update. The TOE ensures the authenticity and integrity of software
updates through digital signatures.
d) System Monitoring. The TOE generates logs of security relevant events. The
TOE stores logs locally and is capable of sending log events to a remote audit
server.
e) Self-Test. The TOE performs a suite of self-tests to ensure the correct
operation and enforcement of its security functions.
f) Cryptographic Operations. The TOE implements BouncyCastle and
OpenSSL cryptographic modules. Relevant Cryptographic Algorithm
Validation Program (CAVP) certificates are shown in Table 4.
Table 4: CAVP Certificates
Module Services Algorithms Certificates
BouncyCastle TLS/HTTPS
X.509v3
Key Encryption
AES-CBC
AES-GCM
RSA KeyGen (186-4)
RSA SigGen (186-4)
RSA SigVer (186-4)
ECDSA KeyGen (186-4)
ECDSA SigGen (186-4)
ECDSA SigVer (186-4)
SHA-1, SHA-256
HMAC-SHA-1, HMAC-SHA-256
KAS-ECC
Hash DRBG
C1551
AES 5940
RSA 3118
ECDSA 1590
Component 2169
SHS 4693
HMAC 3915
KAS 210
DRBG 2493
OpenSSL NTP SHA-1 C1550
SHS 4692
2.4 Physical Scope
9 The physical boundary of the TOE includes the Vision Series Network Packet Broker
v5.3.0 software on the appliance models shown in Table 5 which are delivered to the
user via commercial carrier.
Table 5: TOE models
Model CPU Notes on differences
Vision ONE Intel Core i7-3555LE 1RU - All-in-one tool that provides high-
performance, lossless visibility
Vision 7300/7303 Intel Core i7-3555LE 7RU - High-density, modular platform for
high performance, intelligent visibility
Ixia, A Keysight Business Security Target
Page 11 of 92
Model CPU Notes on differences
Vision E40 Atom C2538 1RU - Cost-effective rack-level visibility
for ANY size data center
Vision E100 Xeon D-1518 1RU - Cost-effective rack-level visibility
for ANY size data center
Vision E10S Celeron 3965U 1RU - Cost-effective rack-level visibility
designed for branch and remote offices
Vision X Xeon D-1527 3RU - Scalable visibility for data centres
today and tomorrow
TradeVision Intel Core i7-3555LE 1RU - Market feed management and tap
aggregation for monitoring capital
markets
2.4.1 Guidance Documents
10 The TOE includes the following guidance documents:
a) Ixia, A Keysight Business Vision Series Network Packet Broker v5.3.0
Common Criteria Guide, v1.0
b) User Guides:
i) Ixia Vision X User Guide v5.3.0, 913-2547-01 Rev B
ii) Ixia Vision X Installation Guide, 913-2542-01 Rev A
iii) Ixia Vision X Quick Start Guide, 913-2499-01 Rev-C
iv) Ixia Vision 7300/7303 User Guide v5.3.0, 913-2548-01 Rev B
v) Ixia Vision 7300/7303 Network Packet Broker Installation Guide v5.2.0,
913-2530-01 Rev A
vi) Ixia Vision 7300/7303 Startup Guide, 913-2413-01 Rev A
vii) Ixia Vision ONE Installation Guide, 913-2419-01 Rev B
viii) Ixia Vision ONE User Guide v5.3.0, 913-2549-01 Rev B
ix) Ixia Vision ONE Startup Guide, 913-2416-01 Rev B
x) Ixia Vision Edge 40/100 Installation Guide, 913-2450-01 Rev A
xi) Ixia Vision Edge 40/100 User Guide v5.3.0, 913-2550-01 Rev B
xii) Ixia Vision E40 E100 Startup Guide, 913-2415-01 Rev A
xiii) Ixia Vision Edge E10S User Guide v5.3.0, 913-2552-01 Rev B
xiv) Ixia Vision Edge 10S Installation Guide, 913-2529-01 Rev A
xv) Ixia TradeVision Installation Guide, 913-2421-01 Rev A
xvi) Ixia TradeVision User Guide v5.3.0, 913-2565-01 Rev B
xvii) Ixia TradeVision Quick Start Guide v5.3.0, 913-2563-01 Rev A
Ixia, A Keysight Business Security Target
Page 12 of 92
2.4.2 Non-TOE Components
11 The TOE operates with the following components in the environment:
a) Audit Server. The TOE is capable of sending audit events to a Syslog server.
b) NTP Server. The TOE synchronizes time with an NTP server.
2.5 Logical Scope
12 The logical scope of the TOE comprises the security functions defined in section 2.3.
Ixia, A Keysight Business Security Target
Page 13 of 92
3 Security Problem Definition
13 The Security Problem Definition is reproduced from section 4 of the NDcPP.
3.1 Threats
Table 6: Threats
Identifier Description
T.UNAUTHORIZED_
ADMINISTRATOR_
ACCESS
Threat agents may attempt to gain Administrator access to the
network device by nefarious means such as masquerading as an
Administrator to the device, masquerading as the device to an
Administrator, replaying an administrative session (in its entirety, or
selected portions), or performing man-in-the-middle attacks, which
would provide access to the administrative session, or sessions
between network devices. Successfully gaining Administrator access
allows malicious actions that compromise the security functionality of
the device and the network on which it resides.
T.WEAK_
CRYPTOGRAPHY
Threat agents may exploit weak cryptographic algorithms or perform a
cryptographic exhaust against the key space. Poorly chosen
encryption algorithms, modes, and key sizes will allow
attackers to compromise the algorithms, or brute force exhaust the key
space and give them unauthorized access allowing them to read,
manipulate and/or control the traffic with minimal effort.
T.UNTRUSTED_
COMMUNICATION_
CHANNELS
Threat agents may attempt to target network devices that do not use
standardized secure tunnelling protocols to protect the critical network
traffic. Attackers may take advantage of poorly designed protocols or
poor key management to successfully perform man-in-the-middle
attacks, replay attacks, etc. Successful attacks will result in loss of
confidentiality and integrity of the critical network traffic, and potentially
could lead to a compromise of the network device itself.
T.WEAK_
AUTHENTICATION_
ENDPOINTS
Threat agents may take advantage of secure protocols that use weak
methods to authenticate the endpoints – e.g. a shared password that
is guessable or transported as plaintext. The consequences are the
same as a poorly designed protocol, the attacker could masquerade
as the Administrator or another device, and the attacker could insert
themselves into the network stream and perform a man-in-the-middle
attack. The result is the critical network traffic is exposed and there
could be a loss of confidentiality and integrity, and potentially the
network device itself could be compromised.
T.UPDATE_
COMPROMISE
Threat agents may attempt to provide a compromised update of the
software or firmware which undermines the security functionality of the
device. Non-validated updates or updates validated using non-secure
or weak cryptography leave the update firmware vulnerable to
surreptitious alteration.
T.UNDETECTED_
ACTIVITY
Threat agents may attempt to access, change, and/or modify the
security functionality of the network device without Administrator
awareness. This could result in the attacker finding an avenue (e.g.,
misconfiguration, flaw in the product) to compromise the device and
Ixia, A Keysight Business Security Target
Page 14 of 92
Identifier Description
the Administrator would have no knowledge that the device has been
compromised.
T.SECURITY_
FUNCTIONALITY_
COMPROMISE
Threat agents may compromise credentials and device data enabling
continued access to the network device and its critical data. The
compromise of credentials includes replacing existing credentials with
an attacker’s credentials, modifying existing credentials, or obtaining
the Administrator or device credentials for use by the attacker.
T.PASSWORD_
CRACKING
Threat agents may be able to take advantage of weak administrative
passwords to gain privileged access to the device. Having privileged
access to the device provides the attacker unfettered access to the
network traffic, and may allow them to take advantage of any trust
relationships with other network devices.
T.SECURITY_
FUNCTIONALITY_
FAILURE
An external, unauthorized entity could make use of failed or
compromised security functionality and might therefore subsequently
use or abuse security functions without prior authentication to access,
change or modify device data, critical network traffic or security
functionality of the device.
3.2 Assumptions
Table 7: Assumptions
Identifier Description
A.PHYSICAL_
PROTECTION
The network device is assumed to be physically protected in its
operational environment and not subject to physical attacks that
compromise the security and/or interfere with the device’s physical
interconnections and correct operation. This protection is assumed to
be sufficient to protect the device and the data it contains. As a result,
the cPP will not include any requirements on physical tamper
protection or other physical attack mitigations. The cPP will not expect
the product to defend against physical access to the device that allows
unauthorized entities to extract data, bypass other controls, or
otherwise manipulate the device.
A.LIMITED_
FUNCTIONALITY
The device is assumed to provide networking functionality as its core
function and not provide functionality/services that could be deemed
as general purpose computing. For example, the device should not
provide a computing platform for general purpose applications
(unrelated to networking functionality).
A.NO_THRU_
TRAFFIC_
PROTECTION
A standard/generic network device does not provide any assurance
regarding the protection of traffic that traverses it. The intent is for the
network device to protect data that originates on or is destined to the
device itself, to include administrative data and audit data. Traffic that
is traversing the network device, destined for another network entity, is
not covered by the NDcPP. It is assumed that this protection will be
covered by cPPs for particular types of network devices (e.g., firewall).
Ixia, A Keysight Business Security Target
Page 15 of 92
Identifier Description
A.TRUSTED_
ADMINISTRATOR
The Security Administrator(s) for the network device are assumed to
be trusted and to act in the best interest of security for the
organization. This includes being appropriately trained, following
policy, and adhering to guidance documentation. Administrators are
trusted to ensure passwords/credentials have sufficient strength and
entropy and to lack malicious intent when administering the device.
The network device is not expected to be capable of defending against
a malicious Administrator that actively works to bypass or compromise
the security of the device.
A.REGULAR_
UPDATES
The network device firmware and software is assumed to be updated
by an Administrator on a regular basis in response to the release of
product updates due to known vulnerabilities.
A.ADMIN_
CREDENTIALS_
SECURE
The Administrator’s credentials (private key) used to access the
network device are protected by the platform on which they reside.
A.RESIDUAL_
INFORMATION
The Administrator must ensure that there is no unauthorized access
possible for sensitive residual information (e.g. cryptographic keys,
keying material, PINs, passwords etc.) on networking equipment when
the equipment is discarded or removed from its operational
environment.
3.3 Organizational Security Policies
Table 8: Organizational Security Policies
Identifier Description
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use,
legal agreements, or any other appropriate information to which users
consent by accessing the TOE.
4 Security Objectives
14 The security objectives are reproduced from section 5 of the NDcPP.
Table 9: Security Objectives for the Operational Environment
Identifier Description
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the
data it contains, is provided by the environment.
OE.NO_GENERAL_
PURPOSE
There are no general-purpose computing capabilities (e.g., compilers
or user applications) available on the TOE, other than those services
necessary for the operation, administration and support of the TOE.
Ixia, A Keysight Business Security Target
Page 16 of 92
Identifier Description
OE.NO_THRU_
TRAFFIC_
PROTECTION
The TOE does not provide any protection of traffic that traverses it. It
is assumed that protection of this traffic will be covered by other
security and assurance measures in the operational environment.
OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance
documentation in a trusted manner.
OE.UPDATES The TOE firmware and software is updated by an Administrator on a
regular basis in response to the release of product updates due to
known vulnerabilities.
OE.ADMIN_CREDEN
TIALS_SECURE
The Administrator’s credentials (private key) used to access the TOE
must be protected on any other platform on which they reside.
OE.RESIDUAL_INFO
RMATION
The Security Administrator ensures that there is no unauthorized
access possible for sensitive residual information (e.g. cryptographic
keys, keying material, PINs, passwords etc.) on networking equipment
when the equipment is discarded or removed from its operational
environment.
Ixia, A Keysight Business Security Target
Page 17 of 92
5 Security Requirements
5.1 Conventions
15 This document uses the following font conventions to identify the operations defined
by the CC:
a) Assignment. Indicated with italicized text.
b) Refinement. Indicated with bold text and strikethroughs.
c) Selection. Indicated with underlined text.
d) Assignment within a Selection: Indicated with italicized and underlined text.
e) Iteration. Indicated by adding a string starting with “/” (e.g.
“FCS_COP.1/Hash”).
16 Note: Operations performed within the Security Target are denoted within brackets
[]. Operations shown without brackets are reproduced from the NDcPP.
5.2 Extended Components Definition
17 Refer to Annex A: Extended Components Definition.
5.3 Functional Requirements
Table 10: Summary of SFRs
Requirement Title
FAU_GEN.1 Audit Data Generation
FAU_GEN.2 User Identity Association
FAU_STG_EXT.1 Protected Audit Event Storage
FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.4 Cryptographic Key Destruction
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_NTP_EXT.1 NTP Protocol
Ixia, A Keysight Business Security Target
Page 18 of 92
Requirement Title
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSC_EXT.2 TLS Client Protocol
FCS_TLSS_EXT.1 TLS Server Protocol
FIA_AFL.1 Authentication Failure Management
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU.7 Protected Authentication Feedback
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.3 X.509 Certificate Requests
FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MOF.1/Functions Management of security functions behaviour
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.2 Restrictions on Security Roles
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric
and private keys)
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_TST_EXT.1 TSF testing
FPT_TUD_EXT.1 Extended: Trusted update
FPT_STM_EXT.1 Reliable Time Stamps
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.4 User-initiated Termination
Ixia, A Keysight Business Security Target
Page 19 of 92
Requirement Title
FTA_TAB.1 Default TOE Access Banners
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1/Admin Trusted Path
5.3.1 Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit;
c) All administrative actions comprising:
o Administrative login and logout (name of user account shall
be logged if individual user accounts are required for
Administrators).
o Changes to TSF data related to configuration changes (in
addition to the information that a change occurred it shall be
logged what has been changed).
o Generating/import of, changing, or deleting of cryptographic
keys (in addition to the action itself a unique key name or
key reference shall be logged).
o Resetting passwords (name of related user account shall be
logged).
o no other actions;
d) Specifically defined auditable events listed in Table 2 Table 11.
Table 11: Audit Events
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
Ixia, A Keysight Business Security Target
Page 20 of 92
Requirement Auditable Events Additional Audit Record
Contents
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_HTTPS_EXT.1 Failure to establish a HTTPS
Session.
Reason for failure
FCS_NTP_EXT.1 Configuration of a new time
server
Removal of configured time
server
Identity if new/removed time
server
FCS_RBG_EXT.1 None. None.
FCS_TLSC_EXT.1 Failure to establish a TLS
Session
Reason for failure
FCS_TLSS_EXT.1 Failure to establish a TLS
Session
Reason for failure
FIA_AFL.1 Unsuccessful login attempts
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Provided user identity, origin
of the attempt (e.g., IP
address).
FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/Rev Unsuccessful attempt to
validate a certificate
Reason for failure
FIA_X509_EXT.2 None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a
manual update
None.
FMT_MOF.1/Functions Modification of the behaviour
of the transmission of audit
None.
Ixia, A Keysight Business Security Target
Page 21 of 92
Requirement Auditable Events Additional Audit Record
Contents
data to an external IT entity,
the handling of audit data, the
audit functionality when Local
Audit Storage Space is full.
FMT_MTD.1/CoreData None. None.
FMT_MTD.1/CryptoKeys None. None.
FMT_SMF.1 All management activities of
TSF data.
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update; result of
the update attempt (success
or failure)
None.
FPT_STM_EXT.1 Discontinuous changes to
time - either Administrator
actuated or changed via an
automated process. (Note
that no continuous changes
to time need to be logged.
See also application note on
FPT_STM_EXT.1)
For discontinuous changes
to time: The old and new
values for the time. Origin of
the attempt to change time
for success and failure (e.g.,
IP address).
FTA_SSL_EXT.1 (if
“terminate the session” is
selected)
The termination of a local
session by the session
locking mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session
locking mechanism.
None.
FTA_SSL.4 The termination of an
interactive session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted
channel. Termination of the
trusted channel. Failure of the
trusted channel functions.
Identification of the initiator
and target of failed trusted
channels establishment
attempt.
Ixia, A Keysight Business Security Target
Page 22 of 92
Requirement Auditable Events Additional Audit Record
Contents
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted
path. Failure of the trusted
path functions.
None.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity, and the
outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of
the functional components included in the cPP/ST, information
specified in column three of Table 2 Table 11.
FAU_GEN.2 User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall
be able to associate each auditable event with the identity of the user
that caused the event.
FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external
IT entity using a trusted channel according to FTP_ITC.1.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.[
• TOE shall consist of a single standalone component that stores audit
data locally]
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the
following rule: [delete the oldest 1 MB of local audit data] when the local
storage space for audit data is full.
5.3.2 Cryptographic Support (FCS)
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: [
• RSA schemes using cryptographic key sizes of 2048-bit or greater
that meet the following: FIPS PUB 186-4, “Digital Signature Standard
(DSS)”, Appendix B.3;
• ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.4;
Ixia, A Keysight Business Security Target
Page 23 of 92
]and specified cryptographic key sizes [assignment: cryptographic key
sizes] that meet the following: [assignment: list of standards].
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance
with a specified cryptographic key establishment method: [
• Elliptic curve-based key establishment schemes that meet the
following: NIST Special Publication 800-56A Revision 2,
“Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”;
] that meets the following: [assignment: list of standards].
FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [
• For plaintext keys in volatile storage, the destruction shall be
executed by a [destruction of reference to the key directly followed
by a request for garbage collection];
• For plaintext keys in non-volatile storage, the destruction shall be
executed by the invocation of an interface provided by a part of the
TSF that [
o logically addresses the storage location of the key and
performs a [single overwrite consisting of [a new value of the
key]];
] that meets the following: No Standard.
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with
a specified cryptographic algorithm AES used in [CBC, GCM] mode and
cryptographic key sizes [128 bits, 256 bits] that meet the following: AES
as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM as
specified in ISO 19772].
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and
Verification)
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm [
• RSA Digital Signature Algorithm and cryptographic key sizes
(modulus) [2048 bits or greater],
] that meet the following: [
• For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard
(DSS)”, Section 5.5, using PKCS #1 v2.1 Signature Schemes
Ixia, A Keysight Business Security Target
Page 24 of 92
RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital
signature scheme 2 or Digital Signature scheme 3,]
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance
with a specified cryptographic algorithm [SHA-1, SHA-256] and
cryptographic key sizes [assignment: cryptographic key sizes] and
message digest sizes [160, 256] bits that meet the following: ISO/IEC
10118-3:2004.
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in
accordance with a specified cryptographic algorithm [HMAC-SHA-1,
HMAC-SHA-256] and cryptographic key sizes [160, 256] and message
digest sizes [160, 256] bits that meet the following: ISO/IEC 9797-
2:2011, Section 7 “MAC Algorithm 2”.
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC
2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [not require client
authentication] if the peer certificate is deemed invalid.
FCS_NTP_EXT.1 NTP Protocol
FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [NTP v4 (RFC
5905)].
FCS_NTP_EXT.1.2 The TSF shall update its system time using [Authentication using [SHA1]
as the message digest algorithm(s)].
FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or
multicast addresses.
FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time
sources.
FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [Hash_DRBG (any)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [[one] hardware based noise source] with
a minimum of [256 bits] of entropy at least equal to the greatest security
Ixia, A Keysight Business Security Target
Page 25 of 92
strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength
Table for Hash Functions”, of the keys and hashes that it will generate.
FCS_TLSC_EXT.2 TLS Client Protocol
FCS_TLSC_EXT.2.1 The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS
and SSL versions. The TLS implementation will support the following
ciphersuites: [
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
4492].
FCS_TLSC_EXT.2.2 The TSF shall verify that the presented identifiers of the following types:
[identifiers defined in RFC 6125] are matched to reference identifiers.
FCS_TLSC_EXT.2.3 The TSF shall only establish a trusted channel if the server certificate is
valid. If the server certificate is deemed invalid, then the TSF shall [not
establish the connection].
FCS_TLSC_EXT.2.4 The TSF shall [present the Supported Elliptic Curves Extension with the
following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves] in the Client Hello.
FCS_TLSS_EXT.1 TLS Server Protocol with mutual authentication
FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS
and SSL versions. The TLS implementation will support the following
ciphersuites:[
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
4492].
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL
3.0, TLS 1.0 and [TLS 1.1].
FCS_TLSS_EXT.1.3 The TSF shall [generate EC Diffie-Hellman parameters over NIST curves
[secp256r1, secp384r1, secp521r1] and no other curves].
5.3.3 Identification and Authentication (FIA)
FIA_AFL.1 Authentication Failure Management
Ixia, A Keysight Business Security Target
Page 26 of 92
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer
within [3] unsuccessful authentication attempts occur related to
Administrators attempting to authenticate remotely using a password.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met, the TSF shall [prevent the offending remote Administrator
from successfully authenticating until [unlock the user] is taken by a local
Administrator;].
Application Note: The above SFR is altered by TD0408.
FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities
for administrative passwords:
a) Passwords shall be able to be composed of any combination of
upper and lower case letters, numbers, and the following special
characters: [[“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [“`”, ”~”, ”_”, ”+”,
”-“, ”=”, ”{“, ”}”, “|”, “\”, “:”, “””, ”;”, ”’”, “<”, “>”, “?”, “,”, “.”, “/”, “[”, ”]”];
b) Minimum password length shall be configurable to between [15] and
[100] characters.
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE
entity to initiate the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [[access to help files (PDF and html format)
• view alarm notifications
• view software version number]]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully
identified and authenticated before allowing any other TSF-mediated
actions on behalf of that administrative user.
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based] authentication
mechanism to perform local administrative user authentication.
Application Note: The above SFR is altered by TD0408.
FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user
while the authentication is in progress at the local console.
FIA_X509_EXT.1/Rev X.509 Certificate Validation
Ixia, A Keysight Business Security Target
Page 27 of 92
FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certification path validation
supporting a minimum path length of three certificates.
• The certification path must terminate with a trusted CA certificate
designated as a trust anchor.
• The TSF shall validate a certification path by ensuring that all CA
certificates in the certification path contain the presence of the
basicConstraints extension and that the CA flag is set to TRUE.
• The TSF shall validate the revocation status of the certificate using [a
Certificate Revocation List (CRL) as specified in RFC 5280 Section
6.3]
• The TSF shall validate the extendedKeyUsage field according to the
following rules:
o Certificates used for trusted updates and executable code
integrity verification shall have the Code Signing purpose (id-
kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage
field.
o Server certificates presented for TLS shall have the Server
Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in
the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client
Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in
the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have
the OCSP Signing purpose (id-kp 9 with OID
1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
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 for [HTTPS, TLS], and [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 [not accept the certificate].
FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by
RFC 2986 and be able to provide the following information in the
request: public key and [Common Name, Organization, Organizational
Unit, Country].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon
receiving the CA Certificate Response.
Ixia, A Keysight Business Security Target
Page 28 of 92
5.3.4 Security Management (FMT)
FMT_MOF.1/ManualUpdate Management of security functions behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to
perform manual updates to Security Administrators.
FMT_MOF.1/Functions Management of security functions behaviour
FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the
functions [transmission of audit data to an external IT entity] to Security
Administrators.
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to
Security Administrators.
FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic
keys to Security Administrators.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
• Ability to administer the TOE locally and remotely;
• Ability to configure the access banner;
• Ability to configure the session inactivity time before session
termination or locking;
• Ability to update the TOE, and to verify the updates using [digital
signature] capability prior to installing those updates;
• Ability to configure the authentication failure parameters for
FIA_AFL.1;
• [
o Ability to configure audit behaviour;
o Ability to manage the cryptographic keys;
o Ability to configure NTP;
o Ability to manage the TOE's trust store and designate
X509.v3 certificates as trust anchors;
o Ability to import X.509v3 certificates to the TOE's trust store;]
FMT_SMR.2 Restrictions on Security Roles
Ixia, A Keysight Business Security Target
Page 29 of 92
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions
• The Security Administrator role shall be able to administer the TOE
locally;
• The Security Administrator role shall be able to administer the TOE
remotely
are satisfied.
5.3.5 Protection of the TSF (FPT)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared,
symmetric and private keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords.
FPT_TST_EXT.1 TSF testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up
(on power on)] to demonstrate the correct operation of the TSF: [
• Firmware integrity tests
• Configuration integrity tests
• Cryptographic algorithm tests
• DRGB tests
• Boot loader image verification].
FPT_TUD_EXT.1 Trusted update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the
currently executing version of the TOE firmware/software and [no other
TOE firmware/software version].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually
initiate updates to TOE firmware/software and [no other update
mechanism].
Ixia, A Keysight Business Security Target
Page 30 of 92
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates
to the TOE using a [digital signature mechanism] prior to installing those
updates.
FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [synchronise time with an NTP server].
5.3.6 TOE Access (FTA)
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [
• terminate the session]
after a Security Administrator-specified time period of inactivity.
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
FTA_SSL.4 User-initiated Termination
FTA_SSL.4.1 Refinement: The TSF shall allow Administrator-initiated termination of
the Administrator’s own interactive session.
FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1 Before establishing an administrative user session the TSF shall
display a Security Administrator-specified advisory notice and
consent warning message regarding use of the TOE.
5.3.7 Trusted path/channels (FTP)
FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted
communication channel between itself and authorized IT entities
supporting the following capabilities: audit server, [no other
capabilities] that is logically distinct from other communication channels
and provides assured identification of its end points and protection of the
channel data from disclosure and detection of modification of the
channel data.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate
communication via the trusted channel.
Ixia, A Keysight Business Security Target
Page 31 of 92
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [audit
server].
FTP_TRP.1 /Admin Trusted Path
FTP_TRP.1.1/Admin The TSF shall be capable of using [HTTPS] to provide a
communication path between itself and authorized remote
Administrators that is logically distinct from other communication paths
and provides assured identification of its end points and protection of the
communicated data from disclosure and provides detection of
modification of the channel data.
FTP_TRP.1.2 /Admin The TSF shall permit remote Administrators to initiate communication
via the trusted path.
FTP_TRP.1.3 /Admin The TSF shall require the use of the trusted path for initial Administrator
authentication and all remote administration actions.
Ixia, A Keysight Business Security Target
Page 32 of 92
5.4 Assurance Requirements
18 The TOE security assurance requirements are summarized in Table 12.
Table 12: Assurance Requirements
Assurance Class Components Description
Security Target
Evaluation
ASE_CCL.1 Conformance Claims
ASE_ECD.1 Extended Components Definition
ASE_INT.1 ST Introduction
ASE_OBJ.1 Security Objectives for the operational environment
ASE_REQ.1 Stated Security Requirements
ASE_SPD.1 Security Problem Definition
ASE_TSS.1 TOE Summary Specification
Development ADV_FSP.1 Basic Functional Specification
Guidance Documents AGD_OPE.1 Operational User Guidance
AGD_PRE.1 Preparative User Guidance
Life Cycle Support ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM Coverage
Tests ATE_IND.1 Independent Testing - conformance
Vulnerability Assessment AVA_VAN.1 Vulnerability Analysis
19 In accordance with section 7.1 of the NDcPP, the following refinement is made to
ASE:
a) ASE_TSS.1.1C Refinement: The TOE summary specification shall describe
how the TOE meets each SFR. In the case of entropy analysis, the TSS is
used in conjunction with required supplementary information on
Entropy.
Ixia, A Keysight Business Security Target
Page 33 of 92
6 TOE Summary Specification
20 The following describes how the TOE fulfils each SFR included in section 5.3.
6.1 Security Audit
6.1.1 FAU_GEN.1
21 The TOE generates the audit records specified at FAU_GEN.1 containing the
following fields:
a) Date and Time Generated
b) Severity Level
c) Tag
d) Message
e) Source IP Address (external Syslog server only)
f) Source Name (external Syslog server only)
g) Date and Time Received (external Syslog server only)
h) Origin (external Syslog server only)
i) Facility (external Syslog server only)
22 The following information is logged as a result of the Security Administrator
generating/importing or deleting cryptographic keys:
a) Generate CSR. Action and key reference.
b) Import Certificate. Action and key reference.
c) Import CA Certificate. Action and key reference.
6.1.2 FAU_GEN.2
23 The TOE includes the user identity in audit events resulting from actions of identified
users.
6.1.3 FAU_STG_EXT.1
24 The Security Administrator can configure the TOE to send logs to a Syslog server.
Log events are sent in real-time. Logs are sent via TLS as described by
FCS_TLSC_EXT.1.
25 The TOE stores local audit data in 5 1MB rotating log files. When the local audit
data store is full, the TOE will delete the oldest log file.
26 Only authorized administrators may view audit records and no capability to modify
the audit records is provided.
6.2 Cryptographic Support
6.2.1 FCS_CKM.1
27 The TOE supports key generation for the following asymmetric schemes:
a) RSA 2048-bit. Used when generating CSRs.
b) ECC P-256/P-384/P-521. Used in TLS.
Ixia, A Keysight Business Security Target
Page 34 of 92
6.2.2 FCS_CKM.2
28 The TOE supports the following key establishment schemes:
a) ECC schemes. Used in TLS. TOE is sender and receiver. The TOE operates
as a TLS server for the web GUI/WebAPI providing administration and as a
TLS client for the trusted channel with a syslog server.
29 Note: RSA is not included in the list of key establishment schemes as it is only used
for authentication in TLS, and not key exchange, per the TLS ciphersuites.
6.2.3 FCS_CKM.4
30 Table 14 shows the origin, storage location and destruction details for cryptographic
keys. Unless otherwise stated, the keys are generated by the TOE.
6.2.4 FCS_COP.1/DataEncryption
31 The TOE provides symmetric encryption and decryption capabilities using 128 and
256 bit AES in CBC and GCM mode. AES is implemented in TLS and is used in
BouncyCastle key encryption.
32 The relevant NIST CAVP certificate numbers are listed Table 4.
6.2.5 FCS_COP.1/SigGen
33 The TOE provides cryptographic signature generation and verification services
using:
a) RSA Signature Algorithm with key size of 2048.
34 RSA verification services are used in the TLS. Additionally, RSA signature
verification is used for TOE firmware integrity checks.
35 The relevant NIST CAVP certificate numbers are listed in Table 4.
6.2.6 FCS_COP.1/Hash
36 The TOE provides cryptographic hashing services using SHA-1 and SHA-256.
37 SHS is implemented in the following parts of the TSF:
a) TLS;
b) Digital signature verification as part of trusted update validation;
c) Hashing of passwords in non-volatile storage; and
d) Authentication of NTP server.
38 The relevant NIST CAVP certificate numbers are listed in Table 4.
6.2.7 FCS_COP.1/KeyedHash
39 The TOE provides keyed-hashing message authentication services using HMAC-
SHA-1, and HMAC-SHA-256.
40 HMAC is implemented in TLS and the configuration integrity test.
41 The characteristics of the HMACs used in the TOE are given in Table 13.
Table 13: HMAC Characteristics
Ixia, A Keysight Business Security Target
Page 35 of 92
Algorithm Block Size Key Size Digest Size
HMAC-SHA-1 512 bits 160 bits 160 bits
HMAC-SHA-256 512 bits 256 bits 256 bits
42 The relevant NIST CAVP certificate numbers are listed in Table 4.
6.2.8 FCS_HTTPS_EXT.1
43 The TOE web GUI/WebAPI is accessed via an HTTPS connection using the TLS
implementation described by FCS_TLSS_EXT.1. The TOE does not use HTTPS in a
client capacity. The TOE’s HTTPS protocol complies with RFC 2818.
44 RFC 2818 specifies HTTP over TLS. The majority of RFC 2818 is spent on
discussing practices for validating endpoint identities and how connections must be
setup and torn down. The TOE web GUI/WebAPI operates on an explicit port
designed to natively speak TLS: it does not attempt STARTTLS or similar multi-
protocol negotiation which is described in section 2.3 of RFC 2818. The web server
attempts to send closure Alerts prior to closing a connection in accordance with
section 2.2.2 of RFC 2818.
6.2.9 FCS_NTP_EXT.1
45 The TOE makes use of an NTP v4 client that implements the symmetric key
authentication scheme defined in RFC5905, performing authentication using SHA-1.
46 The TOE does not update NTP time from broadcast or multicast addresses and
supports configuration of at least 3 NTP time sources.
6.2.10 FCS_RBG_EXT.1
47 The TOE contains a Hash_DRBG (any) that is seeded from a hardware entropy
source that provides a minimum of 256 bits of entropy. Additional detail is provided
the proprietary Entropy Description.
6.2.11 FCS_TLSC_EXT.2
48 The TOE operates as a TLS client for the trusted channel with a syslog server.
49 TLS 1.2 is allowed and ciphersuites are restricted to the following:
a) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
b) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
50 Ciphersuites are not user-configurable.
51 The TOE supports 2-way certificate authentication with X.509v3 certificates for
Syslog communication. Only DNS names are supported as acceptable reference
identifiers. For Syslog certificate verification, the TOE compares the reference
identifiers to the identifier in the presented Syslog server’s TLS certificate.
52 When the TLS client receives an X.509 certificate from the server, the client will
compare the reference identifier with the established Subject Alternative Names
(SANs) in the certificate. If a SAN is available and does not match the reference
identifier, then the verification fails and the channel is terminated. If there are no
SANs of the correct type (DNS name) in the certificate, then the TOE will compare
Ixia, A Keysight Business Security Target
Page 36 of 92
the reference identifier to the Common Name (CN) in the certificate Subject. If there
is no CN, then the verification fails and the channel is terminated. If the CN exists
and does not match, then the verification fails and the channel is terminated.
Otherwise, the reference identifier verification passes and additional verification
actions can proceed.
53 The TLS client supports wildcards but does not support certificate pinning.
54 The TLS client will transmit the Supported Elliptic Curves extension in the Client
Hello message by default with support for the following NIST curves: P256, P384,
P521. The non-TOE server can choose to negotiate the elliptic curve from this set
for any of the mutually negotiable elliptic curve ciphersuites.
6.2.12 FCS_TLSS_EXT.1
55 The TOE operates as a TLS server for the web GUI/WebAPI trusted path.
56 The server only allows TLS protocol version1.2 (rejecting any other protocol version,
including SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 and any other unknown TLS
version string supplied) and is restricted to the following ciphersuites by default:
a) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
b) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
c) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
57 Ciphersuites are not user-configurable.
58 The TLS server is capable of negotiating ciphersuites that include ECDHE key
agreement schemes. The TLS server supports NIST curves P256, P384, P521.
6.3 Identification and Authentication
6.3.1 FIA_PMG_EXT.1
59 The TOE supports the local definition of users with corresponding passwords. The
passwords can be composed of any combination of upper and lower case letters,
numbers, and special characters “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “`”, ”~”, ”_”,
”+”, ”-“, ”=”, ”{“, ”}”, “|”, “\”, “:”, “””, ”;”, ”’”, “<”, “>”, “?”, “,”, “.”, “/”, “[”, ”]”.
60 The minimum password length is settable by the Administrator and can range from
15 to 100 characters.
6.3.2 FIA_UIA_EXT.1
61 The TOE requires all users to be successfully identified and authenticated. The TOE
following actions may occur prior to authentication:
a) Display the warning banner;
b) Access to help files (PDF and html format);
c) View alarm notifications (i.e. system health alarms); and
d) View software version number.
62 Administrative access to the TOE is facilitated through:
a) Directly connecting to the TOE via the Serial Console
b) Remotely connecting to the TOE web GUI/WebAPI via HTTPS
Ixia, A Keysight Business Security Target
Page 37 of 92
6.3.3 FIA_UAU_EXT.2
63 Regardless of the interface at which the administrator interacts, the TOE prompts the
user for a credential. Only after the administrative user presents the correct
authentication credentials will they be granted access to the TOE administrative
functionality.
64 The TOE provides a local password based authentication mechanism.
65 The TOE supports local authentication for each management interface.
Authentication is successful when the submitted username and password are
verified against stored values.
6.3.4 FIA_UAU.7
66 For all authentication at the local Serial Console the TOE displays only bullets when
the administrative password is entered so that the password is obscured.
6.3.5 FIA_AFL.1
67 The TOE is capable of tracking authentication failures of remote administrators.
68 When a user account has sequentially failed authentication the configured number of
times (default 3), the account will be locked until a System Administrator performs a
password reset on the account.
69 The administrator can configure the maximum number of failed attempts using the
web GUI/WebAPI or Serial Console.
70 The Serial Console does not implement the lockout mechanism.
6.3.6 FIA_X509_EXT.1/Rev
71 The TOE performs X.509 certificate validation at the following points:
a) TOE TLS client validation of server X.509 certificates;
b) When certificates are loaded into the TOE, such as when importing CAs,
certificate responses and other device-level certificates
72 In all scenarios, certificates are checked for several validation characteristics:
a) If the certificate ‘notAfter’ date is in the past, then this is an expired certificate
which is considered invalid;
b) The certificate chain must terminate with a trusted CA certificate;
c) Server certificates consumed by the TOE TLS client must have a
‘serverAuthentication’ extendedKeyUsage purpose;
d) The TOE validates a certificate path and treats a certificate as a CA certificate
when certificates include the basicConstraints extensions and that the CA flag
is set to “TRUE” for all CA certificates.
73 Certificate revocation checking for the above scenarios is performed using a CRL.
74 As X.509 certificates are not used for trusted updates, firmware integrity self-tests or
client authentication, the code-signing and clientAuthentication purpose is not
checked in the extendedKeyUsage for related certificates.
75 The TOE ensures that the X.509 certificates adhere to RFC 5280 Section 6.3
(certificate validation and certificate path validation), which can be summarized as
follows:
Ixia, A Keysight Business Security Target
Page 38 of 92
a) The public key algorithm and parameters are checked
b) The current date/time is checked against the validity period revocation status
is checked
c) Issuer name of X matches the subject name of X+1
d) Name constraints are checked
e) Policy OIDs are checked
f) Policy constraints are checked; issuers are ensured to have CA signing bits
g) Path length is checked
h) Critical extensions are processed
76 If, during the entire trust chain verification activity, any certificate under review fails a
verification check, then the entire trust chain is deemed untrusted.
6.3.7 FIA_X509_EXT.2
77 The TOE has a trust store where root CA and intermediate CA certificates can be
stored. The trust store is not cached: if a certificate is deleted, it is immediately
untrusted. If a certificate is added to the trust store, it is immediately trusted for its
given scope.
78 Instructions for configuring the trusted IT entities to supply appropriate X.509
certificates are captured in the guidance documents.
79 As part of the verification process, a CRL is used to determine whether the certificate
is revoked or not. If the CRL cannot be obtained, the validation will fail.
6.3.8 FIA_X509_EXT.3
80 The TOE supports the generation of Certificate Request Messages as specified by
RFC 2986 and validates the chain of certificates from the root CA upon receiving the
CA Certificate Response. Certificate Request Messages provided by the TOE
include the following information in the request:
a) Public key
b) Common Name (CN)
c) Organization (O)
d) Organizational Unit (OU)
e) Country (C)
6.4 Security Management
6.4.1 FMT_MOF.1/ManualUpdate
81 The TOE restricts the ability to perform software updates to Security Administrators.
6.4.2 FMT_MOF.1/Functions
82 The TOE restricts the ability to modify (enable/disable) transmission of audit records
to an external audit server to Security Administrators.
Ixia, A Keysight Business Security Target
Page 39 of 92
6.4.3 FMT_MTD.1/CoreData
83 Users are required to login, no TOE functionality is available before identification and
authentication occurs.
6.4.4 FMT_SMR.2
84 The TOE implements role-based access control based on pre-defined profiles that
are assigned when creating a user.
85 Management of TSF data via the Serial Console or Web GUI/WebAPI is restricted to
Security Administrators.
6.4.5 FMT_MTD.1/CryptoKeys
86 The TOE restricts generation, importation, or deletion of cryptographic keys. to
Security Administrators.
6.4.6 FMT_SMF.1
87 The TOE may be managed via the Serial Console or GUI/WebAPI (HTTPS). The
specific management capabilities include:
a) Ability to administer the TOE locally via Serial Console and remotely via web
GUI/WebAPI
b) Ability to configure the access banner via web GUI/WebAPI
c) Ability to configure the session inactivity time before session termination or
locking via web GUI/WebAPI
d) Ability to update the TOE and to verify the updates via web GUI/WebAPI
e) Ability to configure the authentication failure parameters via web GUI/WebAPI
f) Ability to configure audit behavior (enable/disable remote logging) via web
GUI/WebAPI
g) Ability to configure NTP time sources through web GUI/WebAPI
h) Ability to manage the cryptographic keys, including import and management of
X.509v3 certificates via web GUI/WebAPI.
6.5 Protection of the TSF
6.5.1 FPT_SKP_EXT.1
88 Keys are protected as described in Table 14. In all cases, plaintext keys cannot be
viewed through an interface designed specifically for that purpose.
Table 14: Keys
Key Generation/
Algorithm
Storage Destruction
TLS Server
Private Key
BouncyCastle
RSA (2048 bits)
Flash – encrypted
(BCFKS)
n/a as not plaintext.
Ixia, A Keysight Business Security Target
Page 40 of 92
Key Generation/
Algorithm
Storage Destruction
RAM - plaintext JVM garbage collection on
deallocation.
TLS Client Private Key BouncyCastle
RSA (2048 bits)
Flash – encrypted
(BCFKS)
n/a as not plaintext.
RAM - plaintext JVM garbage collection on
deallocation.
TLS Session Keys BouncyCastle
AES (128)
RAM - plaintext JVM garbage collection on
deallocation.
BCFKS Key
Encrypting Key
BouncyCastle –
PBKDF2
AES (256)
Derived / RAM -
plaintext
JVM garbage collection on
deallocation.
NTP Key User generated Flash – plaintext Overwritten with new value of
key via Linux file overwite.
6.5.2 FPT_APW_EXT.1
89 Passwords are protected as describe in Table 15. In all cases plaintext passwords
cannot be viewed through an interface designed specifically for that purpose.
Table 15: Passwords
Password Generation/ Algorithm Storage
Locally stored administrator
passwords
User generated Flash - SHA-1
6.5.3 FPT_TST_EXT.1
90 At startup, the TOE performs the following tests:
a) Firmware integrity test using CRC32
b) Configuration integrity test using HMAC SHA-256
c) Algorithm Known Answer Tests
d) DRBG health checks: instantiate, un-instantiate, generate, and reseed
e) Boot loader image verification – the boot loader verifies the SHA256 hash of
file “mss-upgrade-components.bin” before the software is installed. Before the
“mss-upgrade-components.bin” file is decrypted, the SHA256 hash value will
be verified. .
91 The TOE performs this suite of FIPS power-up and conditional self-tests to verify its
correct operation. If any of the self-tests fail, the TOE enters into a critical error state
and the appliance must be rebooted by an administrator to run the tests again.
Ixia, A Keysight Business Security Target
Page 41 of 92
92 The cryptographic module executes the following conditional tests when the related
service is invoked:
a) Continuous NDRNG test
b) Continuous DRBG test
c) RSA pairwise consistency test
d) Configuration integrity test using HMAC SHA-256
e) Firmware load test with 2048-bit RSA key
6.5.4 FPT_TUD_EXT.1
93 The current firmware version may be queried using GUI/WebAPI.
94 Digitally signed (RSA 2048) upgrade tar files are acquired by contacting Ixia
Technical Support or downloaded via a Customer Portal. Only authorized
administrators can perform manual software upgrades.
95 When the administrator performs the software upgrade, the TOE verifies the digital
signature of the upgrade files using a hardcoded RSA 2048-bit public key.
96 If the digital signature verification fails, the update is aborted, and a log is generated.
97 Upon successful verification, the TOE software extracts the upgrade components
from the tar file and performs the software upgrade. After the software is installed,
the TOE is automatically restarted and requires the administrator to log in again for
the upgrade process to be complete. If the newly installed software fails for any
reason, the TOE software reverts to the previous version without loss of functionality.
6.5.5 FPT_STM_EXT.1
98 The TOE uses external NTP servers to synchronize the clock and provide reliable
timestamps for syslog messages.
99 The TOE provides reliable time stamps for the following:
a) Security Audit functionality
b) Track the inactivity of administrative sessions
c) Cryptographic functions
6.6 TOE Access
6.6.1 FTA_SSL_EXT.1
100 The TOE is configured to terminate local inactive sessions (Serial Console) based
on a specified time period of inactivity configured by a Security Administrator.
6.6.2 FTA_SSL.3
101 The Security Administrator may configure the TOE to terminate an inactive remote
interactive session following a specified period of time.
6.6.3 FTA_SSL.4
102 Administrative users are allowed to terminate their own interactive sessions by
logging out.
Ixia, A Keysight Business Security Target
Page 42 of 92
6.6.4 FTA_TAB.1
103 The TOE displays an administrator configurable message to users prior to login at
the Serial Console and Web GUI.
104 Note: the Web API is not interactive and does not display a banner.
6.7 Trusted Path/Channels
6.7.1 FTP_ITC.1
105 The TOE supports secure communication with the following IT entities:
a) TLS v1.2 for connections to the Syslog server
6.7.2 FTP_TRP.1/Admin
106 The TOE provides the following trusted paths for remote administration:
a) Web GUI/WebAPI over HTTPS per FCS_HTTPS_EXT.1.1
Ixia, A Keysight Business Security Target
Page 43 of 92
7 Rationale
7.1 Conformance Claim Rationale
107 The following rationale is presented with regard to the PP conformance claims:
a) TOE type. As identified in section 2.1, the TOE is network device, consistent
with the NDcPP.
b) Security problem definition. As shown in section 3, the threats, OSPs and
assumptions are reproduced directly from the NDcPP.
c) Security objectives. As shown in section 4, the security objectives are
reproduced directly from the NDcPP.
d) Security requirements. As shown in section 5, the security requirements are
reproduced directly from the NDcPP. No additional requirements have been
specified.
7.2 Security Objectives Rationale
108 All security objectives are drawn directly from the NDcPP.
7.3 Security Requirements Rationale
109 All security requirements are drawn directly from the NDcPP. Table 16 presents a
mapping between threats and SFRs as presented in the NDcPP.
Table 16: NDcPP SFR Rationale
Identifier SFR Rationale
T.UNAUTHORIZED_ADMINIS
TRATOR_ACCESS
• The Administrator role is defined in FMT_SMR.2 and the
relevant administration capabilities are defined in
FMT_SMF.1 and FMT_MTD.1/CoreData, with optional
additional capabilities in FMT_MOF.1/Services and
FMT_MOF.1/Functions
• The actions allowed before authentication of an
Administrator are constrained by FIA_UIA_EXT.1, and
include the advisory notice and consent warning message
displayed according to FTA_TAB.1
• The requirement for the Administrator authentication
process is described in FIA_UAU_EXT.2
• Locking of Administrator sessions is ensured by
FTA_SSL_EXT.1 (for local sessions), FTA_SSL.3 (for
remote sessions), and FTA_SSL.4 (for all interactive
sessions)
• The secure channel used for remote Administrator
connections is specified in FTP_TRP.1/Admin
• (Malicious actions carried out from an Administrator session
are separately addressed by T.UNDETECTED_ACTIVITY)
Ixia, A Keysight Business Security Target
Page 44 of 92
Identifier SFR Rationale
• (Protection of the Administrator credentials is separately
addressed by T.PASSWORD_CRACKING).
T.WEAK_CRYPTOGRAPHY
• Requirements for key generation and key distribution are
set in FCS_CKM.1 and FCS_CKM.2 respectively
• Requirements for use of cryptographic schemes are set in
FCS_COP.1/DataEncryption, FCS_COP.1/SigGen,
FCS_COP.1/Hash, and FCS_COP.1/KeyedHash
• Requirements for random bit generation to support key
generation and secure protocols (see SFRs resulting from
T.UNTRUSTED_COMMUNICATION_CHANNELS) are set
in FCS_RBG_EXT.1
• Management of cryptographic functions is specified in
FMT_SMF.1
T.UNTRUSTED_COMMUNI
CATION_CHANNELS
• The general use of secure protocols for identified
communication channels is described at the top level in
FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the
requirements for inter-component communications are
addressed by the requirements in FPT_ITT.1
• Requirements for the use of secure communication
protocols are set for all the allowed protocols in
FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2,
FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2,
FCS_HTTPS_EXT.1, FCS_IPSEC_EXT.1,
FCS_SSHC_EXT.1, FCS_SSHS_EXT.1,
FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1,
FCS_TLSS_EXT.2
• Optional and selection-based requirements for use of public
key certificates to support secure protocols are defined in
FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
T.WEAK_AUTHENTICATIO
N_ENDPOINTS
• The use of appropriate secure protocols to provide
authentication of endpoints (as in the SFRs addressing
T.UNTRUSTED_COMMUNICATION_CHANNELS) are
ensured by the requirements in FTP_ITC.1 and
FTP_TRP.1/Admin; for distributed TOEs the authentication
requirements for endpoints in inter-component
communications are addressed by the requirements in
FPT_ITT.1
• Additional possible special cases of secure authentication
during registration of distributed TOE components are
addressed by FCO_CPC_EXT.1 and FTP_TRP.1/Join.
T.UPDATE_COMPROMISE • Requirements for protection of updates are set in
FPT_TUD_EXT.1
• Additional optional use of certificate-based protection of
signatures can be specified using FPT_TUD_EXT.2,
supported by the X.509 certificate processing requirements
in FIA_X509_EXT.1, FIA_X509_EXT.2 and
FIA_X509_EXT.3
Ixia, A Keysight Business Security Target
Page 45 of 92
Identifier SFR Rationale
• Requirements for management of updates are defined in
FMT_SMF.1 and (for manual updates) in
FMT_MOF.1/ManualUpdate, with optional requirements for
automatic updates in FMT_MOF.1/AutoUpdate
T.UNDETECTED_ACTIVITY • Requirements for basic auditing capabilities are specified in
FAU_GEN.1 and FAU_GEN.2, with timestamps provided
according to FPT_STM_EXT.1
• Requirements for protecting audit records stored on the
TOE are specified in FAU_STG.1
• Requirements for secure transmission of local audit records
to an external IT entity via a secure channel are specified in
FAU_STG_EXT.1
• Optional additional requirements for dealing with potential
loss of locally stored audit records are specified in
FAU_STG_EXT.2/LocSpace, and FAU_STG.3/LocSpace
• If (optionally) configuration of the audit functionality is
provided by the TOE then this is specified in FMT_SMF.1,
and confining this functionality to Security Administrators is
required by FMT_MOF.1/Functions.
T.SECURITY_FUNCTIONAL
ITY_COMPROMISE
• Protection of secret/private keys against compromise is
specified in FPT_SKP_EXT.1
• Secure destruction of keys is specified in FCS_CKM.4
• If (optionally) management of keys is provided by the TOE
then this is specified in FMT_SMF.1, and confining this
functionality to Security Administrators is required by
FMT_MTD.1/CryptoKeys
• (Protection of passwords is separately covered under
T.PASSWORD_CRACKING)
T.PASSWORD_CRACKING • Requirements for password lengths and available
characters are set in FIA_PMG_EXT.1
• Protection of password entry by providing only obscured
feedback is specified in FIA_UAU.7
• Actions on reaching a threshold number of consecutive
password failures are specified in FIA_AFL.1
• Requirements for secure storage of passwords are set in
FPT_APW_EXT.1.
T.SECURITY_FUNCTIONAL
ITY_FAILURE
• Requirements for running self-test(s) are defined in
FPT_TST_EXT.1
• Optional use of certificates to support self-test(s) is defined
in FPT_TST_EXT.2 (with support for the use of certificates
in FIA_X509_EXT.1, FIA_X509_EXT.2, and
FIA_X509_EXT.3),
Ixia, A Keysight Business Security Target
Page 46 of 92
Annex A: Extended Components Definition
110 This annex reproduces the NDcPP Appendix C extended components definition.
Security Audit (FAU)
Security Audit Data Generation (FAU_GEN_EXT)
Family Behaviour
This component defines the requirements for components in a distributed TOE to generate
security audit data.
Component levelling
FAU_GEN_EXT.1 Security audit data shall be generated by all components in a distributed TOE
Management: FAU_GEN_EXT.1
The following actions could be considered for the management functions in FMT:
a) The TSF shall have the ability to configure the cryptographic functionality.
Audit: FAU_GEN_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) No audit necessary.
FAU_ GEN_EXT.1 Security Audit Data Generation for Distributed TOE
Components
FAU_GEN_EXT.1 Security Audit Data Generation
Hierarchical to: No other components.
Dependencies: None.
FAU_GEN_EXT.1.1. The TSF shall be able to generate audit records for each TOE
component. The audit records generated by the TSF of each TOE
component shall include the subset of security relevant audit events
which can occur on the TOE component.
Application Note 135
Ixia, A Keysight Business Security Target
Page 47 of 92
The TOE must be able to generate audit records for each TOE component. Some TOE
components of a distributed TOE might not implement the complete TSF of the overall TOE but
only a subset of the TSF. The audit records for each TOE component need to cover all security
relevant audit events according to the subset of the TSF implemented by this particular TOE
component but not necessarily all security relevant audit events according to the TSF of the
overall TOE. If a security-relevant event can occur on multiple TOE components, it needs to
cause generation of an audit record uniquely identifying the component associated with the event.
The ST author shall identify for each TOE component which of the overall required audit events
defined in FAU_GEN.1.1 are logged. The ST author may decide to do this by providing a
corresponding table. The information provided needs to be in agreement with Table 1. The overall
TOE needs to cover all auditable events listed in Table 2 (and Tables 4 and 5 as applicable to the
overall TOE).
Protected audit event storage (FAU_STG_EXT)
Family Behaviour
This component defines the requirements for the TSF to be able to securely transmit audit data
between the TOE and an external IT entity.
Component levelling
FAU_STG_EXT.1 Protected audit event storage requires the TSF to use a trusted channel
implementing a secure protocol.
FAU_STG_EXT.2 Counting lost audit data requires the TSF to provide information about audit
records affected when the audit log becomes full.
FAU_STG_EXT.3 Protected Local audit event storage for distributed TOEs requires the TSF to
use a trusted channel to protect audit transfer to another TOE component.
FAU_STG_EXT.4 Protected Remote audit event storage for distributed TOEs requires the TSF to
use a trusted channel to protect audit transfer to another TOE component.
Management: FAU_STG_EXT.1, FAU_STG_EXT.2, FAU_STG_EXT.3, FAU_STG_EXT.4
The following actions could be considered for the management functions in FMT:
a) The TSF shall have the ability to configure the cryptographic functionality.
Audit: FAU_STG_EXT.1, FAU_STG_EXT.2, FAU_STG_EXT.3, FAU_STG_EXT.4
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
Ixia, A Keysight Business Security Target
Page 48 of 92
a) No audit necessary.
FAU_ STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1 Protected Audit Event Storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FTP_ITC.1 Inter-TSF Trusted Channel
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external
IT entity using a trusted channel according to FTP_ITC.
Application Note 136
For selecting the option of transmission of generated audit data to an external IT entity the TOE
relies on a non-TOE audit server for storage and review of audit records. The storage of these
audit records and the ability to allow the Administrator to review these audit records is provided
by the operational environment in that case. Since the external audit server is not part of the
TOE, there are no requirements on it except the capabilities for ITC transport for audit data. No
requirements are placed upon the format or underlying protocol of the audit data being
transferred. The TOE must be capable of being configured to transfer audit data to an external IT
entity without Administrator intervention. Manual transfer would not meet the requirements.
Transmission could be done in real-time or periodically. If the transmission is not done in real-
time then the TSS describes what event stimulates the transmission to be made and what range
of frequencies the TOE supports for making transfers of audit data to the audit server; the TSS
also suggests typical acceptable frequencies for the transfer.
For distributed TOEs each component must be able to export audit data across a protected
channel external (FTP_ITC.1) or intercomponent (FPT_ITT.1 or FTP_ITC.1) as appropriate. At
least one component of the TOE must be able to export audit records via FTP_ITC.1 such that all
TOE audit records can be exported to an external IT entity.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
[selection:
• TOE shall consist of a single standalone component that stores audit
data locally,
• The TOE shall be a distributed TOE that stores audit data on the
following TOE components: [assignment: identification of TOE
components],
• The TOE shall be a distributed TOE with storage of audit data
provided externally for the following TOE components: [assignment:
list of TOE components that do not store audit data locally and the
other TOE components to which they transmit their generated audit
data].
Application Note 137
If the TOE is a standalone TOE (i.e. not a distributed TOE) the option 'The TOE shall consist of a
single standalone component that stores audit data locally' shall be selected.
If the TOE is a distributed TOE the option 'The TOE shall be a distributed TOE that stores audit
data on the following TOE components: [assignment: identification of TOE components]' shall be
selected and the TOE components which store audit data locally shall be listed in the assignment.
Ixia, A Keysight Business Security Target
Page 49 of 92
Since all TOEs are required to provide functions to store audit data locally this option needs to be
selected for all distributed TOEs. In addition, FAU_GEN_EXT.1 and FAU_STG_EXT.3 shall be
claimed in the ST. If the distributed TOE consists only of components which are storing audit data
locally, it is sufficient to select only the option 'The TOE shall be a distributed TOE that stores
audit data on the following TOE components: [assignment: identification of TOE components]'
and add FAU_GEN_EXT.1 and FAU_STG_EXT.3.
If the TOE is a distributed TOE and some TOE components are not storing audit data locally, the
option 'The TOE shall be a distributed TOE with storage of audit data provided externally for the
following TOE components: [assignment: list of TOE components that do not store audit data
locally and the other TOE components to which they transmit their generated audit data]' shall be
selected in addition to the option 'The TOE shall be a distributed TOE that stores audit data on
the following TOE components: [assignment: identification of TOE components]'. In that case
FAU_STG_EXT.4 shall be claimed in the ST in addition to FAU_GEN_EXT.1 and
FAU_STG_EXT.3. For the option 'The TOE shall be a distributed TOE with storage of audit data
provided externally for the following TOE components: [assignment: list of TOE components that
do not store audit data locally and the other TOE components to which they transmit their
generated audit data]' the TOE components that to not store audit data locally shall be mapped to
the TOE components to which they transmit their generated audit data.
For distributed TOEs this SFR can be fulfilled either by every TOE component storing its own
security audit data locally or by one or more TOE components storing audit data locally and other
TOE components which are not storing audit information locally sending security audit data to
other TOE components for local storage. For the transfer of security audit data between TOE
components a protected channel according to FTP_ITC.1 or FPT_ITT.1 shall be used. The TSS
shall describe which TOE components store security audit data locally and which TOE
components do not store security audit data locally. For the latter, the TSS shall describe at which
other TOE component the audit data is stored locally.
FAU_STG_EXT.1.3 The TSF shall [selection: drop new audit data, overwrite previous audit
records according to the following rule: [assignment: rule for overwriting previous audit records],
[assignment: other action]] when the local storage space for audit data is full.
Application Note 138
The external log server might be used as alternative storage space in case the local storage
space is full. The “other action” could in this case be defined as “send the new audit data to an
external IT entity”.
For distributed TOEs each component is not required to store generated audit data locally but the
overall TOE needs to be able to store audit data locally. Each component must at least provide
the ability to temporarily buffer audit information locally to ensure that audit records are preserved
in case of network connectivity issues. Buffering audit information locally, does not necessarily
involve non-volatile memory: audit information could be buffered in volatile memory. However, the
local storage of audit information in the sense of FAU_STG_EXT.1.3 needs to be done in non-
volatile memory. For every component which performs local storage of audit information, the
behaviour when local storage is exhausted needs to be described. For every component which is
buffering audit information instead of storing audit information locally itself, it needs to be
described what happens in case the buffer space is exhausted.
FAU_ STG_EXT.2 Counting lost audit data
FAU_STG_EXT.2 Counting lost audit data
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG_EXT.1 External Audit Trail Storage
Ixia, A Keysight Business Security Target
Page 50 of 92
FAU_STG_EXT.2.1 The TSF shall provide information about the number of [selection:
dropped, overwritten, [assignment: other information]] audit records in
the case where the local storage has been filled and the TSF takes one
of the actions defined in FAU_STG_EXT.1.3.
Application Note 139
This option should be chosen if the TOE supports this functionality.
In case the local storage for audit records is cleared by the Administrator, the counters associated
with the selection in the SFR should be reset to their initial value (most likely to 0). The guidance
documentation should contain a warning for the Administrator about the loss of audit data when
he clears the local storage for audit records.
For distributed TOEs each component that implements counting of lost audit data has to provide
a mechanism for Administrator access to, and management of, this information.
If FAU_STG_EXT.2 is added to the ST, the ST has to make clear any situations in which lost
audit data is not counted.
FAU_ STG_EXT.3 Protected Local Audit Event Storage for Distributed
TOEs
FAU_STG_EXT.3 Protected Audit Event Storage
Hierarchical to: No other components.
Dependencies: FAU_GEN_EXT.1 Security Audit data generation for Distributed TOE
Components [FPT_ITT.1 Intra-TSF Trusted Channel or FTP_ITC.1 Inter-
TSF Trusted Channel]
FAU_STG_EXT.3.1 The TSF of each TOE component which stores security audit data locally
shall perform the following actions when the local storage space for audit
data is full: [assignment: table of components and for each component its
action chosen according to the following: [selection: drop new audit data,
overwrite previous audit records according to the following rule:
[assignment: rule for overwriting previous audit records], [assignment:
other action]]].
Application Note 140
If a component of a distributed TOE collects data from other components and then forwards it to
another component or external IT entity (cf. FAU_STG_EXT.1.1) then the operations in this SFR
must be performed in a way to cover the storage space action(s) for all of the audit data that the
TOE collects (i.e. not just for the data generated by the collecting component for itself).
It is acceptable for a TOE component to store audit information in multiple places (e.g. for
redundancy), whether locally in the TOE component itself and in another TOE component, or in
more than one other TOE component.
TOE components are not required to monitor or audit connectivity or network outages between
TOE components. This aspect is covered by the assumption A.COMPONENTS_RUNNING.
FAU_ STG_EXT.4 Protected Remote Audit Event Storage for Distributed
TOEs
FAU_STG_EXT.4 Protected Audit Event Storage
Hierarchical to: No other components.
Ixia, A Keysight Business Security Target
Page 51 of 92
Dependencies: FAU_GEN_EXT.1 Security Audit data generation for Distributed TOE
Components [FPT_ITT.1 Intra-TSF Trusted Channel or FTP_ITC.1 Inter-
TSF Trusted Channel]
FAU_STG_EXT.4.1 Each TOE component which does not store security audit data locally
shall be able to buffer security audit data locally until it has been
transferred to another TOE component that stores or forwards it. All
transfer of audit records between TOE components shall use a protected
channel according to [selection: FPT_ITT.1, FTP_ITC.1].
Application Note 141
If a component of a distributed TOE collects data from other components and then forwards it to
another component or external IT entity (cf. FAU_STG_EXT.1.1) then the operations in this SFR
must be performed in a way to cover the storage space action(s) for all of the audit data that the
TOE collects (i.e. not just for the data generated by the collecting component for itself).
It is acceptable for a TOE component to store audit information in multiple places (e.g. for
redundancy), whether locally in the TOE component itself and in another TOE component, or in
more than one other TOE component.
TOE components are not required to monitor or audit connectivity or network outages between
TOE components. This aspect is covered by the assumption A.COMPONENTS_RUNNING.
Cryptographic Support (FCS)
Random Bit Generation (FCS_RBG_EXT)
FCS_RBG_EXT.1 Random Bit Generation
Family Behaviour
Components in this family address the requirements for random bit/number generation. This is a
new family defined for the FCS class.
Component levelling
FCS_RBG_EXT.1 Random Bit Generation requires random bit generation to be performed in
accordance with selected standards and seeded by an entropy source.
Management: FCS_RBG_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen
Audit: FCS_RBG_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Minimal: failure of the randomization process
FCS_RBG_EXT.1 Random Bit Generation
Hierarchical to: No other components
Ixia, A Keysight Business Security Target
Page 52 of 92
Dependencies: No other components
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [selection: Hash_DRBG
(any), HMAC_DRBG (any), CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [selection: [assignment: number of
software-based sources] software-based noise source, [assignment:
number of hardware-based sources] hardware-based noise source] with
a minimum of [selection: 128 bits, 192 bits, 256 bits] of entropy at least
equal to the greatest security strength, according to ISO/IEC 18031:2011
Table C.1 “Security Strength Table for Hash Functions”, of the keys and
hashes that it will generate.
Application Note 142
For the first selection in FCS_RBG_EXT.1.2, the ST author selects at least one of the types of
noise sources. If the TOE contains multiple noise sources of the same type, the ST author fills the
assignment with the appropriate number for each type of source (e.g., 2 software-based noise
sources, 1 hardware-based noise source). The documentation and tests required in the
Evaluation Activity for this element should be repeated to cover each source indicated in the ST.
ISO/IEC 18031:2011 contains three different methods of generating random numbers; each of
these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST
author will select the function used and include the specific underlying cryptographic primitives
used in the requirement. While any of the identified hash functions (SHA-1, SHA-256, SHA-384,
SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for
CTR_DRBG are allowed.
If the key length for the AES implementation used here is different than that used to encrypt the
user data, then FCS_COP.1 may have to be adjusted or iterated to reflect the different key
length. For the selection in FCS_RBG_EXT.1.2, the ST author selects the minimum number of
bits of entropy that is used to seed the RBG, which must be equal or greater than the security
strength of any key generated by the TOE.
Cryptographic Protocols (FCS_DTLSC_EXT, FCS_DTLSS_EXT,
FCS_HTTPS_EXT, FCS_IPSEC_EXT, FCS_NTP_EXT, FCS_SSHC_EXT,
FCS_SSHS_EXT, FCS_TLSC_EXT, FCS_TLSS_EXT)
FCS_DTLSC_EXT DTLS Client Protocol
Family Behaviour
The component in this family addresses the ability for a client to use DTLS to protect data
between the client and a server using the DTLS protocol.
Component levelling
FCS_DTLSC_EXT.1 DTLS Client requires that the client side of DTLS be implemented as
specified.
Ixia, A Keysight Business Security Target
Page 53 of 92
FCS_DTLSC_EXT.2 DTLS Client requires that the client side of the DTLS implementation include
mutual authentication.
Management: FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of DTLS session establishment
b) DTLS session establishment
c) DTLS session termination
FCS_DTLSC_EXT.1 DTLS Client Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM. 1DataEncryption1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen1SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_DTLSC_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347), DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
[assignment: List of optional ciphersuites and reference to RFC in which
each is defined]
Application Note 143
The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The
ST author should select the ciphersuites that are supported.
These requirements will be revisited as new DTLS versions are standardized by the IETF.
In a future version of this cPP DTLS v1.2 will be required for all TOEs.
FCS_DTLSC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference
identifier according to RFC 6125 section 6.
Application Note 144
The rules for verification of identity are described in Section 6 of RFC 6125. The reference
identifier is established by the Administrator (e.g. entering a URL into a web browser or clicking a
link), by configuration (e.g. configuring the name of a mail server or authentication server), or by
an application (e.g. a parameter of an API) depending on the application service. Based on a
singular reference identifier’s source domain and application service type (e.g. HTTP, SIP,
LDAP), the client establishes all reference identifiers which are acceptable, such as a Common
Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name,
and Service Name for the Subject Alternative Name field. The client then compares this list of all
acceptable reference identifiers to the presented identifiers in the DTLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using DNS names, URI
names, or Service Names. Verification using the Common Name is required for the purposes of
backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or
Ixia, A Keysight Business Security Target
Page 54 of 92
Subject Alternative name is discouraged as against best practices but may be implemented.
Finally, the client should avoid constructing reference identifiers using wildcards. However, if the
presented identifiers include wildcards, the client must follow the best practices regarding
matching; these best practices are captured in the evaluation activity.
FCS_DTLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF
shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented server certificate
].
Application Note 145
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If DTLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
If DTLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_DTLSC_EXT.1.4 The TSF shall [selection: not present the Supported Elliptic Curves
Extension, present the Supported Elliptic Curves Extension with the
following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and
no other curves] in the Client Hello.
Application Note 146
If ciphersuites with elliptic curves were selected in FCS_DTLSC_EXT.1.1, a selection of one or
more curves is required. If no ciphersuites with elliptic curves were selected in
FCS_DTLS_EXT.1.1, then “not present the Supported Elliptic Curves Extension” should be
selected.
This requirement limits the elliptic curves allowed for authentication and key agreement to the
NIST curves from FCS_COP.1/SigGen and FCS_CKM.1 and FCS_CKM.2. This extension is
required for clients supporting Elliptic Curve ciphersuites.
FCS_DTLSC_EXT.2 DTLS Client Protocol with Authentication
Hierarchical to: FCS_DTLSC_EXT.1 DTLS Client Protocol
Dependencies: FCS_CKM.1/DataEncryption Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
Ixia, A Keysight Business Security Target
Page 55 of 92
FCS_DTLSC_EXT.2.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347), DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
• [assignment: List of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 147
The ST author should select the ciphersuites that are supported.
These requirements will be revisited as new DTLS versions are standardized by the IETF.
In a future version of this cPP DTLS v1.2 will be required for all TOEs.
FCS_DTLSC_EXT.2.2 The TSF shall verify that the presented identifier matches the reference
identifier according to RFC 6125 section 6.
Application Note 148
The rules for verification of identity are described in Section 6 of RFC 6125. The reference
identifier is established by the Administrator (e.g. entering a URL into a web browser or clicking a
link), by configuration (e.g. configuring the name of a mail server or authentication server), or by
an application (e.g. a parameter of an API) depending on the application service. Based on a
singular reference identifier’s source domain and application service type (e.g. HTTP, SIP,
LDAP), the client establishes all reference identifiers which are acceptable, such as a Common
Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name,
and Service Name for the Subject Alternative Name field. The client then compares this list of all
acceptable reference identifiers to the presented identifiers in the DTLS server’s certificate.
FCS_DTLSC_EXT.2.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF
shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented server certificate
].
Application Note 149
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If DTLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
If DTLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_DTLSC_EXT.2.4 The TSF shall [selection: not present the Supported Elliptic Curves
Extension, present the Supported Elliptic Curves Extension with the
following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and
no other curves] in the Client Hello].
Application Note 150
If ciphersuites with elliptic curves were selected in FCS_DTLSC_EXT.2.1, a selection of one or
more curves is required. If no ciphersuites with elliptic curves were selected in
FCS_DTLS_EXT.2.1, then “not present the Supported Elliptic Curves Extension” should be
selected.
Ixia, A Keysight Business Security Target
Page 56 of 92
This requirement limits the elliptic curves allowed for authentication and key agreement to the
NIST curves from FCS_COP.1/SigGen and FCS_CKM.1 and FCS_CKM.2. This extension is
required for clients supporting Elliptic Curve ciphersuites.
FCS_DTLSC_EXT.2.5 The TSF shall support mutual authentication using X.509v3 certificates.
Application Note 151
The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement
adds that this use must include the client must be capable of presenting a certificate to a DTLS
server for DTLS mutual authentication.
FCS_DTLSC_EXT.2.6 The TSF shall [selection: terminate the DTLS session, silently discard
the record] if a message received contains an invalid MAC.
Application Note 152
The Message Authentication Code (MAC) is negotiated during DTLS handshake phase and is
used to protect integrity of messages received from the sender during DTLS data exchange. If
MAC verification fails, the session must be terminated or the record must be silently discarded.
FCS_DTLSC_EXT.2.7 The TSF shall detect and silently discard replayed messages for:
• DTLS records previously received.
• DTLS records too old to fit in the sliding window.
Application Note 153
Replay Detection is described in section 4.1.2.6 of DTLS 1.2 (RFC 6347) and section 4.1.2.5 of
DTLS 1.0 (RFC 4347). For each received record, the receiver verifies the record contains a
sequence number is within the sliding receive window and does not duplicate the sequence
number of any other record received during the session.
"Silently Discard" means the TOE discards the packet responding.
FCS_DTLSS_EXT DTLS Server Protocol
Family Behaviour
The component in this family addresses the ability for a server to use DTLS to protect data
between a client and the server using the DTLS protocol.
Component levelling
FCS_DTLSS_EXT.1 DTLS Server requires that the server side of TLS be implemented as
specified.
FCS_DTLSS_EXT.2: DTLS Server requires the mutual authentication be included in the DTLS
implementation.
Management: FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of DTLS session establishment.
b) DTLS session establishment
Ixia, A Keysight Business Security Target
Page 57 of 92
c) DTLS session termination
FCS_DTLSS_EXT.1 DTLS Server Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1//DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1//SigGen Cryptographic operation (Signature Generation
and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_DTLSS_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347), DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
• [assignment: List of optional ciphersuites and reference to RFC in
which each is defined]
Application Note 154
The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The
ST author should select the ciphersuites that are supported.
These requirements will be revisited as new DTLS versions are standardized by the IETF.
In a future version of this cPP DTLS v1.2 will be required for all TOEs.
FCS_DTLSS_EXT.1.2 The TSF shall deny connections from clients requesting [assignment: list
of protocol versions].
Application Note 155
This version of the cPP does not require the TOE to deny DTLS v1.0. In a future version of this
cPP DTLS v1.0 will be required to be denied for all TOEs.
FCS_DTLSS_EXT.1.3 The TSF shall not proceed with a connection handshake attempt if the
DTLS Client fails validation.
Application Note 156
The process to validate the IP address of a DTLS client is specified in section 4.2.1 of RFC 6347
(DTLS 1.2) and RFC 4347 (DTLS 1.0). The TOE validates the DTLS client during Connection
Establishment (Handshaking) and prior to the TSF sending a Server Hello message. After
receiving a ClientHello, the DTLS Server sends a HelloVerifyRequest along with a cookie. The
cookie is a signed message using the keyed hash function specified in FCS_COP.1 /KeyedHash.
The DTLS Client then sends another ClientHello with the cookie attached. If the DTLS server
successfully verifies the signed cookie, the Client is not using a spoofed IP address.
FCS_DTLSS_EXT.1.4 The TSF shall [selection: perform RSA key establishment with key size
[selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman
parameters over NIST curves [selection: secp256r1, secp384r1,
secp521r1] and no other curves; generate Diffie-Hellman parameters of
size [selection: 2048 bits, 3072 bits]].
Application Note 157
Ixia, A Keysight Business Security Target
Page 58 of 92
If the ST lists a DHE or ECDHE ciphersuite in FCS_DTLSS_EXT.1.1, the ST must include the
Diffie-Hellman or NIST curves selection in the requirement. FMT_SMF.1 requires the
configuration of the key agreement parameters in order to establish the security strength of the
DTLS connection.
FCS_DTLSS_EXT.1.5 The TSF shall [selection: terminate the DTLS session, silently discard
the record] if a message received contains an invalid MAC.
Application Note 158
The Message Authentication Code (MAC) is negotiated during DTLS handshake phase and is
used to protect integrity of messages received from the sender during DTLS data exchange. If
MAC verification fails, the session must be terminated or the record must be silently discarded.
FCS_DTLSS_EXT.1.6 The TSF shall detect and silently discard replayed messages for:
• DTLS records previously received.
• DTLS records too old to fit in the sliding window.
Application Note 159
Replay Detection is described in section 4.1.2.6 of DTLS 1.2 (RFC 6347) and section 4.1.2.5 of
DTLS 1.0 (RFC 4347). For each received record, the receiver verifies the record contains a
sequence number is within the sliding receive window and does not duplicate the sequence
number of any other record received during the session.
"Silently Discard" means the TOE discards the packet without responding.
FCS_DTLSS_EXT.2 DTLS Server Protocol with mutual authentication
Hierarchical to: FCS_DTLSS_EXT.1 DTLS Server Protocol
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1//DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1//SigGen Cryptographic operation (Signature Generation
and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_DTLSS_EXT.2.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347), DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
• [assignment: List of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 160
The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The
ST author should select the ciphersuites that are supported.
These requirements will be revisited as new DTLS versions are standardized by the IETF.
In a future version of this cPP DTLS v1.2 will be required for all TOEs.
FCS_DTLSS_EXT.2.2 The TSF shall deny connections from clients requesting [assignment: list
of protocol versions].
Application Note 161
Ixia, A Keysight Business Security Target
Page 59 of 92
This version of the cPP does not require the TOE to deny DTLS v1.0. In a future version of this
cPP DTLS v1.0 will be required to be denied for all TOEs.
FCS_DTLSS_EXT.2.3 The TSF shall not proceed with a connection handshake attempt if the
DTLS Client fails validation.
Application Note 162
The process to validate the IP address of a DTLS client is specified in section 4.2.1 of RFC 6347
(DTLS 1.2) and RFC 4347 (DTLS 1.0). The TOE validates the DTLS client during Connection
Establishment (Handshaking) and prior to the TSF sending a Server Hello message. After
receiving a ClientHello, the DTLS Server sends a HelloVerifyRequest along with a cookie. The
cookie is a signed message using the keyed hash function specified in FCS_COP.1/KeyedHash.
The DTLS Client then sends another ClientHello with the cookie attached. If the DTLS server
successfully verifies the signed cookie, the Client is not using a spoofed IP address.
FCS_DTLSS_EXT.2.4 The TSF shall [selection: perform RSA key establishment with key size
[selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman
parameters over NIST curves [selection: secp256r1, secp384r1,
secp521r1] and no other curves; generate Diffie-Hellman parameters of
size [selection: 2048 bits, 3072 bits]].
Application Note 163
If the ST lists a DHE or ECDHE ciphersuite in FCS_DTLSS_EXT.2.1, the ST must include the
Diffie-Hellman or NIST curves selection in the requirement. FMT_SMF.1 requires the
configuration of the key agreement parameters in order to establish the security strength of the
DTLS connection.
FCS_DTLSS_EXT.2.5 The TSF shall [selection: terminate the DTLS session, silently discard the
record] if a message received contains an invalid MAC.
Application Note 164
The Message Authentication Code (MAC) is negotiated during the DTLS handshake phase and is
used to protect integrity of messages received from the sender during DTLS data exchange. If
MAC verification fails, the session must be terminated or the record must be silently discarded.
FCS_DTLSS_EXT.2.6 The TSF shall detect and silently discard replayed messages for:
• DTLS records that have previously been received.
• DTLS records too old to fit in the sliding window.
Application Note 165
Replay Detection is described in section 4.1.2.6 of DTLS 1.2 (RFC 6347) and section 4.1.2.5 of
DTLS 1.0 (RFC 4347). For each received record, the receiver verifies the record contains a
sequence number is within the sliding receive window and does not duplicate the sequence
number of any other record received during the session.
"Silently Discard" means the TOE discards the packet without responding.
FCS_DTLSS_EXT.2.7 The TSF shall support mutual authentication of DTLS clients using
X.509v3 certificates.
Application Note 166
The use of X.509v3 certificates for DTLS is addressed in FIA_X509_EXT.2.1. This requirement
adds that this use must include support for client-side certificates for DTLS mutual authentication.
FCS_DTLSS_EXT.2.8 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the client certificate is invalid. The TSF
shall also [selection:
• Not implement any administrator override mechanism
Ixia, A Keysight Business Security Target
Page 60 of 92
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented client certificate
].
Application Note 167
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If DTLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
If DTLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_DTLSS_EXT.2.9 The TSF shall not establish a trusted channel if the distinguished name
(DN) or Subject Alternative Name (SAN) contained in a certificate does
not match the expected identifier for the client.
Application Note 168
The client identifier may be in the Subject field or the Subject Alternative Name extension of the
certificate. The expected identifier may either be configured, may be compared to the Domain
Name, IP address, username, or email address used by the peer, or may be passed to a
directory server for comparison.
FCS_HTTPS_EXT.1 HTTPS Protocol
Family Behaviour
Components in this family define the requirements for protecting remote management sessions
between the TOE and a Security Administrator. This family describes how HTTPS will be
implemented. This is a new family defined for the FCS Class.
Component levelling
FCS_HTTPS_EXT.1 HTTPS requires that HTTPS be implemented according to RFC 2818 and
supports TLS.
Management: FCS_HTTPS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_HTTPS_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) There are no auditable events foreseen.
FCS_HTTPS_EXT.1 HTTPS Protocol
Hierarchical to: No other components
Ixia, A Keysight Business Security Target
Page 61 of 92
Dependencies: [FCS_TLSC_EXT.1 TLS Client Protocol, or
FCS_TLSS_EXT.1 TLS Server Protocol]
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC
2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement the HTTPS protocol using TLS.
FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [selection: not establish
the connection, request authorization to establish the connection,
[assignment: other action]] if the peer certificate is deemed invalid.
FCS_IPSEC_EXT.1 IPsec Protocol
Family Behaviour
Components in this family address the requirements for protecting communications using IPsec.
Component levelling
FCS_IPSEC_EXT.1 IPsec requires that IPsec be implemented as specified.
Management: FCS_IPSEC_EXT.1
The following actions could be considered for the management functions in FMT:
a) Maintenance of SA lifetime configuration
Audit: FCS_IPSEC_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Decisions to DISCARD, BYPASS, PROTECT network packets processed by the TOE.
b) Failure to establish an IPsec SA
c) IPsec SA establishment
d) IPsec SA termination
e) Negotiation “down” from an IKEv2 to IKEv1 exchange.
FCS_IPSEC_EXT.1 Internet Protocol Security (IPsec) Communications
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
Ixia, A Keysight Business Security Target
Page 62 of 92
FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC
4301.
Application Note 169
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 SPD 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.
FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches
anything that is otherwise unmatched, and discards it.
FCS_IPSEC_EXT.1.3 The TSF shall implement [selection: tunnel mode, transport mode].
FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC
4303 using the cryptographic algorithms [selection: AES-CBC-128, AES-
CBC-192, AES-CBC-256 (specified in RFC 3602), no other algorithm]
together with a Secure Hash Algorithm (SHA)-based HMAC [selection:
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, no
other algorithm] and [selection: AES-GCM-128, AES-GCM-192, AES-
GCM-256 (specified in RFC 4106), no other algorithm].
FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [selection:
• IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs
2407, 2408, 2409, RFC 4109, [selection: no other RFCs for extended
sequence numbers, RFC 4304 for extended sequence numbers],
and [selection: no other RFCs for hash functions, RFC 4868 for hash
functions];
• IKEv2 as defined in RFCs 5996 [selection: with no support for NAT
traversal, with mandatory support for NAT traversal as specified in
RFC 5996, section 2.23)], and [selection: no other RFCs for hash
functions, RFC 4868 for hash functions]].
FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [selection: IKEv1,
IKEv2] protocol uses the cryptographic algorithms [selection: AES-CBC-
128, AES_CBC-192 AES-CBC-256 (specified in RFC 3602), AES-GCM-
128, AES-GCM-192, AES-GCM-256 (specified in RFC 5282)].
Application Note 170
AES-GCM-128, AES-GCM-192 and AES-GCM-256 may only be selected if IKEv2 is also
selected, as there is no RFC defining AES-GCM for IKEv1.
FCS_IPSEC_EXT.1.7 The TSF shall ensure that [selection:
• IKEv1 Phase 1 SA lifetimes can be configured by a Security
Administrator based on [selection:
o number of bytes;
o length of time, where the time values can be configured
within [assignment: integer range including 24] hours;
Ixia, A Keysight Business Security Target
Page 63 of 92
];
• IKEv2 SA lifetimes can be configured by a Security Administrator
based on [selection:
o number of bytes;
o length of time, where the time values can be configured
within [assignment: integer range including 24] hours
]
].
Application Note 171
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or both, depending
on the selection in FCS_IPSEC_EXT.1.5). The ST author chooses either volume-based lifetimes
or time-based lifetimes (or a combination). This requirement must be accomplished by providing
Security Administrator-configurable lifetimes (with appropriate instructions in documents
mandated by AGD_OPE). Hardcoded limits do not meet this requirement. In general, instructions
for setting the parameters of the implementation, including lifetime of the SAs, should be included
in the guidance documentation generated for AGD_OPE.
FCS_IPSEC_EXT.1.8 The TSF shall ensure that [selection:
• IKEv1 Phase 2 SA lifetimes can be configured by a Security
Administrator based on [selection:
o number of bytes;
o length of time, where the time values can be configured
within [assignment: integer range including 8] hours;
];
• IKEv2 Child SA lifetimes can be configured by a Security
Administrator based on [selection:
o number of bytes;
o length of time, where the time values can be configured
within [assignment: integer range including 8] hours;
]
].
Application Note 172
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or both, depending
on the selection in FCS_IPSEC_EXT.1.5). The ST author chooses either volume-based lifetimes
or time-based lifetimes (or a combination). This requirement must be accomplished by providing
Security Administrator-configurable lifetimes (with appropriate instructions in documents
mandated by AGD_OPE). Hardcoded limits do not meet this requirement. In general, instructions
for setting the parameters of the implementation, including lifetime of the SAs, should be included
in the guidance documentation generated for AGD_OPE.
FCS_IPSEC_EXT.1.9 The TSF 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 security strength of
the negotiated Diffie-Hellman group] bits.
Ixia, A Keysight Business Security Target
Page 64 of 92
Application Note 173
For DH groups 19 and 20, the "x" value is the point multiplier for the generator point G.
Since the implementation may allow different Diffie-Hellman groups to be negotiated for use in
forming the SAs, the assignment in FCS_IPSEC_EXT.1.9 may contain multiple values. For each
DH group supported, the ST author consults Table 2 in NIST SP 800-57 “Recommendation for
Key Management – Part 1: General” to determine the security strength (“bits of security”)
associated with the DH group. Each unique value is then used to fill in the assignment for this
element. 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.
FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [selection: IKEv1, IKEv2]
exchanges of length [selection:
• according to the security strength associated with the negotiated
Diffie-Hellman group;
• at least 128 bits in size and at least half the output size of the
negotiated pseudorandom function (PRF) hash
].
Application Note 174
The ST author must select the second option for nonce lengths if IKEv2 is also selected (as this is
mandated in RFC 5996). The ST author may select either option for IKEv1.
For the first option for nonce lengths, since the implementation may allow different Diffie-Hellman
groups to be negotiated for use in forming the SAs, the assignment in FCS_IPSEC_EXT.1.10
may contain multiple values. For each DH group supported, the ST author consults Table 2 in
NIST SP 800-57 “Recommendation for Key Management –Part 1: General” to determine the
security strength (“bits of security”) associated with the DH group. Each unique value is then used
to fill in the assignment for this element. 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.
Because nonces may be exchanged before the DH group is negotiated, the nonce used should
be large enough to support all TOE-chosen proposals in the exchange.
FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Group(s)
[selection: 14 (2048-bit MODP), 19 (256-bit Random ECP), 20 (384-bit
Random ECP), 24 (2048-bit MODP with 256-bit POS)].
FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the
symmetric algorithm (in terms of the number of bits in the key) negotiated
to protect the [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 175
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.
FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication
using [selection: RSA, ECDSA] that use X.509v3 certificates that
Ixia, A Keysight Business Security Target
Page 65 of 92
conform to RFC 4945 and [selection: Pre-shared Keys, no other
method].
FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented identifier
in the received certificate matches the configured reference identifier,
where the presented and reference identifiers are of the following fields
and types: [selection: SAN: IP address, SAN: Fully Qualified Domain
Name (FQDN), SAN: user FQDN, CN: IP address, CN: Fully Qualified
Domain Name (FQDN), CN: user FQDN, Distinguished Name (DN)] and
[selection: no other reference identifier type, [assignment: other
supported reference identifier types]].
FCS_NTP_EXT.1 NTP Protocol
Family Behaviour
The component in this family addresses the ability for a TOE to protect NTP time synchronization
traffic.
Component levelling
FCS_NTP_EXT.1 Requires NTP to be implemented as specified
Management: FCS_NTP_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure NTP
Audit: FCS_NTP_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) No audit requirements are specified.
FCS_NTP_EXT.1 NTP Protocol
Hierarchical to: No other components
Dependencies: FCS_COP.1 Cryptographic operation
[FCS_DTLSC_EXT.1 DTLC Client Protocol or
FCS_IPSEC_EXT.1 IPsec Protocol]
FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [selection: NTP v3
(RFC 1305), NTP v4 (RFC 5905)].
FCS_NTP_EXT.1.2 The TSF shall update its system time using [selection:
• Authentication using [selection: SHA1, SHA256, SHA384, SHA512,
AES-CBC-128, AES-CBC-256] as the message digest algorithm(s);
• [selection: IPsec, DTLS] to provide trusted communication between
itself and an NTP time source.
].
Ixia, A Keysight Business Security Target
Page 66 of 92
FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or
multicast addresses.
Application Note 176
The broadcast and multicast addresses are deemed as any addressing scheme designed to be
one-to-many.
FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time
sources.
Application Note 177
The TOE has to support configuration of at least three (3) time sources though not mandated that
the TOE is configured to always use at least 3 time sources.
FCS_SSHC_EXT.1 SSH Client
Family Behaviour
The component in this family addresses the ability for a client to use SSH to protect data between
the client and a server using the SSH protocol.
Component levelling
FCS_SSHC_EXT.1 SSH Client requires that the client side of SSH be implemented as specified.
Management: FCS_SSHC_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSHC_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of SSH session establishment
b) SSH session establishment
c) SSH session termination
FCS_SSHC_EXT.1 SSH Client Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
Ixia, A Keysight Business Security Target
Page 67 of 92
FCS_SSHC_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s)
[selection: 4251, 4252, 4253, 4254, 5647, 5656, 6187, 6668, 8332].
Application Note 178
The ST author selects which of the RFCs to which conformance is being claimed. Note that these
need to be consistent with selections in later elements of this component (e.g., cryptographic
algorithms permitted). RFC 4253 indicates that certain cryptographic algorithms are
“REQUIRED”. This means that the implementation must include support, not that the algorithms
must be enabled for use. Ensuring that algorithms indicated as “REQUIRED” but not listed in the
later elements of this component are implemented is out of scope of the evaluation activity for this
requirement.
RFC 5647 only applies to the RFC compliant implementation of GCM; a TOE that only
implements the “@openssh.com” variant of GCM should not select 5647. aes*-
gcm@openssh.com is specified in Section 1.6 of the OpenSSH Protocol Specification
(https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.31).
FCS_SSHC_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-
based, [selection: password-based, no other method].
FCS_SSHC_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [assignment: number of bytes] bytes in an SSH transport
connection are dropped.
Application Note 179
RFC 4253 provides for the acceptance of “large packets” with the caveat that the packets should
be of “reasonable length” or dropped. The assignment should be filled in by the ST author with
the maximum packet size accepted, thus defining “reasonable length” for the TOE.
FCS_SSHC_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption
algorithms: [assignment: list of encryption algorithms].
FCS_SSHC_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [selection: ssh-rsa, rsa-sha2-256, rsa-sha2-512,
ecdsa-sha2-nistp256, x509v3-ssh-rsa, ecdsa-sha2-nistp384, ecdsa-
sha2-nistp521, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-
nistp384, x509v3-ecdsa-sha2-nistp521, x509v3-rsa2048-sha256] as its
public key algorithm(s) and rejects all other public key algorithms
FCS_SSHC_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[assignment: list of data integrity MAC algorithms] as its data integrity
MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHC_EXT.1.7 The TSF shall ensure that [assignment: list of key exchange methods]
are the only allowed key exchange methods used for the SSH protocol.
FCS_SSHC_EXT.1.8 The TSF shall ensure that within SSH connections the same session
keys are used for a threshold of no longer than one hour, and no more
than one gigabyte of transmitted data. After either of the thresholds are
reached a rekey needs to be performed.
Application Note 180
This SFR defines two thresholds - one for the maximum time span the same session keys can be
used and the other one for the maximum amount of data that can be transmitted using the same
session keys. Both thresholds need to be implemented and a rekey needs to be performed on
whichever threshold is reached first. For the maximum transmitted data threshold, the total
Ixia, A Keysight Business Security Target
Page 68 of 92
incoming and outgoing data needs to be counted. The rekey applies to all session keys
(encryption, integrity protection) for incoming and outgoing traffic.
It is acceptable for a TOE to implement lower thresholds than the maximum values defined in the
SFR.
For any configurable threshold related to this requirement the guidance documentation needs to
specify how the threshold can be configured. The allowed values must either be specified in the
guidance documentation and must be lower or equal to the thresholds specified in this SFR or the
TOE must not accept values beyond the thresholds specified in this SFR.
FCS_SSHC_EXT.1.9 The TSF shall ensure that the SSH client authenticates the identity of the
SSH server using a local database associating each host name with its
corresponding public key or [selection: a list of trusted certification
authorities, no other methods] as described in RFC 4251 section 4.1.
Application Note 181
The list of trusted certification authorities can only be selected if x509v3-ssh-rsa, x509v3-ecdsa-
sha2-nistp256, x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521 or x509v3-rsa2048-
sha256 are selected in FCS_SSHC_EXT.1.5.
FCS_SSHS_EXT.1 SSH Server Protocol
Family Behaviour
The component in this family addresses the ability for a server to offer SSH to protect data
between a client and the server using the SSH protocol.
Component levelling
FCS_SSHS_EXT.1 SSH Server requires that the server side of SSH be implemented as
specified.
Management: FCS_SSHS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSHS_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of SSH session establishment
b) SSH session establishment
c) SSH session termination
FCS_SSHS_EXT.1 SSH Server Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
Ixia, A Keysight Business Security Target
Page 69 of 92
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s)
[selection: 4251, 4252, 4253, 4254, 5647, 5656, 6187, 6668, 8332].
Application Note 182
The ST author selects which of the RFCs to which conformance is being claimed. Note that these
need to be consistent with selections in later elements of this component (e.g., cryptographic
algorithms permitted). RFC 4253 indicates that certain cryptographic algorithms are
“REQUIRED”. This means that the implementation must include support, not that the algorithms
must be enabled for use. Ensuring that algorithms indicated as “REQUIRED” but not listed in the
later elements of this component are implemented is out of scope of the evaluation activity for this
requirement.
RFC 5647 only applies to the RFC compliant implementation of GCM; a TOE that only
implements the “@openssh.com” variant of GCM should not select 5647. aes*-
gcm@openssh.com is specified in Section 1.6 of the OpenSSH Protocol Specification
(https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.31).
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-
based, password-based.
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [assignment: number of bytes] bytes in an SSH transport
connection are dropped.
Application Note 183
RFC 4253 provides for the acceptance of “large packets” with the caveat that the packets should
be of “reasonable length” or dropped. The assignment should be filled in by the ST author with
the maximum packet size accepted, thus defining “reasonable length” for the TOE.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption
algorithms: [assignment: encryption algorithms].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [selection: ssh-rsa, rsa-sha2-256, rsa-sha2-512,
ecdsa-sha2-nistp256, x509v3-ssh-rsa, ecdsa-sha2-nistp384, ecdsa-
sha2-nistp521, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-
nistp384, x509v3-ecdsa-sha2-nistp521, x509v3-rsa2048-sha256] as its
public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[assignment: list of MAC algorithms] as its MAC algorithm(s) and rejects
all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [assignment: list of key exchange methods]
are the only allowed key exchange methods used for the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections the same session
keys are used for a threshold of no longer than one hour, and no more
Ixia, A Keysight Business Security Target
Page 70 of 92
than one gigabyte of transmitted data. After either of the thresholds are
reached a rekey needs to be performed.
Application Note 184
This SFR defines two thresholds - one for the maximum time span the same session keys can be
used and the other one for the maximum amount of data that can be transmitted using the same
session keys. Both thresholds need to be implemented and a rekey needs to be performed on
whichever threshold is reached first. For the maximum transmitted data threshold, the total
incoming and outgoing data needs to be counted. The rekey applies to all session keys
(encryption, integrity protection) for incoming and outgoing traffic.
It is acceptable for a TOE to implement lower thresholds than the maximum values defined in the
SFR.
For any configurable threshold related to this requirement the guidance documentation needs to
specify how the threshold can be configured. The allowed values must either be specified in the
guidance documentation and must be lower or equal to the thresholds specified in this SFR or the
TOE must not accept values beyond the thresholds specified in this SFR.
FCS_TLSC_EXT TLS Client Protocol
Family Behaviour
The component in this family addresses the ability for a client to use TLS to protect data between
the client and a server using the TLS protocol.
Component levelling
FCS_TLSC_EXT.1 TLS Client requires that the client side of TLS be implemented as specified.
FCS_TLSC_EXT.2 TLS Client requires that the client side of the TLS implementation include
mutual authentication.
Management: FCS_TLSC_EXT.1, FCS_TLSC_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_TLSC_EXT.1, FCS_TLSC_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of TLS session establishment
b) TLS session establishment
c) TLS session termination
FCS_TLSC_EXT.1 TLS Client Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM. 1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Ixia, A Keysight Business Security Target
Page 71 of 92
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSC_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC
4346)] and reject all other TLS and SSL versions. The TLS
implementation will support the following ciphersuites:
• [assignment: list of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 185
The ciphersuites to be tested in the evaluated configuration are limited by this requirement.
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference
identifier per RFC 6125 section 6.
Application Note 186
The rules for verification of identify are described in Section 6 of RFC 6125. The reference
identifier is established by the user (e.g. entering a URL into a web browser or clicking a link), by
configuration (e.g. configuring the name of a mail server or authentication server), or by an
application (e.g. a parameter of an API) depending on the application service. Based on a
singular reference identifier’s source domain and application service type (e.g. HTTP, SIP,
LDAP), the client establishes all reference identifiers which are acceptable, such as a Common
Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name,
and Service Name for the Subject Alternative Name field. The client then compares this list of all
acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using DNS names, URI
names, or Service Names. Verification using the Common Name is required for the purposes of
backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or
Subject Alternative name is discouraged as against best practices but may be implemented.
Finally, the client should avoid constructing reference identifiers using wildcards. However, if the
presented identifiers include wildcards, the client must follow the best practices regarding
matching; these best practices are captured in the evaluation activity.
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF
shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented server certificate
].
Application Note 187
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If TLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
Ixia, A Keysight Business Security Target
Page 72 of 92
If TLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_TLSC_EXT.1.4 The TSF shall [selection: not present the Supported Elliptic Curves
Extension, present the Supported Elliptic Curves Extension with the
following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and
no other curves] in the Client Hello.
Application Note 188
If ciphersuites with elliptic curves were selected in FCS_TLSC_EXT.1.1, a selection of one or
more curves is required. If no ciphersuites with elliptic curves were selected in
FCS_TLS_EXT.1.1, then “not present the Supported Elliptic Curves Extension” should be
selected.
This requirement limits the elliptic curves allowed for authentication and key agreement to the
NIST curves from FCS_COP.1/SigGen and FCS_CKM.1 and FCS_CKM.2. This extension is
required for clients supporting Elliptic Curve ciphersuites.
FCS_TLSC_EXT.2 TLS Client Protocol with Authentication
Hierarchical to: FCS_TLSC_EXT.1 TLS Client Protocol
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSC_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC
4346)] and reject all other TLS and SSL versions. The TLS
implementation will support the following ciphersuites:
• [assignment: list of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 189
The ciphersuites to be tested in the evaluated configuration are limited by this requirement.
FCS_TLSC_EXT.2.2 The TSF shall verify that the presented identifier matches the reference
identifier per RFC 6125 section 6.
Application Note 190
The rules for verification of identify are described in Section 6 of RFC 6125. The reference
identifier is established by the user (e.g. entering a URL into a web browser or clicking a link), by
configuration (e.g. configuring the name of a mail server or authentication server), or by an
application (e.g. a parameter of an API) depending on the application service. Based on a
singular reference identifier’s source domain and application service type (e.g. HTTP, SIP,
LDAP), the client establishes all reference identifiers which are acceptable, such as a Common
Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name,
and Service Name for the Subject Alternative Name field. The client then compares this list of all
acceptable reference identifiers to the presented identifiers in the TLS server’s certificate.
Ixia, A Keysight Business Security Target
Page 73 of 92
The preferred method for verification is the Subject Alternative Name using DNS names, URI
names, or Service Names. Verification using the Common Name is required for the purposes of
backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or
Subject Alternative name is discouraged as against best practices but may be implemented.
Finally, the client should avoid constructing reference identifiers using wildcards. However, if the
presented identifiers include wildcards, the client must follow the best practices regarding
matching; these best practices are captured in the evaluation activity.
FCS_TLSC_EXT.2.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF
shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented server certificate
].
Application Note 191
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If TLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
If TLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_TLSC_EXT.2.4 The TSF shall [selection: not present the Supported Elliptic Curves
Extension, present the Supported Elliptic Curves Extension with the
following NIST curves: [selection: secp256r1, secp384r1, secp521r1] and
no other curves] in the Client Hello.
Application Note 192
If ciphersuites with elliptic curves were selected in FCS_TLSC_EXT.1.1, a selection of one or
more curves is required. If no ciphersuites with elliptic curves were selected in
FCS_TLS_EXT.1.1, then “not present the Supported Elliptic Curves Extension” should be
selected.
This requirement limits the elliptic curves allowed for authentication and key agreement to the
NIST curves from FCS_COP.1/SigGen and FCS_CKM.1 and FCS_CKM.2. This extension is
required for clients supporting Elliptic Curve ciphersuites.
FCS_TLSC_EXT.2.5 The TSF shall support mutual authentication using X.509v3 certificates.
Application Note 193
The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement
adds that this use must include the client must be capable of presenting a certificate to a TLS
server for TLS mutual authentication.
FCS_TLSS_EXT TLS Server Protocol
Family Behaviour
Ixia, A Keysight Business Security Target
Page 74 of 92
The component in this family addresses the ability for a server to use TLS to protect data
between a client and the server using the TLS protocol.
Component levelling
FCS_TLSS_EXT.1 TLS Server requires that the server side of TLS be implemented as specified.
FCS_TLSS_EXT.2: TLS Server requires the mutual authentication be included in the TLS
implementation.
Management: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Failure of TLS session establishment
b) TLS session establishment
c) TLS session termination
FCS_TLSS_EXT.1 TLS Server Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC
4346)] and reject all other TLS and SSL versions. The TLS
implementation will support the following ciphersuites:
• [assignment: list of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 194
The ciphersuites to be tested in the evaluated configuration are limited by this requirement.
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL
3.0, TLS 1.0 and [selection: TLS 1.1, TLS 1.2, none].
Application Note 195
All SSL versions and TLS v1.0 are denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1
should be selected here. (If “none” is the selection for this element then the ST author may omit
the words “and none”.)
Ixia, A Keysight Business Security Target
Page 75 of 92
FCS_TLSS_EXT.1.3 The TSF shall [selection: perform RSA key establishment with key size
[selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman
parameters over NIST curves [selection: secp256r1, secp384r1,
secp521r1] and no other curves; generate Diffie-Hellman parameters of
size [selection: 2048 bits, 3072 bits]].
Application Note 196
The assignments will be filled in based on the assignments performed in FCS_TLSS_EXT.1.1.
FCS_TLSS_EXT.2 TLS Server Protocol with mutual authentication
Hierarchical to: FCS_TLSS_EXT.1 TLS Server Protocol
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES Data
encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSS_EXT.2.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC
4346)] and reject all other TLS and SSL versions. The TLS
implementation will support the following ciphersuites:
• [assignment: list of optional ciphersuites and reference to RFC in
which each is defined].
Application Note 197
The ciphersuites to be tested in the evaluated configuration are limited by this requirement.
FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL
3.0, TLS 1.0 and [selection: TLS 1.1, TLS 1.2, none].
Application Note 198
All SSL versions and TLS v1.0 are denied. Any TLS versions not selected in FCS_TLSS_EXT.1.1
should be selected here. (If “none” is the selection for this element then the ST author may omit
the words “and none”.)
FCS_TLSS_EXT.2.3 The TSF shall [selection: perform RSA key establishment with key size
[selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman
parameters over NIST curves [selection: secp256r1, secp384r1,
secp521r1] and no other curves; generate Diffie-Hellman parameters of
size [selection: 2048 bits, 3072 bits]].
Application Note 199
The assignments will be filled in based on the assignments performed in FCS_TLSS_EXT.2.1.
FCS_TLSS_EXT.2.4 The TSF shall support mutual authentication of TLS clients using
X.509v3 certificates.
Application Note 200
The use of X.509v3 certificates for TLS is addressed in FIA_X509_EXT.2.1. This requirement
adds that this use must include support for client-side certificates for TLS mutual authentication.
Ixia, A Keysight Business Security Target
Page 76 of 92
FCS_TLSS_EXT.2.5 When establishing a trusted channel, by default the TSF shall not establish
a trusted channel if the client certificate is invalid. The TSF shall also
[selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the
TSF fails to [selection: match the reference identifier, validate
certificate path, validate expiration date, determine the revocation
status] of the presented client certificate
].
Application Note 201
“Revocation status” refers to a OCSP or CRL response that indicates the presented certificate is
invalid. Inability to make a connection to determine validity shall be handled as specified in
FIA_X509_EXT.2.2.
If TLS is selected in FTP_ITC then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/Rev.
If TLS is selected in FPT_ITT, then certificate validity is tested in accordance with testing
performed for FIA_X509_EXT.1/ITT.
FCS_TLSS_EXT.2.6 The TSF shall not establish a trusted channel if the distinguished name
(DN) or Subject Alternative Name (SAN) contained in a certificate does
not match the expected identifier for the client.
Application Note 202
This requirement only applies to those TOEs performing mutually-authenticated TLS
(FCS_TLSS_EXT.2.4). The peer identifier may be in the Subject field or the Subject Alternative
Name extension of the certificate. The expected identifier may either be configured, may be
compared to the Domain Name, IP address, username, or email address used by the peer, or
may be passed to a directory server for comparison.
Identification and Authentication (FIA)
Password Management (FIA_PMG_EXT)
Family Behaviour
The TOE defines the attributes of passwords used by administrative users to ensure that strong
passwords and passphrases can be chosen and maintained.
Component levelling
FIA_PMG_EXT.1 Password management requires the TSF to support passwords with varying
composition requirements, minimum lengths, maximum lifetime, and similarity constraints.
Management: FIA_PMG_EXT.1
No management functions.
Audit: FIA_PMG_EXT.1
No specific audit requirements.
Ixia, A Keysight Business Security Target
Page 77 of 92
FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1 Password Management
Hierarchical to: No other components.
Dependencies: No other components.
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities
for administrative passwords:
c) Passwords shall be able to be composed of any combination of
upper and lower case letters, numbers, and the following special
characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”,
[assignment: other characters]];
d) Minimum password length shall be configurable to between
[assignment: minimum number of characters supported by the TOE]
and [assignment: number of characters greater than or equal to 15]
characters.
Application Note 203
The ST author selects the special characters that are supported by the TOE. They may optionally
list additional special characters supported using the assignment. "Administrative passwords"
refers to passwords used by Administrators at the local console, over protocols that support
passwords, such as SSH and HTTPS, or to grant configuration data that supports other SFRs in
the Security Target.
The second assignment should be configured with the largest minimum password length the
Security Administrator can configure.
User Identification and Authentication (FIA_UIA_EXT)
Family Behaviour
The TSF allows certain specified actions before the non-TOE entity goes through the
identification and authentication process.
Component levelling
FIA_UIA_EXT.1 User Identification and Authentication requires Administrators (including remote
Administrators) to be identified and authenticated by the TOE, providing assurance for that end of
the communication path. It also ensures that every user is identified and authenticated before the
TOE performs any mediated functions
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure the list of TOE services available before an entity is identified and
authenticated
Audit: FIA_UIA_EXT.N
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) All use of the identification and authentication mechanism
Ixia, A Keysight Business Security Target
Page 78 of 92
b) Provided user identity, origin of the attempt (e.g. IP address)
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1 User Identification and Authentication
Hierarchical to: No other components.
Dependencies: FTA_TAB.1 Default TOE Access Banners
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE
entity to initiate the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [selection: no other actions, automated generation of cryptographic
keys, [assignment: list of services, actions performed by the TSF in
response to non-TOE requests]].
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully
identified and authenticated before allowing any other TSF-mediated
actions on behalf of that administrative user.
Application Note 204
This requirement applies to users (Administrators and external IT entities) of services available
from the TOE directly, and not services available by connecting through the TOE. While it should
be the case that few or no services are available to external entities prior to identification and
authentication, if there are some available (perhaps ICMP echo) these should be listed in the
assignment statement; if automated generation of cryptographic keys is supported without
administrator authentication, the option "automated generation of cryptographic keys" should be
selected; otherwise “no other actions” should be selected.
Authentication can be password-based through the local console or through a protocol that
supports passwords (such as SSH), or be certificate based (such as SSH, TLS).
For communications with external IT entities (an audit server, for instance), such connections
must be performed in accordance with FTP_ITC.1, whose protocols perform identification and
authentication. This means that such communications (e.g., establishing the IPsec connection to
the authentication server) would not have to be specified in the assignment, since establishing
the connection “counts” as initiating the identification and authentication process.
According to the application note for FMT_SMR.2, for distributed TOEs at least one TOE
component has to support the authentication of Security Administrators according to
FIA_UIA_EXT.1 and FIA_UAU_EXT.2 but not necessarily all TOE components. In case not all
TOE components support this way of authentication for Security Administrators the TSS shall
describe how Security Administrators are authenticated and identified.
User authentication (FIA_UAU_EXT)
Family Behaviour
Provides for a locally based administrative user authentication mechanism
Component levelling
Ixia, A Keysight Business Security Target
Page 79 of 92
FIA_UAU_EXT.2 The password-based authentication mechanism provides administrative users a
locally based authentication mechanism.
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
a) None
Audit: FIA_UAU_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Minimal: All use of the authentication mechanism
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2 Password-based Authentication Mechanism
Hierarchical to: No other components.
Dependencies: No other components.
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication
mechanism, [selection: [assignment: other authentication mechanism(s)],
no other authentication mechanism] to perform local administrative user
authentication.
Application Note 205
The assignment should be used to identify any additional local authentication mechanisms
supported. Local authentication mechanisms are defined as those that occur through the local
console; remote administrative sessions (and their associated authentication mechanisms) are
specified in FTP_TRP.1/Admin.
According to the application note for FMT_SMR.2, for distributed TOEs at least one TOE
component has to support the authentication of Security Administrators according to
FIA_UIA_EXT.1 and FIA_UAU_EXT.2 but not necessarily all TOE components. In case not all
TOE components support this way of authentication for Security Administrators the TSS shall
describe how Security Administrators are authenticated and identified.
Authentication using X.509 certificates (FIA_X509_EXT)
Family Behaviour
This family defines the behaviour, management, and use of X.509 certificates for functions to be
performed by the TSF. Components in this family require validation of certificates according to a
specified set of rules, use of certificates for authentication for protocols and integrity verification,
and the generation of certificate requests.
Component levelling
Ixia, A Keysight Business Security Target
Page 80 of 92
FIA_X509_EXT.1 X509 Certificate Validation, requires the TSF to check and validate certificates
in accordance with the RFCs and rules specified in the component.
FIA_X509_EXT.2 X509 Certificate Authentication, requires the TSF to use certificates to
authenticate peers in protocols that support certificates, as well as for integrity verification and
potentially other functions that require certificates.
FIA_X509_EXT.3 X509 Certificate Requests, requires the TSF to be able to generate Certificate
Request Messages and validate responses.
Management: FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
The following actions could be considered for the management functions in FMT:
a) Remove imported X.509v3 certificates
b) Approve import and removal of X.509v3 certificates
c) Initiate certificate requests
Audit: FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Minimal: No specific audit requirements are specified.
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.1 X.509 Certificate Validation
Hierarchical to: No other components
Dependencies: FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.1.1 The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certification path validation.
• The certification path must terminate with a trusted CA certificate
designated as a trust anchor.
• The TSF shall validate a certification path by ensuring that all CA
certificates in the certification path contain the basicConstraints
extension with the CA flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using
[selection: the Online Certificate Status Protocol (OCSP) as specified
in RFC 6960, a Certificate Revocation List (CRL) as specified in RFC
5280 Section 6.3, Certificate Revocation List (CRL) as specified in
RFC 5759 Section 5, no revocation method]
• The TSF shall validate the extendedKeyUsage field according to the
following rules: [assignment: rules that govern contents of the
extendedKeyUsage field that need to be verified].
Application Note 206
Ixia, A Keysight Business Security Target
Page 81 of 92
FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author selects whether
revocation status is verified using OCSP or CRLs. If the TOE is distributed and X.509 based
authentication is being used to authenticate the protocol selected in FPT_ITT.1, certificate
revocation checking is optional. It is optional because there are additional requirements
surrounding the enabling and disabling of the FPT_ITT channel defined in FCO_CPC_EXT.1. If
revocation is not supported the ST author selects no revocation method. The ST author fills in the
assignment with rules that may apply to other requirements in the ST. For instance, if a protocol
such as TLS that uses certificates is specified in the ST, then certain values for the
extendedKeyUsage field (e.g., “Server Authentication Purpose”) could be specified.
FIA_X509_EXT.1.2 The TSF shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
Application Note 207
This requirement applies to certificates that are used and processed by the TSF and restricts the
certificates that may be added as trusted CA certificates.
FIA_X509_EXT.2 X509 Certificate Authentication
FIA_X509_EXT.2 X.509 Certificate Authentication
Hierarchical to: No other components
Dependencies: FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to
support authentication for [selection: DTLS, HTTPS, IPsec, TLS, SSH,
[assignment: other protocols], no protocols], and [selection: code signing
for system software updates, code signing for integrity verification,
[assignment: other uses], no additional uses].
Application Note 208
If the TOE specifies the implementation of communications protocols that perform peer
authentication using certificates, the ST author either selects or assigns the protocols that are
specified; otherwise, they select “no protocols”. Protocols that do not use X.509 based peer
authentication include SSH, where ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, and/or
ecdsa-sha2-nistp521 are selected. The TOE may also use certificates for other purposes; the
second selection and assignment are used to specify these cases.
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, accept the certificate,
not accept the certificate].
Application Note 209
Often a connection must be established to check the revocation status of a certificate - either to
download a CRL or to perform a lookup using OCSP. The selection is used to describe the
behaviour in the event that such a connection cannot be established (for example, due to a
network error). If the TOE has determined the certificate valid according to all other rules in
FIA_X509_EXT.1, the behaviour indicated in the selection determines the validity. The TOE must
not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. If the
Administrator-configured option is selected by the ST Author, the ST Author also selects the
corresponding function in FMT_SMF.1.
If the TOE is distributed and FIA_X509_EXT.1/ITT is selected, then certificate revocation
checking is optional. This is due to additional authorization actions being performed in the
Ixia, A Keysight Business Security Target
Page 82 of 92
enabling and disabling of the intra-TOE trusted channel as defined in FCO_CPC_EXT.1. In this
case, a connection is not required to determine certificate validity and this SFR is trivially
satisfied.
FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3 X.509 Certificate Requests
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986
and be able to provide the following information in the request: public key
and [selection: device-specific information, Common Name,
Organization, Organizational Unit, Country, [assignment: other
information]].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon
receiving the CA Certificate Response.
Protection of the TSF (FPT)
Protection of TSF Data (FPT_SKP_EXT)
Family Behaviour
Components in this family address the requirements for managing and protecting TSF data, such
as cryptographic keys. This is a new family modelled after the FPT_PTD Class.
Component levelling
FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys), requires preventing
symmetric keys from being read by any user or subject. It is the only component of this family.
Management: FPT_SKP_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FPT_SKP_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) There are no auditable events foreseen.
Ixia, A Keysight Business Security Target
Page 83 of 92
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
Hierarchical to: No other components.
Dependencies: No other components.
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
Application Note 210
The intent of this requirement is for the device to protect keys, key material, and authentication
credentials from unauthorized disclosure. This data should only be accessed for the purposes of
their assigned security functionality, and there is no need for them to be displayed/accessed at
any other time. This requirement does not prevent the device from providing indication that these
exist, are in use, or are still valid. It does, however, restrict the reading of the values outright.
Protection of Administrator Passwords (FPT_APW_EXT)
FPT_APW_EXT.1 Protection of Administrator Passwords
Family Behaviour
Components in this family ensure that the TSF will protect plaintext credential data such as
passwords from unauthorized disclosure.
Component levelling
FPT_APW_EXT.1 Protection of Administrator passwords requires that the TSF prevent plaintext
credential data from being read by any user or subject.
Management: FPT_APW_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_APW_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) No audit necessary.
FPT_APW_EXT.1 Protection of Administrator Passwords
Hierarchical to: No other components
Dependencies: No other components.
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
Ixia, A Keysight Business Security Target
Page 84 of 92
Application Note 211
The intent of the requirement is that raw password authentication data is not stored in the clear,
and that no user or Administrator is able to read the plaintext password through “normal”
interfaces. An all-powerful Administrator could directly read memory to capture a password but is
trusted not to do so. Passwords should be obscured during entry on the local console in
accordance with FIA_UAU.7.
TSF Self-Test (FPT_TST_EXT)
FPT_TST_EXT.1 TSF Testing
Family Behaviour
Components in this family address the requirements for self-testing the TSF for selected correct
operation.
Component levelling
FPT_TST_EXT.1 TSF Self-Test requires a suite of self-tests to be run during initial start-up in
order to demonstrate correct operation of the TSF.
FPT_TST_EXT.2 Self-tests based on certificates applies when using certificates as part of self-
test, and requires that the self-test fails if a certificate is invalid.
Management: FPT_TST_EXT.1, FPT_TST_EXT.2
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_TST_EXT.1, FPT_TST_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data generation
is included in the PP/ST:
a) Indication that TSF self-test was completed
b) Failure of self-test
FPT_TST_EXT.1 TSF testing
Hierarchical to: No other components.
Dependencies: No other components.
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during
initial start-up (on power on), periodically during normal operation, at the
request of the authorised user, at the conditions [assignment: conditions
under which self-tests should occur]] to demonstrate the correct
operation of the TSF: [assignment: list of self-tests run by the TSF].
Application Note 212
Ixia, A Keysight Business Security Target
Page 85 of 92
It is expected that self-tests are carried out during initial start-up (on power on). Other options
should only be used if the developer can justify why they are not carried out during initial start-up.
It is expected that at least self-tests for verification of the integrity of the firmware and software as
well as for the correct operation of cryptographic functions necessary to fulfil the SFRs will be
performed. If not all self-tests are performed during start-up multiple iterations of this SFR are
used with the appropriate options selected. In future versions of this cPP the suite of self-tests will
be required to contain at least mechanisms for measured boot including self-tests of the
components which perform the measurement.
Non-distributed TOEs may internally consist of several components that contribute to enforcing
SFRs. Self-testing shall cover all components that contribute to enforcing SFRs and verification of
integrity shall cover all software that contributes to enforcing SFRs on all components.
For distributed TOEs all TOE components have to perform self-tests. This does not necessarily
mean that each TOE component has to carry out the same self-tests: the ST describes the
applicability of the selection (i.e. when self-tests are run) and the final assignment (i.e. which self-
tests are carried out) to each TOE component.
Application Note 213
If certificates are used by the self-test mechanism (e.g. for verification of signatures for integrity
verification), certificates are validated in accordance with FIA_X509_EXT.1 and should be
selected in FIA_X509_EXT.2.1. Additionally, FPT_TST_EXT.2 must be included in the ST.
FPT_TST_EXT.2 Self-tests based on certificates
Hierarchical to: No other components.
Dependencies: No other components.
FPT_TST_EXT.2.1 The TSF shall fail self-testing if a certificate is used for self-tests and the
corresponding certificate is deemed invalid.
Application Note 214
Certificates may optionally be used for self-tests (FPT_TST_EXT.1.1). This element must be
included in the ST if certificates are used for self-tests. If “code signing for integrity verification” is
selected in FIA_X509_EXT.2.1, FPT_TST_EXT.2 must be included in the ST.
Validity is determined by the certification path and the expiration date. If the self-test is executed
as part of TOE initialization (e.g. boot), there is no expectation of a revocation status check as the
necessary functionality, configuration, or infrastructure required to perform such check might not
be available.
Trusted Update (FPT_TUD_EXT)
Family Behaviour
Components in this family address the requirements for updating the TOE firmware and/or
software.
Component levelling
Ixia, A Keysight Business Security Target
Page 86 of 92
FPT_TUD_EXT.1 Trusted Update requires management tools be provided to update the TOE
firmware and software, including the ability to verify the updates prior to installation.
FPT_TUD_EXT.2 Trusted update based on certificates applies when using certificates as part of
trusted update and requires that the update does not install if a certificate is invalid.
Management: FPT_TUD_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to update the TOE and to verify the updates
b) Ability to update the TOE and to verify the updates using the digital signature capability
(FCS_COP.1/SigGen) and [selection: no other functions, [assignment: other cryptographic
functions (or other functions) used to support the update capability]]
c) Ability to update the TOE, and to verify the updates using [selection: digital signature,
published hash, no other mechanism] capability prior to installing those updates
Audit: FPT_TUD_EXT.1, FPT_TUD_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Initiation of the update process.
b) Any failure to verify the integrity of the update
FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1 Trusted update
Hierarchical to: No other components
Dependencies: FCS_COP.1/SigGen Cryptographic operation (for Cryptographic
Signature and Verification), or FCS_COP.1/Hash Cryptographic
operation (for cryptographic hashing)
FPT_TUD_EXT.1.1 The TSF shall provide [assignment: Administrators] the ability to query
the currently executing version of the TOE firmware/software and
[selection: the most recently installed version of the TOE
firmware/software; no other TOE firmware/software version].
Application Note 215
If a trusted update can be installed on the TOE with a delayed activation the version of both the
currently executing image and the installed but inactive image must be provided. In this case the
option 'the most recently installed version of the TOE firmware/software' needs to be chosen from
the selection in FPT_TUD_EXT.1.1 and the TSS needs to describe how and when the inactive
version becomes active. If all trusted updates become active as part of the installation process,
only the currently executing version needs to be provided. In this case the option 'no other TOE
firmware/software version' shall be chosen from the selection in FPT_TUD_EXT.1.1..
For a distributed TOE, the method of determining the installed versions on each component of the
TOE is described in the operational guidance.
FPT_TUD_EXT.1.2 The TSF shall provide [assignment: Administrators] the ability to
manually initiate updates to TOE firmware/software and [selection:
Ixia, A Keysight Business Security Target
Page 87 of 92
support automatic checking for updates, support automatic updates, no
other update mechanism].
Application Note 216
The selection in FPT_TUD_EXT.1.2 distinguishes the support of automatic checking for updates
and support of automatic updates. The first option refers to a TOE that checks whether a new
update is available, communicates this to the Administrator (e.g. through a message during an
Administrator session, through log files) but requires some action by the Administrator to actually
perform the update. The second option refers to a TOE that checks for updates and automatically
installs them upon availability.
The TSS explains what actions are involved in the TOE support when using the “support
automatic checking for updates” or “support automatic updates” selections.
When published hash values (see FPT_TUD_EXT.1.3) are used to protect the trusted update
mechanism, the TOE must not automatically download the update file(s) together with the hash
value (either integrated in the update file(s) or separately) and automatically install the update
without any active authorization by the Security Administrator, even when the calculated hash
value matches the published hash value. When using published hash values to protect the
trusted update mechanism, the option “support of automatic updates” must not be used
(automated checking for updates is permitted, though). The TOE may automatically download the
update file(s) themselves but not to the hash value. For the published hash approach, it is
intended that a Security Administrator is always required to give active authorisation for
installation of an update (as described in more detail under FPT_TUD_EXT.1.3) below. Due to
this, the type of update mechanism is regarded as “manually initiated update”, even if the update
file(s) may be downloaded automatically. A fully automated approach (without Security
Administrator intervention) can only be used when “digital signature mechanism” is selected in
FPT_TUD_EXT.1.3 below.
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates
to the TOE using a [selection: digital signature mechanism, published
hash] prior to installing those updates.
Application Note 217
The digital signature mechanism referenced in the selection of FPT_TUD_EXT.1.3 is one of the
algorithms specified in FCS_COP.1/SigGen. The published hash referenced in
FPT_TUD_EXT.1.3 is generated by one of the functions specified in FCS_COP.1/Hash. The ST
author should choose the mechanism implemented by the TOE; it is acceptable to implement
both mechanisms.
When published hash values are used to secure the trusted update mechanism, an active
authorization of the update process by the Security Administrator is always required. The secure
transmission of an authentic hash value from the developer to the Security Administrator is one of
the key factors to protect the trusted update mechanism when using published hashes and the
guidance documentation needs to describe how this transfer has to be performed. For the
verification of the trusted hash value by the Security Administrator different use cases are
possible. The Security Administrator could obtain the published hash value as well as the update
file(s) and perform the verification outside the TOE while the hashing of the update file(s) could
be done by the TOE or by other means. Authentication as Security Administrator and initiation of
the trusted update would in this case be regarded as “active authorization” of the trusted update.
Alternatively, the Administrator could provide the TOE with the published hash value together with
the update file(s) and the hashing and hash comparison is performed by the TOE. In case of
successful hash verification, the TOE can perform the update without any additional step by the
Security Administrator. Authentication as Security Administrator and sending the hash value to
the TOE is regarded as “active authorization” of the trusted update (in case of successful hash
verification), because the Administrator is expected to load the hash value only to the TOE when
intending to perform the update. As long as the transfer of the hash value to the TOE is
performed by the Security Administrator, loading of the update file(s) can be performed by the
Security Administrator or can be automatically downloaded by the TOE from a repository.
Ixia, A Keysight Business Security Target
Page 88 of 92
If the digital signature mechanism is selected, the verification of the signature shall be performed
by the TOE itself. For the published hash option, the verification can be done by the TOE itself as
well as by the Security Administrator. In the latter case use of TOE functionality for the verification
is not mandated, so verification could be done using non-TOE functionality of the device
containing the TOE or without using the device containing the TOE.
For distributed TOEs all TOE components shall support Trusted Update. The verification of the
signature or hash on the update shall either be done by each TOE component itself (signature
verification) or for each component (hash verification).
Updating a distributed TOE might lead to the situation where different TOE components are
running different software versions. Depending on the differences between the different software
versions the impact of a mixture of different software versions might be no problem at all or
critical to the proper functioning of the TOE. The TSS shall detail the mechanisms that support
the continuous proper functioning of the TOE during trusted update of distributed TOEs.
Application Note 218
Future versions of this cPP will mandate the use of a digital signature mechanism for trusted
updates.
Application Note 219
If certificates are used by the update verification mechanism, certificates are validated in
accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally,
FPT_TUD_EXT.2 must be included in the ST.
Application Note 220
“Update” in the context of this SFR refers to the process of replacing a non-volatile, system
resident software component with another. The former is referred to as the NV image, and the
latter is the update image. While the update image is typically newer than the NV image, this is
not a requirement. There are legitimate cases where the system owner may want to rollback a
component to an older version (e.g. when the component manufacturer releases a faulty update,
or when the system relies on an undocumented feature no longer present in the update).
Likewise, the owner may want to update with the same version as the NV image to recover from
faulty storage.
All discrete firmware and software elements (e.g. applications, drivers, and kernel) of the TSF
need to be protected, i.e. they should either be digitally signed by the corresponding
manufacturer and subsequently verified by the mechanism performing the update or a hash
should be published for them which needs to be verified before the update.
FPT_TUD_EXT.2 Trusted Update based on certificates
FPT_TUD_EXT.2 Trusted update based on certificates
Hierarchical to: No other components
Dependencies: FPT_TUD_EXT.1
FPT_TUD_EXT.2.1 The TSF shall not install an update if the code signing certificate is
deemed invalid.
FPT_TUD_EXT.2.2 When the certificate is deemed invalid because the certificate has
expired, the TSF shall [selection: allow the Administrator to choose
whether to accept the certificate in these cases, accept the certificate,
not accept the certificate].
Application Note 221
Certificates may optionally be used for code signing of system software updates
(FPT_TUD_EXT.1.3). This element must be included in the ST if certificates are used for
Ixia, A Keysight Business Security Target
Page 89 of 92
validating updates. If “code signing for system software updates” is selected in
FIA_X509_EXT.2.1, FPT_TUD_EXT.2 must be included in the ST.
Validity is determined by the certification path, the expiration date, and the revocation status in
accordance with FIA_X509_EXT.1. For expired certificates the author of the ST selects whether
the certificate shall be accepted, rejected or the choice is left to the Administrator to accept or
reject the certificate.
Time stamps (FPT_STM_EXT)
Family Behaviour
Components in this family extend FPT_STM requirements by describing the source of time used
in timestamps.
Component levelling
FPT_STM_EXT.1 Reliable Time Stamps is hierarchic to FPT_STM.1: it requires that the TSF
provide reliable time stamps for TSF and identifies the source of the time used in those
timestamps.
Management: FPT_STM_EXT.1
The following actions could be considered for the management functions in FMT:
a) Management of the time
b) Administrator setting of the time.
Audit: FTA_SSL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Discontinuous changes to the time.
FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1 Reliable Time Stamps
Hierarchical to: No other components
Dependencies: No other components.
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [selection: allow the Security Administrator to set the time,
synchronise time with an NTP server].
Application Note 222
Reliable time stamps are expected to be used with other TSF, e.g. for the generation of audit data
to allow the Security Administrator to investigate incidents by checking the order of events and to
determine the actual local time when events occurred. The decision about the required level of
accuracy of that information is up to the Administrator.
The TOE depends on time and date information, either provided by a local real-time clock that is
manually managed by the Security Administrator or through the use of one or more external NTP
Ixia, A Keysight Business Security Target
Page 90 of 92
servers. The corresponding option(s) shall be chosen from the selection in FPT_STM_EXT.1.2.
The use the automatic synchronisation with an external NTP server is recommended but not
mandated. Note that for the communication with an external NTP server, FCS_NTP_EXT.1 shall
be claimed. The ST author describes in the TSS how the external time and date information is
received by the TOE and how this information is maintained.
The term “reliable time stamps” refers to the strict use of the time and date information, that is
provided, and the logging of all discontinuous changes to the time settings including information
about the old and new time. With this information, the real time for all audit data can be
determined. Note, that all discontinuous time changes, Administrator actuated or changed via an
automated process, must be audited. No audit is needed when time is changed via use of kernel
or system facilities – such as daytime (3) – that exhibit no discontinuities in time.
For distributed TOEs it is expected that the Security Administrator ensures synchronization
between the time settings of different TOE components. All TOE components shall either be in
sync (e.g. through synchronisation between TOE components or through synchronisation of
different TOE components with external NTP servers) or the offset should be known to the
Administrator for every pair of TOE components. This includes TOE components synchronized to
different time zones.
TOE Access (FTA)
TSF-initiated Session Locking (FTA_SSL_EXT)
Family Behaviour
Components in this family address the requirements for TSF-initiated and user-initiated locking,
unlocking, and termination of interactive sessions.
The extended FTA_SSL_EXT family is based on the FTA_SSL family.
Component levelling
FTA_SSL_EXT.1 TSF-initiated session locking, requires system initiated locking of an interactive
session after a specified period of inactivity. It is the only component of this family.
Management: FTA_SSL_EXT.1
The following actions could be considered for the management functions in FMT:
c) Specification of the time of user inactivity after which lock-out occurs for an individual
user.
Audit: FTA_SSL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
b) Any attempts at unlocking an interactive session.
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1 TSF-initiated Session Locking
Ixia, A Keysight Business Security Target
Page 91 of 92
Hierarchical to: No other components
Dependencies: FIA_UAU.1 Timing of authentication
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection:
• lock the session - disable any activity of the Administrator’s data
access/display devices other than unlocking the session, and
requiring that the Administrator re-authenticate to the TSF prior to
unlocking the session;
• terminate the session]
after a Security Administrator-specified time period of inactivity.
Communication (FCO)
Communication Partner Control (FCO_CPC_EXT)
Family Behaviour
This family is used to define high-level constraints on the ways that partner IT entities
communicate. For example, there may be constraints on when communication channels can be
used, how they are established, and links to SFRs expressing lower-level security properties of
the channels.
Component levelling
FCO_CPC_EXT.1 Component Registration Channel Definition, requires the TSF to support a
registration channel for joining together components of a distributed TOE, and to ensure that the
availability of this channel is under the control of an Administrator. It also requires statement of
the type of channel used (allowing specification of further lower-level security requirements by
reference to other SFRs).
Management: FCO_CPC_EXT.1
No separate management functions are required. Note that elements of the SFR already specify
certain constraints on communication in order to ensure that the process of forming a distributed
TOE is a controlled activity.
Audit: FCO_CPC_EXT.1
The following actions should be auditable if FCO_CPC_EXT.1 is included in the PP/ST:
a) Enabling communications between a pair of components as in FCO_CPC_EXT.1.1
(including identities of the endpoints).
b) Disabling communications between a pair of components as in FCO_CPC_EXT.1.3
(including identity of the endpoint that is disabled).
If the required types of channel in FCO_CPC_EXT.1.2 are specified by using other SFRs then the
use of the registration channel may be sufficiently covered by the audit requirements on those
SFRs: otherwise a separate audit requirement to audit the use of the channel should be identified
for FCO_CPC_EXT.1.
Ixia, A Keysight Business Security Target
Page 92 of 92
FCO_CPC_EXT.1 Component Registration Channel Definition
FCO_CPC_EXT.1 Component Registration Channel Definition
Hierarchical to: No other components.
Dependencies: No other components.
FCO_CPC_EXT.1.1 The TSF shall require a Security Administrator to enable
communications between any pair of TOE components before such
communication can take place.
FCO_CPC_EXT.1.2 The TSF shall implement a registration process in which components
establish and use a communications channel that uses [assignment: list
of different types of channel given in the form of a selection] for at least
[assignment: type of data for which the channel must be used].
FCO_CPC_EXT.1.3 The TSF shall enable a Security Administrator to disable
communications between any pair of TOE components.
Application Note 223
This SFR is generally applied to a distributed TOE in order to control the process of creating the
distributed TOE from its components by means of a registration process in which a component
joins the distributed TOE by registering with an existing component of the distributed TOE. When
creating the TSF from the initial pair of components, either of these components may be identified
as the TSF for the purposes of satisfying the meaning of “TSF” in this SFR.
The intention of this requirement is to ensure that there is a registration process that includes a
positive enablement step by an Administrator before components joining a distributed TOE can
communicate with the other components of the TOE and before the new component can act as
part of the TSF. The registration process may itself involve communication with the joining
component: many network devices use a bespoke process for this, and the security requirements
for the “registration communication” are then defined in FCO_CPC_EXT.1.2. Use of this
“registration communication” channel is not deemed inconsistent with the requirement of
FCO_CPC_EXT.1.1 (i.e. the registration channel can be used before the enablement step, but
only in order to complete the registration process).