ã 2023 F5, Inc. All Rights Reserved.
F5 BIG-IP® 16.1.3.1 including SSLO
Security Target
Document Number: CC2020-ASE_ST-003
Document Version: 6.12
Date: December 14, 2023
Prepared By:
Saffire Systems
PO Box 40295
Indianapolis, IN 46240
Prepared For:
F5, Inc.
801 Fifth Avenue
Seattle, WA 98104
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. i
Table of Contents
1 INTRODUCTION........................................................................................................................................1
1.1 SECURITY TARGET IDENTIFICATION...........................................................................................................1
1.2 TOE IDENTIFICATION.................................................................................................................................1
1.2.1 F5 Devices........................................................................................................................................1
1.3 DOCUMENT TERMINOLOGY........................................................................................................................4
1.3.1 ST Specific Terminology ..................................................................................................................4
1.3.2 Acronyms..........................................................................................................................................4
1.4 TOE TYPE ..................................................................................................................................................5
1.5 TOE OVERVIEW .........................................................................................................................................5
1.6 TOE DESCRIPTION .....................................................................................................................................6
1.6.1 Introduction......................................................................................................................................6
1.6.2 Architecture Description..................................................................................................................7
1.6.3 Physical Boundaries ......................................................................................................................10
1.6.3.1 Physical boundaries ...................................................................................................................................10
1.6.3.2 Guidance Documentation...........................................................................................................................11
1.6.4 Logical Boundaries........................................................................................................................12
1.6.4.1 Security Audit............................................................................................................................................13
1.6.4.2 Cryptographic Support...............................................................................................................................13
1.6.4.3 Identification and Authentication ..............................................................................................................14
1.6.4.4 Security Management ................................................................................................................................14
1.6.4.5 Protection of the TSF.................................................................................................................................15
1.6.4.6 TOE access.................................................................................................................................................15
1.6.4.7 Trusted Path/Channels ...............................................................................................................................15
1.6.4.8 User Data Protection..................................................................................................................................16
1.6.5 Delivery..........................................................................................................................................16
1.6.5.1 F5 Devices and vCMP ...............................................................................................................................16
1.6.5.2 Documentation...........................................................................................................................................16
2 CONFORMANCE CLAIMS.....................................................................................................................17
2.1 CC CONFORMANCE CLAIMS.....................................................................................................................17
2.2 PP AND PACKAGE CLAIMS .......................................................................................................................17
2.3 CONFORMANCE RATIONALE.....................................................................................................................19
3 SECURITY PROBLEM DEFINITION...................................................................................................20
3.1 THREAT ENVIRONMENT ...........................................................................................................................20
3.2 THREATS ..................................................................................................................................................21
3.3 ORGANISATIONAL SECURITY POLICIES ....................................................................................................23
3.4 ASSUMPTIONS ..........................................................................................................................................23
4 SECURITY OBJECTIVES.......................................................................................................................26
4.1 SECURITY OBJECTIVES FOR THE TOE ......................................................................................................26
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ..............................................................27
5 EXTENDED COMPONENTS DEFINITION.........................................................................................29
6 SECURITY REQUIREMENTS................................................................................................................31
6.1 CONVENTIONS ..........................................................................................................................................32
6.2 SECURITY FUNCTIONAL REQUIREMENTS .................................................................................................33
6.2.1 Security Audit (FAU) .....................................................................................................................33
6.2.1.1 FAU_GCR_EXT.1 Generation of Certificate Repository.........................................................................33
6.2.1.2 FAU_GEN.1 Audit Data Generation.........................................................................................................33
6.2.1.3 FAU_GEN.1/STIP Audit Data Generation (STIP)....................................................................................35
6.2.1.4 FAU_GEN.2 User Identity Association ..............................................................................................37rror
6.2.1.5 FAU_STG.1 Protected Audit Trail Storage...............................................................................................37
6.2.1.6 FAU_STG.4 Prevention of Audit Data Loss.............................................................................................37
6.2.1.7 FAU_STG_EXT.1 Protected Audit Event Storage ...................................................................................37
6.2.1.8 FAU_STG_EXT.3/LocSpace Action in case of possible audit data loss..................................................37
6.2.2 Cryptographic Operations (FCS) ..................................................................................................37
6.2.2.1 FCS_CKM.1 Cryptographic Key Generation............................................................................................37
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. ii
6.2.2.2 FCS_CKM.2 Cryptographic Key Establishment.......................................................................................38
6.2.2.3 FCS_CKM.4 Cryptographic Key Destruction...........................................................................................38
6.2.2.4 FCS_COP.1/DataEncryption Cryptographic operation (AES Data Encryption/Decryption) ...................38
6.2.2.5 FCS_COP.1/SigGen Cryptographic operation (Signature Generation and Verification) .........................38
6.2.2.6 FCS_COP.1/Hash Cryptographic operation (Hash Operation) .................................................................39
6.2.2.7 FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash Algorithm)...........................................39
6.2.2.8 FCS_COP.1/STIP Cryptographic operation (Data Encryption/Decryption in Support of STIP)..............39
6.2.2.9 FCS_HTTPS_EXT.1 HTTPS Protocol......................................................................................................39
6.2.2.10 FCS_RBG_EXT.1 Random Bit Generation ..............................................................................................39
6.2.2.11 FCS_SSHS_EXT.1 SSH Server Protocol..................................................................................................40
6.2.2.12 FCS_STG_EXT.1 Cryptographic Key Storage.........................................................................................40
6.2.2.13 FCS_TLSC_EXT.1[1] TLS Client Protocol without mutual authentication (TLS1.1).............................40
6.2.2.14 FCS_TLSC_EXT.1[2] TLS Client Protocol without mutual authentication (TLS 1.2)............................41
6.2.2.15 FCS_TLSC_EXT.2 TLS Client support for mutual authentication...........................................................42
6.2.2.16 FCS_TLSS_EXT.1[1] TLS Server Protocol (Data Plane Server – TLS 1.1)............................................42
6.2.2.17 FCS_TLSS_EXT.1[2] TLS Server Protocol (Data Plane Server – TLS 1.2)............................................42
6.2.2.18 FCS_TLSS_EXT.1[3] TLS Server Protocol (Control Plane Server – TLS 1.1) .......................................43
6.2.2.19 FCS_TLSS_EXT.1[4] TLS Server Protocol (Control Plane Server – TLS 1.2) .......................................43
6.2.2.20 FCS_TTTC_EXT.1 Thru-Traffic TLS Inspection Client Protocol ...........................................................44
6.2.2.21 FCS_TTTC_EXT.4 STIP Client-Side Support for Renegotiation ............................................................46
6.2.2.22 FCS_TTTC_EXT.5 Thru-Traffic TLS Inspection Client Support for Supported Groups Extension .......46
6.2.2.23 FCS_TTTS_EXT.1 Thru-Traffic TLS Inspection Server Protocol...........................................................46
6.2.2.24 FCS_TTTS_EXT.4 STIP Server-Side Support for Renegotiation ............................................................48
6.2.3 User Data Protection (FDP)..........................................................................................................48
6.2.3.1 FDP_CER_EXT.1 Certificate Profiles for Server Certificates..................................................................48
6.2.3.2 FDP_CER_EXT.2 Certificate Request Matching of Server Certificates ..................................................49
6.2.3.3 FDP_CER_EXT.3 Certificate Issuance Rules for Server Certificates ......................................................49
6.2.3.4 FDP_CSIR_EXT.1 Certificate Status Information Required....................................................................49
6.2.3.5 FDP_PPP_EXT.1 Plaintext Processing Policy..........................................................................................50
6.2.3.6 FDP_PRC_EXT.1 Plaintext Routing Control ...........................................................................................50
6.2.3.7 FDP_RIP.1 Subset Residual Information Protection.................................................................................50
6.2.3.8 FDP_STG_EXT.1 Certificate Data Storage ..............................................................................................50
6.2.3.9 FDP_STIP_EXT.1 SSL/TLS Inspection Proxy Functions........................................................................50
6.2.3.10 FDP_TEP_EXT.1 SSL/TLS Inspection Proxy Policy...............................................................................51
6.2.4 Identification and Authentication (FIA).........................................................................................53
6.2.4.1 FIA_AFL.1 Authentication Failure Management......................................................................................53
6.2.4.2 FIA_ENR_EXT.1 Certifícate Enrollment .................................................................................................53
6.2.4.3 FIA_PMG_EXT.1 Password Management ...............................................................................................53
6.2.4.4 FIA_UIA_EXT.1 User Identification and Authentication.........................................................................53
6.2.4.5 FIA_UAU_EXT.2 Password-based Authentication Mechanism ..............................................................53
6.2.4.6 FIA_UAU.7 Protected Authentication Feedback ......................................................................................54
6.2.4.7 FIA_X509_EXT.1/Rev X.509 Certificate Validation ...............................................................................54
6.2.4.8 FIA_X509_EXT.1/STIP Certificate Validation (STIP) ............................................................................54
6.2.4.9 FIA_X509_EXT.2 X.509 Certificate Authentication................................................................................55
6.2.4.10 FIA_X509_EXT.2/STIP X.509 Certificate Authentication.......................................................................55
6.2.4.11 FIA_X509_EXT.3 X.509 Certificate Requests .........................................................................................56
6.2.5 Security Management (FMT).........................................................................................................56
6.2.5.1 FMT_MOF.1/ManualUpdate Management of security functions behavior..............................................56
6.2.5.2 FMT_MOF.1/Services Management of security functions behavior ........................................................56
6.2.5.3 FMT_MOF.1/STIP Management of security functions behavior..............................................................56
6.2.5.4 FMT_MTD.1/CoreData Management of TSF Data ..................................................................................56
6.2.5.5 FMT_MTD.1/CryptoKeys Management of TSF Data ..............................................................................57
6.2.5.6 FMT_SMF.1 Specification of Management Functions .............................................................................57
6.2.5.7 FMT_SMF.1/STIP Specification of Management Functions (STIP)........................................................57
6.2.5.8 FMT_SMR.2 Restrictions on security roles ..............................................................................................57
6.2.5.9 FMT_SMR.2/STIP Restrictions on security roles (STIP).........................................................................58
6.2.6 Protection of TSF (FPT) ................................................................................................................58
6.2.6.1 FPT_APW_EXT.1 Protection of Administrator Passwords......................................................................58
6.2.6.2 FPT_FLS.1 Failure with Preservation of Secure State..............................................................................58
6.2.6.3 FPT_KST_EXT.1 No Plaintext Key Export..............................................................................................58
6.2.6.4 FPT_KST_EXT.2 TSF Key Protection .....................................................................................................58
6.2.6.5 FPT_RCV.1 Manual Trusted Recovery.....................................................................................................58
6.2.6.6 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric, and private keys).58
6.2.6.7 FPT_STM_EXT.1 Reliable Time Stamps.................................................................................................59
6.2.6.8 FPT_TST_EXT.1/PowerOn TSF Testing (Extended)...............................................................................59
6.2.6.9 FPT_TST_EXT.1/OnDemand TSF Testing (Extended)............................................................................59
6.2.6.10 FPT_TUD_EXT.1 Trusted Update............................................................................................................59
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. iii
6.2.7 TOE Access (FTA) .........................................................................................................................59
6.2.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ....................................................................................59
6.2.7.2 FTA_SSL.3 TSF-initiated Termination (Refinement)...............................................................................59
6.2.7.3 FTA_SSL.4 User-initiated Termination (Refinement)..............................................................................59
6.2.7.4 FTA_TAB.1 Default TOE Access Banners (Refinement) ........................................................................59
6.2.8 Trusted path/channels (FTP) .........................................................................................................60
6.2.8.1 FTP_ITC.1 Inter-TSF trusted channel.......................................................................................................60
6.2.8.2 FTP_TRP.1/Admin Trusted Path ..............................................................................................................60
6.3 TOE SECURITY ASSURANCE REQUIREMENTS ..........................................................................................60
6.4 SECURITY REQUIREMENTS RATIONALE....................................................................................................61
6.4.1 Security Functional Requirement Dependencies ...........................................................................61
7 TOE SUMMARY SPECIFICATION.......................................................................................................62
7.1 SECURITY AUDIT......................................................................................................................................62
7.1.1 Audit Generation............................................................................................................................62
7.1.2 Audit Storage..................................................................................................................................63
7.1.3 Certificate Repository ....................................................................................................................64
7.2 CRYPTOGRAPHIC SUPPORT.......................................................................................................................64
7.2.1 Key Generation and Establishment................................................................................................64
7.2.2 Zeroization of Critical Security Parameters..................................................................................65
7.2.3 Cryptographic operations in the TOE ...........................................................................................68
7.2.4 Random Number Generation .........................................................................................................69
7.2.5 SSH.................................................................................................................................................70
7.2.6 TLS Protocol ..................................................................................................................................71
7.2.7 HTTPS Protocol.............................................................................................................................72
7.2.8 Thru-Traffic TLS Inspection...........................................................................................................73
7.2.8.1 Thru-Traffic TLS Inspection Client Protocol ............................................................................................73
7.2.8.2 Thru-Traffic TLS Inspection Server Protocol............................................................................................74
7.3 USER DATA PROTECTION .........................................................................................................................76
7.3.1 Forged Certificate Issuance...........................................................................................................76
7.3.2 Residual Information Protection....................................................................................................77
7.3.3 Certificate Data Storage ................................................................................................................77
7.3.4 TLS Establishment Policy ..............................................................................................................77
7.3.5 Plaintext Processing and Routing..................................................................................................80
7.3.6 SSL/TLS Inspection Proxy Functions.............................................................................................80
7.4 IDENTIFICATION AND AUTHENTICATION ..................................................................................................81
7.4.1 Password policy and user lockout .................................................................................................82
7.4.2 Certificate Enrollment....................................................................................................................82
7.4.3 TLS Certificate Validation .............................................................................................................83
7.4.4 Thru-Traffic Processing Certificate Validation.............................................................................83
7.5 SECURITY FUNCTION MANAGEMENT .......................................................................................................84
7.5.1 Security Roles.................................................................................................................................86
7.6 PROTECTION OF THE TSF .........................................................................................................................88
7.6.1 Protection of Sensitive Data ..........................................................................................................88
7.6.2 Self-tests .........................................................................................................................................88
7.6.3 Update Verification........................................................................................................................89
7.6.4 Time Source....................................................................................................................................89
7.6.5 Preservation of Secure State and Trusted Recovery......................................................................90
7.6.6 Key Protection................................................................................................................................90
7.7 TOE ACCESS ............................................................................................................................................90
7.8 TRUSTED PATH/CHANNELS ......................................................................................................................91
List of Tables
Table 1: Supported Hardware Models.....................................................................................................4
Table 2: Guidance Documentation........................................................................................................12
Table 3: Security Functional Requirements ..........................................................................................32
Table 4: NDcPP Security Functional Requirements and Auditable Events.........................................35
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. iv
Table 5: STIP Security Functional Requirements and Auditable Events.............................................37
Table 6: Management Functions and Privileges....................................................................................56
Table 7: Security Assurance Requirements..........................................................................................61
Table 8: Audit Logs and Their Content.................................................................................................63
Table 9: Key generation in the TOE......................................................................................................65
Table 10: Zeroization of Critical Security Parameters ..........................................................................68
Table 11: Cryptographic primitives in the TOE....................................................................................69
Table 12: SSH Algorithms.....................................................................................................................70
Table 13: Cipher suites..........................................................................................................................72
Table 14: TLS Server Error Alerts ........................................................................................................76
Table 15: BIG-IP Management Functions per interface........................................................................85
Table 16: BIG-IP User Roles.................................................................................................................87
List of Figures
Figure 1: BIG-IP Subsystems for F5 Devices and vCMP in Application Delivery Controller
Deployments ...................................................................................................................................8
Figure 2: Architectural aspects of BIG-IP – F5 Device and vCMP in Application Delivery Controller
Deployments .................................................................................................................................10
Figure 3: BIG-IP SSLO Traffic .............................................................................................................14
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 1
1 Introduction
This section identifies the Security Target, Target of Evaluation (TOE), conformance claims, ST
organization, document conventions, and terminology. It also includes an overview of the evaluated
product.
1.1 Security Target Identification
This section will provide information necessary to identify and control the Security Target and the
TOE.
ST Title: F5 BIG-IP 16.1.3.1 including SSLO Security Target
Version: 6.12
Publication Date: December 14, 2023
Sponsor: F5, Inc.
Developer: F5, Inc.
ST Author: Michelle Ruppel, Saffire Systems
1.2 TOE Identification
The TOE claiming conformance to this ST is identified as BIG-IP Version 16.1.3.1 including SSLO
(build Hotfix-BIGIP-16.1.3.1.0.128.11-ENG, also referred to as 16.1.3.1+EHF) running on any of the
devices identified in Section 1.2.1 . The TOE is deployed with the following license modes/modules:
• Application Delivery Controller deployment
o Appliance Mode
o Traffic Management Operating System (TMOS) modules
o Traffic Management Microkernel (TMM) module
o SSL Orchestrator (SSLO) module
o Local Traffic Manager (LTM) module
1.2.1 F5 Devices
The TOE consists of any of the hardware appliances listed in Table 1 installed with LTM+SSLO with
appliance mode software.
Explanation of table columns in the table below.
SKU (stock-keeping unit). A set of product SKUs define the hardware and software that is licensed
and shipped.
Each row in this table is a delivery option consisting of multiple product SKUs. The SKUs together
define the following for appliances:
- Base BIG-IP and platform (F5-BIG-LTM-nnn)
- Additional modules (F5-ADD-BIG-SSLO-nnn)
- Appliance mode (F5-ADD-BIG-MODE).
VIPRION devices are the same, but with the addition of VPR to the SKU, and the addition of a SKU
specifying the chassis (for example F5-VPR-LTM-C2400-AC).
vCMP?. A “Y” entry in the column notes that the platform supports, and the licensing allows, the use
of vCMP.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 2
Part #. This refers to the part number of the hardware device (appliance, blade, and/or chassis)
included in the platform SKU.
Model Series. Designates the family of appliances or blades to which the specified SKU belongs.
SKU VCMP? Part # Model Series
F5-BIG-LTM-I4600
F5-ADD-BIG-SSLO-2
F5-ADD-BIG-MODE
N 200-0390-07 i4000
F5-BIG-LTM-I5600
F5-ADD-BIG-SSLO-3
F5-ADD-BIG-MODE
N 200-0396-09 i5000
F5-BIG-LTM-I7600
F5-ADD-BIG-SSLO-3
F5-ADD-BIG-MODE
N 500-0031-01 i7000
F5-BIG-LTM-I10600
F5-ADD-BIG-SSLO-4
F5-ADD-BIG-MODE
N 500-0030-01 i10000
F5-BIG-LTM-I11600-DS
F5-ADD-BIG-SSLO-4
F5-ADD-BIG-MODE
Y 500-0015-05 i11000-DS
F5-BIG-LTM-I15600
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
N 500-0042-00 i15000
F5-BIG-LTM-I4800
F5-ADD-BIG-SSLO-2
F5-ADD-BIG-MODE
N 200-0390-07 i4000
F5-BIG-LTM-I5800
F5-ADD-BIG-SSLO-23
F5-ADD-BIG-MODE
Y 200-0396-09 i5000
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 3
F5-BIG-LTM-I5820-DF
F5-ADD-BIG-SSLO-3
F5-ADD-BIG-MODE
Y 500-0017-17 i5000
F5-BIG-LTM-I7800
F5-ADD-BIG-SSLO-3
F5-ADD-BIG-MODE
Y 500-0031-01 i7000
F5-BIG-LTM-I7820-DF
F5-ADD-BIG-SSLO-3
F5-ADD-BIG-MODE
Y 500-0032-01 i7000
F5-BIG-LTM-I10800
F5-ADD-BIG-SSLO-4
F5-ADD-BIG-MODE
Y 500-0030-01 i10000
F5-BIG-LTM-I11800-DS
F5-ADD-BIG-SSLO-4
F5-ADD-BIG-MODE
Y 500-0015-05 i11000-DS
F5-BIG-LTM-I15800
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
Y 500-0042-00 i15000
F5-BIG-LTM-I15820-DF
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
Y 500-0043-00 I15000-DF
F5-VPR-LTM-C2400-AC
F5-VPR-LTM-B2250
F5-ADD-VPR-SSLOC2X00
F5-ADD-BIG-MODE
F5-ADD-VPR-VCMP-2400
Y 400-0028-12
400-0039-03
C2400
B2250
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 4
F5-VPR-LTM-C4480-AC
F5-VPR-LTM-B4450
F5-ADD-VPR-SSLOC44X0
F5-ADD-BIG-MODE
F5-ADD-VPR-VCMP-4480
Y 400-0033-04
400-0053-11
C4480
B4450
Table 1: Supported Hardware Models
Each of the hardware platforms includes a third party proprietary cryptographic acceleration card. All
hardware platforms, except the B2250, include the Intel Coleto Creek (8955). The B2250 model
includes the Cavium Nitrox (CN3540-500-C20).
1.3 Document Terminology
Please refer to CC Part 1 Section 4 for definitions of commonly used CC terms.
1.3.1 ST Specific Terminology
This section contains definitions of technical terms that are used with a meaning specific to
this document. Terms defined in the CC Part 2 are not reiterated here, unless stated otherwise.
Administrators
Administrators are administrative users of the TOE, i.e. those users defined in the TOE
to be authorized to access the configuration interfaces of the TOE. Different roles can be
assigned to administrators, including the Administrator role -- the name of the role is not
to be confused with the general reference to an administrator being an administrative user
of the TOE in any role.
User
Humans or machines interacting with the TOE via the provided user and programmatic
interfaces. The TOE deals with different types of users -- administrators in charge of
configuring and operating the TOE, and traffic users who are subject to the TOE's
networking capabilities. User interactions with the TOE are transparent to the user, and
in most cases the users are not aware of the existence of the TOE.
1.3.2 Acronyms
CC Common Criteria
CMI Central Management Infrastructure
CRL Certificate Revocation List
CRLDP Certificate Revocation List Distribution Point
GUI Graphical User Interface
HSL High-Speed Logging
LTM Local Traffic Manager
OSP Organisational Security Policy
PP Protection Profile
SFP Security Function Policy
SFR Security Functional Requirement
SOAP Simple Object Access Protocol
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 5
TLS Transport Layer Security
TMM Traffic Management Microkernel
TMOS Traffic Management Operating System
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
vCMP Virtual Clustered Multi-Processing
VE Virtual Edition
1.4 TOE Type
The TOE type is a Networking Device.
1.5 TOE Overview
The BIG-IP products subject to this evaluation represent Application Delivery Controllers based on
F5's Traffic Management Operating System (TMOS). In particular,
• SSL Orchestrator (SSLO), which includes the Local Traffic Manager (LTM) and SSLO
modules, provides network traffic management capabilities.
BIG-IP products run on appliance or blade hardware provided by F5 listed in Section 1.2.1 . In
addition, BIG-IP running as a guest instance on F5 devices (appliances or blades) that support F5's
Virtual Clustered Multiprocessing (vCMP) environment is included. vCMP implements a purpose-
built embedded hypervisor that allows organizations to run multiple virtual instances of BIG-IP on the
same hardware.)
The TOE is located between a monitored client and a requested server enabling the TOE to intercept
TLS traffic between the two endpoints. The TOE's Traffic Management Microkernel (TMM), along
with additional software, provides basic networking functionality, with the TOE operating as a
network switch and reverse proxy. The BIG-IP SSLO implements secured connections between the
monitored client and the requested server with BIG-IP SSLO in the middle. This is accomplished by
establishing two TLS sessions: one TLS session between the monitored client and BIG-IP SSLO and
the other between BIG-IP SSLO and the requested server endpoint. This includes the following
security functions:
• Security Audit: BIG-IP implements syslog capabilities to generate audit records for security-
relevant events. In addition, the BIG-IP protects the audit trail from unauthorized modifications
and loss of audit data due to insufficient space.
• Cryptographic Support: In BIG-IP, cryptographic functionality in the control plane is
provided by the OpenSSL cryptographic module. The BIG-IP provides a secure shell (SSH) to
allow administrators to connect over a dedicated network interface. BIG-IP also implements
the TLS protocol to allow administrators to remotely manage the TOE. BIG-IP implements a
TLS client for interactions with other TLS servers. The BIG-IP SSLO cryptography is provided
by the cryptographic module within TMM, also based on OpenSSL. SSLO implements the TLS
protocol with forward proxy capabilities including inspection processing, bypassing inspection
processing, and blocking unauthorized sessions.
Both of these cryptographic implementations utilize a cryptographic module which provides
random number generation, key generation, key establishment, key storage, key destruction,
hash operations, encryption/decryption operations, and digital signature operations.
A limited Certification Authority (CA) is also embedded in the BIG-IP SSLO to issue
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 6
certificates in order to establish TLS sessions with the monitored client and the requested server
endpoint.
• Identification and Authentication: An internal password-based repository is implemented for
authentication of management users. BIG-IP enforces a strong password policy and disabling
user accounts after a configured number of failed authentication attempts.
• Security Function Management: A command line interface (available via the traffic
management shell "tmsh"), web-based GUI ("Configuration utility"), a SOAP-based API
("iControl API"), and a REST-based API (“iControl REST API”) are offered to administrators
for all relevant configuration of security functionality. The TOE manages configuration objects
in a partition which includes users, server pools, etc. This includes the authentication of
administrators by user name and password, as well as access control based on pre-defined roles
and, optionally, groups of objects ("Profiles"). "Profiles" can be defined for individual servers
and classes of servers that the TOE forwards traffic from clients to, and for traffic that matches
certain characteristics, determining the kind of treatment applicable to that traffic. Management
capabilities offered by the TOE include the definition of templates for certain configuration
options. The management functionality also implements roles for separation of duties.
• Protection of the TSF: BIG-IP implements many capabilities to protect the integrity and
management of its own security functionality. These capabilities include the protection of
sensitive data, such as passwords and keys, self-tests, product update verification, and reliable
time stamping.
• TOE Access: Prior to interactive user authentication, the BIG-IP can display an administrative-
defined banner. BIG-IP terminates interactive sessions after an administrator-defined period of
inactivity and allows users to terminate their own authenticated session.
• Trusted Path / Channels: The TOE protects remote connections to its management interfaces
with TLS and SSH. The TOE also protects communication channels with audit servers using
TLS.
• User Data Protection: The BIG-IP SSLO implements certificate profiles for TLS server
certificates issued by the CA embedded in the TOE, enforces TLS plaintext processing policies,
ensures residual information contained in TLS buffers is not available, protects trusted public
keys and certificates used in SSLO, and performs inspection operations and proxy functions of
SSLO sessions.
1.6 TOE Description
1.6.1 Introduction
Typical BIG-IP network environments include an internal network, administrator network, external
network, server pools, and redundant BIG-IP systems. In this typical example,
• Internet connections are mediated by BIG-IP to provide access to certain resources located in
an organization's internal server pool, for example to a web-based e-commerce system
presenting a storefront to consumers
• Users in the organization's Intranet also access resources in the server pools to interact with the
internal server pool. Although not included in the TOE, BIG-IP provides server termination of
traffic flowing to a backend server by implementing a TLS client protocol.
• Network administrators connect to BIG-IP via a dedicated network interface to administer the
TOE
• TLS connections from the organization’s Intranet to servers hosted on the Internet are mediated
by BIG-IP to provide the capability to decrypt encrypted traffic, inspect the traffic using
security controls, then re-encrypt the traffic and transmit it to its destination
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 7
• The TOE is optionally set up in a redundant failover configuration, with heartbeat monitoring
and reporting via a data link between the two instances
When deployed as two redundant systems configured in an active/standby failover configuration, the
two systems can synchronize their configuration data and provide state and persistence monitoring. The
TOE will fail over to the redundant system while maintaining a secure configuration if failures the
active device sends a request to the standby device or if the standby device detects missing heartbeats
from the active device. The new active device will continue to enforce security policies for new (and
possibly active) connections mediated by the TOE. BIG-IP uses CMI (Central Management
Infrastructure), a proprietary protocol, for the incremental exchange of configuration data and failover
status between TOE instances; CMI is encapsulated in TLS to provide integrity and confidentiality
protections. In this configuration a physical network port will be dedicated on each device for the
exchange of synchronization data and failover monitoring with the standby device. Failover /
redundancy is not in the scope of the evaluated configuration. Connection mirroring does not function
with SSL forward proxy connections.
1.6.2 Architecture Description
The TOE is separated into two (2) distinct planes, the control plane and the data plane. The control
plane validates, stores, and passes configuration data to all necessary systems. It also provides all
administrative access to the TOE. The data plane passes user traffic through the TOE.
The TOE implements and supports the following network protocols: TLS (client and server), SSH,
HTTPS, FTP. The TOE protects remote connections to its management interfaces with TLS and SSH.
The TOE also protects communication channels with audit servers using TLS (TLSv1.1 and
TLSv1.2). The cryptographic functionality implemented in the TOE is provided by OpenSSL.
The TOE is divided into the following subsystems:
• F5 Device (hardware or virtual) for F5 devices or vCMP deployments,
• Traffic Management Operating System (TMOS),
• Traffic Management Micro-kernel (TMM),
• SSL Orchestrator (SSLO), and
• Local Traffic Manager (LTM).
F5’s TMOS is a Linux-based operating system customized for performance and to execute on the
TOE hardware or in the TOE Virtual Clustered Multiprocessing (vCMP) environment. The vCMP is
an embedded hypervisor that allows multiple instances of the TOE to execute on the same underlying
hardware. The TMM is the data plane of the product and all data plane traffic passes through the
TMM. The LTM controls network traffic coming into or exiting the local area network (LAN) and
provides the ability to intercept and redirect incoming network traffic. The SSLO module intercepts a
TLS session between a monitored client and requested server and implements a TLS session between
the monitored client and the TOE and another TLS session between the TOE and the requested server.
The SSLO module can also be configured to send the intercepted traffic to external inspection
services.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 8
Figure 1: BIG-IP Subsystems for F5 Devices and vCMP in Application Delivery Controller
Deployments
TMOS is a Linux operating system that runs directly on device hardware, in a vCMP environment.
TMOS is a modified version of the RedHat Linux kernel. In addition to providing the standard
operating system features (such as process management, file management, etc), the TMOS provides
the following security features for the TOE:
• Auditing functionality, using the host system's syslog capabilities. (In addition, a concept called
"high-speed logging" (HSL) allows TMM instances to send certain log traffic directly to
external audit servers.)
• Time stamping
• Management functionality, presented to consumers via a dedicated shell providing a command
line interface (traffic management shell, "tmsh") that can be reached by administrators via SSH
(OpenSSH); and via a web GUI (“Configuration Utility”), a SOAP protocol interface
("iControl API"), or REST interface (“iControl REST API”) that can be reached through a
network interface via HTTPS. Those management interfaces are implemented in the
background by a central management control program daemon (mcpd) that provides
configuration information to individual TOE parts and coordinates its persistent storage.
• Authentication functionality is enforced on all administrative interfaces. Administrative
interfaces implement an internal password-based repository for authentication of administrative
users.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 9
• Cryptographic algorithms provided by OpenSSL.
• Individual daemons introduced by BIG-IP packages, such as the modules implementing the
LTM and SSLO logic.
At the core of BIG-IP is a concept referred to as Traffic Management Microkernel (TMM),
representing the data plane of the product when compared to traditional network device architectures.
It is implemented by a daemon running with root privileges, performing its own memory
management, and having direct access to the network hardware. TMM implements a number of
sequential filters both for the “client-side” and “server-side” network interfaces served by BIG-IP.
The filters implemented in TMM include a TCP, TLS, compression, and HTTP filter, amongst others.
If the hardware provides more than one CPU, TMM runs multi-threaded (one thread per CPU). In this
case, disaggregators in the kernel are responsible for de-multiplexing and multiplexing network traffic
for handling by an individual TMM thread. In addition to the actual switch hardware, F5 appliance
hardware also contains a High-Speed Bridge (HSB, implemented by means of an FPGA) that
performs basic traffic filtering functionality as instructed by TMM.
Additional plug-in filters can be added to this queue by individual product packages. These plug-ins
typically have a filter component in TMM, with additional and more complex logic in a counter-part
implemented in a Linux-based daemon (module). The plug-in modules relevant to the SSLO
Deployments are shown in Figure 2. These plug-in modules include:
• Local Traffic Manager (LTM): authentication of HTTP (based on Apache) traffic and advanced
traffic forwarding directives
• SSL Orchestrator (SSLO): enhance TLS-based client connectivity by providing visibility into
TLS traffic and the ability for external inspection services on that traffic.
A diagram depicting aspects of the TOE’s architecture and the boundaries of the TOE are provided in
Figure 2.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 10
Figure 2: Architectural aspects of BIG-IP – F5 Device and vCMP in Application Delivery
Controller Deployments
1.6.3 Physical Boundaries
This section lists the physical components of the product and denotes which are in the TOE and which
are in the environment.
1.6.3.1 Physical boundaries
When BIG-IP version 16.1.3.1 is running on one of the F5 devices identified in Section 1.2.1, the
TOE includes hardware and software physical components as identified in Section 1.2.1.
The evaluated configuration of BIG-IP Version 16.1.3.1 including SSLO represents a licensing option
with the following F5 modules present and operational:
• Application Delivery Controller deployment
o Appliance Mode
o Traffic Management Operating System (TMOS) modules
o Traffic Management Microkernel (TMM) module
o SSL Orchestrator (SSLO) module
o Local Traffic Manager (LTM) module
The following required components can be found in the operating environment of the TOE on systems
other than those hosting the TOE:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 11
• audit servers.
Client software (e.g., the BIG-IP Client for TLS VPN connections, endpoint inspection software
executed on clients) are optional components that are not part of the TOE.
1.6.3.2 Guidance Documentation
Relevant guidance documents for the secure operation of BIG-IP that are part of the TOE are:
Certification-specific References
K76615426: Common Criteria Certification for BIG-IP 16.1.3.1
BIG-IP Common Criteria Evaluation Configuration Guide BIG-IP Release 16.1.3.1 Including SSLO
General BIG-IP References
BIG-IP Device Service Clustering: Administration
BIG-IP Digital Certificates: Administration
BIG-IP Local Traffic Manager: Implementations
BIG-IP Local Traffic Manager: Monitors Reference
BIG-IP Local Traffic Manager: Profiles Reference
BIG-IP Local Traffic Manager: Configuring a Custom Cipher String for SSL Negotiation
BIG-IP Release Note
BIG-IP System: Essentials
BIG-IP System: SSL Administration
BIG-IP System: User Account Administration
BIG-IP Systems: Getting Started Guide
BIG-IP TMOS: Implementations
BIG-IP TMOS: Routing Administration
External Monitoring of BIG-IP Systems: Implementations
GUI Help Files
iControl API Reference
iControl REST API User Guide
K08859735: Overview of the FTP profile (14.x – 16.x)
K12042624: Restricting access to the Configuration utility using client certificates (13.x – 16.x)
K13092: Overview of securing access to the BIG-IP system
K13123: Managing BIG-IP product hotfixes (11.x – 17.x)
K13302: Configuring the BIG-IP system to use an SSL chain certificate (11.x – 16.x)
K13454: Configuring SSH public key authentication on BIP-IP systems (11.x – 16.x)
K14620: Managing SSL Certificates for BIG-IP systems using the Configuration utility
K14783: Overview of the Client SSL profile (11.x – 17.x)
K14806: Overview of the Server SSL profile (11.x – 17.x)
K15462: Managing SSL certificates for BIG-IP systems using tmsh
K15497: Configuring a secure password policy for the BIG-IP system (11.x – 16.x)
K15664: Overview of BIG-IP device certificates (11.x – 16.x)
K42531434: Replacing the Configuration utility’s self-signed SSL certificate with a CA-signed SSL
certificate
K48615077: BIG-IP Daemons (15.x – 16.x)
K5532: Configuring the level of information logged for Traffic Management-related events
K6068: Configuring a pre-login or post-login message banner for the BIG-IP or Enterprise
Manager system
K7683: Connecting a serial terminal to a BIG-IP system
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 12
K7752: Licensing the BIG-IP system
K8021: Configuring the BIG-IP LTM system to allow outbound FTP sessions
K80425458: Modifying the list of ciphers and MAC algorithms used by the SSH service on the
BIG-IP system or BIG-IQ system
K9908: Configuring an automatic logout for idle sessions
K75106155: Configuring OCSP stapling (13.x – 16.x)
F5 SSL Orchestrator Deployment Guide - Version 9
README.Hotfix-BIGIP-16.1.3.1.0.119.11-ENG.txt
Traffic Management Shell (tmsh) Reference Guide (versions 17.0.0 and 12.0.01
)
Platform-specific References – Hardware and vCMP
Platform Guide: i2000/i4000 Series
Platform Guide: i5000/i7000/i10000/i11000 Series
Platform Guide: i15000 Series
Platform Guide: VIPRION® 2200
Platform Guide: VIPRION® 4400 Series
vCMP for Appliance Models: Administration
vCMP for VIPRION Systems: Administration
Table 2: Guidance Documentation
1.6.4 Logical Boundaries
The following security functions provided by the TOE are described in more detail in the subsections
below:
• Security Audit
• Cryptographic Support
• Identification and Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channels
• User Data Protection
The following configuration specifics apply to the evaluated configuration of the TOE:
• Appliance mode is licensed. Appliance mode disables root access to the TOE operating
system and disables bash shell.
• Certificate validation is performed using CRLs.
• Disabled interfaces:
o All command shells other than tmsh are disabled. For example, bash and other user-
serviceable shells are excluded.
1
The tmsh reference guide version 17.0.0 zipfile contains the pages for each of the tmsh commands. The 12.0.0
pdf contains additional general information that is still valid in 16.1.3.1 but not reproduced in the 17.0.0 zipfile.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 13
o Management of the TOE via SNMP is disabled.
o Management of the TOE via the appliance's LCD display is disabled. (applicable to F5
devices and vCMP only)
o Remote (i.e., SSH) access to the Lights Out / Always On Management2
capabilities of the
system is disabled. (applicable to F5 devices and vCMP only)
o SSH client
1.6.4.1 Security Audit
BIG-IP implements auditing functionality based on standard syslog functionality. This includes the
support of remote audit servers for capturing of audit records. Audit records are generated for all
security-relevant events, such as the use of configuration interfaces by administrators, the
authentication of traffic, and the application of network traffic rules.
While the TOE can store audit records locally for cases when an external log server becomes
unavailable, in the evaluated configuration an external log server is used as the primary means of
archiving audit records.
In the evaluated configuration, BIG-IP logs a warning to notify the administrator when the local audit
storage exceeds a configurable maximum size. Once the configurable maximum size is reached, BIG-
IP overwrites the oldest audit records.
1.6.4.2 Cryptographic Support
All cryptographic operations, including algorithms and key generation used by the TOE are provided
by the F5 cryptographic module (OpenSSL) within the TMOS.
Various security functions in BIG-IP rely on cryptographic mechanisms for their effective
implementation. Trusted paths for the TOE administrator are provided by SSH for the tmsh
administrative interface and by TLS for the Configuration utility, iControl API and iControl REST
API. For administrative sessions, the TOE always acts as a server. For traffic sessions, the TOE may
act as a TLS client or server. Trusted channels between the TOE and external entities, such as a syslog
server, are provided by TLS connections.
For TLS sessions, the TOE implements certificate validation using the OpenSSL crypto library.
The TOE utilizes cryptographic algorithms that have been validated using the NIST ACVP tests.
For F5 devices and vCMP platforms, the underlying hardware platforms of the TOE include a third
party proprietary cryptographic acceleration card that is used to provide both sufficient entropy to
support random number generation (RNG) and acceleration.
1.6.4.2.1 Key Generation
The TOE can generate asymmetric keys using RSA schemes and ECC schemes. For F5 devices and
vCMP platforms, the underlying hardware platforms of the TOE include a third party proprietary
cryptographic acceleration card that is used to provide sufficient entropy to support RNG. For F5
devices and vCMP platforms, the TOE provides a total of four entropy sources. The TOE can generate
keys (and certificates) for a number of uses, including:
• Keypairs for the SSH server functionality
• TLS server and client certificates
2
Lights Out / Always On Management is an add-on module providing a management system for non-security
related features not required for operation of the TOE.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 14
• Session keys for SSH and TLS sessions
1.6.4.2.2 SSL/TLS Inspection Proxy
The TOE implements an administrator-configurable SSL/TLS Inspection proxy. The administrator
configures SSL forward proxy profiles to define which TLS connections are subject to inspection, to
define the TLS session parameters of the connections, and to define any inspection services that will
be performed on the connection.
The SSLO module accomplishes the inspection operation by terminating TLS sessions between a
monitored client and the requested server that meet the SSLO policy conditions, then replacing the
end-to-end connection with two TLS sessions that terminate at the TOE. The TOE establishes a TLS
session between the TOE (acting as the monitored client) and the requested server and a second TLS
session between the TOE (acting as the requested server) and the monitored client. By intercepting the
TLS session, the TOE can send the decrypted traffic to an external inspection service for processing.
As configured by the SSL forward proxy profiles, SSLO also determines which TLS sessions should
bypass inspection processing and be routed without decryption, inspection, and modification. When
SSLO determines that a session is not authorized, the session is blocked and the traffic is not routed to
the other endpoint.
Figure 3: BIG-IP SSLO Traffic
1.6.4.3 Identification and Authentication
The TOE identifies individual administrative users by user name and authenticates them by passwords
stored in a local configuration database; the TOE can enforce a password policy based on overall
minimum length and number of characters of different types required. BIG-IP obscures passwords
entered by users.
Authentication of administrators is enforced at all configuration interfaces, i.e. at the shell (tmsh, via
SSH), the Configuration utility (web-based GUI), iControl API, and iControl REST API.
1.6.4.4 Security Management
The TOE allows administrators to configure all relevant aspects of security functionality implemented
by the TSF. For this purpose, BIG-IP offers multiple interfaces to administrators:
• Configuration utility
The Configuration utility presents a web-based GUI available to administrators via HTTPS
that allows administration of most aspects of the TSF.
• traffic management shell (tmsh)
tmsh is a shell providing a command line interface that is available via SSH. It allows
administration of all aspects of the TSF.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 15
• iControl API
The iControl API is a SOAP based protocol interface that allows programmatic access to the
TSF configuration via HTTPS.
• iControl REST API
The iControl REST API is effectively a front-end to tmsh and is built on the Representational
State Transfer (REST), which allows programmatic access to the TSF via HTTPS.
The TOE provides the ability to administer the TOE both locally and remotely using any of the four
administrative interfaces. Local administration is performed via the serial port console. By default
and in the evaluated configuration, remote access to the management interfaces is only made available
on the dedicated management network port of a BIG-IP system.
BIG-IP implements a hierarchy of roles that are pre-defined to grant administrators varying degrees of
control over the basic configuration of the TOE, and additional roles are introduced for module-
specific tasks. These roles can be assigned to users by authorized administrators.
In addition to roles, the TOE allows the definition of partitions. Configuration objects, such as server
pools or service profiles, can be assigned to individual partitions, as can administrative users. This
allows administrative access of individual administrators to be restricted to configuration objects that
belong to the partition that has been assigned to the user.
1.6.4.5 Protection of the TSF
The TOE is designed to protect critical security data, including keys and passwords. In addition, the
TOE includes self-tests that monitor continue operation of the TOE to ensure that it is operating
correctly. The TOE also provides a mechanism to provide trusted updates to the TOE firmware or
software and reliable timestamps in order to support TOE functions, including accurate audit
recording.
1.6.4.6 TOE access
The TOE implements session inactivity time-outs for Configuration utility and tmsh sessions and
displays a warning banner before establishing an interactive session between a human user and the
TOE.
1.6.4.7 Trusted Path/Channels
This chapter summarizes the security functionality provided by the TOE in order to protect the
confidentiality and integrity of network connections described below.
1.6.4.7.1 Generic network traffic
The BIG-IP allows the termination of data plane TLS connections on behalf of internal servers or
server pools. External clients can thus connect via TLS to the TOE, which acts as a TLS server and
decrypts the traffic and then forwards it to internal servers for processing of the content. It is also
possible to (re-) encrypt traffic from the TOE to servers in the organization with TLS, with the TOE
acting as a TLS client.
1.6.4.7.2 Administrative traffic
The TOE secures administrative traffic (i.e., administrators connecting to the TOE in order to
configure and maintain it) as follows:
• Remote access to the traffic management shell (tmsh) is secured via SSH.
• Remote access to the web-based Configuration utility, iControl REST API, and iControl API
is secured via TLS.
1.6.4.7.3 OpenSSH
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 16
The TOE SSH implementation is based on OpenSSH; however, the TOE OpenSSH configuration sets
the implementation via the sshd_config as follows:
• Supports two types of authentication, RSA public-key and password-based
• Packets greater than (256*1024) bytes are dropped
• The transport encryption algorithms are limited to AES-CBC-128, AES-CBC-256, AES-CTR-
128, AES-CTR-256
• The SSH public-key authentication algorithms are limited to ecdsa-sha2-nistp256, ecdsa-sha2-
nistp384
• The transport data integrity algorithm is limited to HMAC-SHA1 and HMAC-SHA2-256
• The SSH protocol key exchange mechanism is limited to ecdh-sha2-nistp256 and ecdh-sha2-
nistp384.
1.6.4.7.4 Remote logging
The TOE offers the establishment of TLS sessions with external log hosts in the operational
environment for protection of audit records in transfer.
1.6.4.8 User Data Protection
The TOE implements certificate profiles for TLS server certificates issued by the CA embedded in the
TOE and issues certificates as specified by these profiles. The TOE is also capable of providing a
method to link the TLS server certificates validated by the TOE to the forged certificate issued by the
TOE to represent that server. The TOE performs TLS plaintext processing policies when the policy
authorizes inspection processing.
Residual information contained in TLS buffers is not available upon allocation of the resource.
Trusted public keys and certificates used in SSLO are protected.
1.6.5 Delivery
1.6.5.1 F5 Devices and vCMP
The F5 BIG-IP hardware is manufactured and shipped via common carrier from an authorized
subcontractor, Flextronics, headquartered in Milpitas, California. Manufacturing for the BIG-IP
product consists of assembling the hardware, loading the BIG-IP software image onto the hard disk
drive and performing test and inspection activities. Flextronics has been qualified by F5, Inc. to
manufacture, test, and deliver the BIG-IP product through an on-site assessment, process evaluation
and F5, Inc. Supplier Approval Program.
The BIG-IP system arrives from the factory with the SKU-specified software pre-installed. However,
to guard against potential tampering during shipping, customers are directed to reinstall the software
from the F5 download website. Instructions for this are in the Guidance document.
1.6.5.2 Documentation
Administrator, Configuration, and Installation manuals are made available to customers on the F5
Website by product model number and applicable revision. Manuals are not shipped with the product.
In addition, an ISO of the customer documentation referenced by this evaluation is available in the
same download directory as the product ISO. The documentation ISO, like the product ISO, is
available only over a TLS or HTTPS connection. For additional security, the sha256 checksum of the
ISO is also published with the ISO; its file name is the ISO file name concatenated with “.sha256”.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 17
2 Conformance Claims
2.1 CC Conformance Claims
This ST was developed to Common Criteria (CC) for Information Technology Security Evaluation –
April 2017 Version 3.1, Revision 5, CCMB-2017-04-001
The ST claims to be:
CC Version 3.1 Part 2 extended
CC Version 3.1 Part 3 conformant
2.2 PP and Package Claims
The ST claims exact conformance to the following:
• PP-Configuration for Network Device and SSL/TLS Inspection Proxy (STIP) (CFG_ND-
STIP_V1.1), Version 1.1, 2023-10-06
CFG_ND-STIP_V1.1 consists of the following components:
• collaborative Protection Profile for Network Devices (NDcPP), Version 2.2e, 23-March 2020
conformant
• PP-Module for SSL/TLS Inspection Proxy (STIPM), Version 1.1, 2022-11-17
The ST is compliant with the following NDcPP technical decisions:
NDcPP Technical Decision Applicability
0800 – Updated NIT Technical Decision for IPsec IKE/SA
Lifetimes Tolerance
Not applicable. The TOE does not
claim FCS_IPSEC_EXT.1
0792 – NIT Technical Decision: FIA_PMG_EXT.1 - TSS EA
not in line with SFR
Applicable.
0790 – NIT Technical Decision: Clarification Required for
testing IPv6
Applicable.
0738 – NIT Technical Decision for Link to Allowed-With
List
Applicable.
0670 – NIT Technical Decision for Mutual and Non-Mutual
Auth TLSC Testing
Applicable.
0639 – NIT Technical Decision for Clarification for NTP
MAC Keys
Not applicable. The TOE does not
claim FCS_NTP_EXT.1
0638 – NIT Technical Decision for Key Pair Generation for
Authentication
Applicable.
0636 – NIT Technical Decision for Clarification of Public
Key User Authentication for SSH
Not applicable. The TOE does not
claim FCS_SSHC_EXT.1.
0635 – NIT Technical Decision for TLS Server and Key
Agreement Parameters
Applicable.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 18
NDcPP Technical Decision Applicability
0633 – NIT Technical Decision for IPsec IKE/SA Lifetimes
Tolerance
Not applicable. The TOE does not
claim FCS_IPSEC_EXT.1.
0632 – NIT Technical Decision for Consistency with Time
Data for vNDs
Applicable, but the TOE does not
obtain time from the underlying
virtualization system.
0631 – NIT Technical Decision for Clarification of public
key authentication for SSH Server
Applicable.
0592 – NIT Technical Decision for Local Storage of Audit
Records
Applicable.
0591 – NIT Technical Decision for Virtual TOEs and
hypervisors
Applicable, but the TOE does not
include VMs.
0581 – NIT Technical Decision for Elliptic curve-based key
establishment and NIST SP 800-56Arev3
Not applicable. The TOE
implements elliptic curve-based
key establishment that confirms to
NIST SP 800- 56Arev2, not NIST
SP 800- 56Arev3.
0580 – NIT Technical Decision for clarification about use of
DH14 in NDcPPv2.2e
Not applicable. The TOE does not
implement FFC schemes for
cryptographic key establishment.
0572 – NIT Technical Decision for Restricting FTP_ITC.1 to
only IP address identifiers
Applicable.
0571 – NIT Technical Decision for Guidance on how to
handle FIA_AFL.1
Applicable.
0570 – NIT Technical Decision for Clarification about
FIA_AFL.1
Applicable.
0569 – NIT Technical Decision for Session ID Usage
Conflict in FCS_DTLSS_EXT.1.7
Applicable.
0564 – NIT Technical Decision for Vulnerability Analysis
Search Criteria
Applicable.
0563 – NIT Technical Decision for Clarification of audit date
information
Applicable.
0556 – NIT Technical Decision for RFC 5077 question Applicable.
0555 – NIT Technical Decision for RFC Reference incorrect
in TLSS Test
Applicable.
0547 – NIT Technical Decision for Clarification on developer
disclosure of AVA_VAN
Applicable.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 19
NDcPP Technical Decision Applicability
0546 – NIT Technical Decision for DTLS - clarification of
Application Note 63
Not applicable. The TOE does not
claim FCS_DTLSC_EXT.1
0537 - NIT Technical Decision for Incorrect reference to
FCS_TLSC_EXT.2.3
Applicable.
0536 - NIT Technical Decision for Update Verification
Inconsistency
Applicable.
0528 - NIT Technical Decision for Missing EAs for
FCS_NTP_EXT.1.4
Not applicable. The TOE does not
claim FCS_NTP_EXT.1
0527 - Updates to Certificate Revocation Testing
(FIA_X509_EXT.1)
Applicable. The ST supports EC
certificates
The ST is compliant with the following STIPM TDs:
STIPM Technical Decision Applicability
0808 – Clarification on EKU Fields for
FIA_X509_EXT.1/STIP
Applicable.
0774 – Correction to Supported Cipher Suite in
FCS_TTTC_EXT.1.1 and FCS_TTTS_EXT.1.1
Applicable.
0741 – Arbitrary Ciphers in FCS_TTTC/S_EXT Applicable.
The ST was also evaluated against the individual evaluation activities
• Evaluation Activities for Network Device cPP, Version 2.2, 20-December-2019
• Supporting Document Mandatory Technical Document PP-Module for SSL/TLS Inspection
Proxy, Version 1.1, 2022-11-17
2.3 Conformance Rationale
The ST claims exact conformance to the CFG_ND-STIP_V1.1.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 20
3 Security Problem Definition
A network device has a network infrastructure role it is designed to provide. In doing so, the network
device communicates with other network devices and other network entities (an entity not defined as
a network device) over the network. At the same time, it must provide a minimal set of common
security functionality expected by all network devices. The security problem to be addressed by a
compliant network device is defined as this set of common security functionality that addresses the
threats that are common to network devices, as opposed to those that might be targeting the specific
functionality of a specific type of network device. The set of common security functionality addresses
communication with the network device, both authorized and unauthorized, the ability to perform
valid or secure updates, the ability to audit device activity, the ability to securely store and utilize
device and administrator credentials and data, and the ability to self-test critical device components
for failures.
A STIP is a network device that embeds limited CA functionality to support the replacement of end-
to-end TLS sessions with TLS session threads, making the underlying plaintext available to additional
network security functionality. As such, it exposes data within the TOE boundary, and to external
processes, which would normally be encrypted. It manages a CA signing key that is trusted by the
monitored clients to issue TLS server certificates representing the requested servers for which
inspection is authorized.
The TOE is intended to be used either in environments in which, at most, sensitive but unclassified
information is processed, or the sensitivity level of information in both the internal and external
networks is equivalent.
This security target includes a restatement of the Security Problem Definition (threats, organizational
security policies, and assumptions) from NDcPP and STIPM. The threats, organizational security
policies and assumptions are repeated here for the convenience of the reader. Refer to the NDcPP and
STIPM for additional detail.
3.1 Threat Environment
This section describes the threat model for the TOE and identifies the individual threats that
are assumed to exist in the operational environment of the TOE.
The assets to be protected by the TOE are:
• Critical network traffic (administration traffic, authentication traffic, audit traffic, etc.)
to/from the TOE
• The TSF and TSF data
The threat agents having an interest in manipulating the TOE and TSF behavior to gain access
to these assets can be categorized as:
• Unauthorized third parties (“attackers”, such as malicious remote users, parties, or
external IT entities) which are unknown to the TOE and its runtime environment.
Attackers are traditionally located outside the organizational environment that the TOE
is employed to protect, but may include organizational insiders, too.
• Authorized users of the TOE (i.e., administrators) who try to manipulate configuration
data that they are not authorized to access. TOE administrators, as well as
administrators of the operational environment, are assumed to be trustworthy, trained
and to follow the instructions provided to them with respect to the secure configuration
and operation of the systems under their responsibility. Hence, only inadvertent
attempts to manipulate the safe operation of the TOE are expected from this
community.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 21
The motivation of threat agents is assumed to be commensurate with the assurance level
pursued by this evaluation, i.e., the TOE intends to resist penetration by attackers with a Basic
attack potential.
3.2 Threats
The threats identified in this section may be addressed by the TOE, TOE environment, or a
combination of both. The threat agents are authorized persons/processes, unauthorized
persons/processes, or external IT entities not authorized to use the TOE itself. The threats identified
assume that the threat agent is a person with a low attack potential who possesses an average
expertise, few resources, and low to moderate motivation.
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
tunneling 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., 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
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 22
avenue (e.g., misconfiguration, flaw in the product) to compromise the device and 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 include 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.
T.UNTRUSTED_COMMUNICATION
Untrusted intermediate systems have access to provide unauthorized communications to the
TOE, or to manipulate authorized TLS messages in an attempt to compromise the TOE, the
monitored clients, or the requested servers. Within this PP-Module, the focus is on an
adversary that controls or exploits a requested server that may attempt to cause the device to
inappropriately bypass inspection.
Use of weak cryptography can allow adversary access to plaintext intended by the monitored
clients to be encrypted. Such access could disclose user passwords that facilitate additional
activities against users of monitored clients. Within this PP-Module, the focus is on the use of
weak cryptography and adversary attempts to degrade the cryptographic operations within the
TLS protocol.
External network security devices may communicate with the TOE to apply security services
to the exposed plaintext. An adversary may attempt to gain access the plaintext via misrouting
of traffic or manipulate the traffic in such a way as to cause unauthorized exposure, denial of
service, or corruption of the underlying plaintext.
T.AUDIT
Certificates issued by the device are trusted by monitored clients, and are required for analysis
if traffic processed by the device causes the client to fail or become compromised. Unknown
activity related to the issuance and use of certificates can allow an adversary to mask client
exploits through or via the TOE, especially if the device fails before the incident can be
understood. Unknown activity associated to routing configurations, communications with the
TOE, as well as the decision to bypass inspection of traffic can allow an adversary to mask
attempts to access monitored clients.
T.UNAUTHORIZED_USERS
In addition to managing administrative credentials, authorized users may have role
restrictions to limit their access to the device’s certification authority functionality. In
addition to the threat of disclosure or modification of authorized user credentials to users
without authorized access to the device, a user with limited access might attempt to extend
their access by gaining access to other user’s credentials.
T.CREDENTIALS
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 23
In addition to device credentials used in protected communications, the device maintains a
trusted certification authority signing key. A malicious user or flawed TOE implementation
may cause the disclosure or unauthorized manipulation of the signing key which can result in
unintended certificates, signed executables, or signed data that would be trusted by monitored
clients. Any modification of the signing key can result in denial of service to inspection
capabilities, or to the monitored clients.
T.SERVICES
Manipulation of the device can result in issued certificates being used for unauthorized
purposes or abuse of inspection services. An authorized user (AU) (or adversary able to gain
access to AU credentials) can access or misuse device services, or disclose sensitive or
security critical data.
T.DEVICE_FAILURE
Failure of the certification authority component can result in unauthorized or improperly
constrained certificates, or the inability to properly manage the validity of issued certificates.
Failure of routing traffic to inspection processing (internal or external) can result in
unauthorized disclosure or modification of traffic, or denial of service to monitored clients.
T.UNAUTHORIZED_DISCLOSURE
In addition to general threats to network devices, the TOE controls access to sensitive data
that is intended by the monitored client to be encrypted. A malicious user or flawed TOE
implementation could cause data to be transmitted in cleartext for which a user has a
reasonable expectation of confidentiality.
T.INAPPROPRIATE_ACCESS
Decryption services applied to traffic between monitored clients and unintended servers can
violate privacy laws, or disclose unauthorized traffic to inspection processes. Certification
authority signature applied to unauthorized data could facilitate adversary exploits of
monitored clients.
3.3 Organisational Security Policies
The TOE environment must include and comply with the following organizational security policies.
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.
P.AUTHORIZATION_TO_INSPECT
The authority to inspect client traffic may be limited by law, regulation, or policies based on
the monitored client, requested server, or nature of the traffic. The TOE may be required to
additionally provide a consent to monitor notice for users whose traffic is inspected by the
device, if the monitored client might not provide such a banner.
3.4 Assumptions
The assumptions defined below are made on the operational environment to ensure that the security
functionality defined in this ST can be provided by the TOE.
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
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 24
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. For vNDs, this assumption applies to the physical platform on which the VM runs.
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).
In the case of vNDs, the VS is considered part of the TOE with only one vND instance
for each physical hardware platform. The exception being where components of the
distributed TOE run inside more than one virtual machine (VM) on a single VS. There
are no other guest VMs on the physical platform providing non-Network Device
functionality.
The assumed functionality of the TOE includes the behavior needed to satisfy the
functional claims of STIPM.
A.NO_THRU_TRAFFIC_PROTECTION
The 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 and PP-
Modules for particular types of Network Devices (e.g., firewall).
This assumption only applies to the interfaces of the TOE that are defined by the NDcPP and
not STIPM.
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.
For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s)
are expected to fully validate (e.g. offline verification) any CA certificate (root CA certificate
or intermediate CA certificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CA
Key Store', or similar) as a trust anchor prior to use (e.g. offline verification).
The functional claims of STIPM offer a limited ability to protect against malicious
administrators, which is not within the scope of the original assumption.
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
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 25
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.
Residual information is expanded to include information relevant to STIP operation (e.g.
decrypted SSL/TLS payload, ephemeral keys).
A.VS_TRUSTED_ADMINISTRATOR (applies to vNDs only)
The Security Administrators for the VS are assumed to be trusted and to act in the best
interest of security for the organization. This includes not interfering with the correct
operation of the device. The Network Device is not expected to be capable of defending
against a malicious VS Administrator that actively works to bypass or compromise the
security of the device.
A.VS_REGULAR_UPDATES (applies to vNDs only)
The VS software is assumed to be updated by the VS Administrator on a regular basis in
response to the release of product updates due to known vulnerabilities.
A.VS_ISOLATON (applies to vNDs only)
For vNDs, it is assumed that the VS provides, and is configured to provide sufficient
isolation between software running in VMs on the same physical platform. Furthermore, it is
assumed that the VS adequately protects itself from software running inside VMs on the
same physical platform.
A.VS_CORRECT_CONFIGURATION (applies to vNDs only)
For vNDs, it is assumed that the VS and VMs are correctly configured to support ND
functionality implemented in VMs.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 26
4 Security Objectives
This chapter describes the security objectives for the TOE and the security objectives for the TOE’s
operating environment (i.e., security objectives addressed by the IT domain or by non-technical or
procedural means).
4.1 Security Objectives for the TOE
The security objectives for the TOE are listed below.
O.AUDIT_LOSS_RESPONSE
The TOE will respond to possible loss of audit records when an audit trail cannot be written to
by restricting auditable events.
O.CERTIFICATES
The TSF must ensure that certificates, certificate revocation lists, and certificate status
information are valid.
O.DISPLAY_BANNER
The TOE will display an advisory warning regarding use of the TOE.
O.INTEGRITY_PROTECTION
The TOE will provide appropriate integrity protection for TSF data and software and any user
data stored by the TOE.
O.PERSISTENT_KEY_PROTECTION
The TOE will provide appropriate confidentiality and access protection to persistent keys and
security critical parameters stored by the TOE.
O.PROTECTED_COMMUNICATIONS
The TOE will provide protected communication channels for administrators, other parts of a
distributed TOE, and authorized IT entities. The TOE will protect data assets when they are
being transmitted to and from the TOE, including through intervening untrusted components.
O.RECOVERY
The TOE will have the ability to store and recover to a previous state at the direction of the
administrator (e.g., provide support for archival and recovery capabilities).
O.RESIDUAL_INFORMATION_CLEARING
The TOE will ensure that any data contained in a protected resource is not available when the
resource is reallocated.
O.SYSTEM_MONITORING
The TOE will provide the ability to generate audit data and send that data to an external IT
entity. The TOE will record in audit records: date and time of action and the entity responsible
for the action. The TOE will provide the ability to store and review certificate information.
O.TOE_ADMINISTRATION
The TOE will provide mechanisms to ensure that only privileged users are able to log in and
configure the TOE, and provide protections for logged-in users. The TOE will ensure that
administrative responsibilities are separated across different roles in order to mitigate the impact
of improper administrative activities or unauthorized administrative access.
O.TRAFFIC_MONITORING
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 27
The TOE will provide a mechanism for processing SSL/TLS traffic. This mechanism requires
the TOE to enforce a policy to process encrypted traffic, which results in the traffic being
allowed, blocked, or decrypted for further inspection. This mechanism also requires the TOE to
enforce a policy to process decrypted traffic, which may be inspected for unauthorized content
either by the TOE itself or through an interface with an external inspection component.
4.2 Security Objectives for the Operational Environment
The security objectives for the operational environment are listed below.
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. Note: For vNDs the TOE includes only the contents of the its own VM,
and does not include other VMs or the VS.
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.
This operational environment security objective only applies to the interfaces of the TOE that are
defined by the NDcPP and not STIPM.
OE.TRUSTED_ADMIN
Security Administrators are trusted to follow and apply all guidance documentation in a trusted
manner. For vNDs, this includes the VS Administrator responsible for configuring the VMs
that implement ND functionality.
For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are
assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove
any certificate from the TOE’s trust store in case such certificate can no longer be trusted.
STIPM also allows for the enforcement of administrative role separation, which can be used to
limit the impact of malicious use of the TOE.
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_CREDENTIALS_SECURE
The administrator’s credentials (private key) used to access the TOE must be protected on any
other platform on which they reside.
OE.RESIDUAL_INFORMATION
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. For vNDs, this applies when the physical platform on which the VM runs is
removed from its operational environment.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 28
Residual information is expanded to include information relevant to STIP operation (e.g.
decrypted SSL/TLS payload, ephemeral keys).
OE.VM_CONFIGURATION (applies to vNDs only)
For vNDs, the Security Administrator ensures that the VS and VMs are configured to
• reduce the attack surface of VMs as much as possible while supporting ND
functionality (e.g., remove unnecessary virtual hardware, turn off unused inter-VM
communications mechanisms), and
• correctly implement ND functionality (e.g., ensure virtual networking is properly
configured to support network traffic, management channels, and audit reporting).
The VS should be operated in a manner that reduces the likelihood that vND operations are
adversely affected by virtualisation features such as cloning, save/restore, suspend/resume,
and live migration.
If possible, the VS should be configured to make use of features that leverage the VS’s
privileged position to provide additional security functionality. Such features could include
malware detection through VM introspection, measured VM boot, or VM snapshot for
forensic analysis.
OE.AUDIT
The operational environment includes an audit server with adequate storage to retain the audit
record, and the audit server provides adequate availability, integrity, and access control to the
audit record to support operational requirements. Administration of the audit server is separate
from that of the SSL/TLS inspection proxy, and can support all required role separations.
OE.CERT_REPOSITORY
The OE provides a certificate repository for storage of certificates (and optionally CRLs) issued
by the TSF.
OE.CERT_REPOSITORY_SEARCH
The OE provides the ability to search a certificate repository for specific certificate fields in
certificates issued by the TSF and return the certificate and an identifier for the certificate that
can be used to search the audit trail for events related to that certificate and for unauthorized or
improperly constrained certificates.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 29
5 Extended Components Definition
All of the extended components used in this ST are taken from the NDcPP or STIPM .
The NDcPP defines the following extended security functional requirements (SFRs) claimed in this
ST. Refer to the NDcPP for the definition of these extended SFRs since they are not redefined in this
ST.
Security Audit (FAU)
FAU_STG_EXT.1
FAU_STG_EXT.3/LocSpace
Cryptographic Support (FCS)
FCS_HTTPS_EXT.1
FCS_RBG_EXT.1
FCS_SSHS_EXT.1
FCS_TLSC_EXT.1
FCS_TLSC_EXT.2
FCS_TLSS_EXT.1
Identification and Authentication (FIA)
FIA_PMG_EXT.1
FIA_UIA_EXT.1
FIA_UAU_EXT.2
FIA_X509_EXT.1/Rev
FIA_X509_EXT.2
FIA_X509_EXT.3
Protection of the TSF (FPT)
FPT_SKP_EXT.1
FPT_APW_EXT.1
FPT_STM_EXT.1
FPT_TST_EXT.1/PowerOn
FPT_TST_EXT.1/OnDemand
FPT_TUD_EXT.1
TOE Access (FTA)
FTA_SSL_EXT.1
The STIPM defines the following extended security functional requirements (SFRs) claimed in this
ST. Refer to the STIPM for the definition of these extended SFRs since they are not redefined in this
ST.
Security Audit (FAU)
FAU_GCR_EXT.1
Cryptographic Support (FCS)
FCS_STG_EXT.1
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 30
FCS_TTTC_EXT.1
FCS_TTTC_EXT.4
FCS_TTTC_EXT.5
FCS_TTTS_EXT.1
FCS_TTTS_EXT.4
User Data Protection (FDP)
FDP_CER_EXT.1
FDP_CER_EXT.2
FDP_CER_EXT.3
FDP_CSIR_EXT.1
FDP_PPP_EXT.1
FDP_PRC_EXT.1
FDP_STG_EXT.1
FDP_STIP_EXT.1
FDP_TEP_EXT.1
Identification and Authentication (FIA)
FIA_ENR_EXT.1
FIA_X509_EXT.1/STIP
FIA_X509_EXT.2/STIP
Protection of the TSF (FPT)
FPT_KST_EXT.1
FPT_KST_EXT.2
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 31
6 Security Requirements
The security requirements that are levied on the TOE are specified in this section of the ST. Each of
them is drawn from the NDcPP or STIPM.
TOE Security Functional Requirements
(from CC Part 2)
NDcPP, STIPM,
or Both
FAU_GEN.1 Audit Data Generation NDcPP
FAU_GEN.1/STIP Audit Data Generation (STIP) STIPM
FAU_GEN.2 User Identity Association NDcPP
FAU_STG.1 Protected Audit Trail Storage NDcPP
FAU_STG.4 Prevention of Audit Data Loss STIPM
FCS_CKM.1 Cryptographic Key Generation NDcPP
FCS_CKM.2 Cryptographic Key Establishment NDcPP
FCS_CKM.4 Cryptographic Key Destruction Both
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
NDcPP
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and
Verification)
NDcPP
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) NDcPP
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) NDcPP
FCS_COP.1/STIP Cryptographic Operation (Data Encryption/Decryption
in Support of STIP
STIPM
FDP_RIP.1 Subset Residual Information Protection STIPM
FIA_AFL.1 Authentication Failure Management NDcPP
FIA_UAU.7 Protected Authentication Feedback NDcPP
FMT_MOF.1/ManualUpdate Management of Security Functions
Behaviour/ManualUpdate
NDcPP
FMT_MOF.1/Services Management of Security Functions Behaviour/Services NDcPP
FMT_MOF.1/STIP Management of Security Functions Behaviour/STIP STIPM
FMT_MTD.1/CoreData Management of TSF Data/CoreData NDcPP
FMT_MTD.1/CryptoKeys Management of TSF Data/CryptoKeys NDcPP
FMT_SMF.1 Specification of Management Functions NDcPP
FMT_SMF.1/STIP Specification of Management Functions (STIP) STIPM
FMT_SMR.2 Restrictions on Security Roles NDcPP
FMT_SMR.2/STIP Restrictions on Security Roles (STIP) STIPM
FPT_FLS.1 Failure with Preservation of Secure State STIPM
FPT_RCV.1 Manual Trust Recovery STIPM
FTA_SSL.3 TSF-initiated Termination NDcPP
FTA_SSL.4 User-initiated Termination NDcPP
FTA_TAB.1 Default TOE Access Banners NDcPP
FTP_ITC.1 Inter-TSF Trusted Channel NDcPP
FTP_TRP.1/Admin Trusted Path NDcPP
Extended Security Functional Requirements
FAU_GCR_EXT.1 Generation of Certificate Repository STIPM
FAU_STG_EXT.1 Protected Audit Event Storage NDcPP
FAU_STG_EXT.3/LocSpace Display Warning for Local Storage Space NDcPP
FCS_HTTPS_EXT.1 HTTPS Protocol NDcPP
FCS_RBG_EXT.1 Random Bit Generation NDcPP
FCS_SSHS_EXT.1 SSH Server Protocol NDcPP
FCS_STG_EXT.1 Cryptographic Key Storage STIPM
FCS_TLSC_EXT.1[1]-[2] TLS Client Protocol Without Mutual Authentication NDcPP
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 32
FCS_TLSC_EXT.2 TLS Client Protocol for Mutual Authentication NDcPP
FCS_TLSS_EXT.1[1]-[4] TLS Server Protocol Without Mutual Authentication NDcPP
FCS_TTTC_EXT.1 Thru-Traffic TLS Inspection Client Protocol STIPM
FCS_TTTC_EXT.4 STIP Client-Side Support for Renegotiation STIPM
FCS_TTTC_EXT.5 Thru-Traffic TLS Inspection Client Support for
Supported Groups Extension
STIPM
FCS_TTTS_EXT.1 Thru-Traffic TLS Inspection Server Protocol STIPM
FCS_TTTS_EXT.4 STIP Server-Side Support for Renegotiation STIPM
FDP_CER_EXT.1 Certificate Profiles for Server Certificates STIPM
FDP_CER_EXT.2 Certificate Request Matching of Server Certificates STIPM
FDP_CER_EXT.3 Certificate Issuance Rules for Server Certificates STIPM
FDP_CSIR_EXT.1 Certificate Status Information Required STIPM
FDP_PPP_EXT.1 Plaintext Processing Policy STIPM
FDP_PRC_EXT.1 Plaintext Routing Control STIPM
FDP_STG_EXT.1 Certificate Data Storage STIPM
FDP_STIP_EXT.1 SSL/TLS Inspection Proxy Functions STIPM
FDP_TEP_EXT.1 SSL/TLS Inspection Proxy Policy STIPM
FIA_ENR_EXT.1 Certificate Enrollment STIPM
FIA_PMG_EXT.1 Password Management NDcPP
FIA_UIA_EXT.1 User Identification and Authentication NDcPP
FIA_UAU_EXT.2 Password-based Authentication Mechanism NDcPP
FIA_X509_EXT.1/Rev X.509 Certificate Validation Both
FIA_X509_EXT.1/STIP Certificate Validation (STIP) Both
FIA_X509_EXT.2 X.509 Certificate Authentication NDcPP
FIA_X509_EXT.2/STIP X.509 Certificate Authentication (STIP) STIPM
FIA_X509_EXT.3 X.509 Certificate Requests Both
FPT_APW_EXT.1 Protection of Administrator Passwords NDcPP
FPT_KST_EXT.1 No Plaintext Key Export STIPM
FPT_KST_EXT.2 TSF Key Protection STIPM
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared,
symmetric, and private keys)
NDcPP
FPT_STM_EXT.1 Reliable Time Stamps NDcPP
FPT_TST_EXT.1/ PowerOn TSF Testing NDcPP
FPT_TST_EXT.1/
OnDemand
TSF Testing NDcPP
FPT_TUD_EXT.1 Trusted Update NDcPP
FTA_SSL_EXT.1 TSF-initiated Session Locking NDcPP
Table 3: Security Functional Requirements
6.1 Conventions
The CC defines four operations on security functional requirements. The SFRs claimed in this
ST have all been drawn from the NDcPP and STIPM. The CC operations already performed in
the NDcPP and STIPM are reproduced in plain text and not denoted in this ST. Instead, the
requirements have been copied from the NDcPP and STIPM and any remaining operations
have been completed herein. The NDcPP and STIPM made refinements and SFR operations
defined in the Common Criteria (CC) and the PPs should be consulted to identify those
operations. The conventions below define the denotations used in this ST to identify the
operations completed in this ST by the ST author.
Assignment made in ST: indicated with italics text
Selection made in ST: indicated with underlined text
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 33
Refinement made in ST: additions indicated with bold text
deletions indicated with strikethrough text
Iteration made in ST: indicated with typical CC requirement naming followed by an
iteration number in brackets, e.g., [1], [2], [3].
6.2 Security Functional Requirements
6.2.1 Security Audit (FAU)
6.2.1.1 FAU_GCR_EXT.1 Generation of Certificate Repository
FAU_GCR_EXT.1.1 The TSF shall invoke the Operational Environment to store certificates issued
by the TSF.
6.2.1.2 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 shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
• Administrative login and logout (name of user account shall be
logged if individual user accounts are required for administrators).
• 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).
• Generating/import of, changing, or deleting of cryptographic keys (in
addition to the action itself a unique key name or key reference shall
be logged).
• Resetting passwords (name of related user account shall be logged).
• Starting and stopping services;
d) Specifically defined auditable events listed in Table 2 Table 4.
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 4.
Requirement Auditable Events Additional Audit
Record Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG.1 None. None.
FAU_STG_EXT.1 None. None.
FAU_STG_EXT.3/LocSpace Low storage space for audit events. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 34
Requirement Auditable Events Additional Audit
Record Contents
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_RBG_EXT.1 None. None.
FCS_SSHS_EXT.1 Failure to establish an SSH
Session
Reason for failure.
FCS_TLSC_EXT.1[1]-[2] Failure to establish a TLS Session Reason for failure.
FCS_TLSC_EXT.2 Failure to establish a TLS Session Reason for failure.
FCS_TLSS_EXT.1[1]-[4] Failure to establish a TLS Session Reason for failure.
FIA_AFL.1 Unsuccessful login attempt limits
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.
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
• Any addition, replacement or
removal of trust anchors in the
TOE’s trust store.
• Reason for
failure of
certificate
validation
• Identification of
certificates
added, replaced
or removed as
trust anchor in
the TOE’s trust
store
FIA_X509_EXT.2 None None
FIA_X509_EXT.3 None. None.
FMT_MOF.1/Services None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
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/PowerOn None. None.
FPT_TST_EXT.1/OnDemand 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
For discontinuous
changes to time: The
old and new values
for the time. Origin
of the attempt to
change time for
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 35
Requirement Auditable Events Additional Audit
Record Contents
application note on
FPT_STM_EXT.1 in the NDcPP.
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.
FTP_TRP.1/Admin • Initiation of the trusted path.
• Termination of the trusted
path.
• Failure of the trusted path
functions.
None.
Table 4: NDcPP Security Functional Requirements and Auditable Events
6.2.1.3 FAU_GEN.1/STIP Audit Data Generation (STIP)
FAU_GEN.1.1/STIP The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) auditable events defined in Auditable Events for Mandatory Requriements
table Table 5,
d) applicable auditable events defined in Auditable Events for Selection-based
Requriements table Table 5.
FAU_GEN.1.2/STIP The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST,
c) additional information defined in Auditable Events for Mandatory
Requriements table Table 5,
d) additional information defined in applicable auditable events in Auditable
Events for Selection-based Requriements table Table 5,
e) additional information defined in Auditable Events table Table 5 for each
auditable event, where applicable.
Requirement Auditable Events Additional Audit Record
Contents
FAU_GCR_EXT.1 None. None.
FAU_STG.4 None. None.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 36
Requirement Auditable Events Additional Audit Record
Contents
FCS_COP.1/STIP None. None.
FCS_STG_EXT.1 None. None.
FCS_TTTC_EXT.1 Establishment of TLS session TLS session parameters
FCS_TTTC_EXT.4 None. None.
FCS_TTTC_EXT.5 None. None.
FCS_TTTS_EXT.1 Establishment of TLS session TLS session parameters
FCS_TTTS_EXT.4 None. None.
FDP_CER_EXT.1 None. None.
FDP_CER_EXT.2 Linking of issued certificate to
validated certificate
Success: issued certificate value,
issued certificate object identifier,
validated certificate value,
validated certificate object
identifier
Failure: Reason for failure
FDP_CER_EXT.3 Certificate generation Success: Certificate value,
certificate object identifier
FDP_CSIR_EXT.1 None. None.
FDP_PPP_EXT.1 Configuration changes to the
plaintext processing policy
None.
FDP_PRC_EXT.1 Plaintext routed to inspection
processing functional
component
TLS Session Thread identifier,
Connector virtual server name
FDP_RIP.1 None. None.
FDP_STG_EXT.1 None. None.
FDP_STIP_EXT.1 Establishment of a TLS
inspection session thread
Client side SID, server side SID,
Client SSL ciphers, Client TLS
version, Server SSL ciphers,
Server TLS version associated to
the thread
Establishment of an encrypted
TLS data flow
Client side SID, server side SID,
Client SSL ciphers, Client TLS
version, Server SSL ciphers,
Server TLS version
Bypass operation invoked TLS session thread identifier,
identifier(s) of processing
element(s) bypassed, reason for
bypass
Block operation involved TLS Session Thread identifier,
reason for blocking
FDP_TEP_EXT.1 Mutual authentication
authorized
Client certificate hash, Client DN
FIA_ENR_EXT.1 None. None.
FIA_X509_EXT.1/STIP None. None.
FIA_X509_EXT.2/STIP None. None.
FMT_MOF.1/STIP None. None.
FMT_SMF.1/STIP None. None.
FMT_SMR.2/STIP None. None.
FPT_FLS.1 Invocation of failures under
this requirement
Indication that the TSF has failed
with the type of failure that
occurred
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 37
Requirement Auditable Events Additional Audit Record
Contents
FPT_KST_EXT.1 None. None.
FPT_KST_EXT.2 All attempts to use the TOE’s
embedded CA’s private signing
key, and no other secret and
private keys
Identifier of user or process that
attempted access
FPT_RCV.1 The fact that a failure or
service discontinuity occurred
None.
Resumption of the regular
operation
TSF failure types that are
available on recovery
Table 5: STIP Security Functional Requirements and Auditable Events
6.2.1.4 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.
6.2.1.5 FAU_STG.1 Protected Audit Trail Storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the stored audit
records in the audit trail.
6.2.1.6 FAU_STG.4 Prevention of Audit Data Loss
FAU_STG.4.1 The TSF shall prevent audited events, except those taken by the Security
Administrator and no other actions to be taken in the case of audit storage failure
if the audit trail cannot be written to.
6.2.1.7 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. In
addition
• The 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: log files are numbered and the oldest log file is deleted when the local
storage space for audit data is full.
6.2.1.8 FAU_STG_EXT.3/LocSpace Action in case of possible audit data loss
FAU_STG_EXT.3.1/LocSpaceThe TSF shall generate a warning to inform the Administrator before
the audit trail exceeds the local audit trail storage capacity.
6.2.2 Cryptographic Operations (FCS)
6.2.2.1 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:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 38
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Appendix B.3;
• ECC schemes using “NIST curves” P-256, P-384 that meet the following:
FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
and specified cryptographic key sizes [assignment: cryptographic key sizes] that
meet the following: [assignment: list of standards].
Application Note: The TOE generates RSA keys with 2048 and 3072 key sizes.
6.2.2.2 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:
• RSA-based key establishment schemes that meet the following: RSAES-
PKCS1-v1_5 as specified in Section 7.2 of RFC 3447, “Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1”;
• 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].
6.2.2.3 FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys and critical security parameters, when
no longer required in accordance with the specified cryptographic key destruction
method
• For plaintext keys in volatile storage, the destruction shall be executed by a
single overwrite consisting of zeroes;
• For plaintext keys in non-volatile storage, the destruction shall be executed
by the invocation of an interface provided by a part of the TSF that
o when not in the EEPROM, logically addresses the storage location of
the key and performs a single overwrite consisting of zeroes
o when in EEPROM on F5 Devices and vCMP, logically addresses the
storage location of the key and performs a single overwrite consisting of
random data
that meets the following: no standard.
6.2.2.4 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, CTR, 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, CTR as specified in
ISO 10116, GCM as specified in ISO 19772.
6.2.2.5 FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification)
FCS_COP.1.1SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 39
• RSA Digital Signature Algorithm and cryptographic key sizes (modulus)
2048, 3072 bits,
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes 256,
384 bits
that meet the following:
• For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or
RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital
Signature scheme 3,
• For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 6 and Appendix D, Implementing “NIST curves” P-256, P-384; ISO/IEC
14888-3, Section 6.4
.
6.2.2.6 FCS_COP.1/Hash Cryptographic operation (Hash Operation)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a
specified cryptographic algorithm SHA-1, SHA-256, SHA-384 and cryptographic
key sizes [assignment: cryptographic key sizes] and message digest sizes 160,
256, 384 bits that meet the following: ISO/IEC 10118-3:2004.
6.2.2.7 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, HMAC-SHA-384 and cryptographic key sizes for SHA-1 the key size
is ≥ 160 bits, for SHA-256 the key size is ≥ 256 bits, for SHA-384 the key size is ≥
384 bits used in HMAC and message digest sizes 160, 256, 384 bits that meet the
following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
6.2.2.8 FCS_COP.1/STIP Cryptographic operation (Data Encryption/Decryption in
Support of STIP)
FCS_COP.1.1/STIP The TSF shall perform encryption/decryption in accordance with a specified
cryptographic algorithms AES in CCM and CCM-8 mode and no other
algorithms and cryptographic key sizes 128 bits, 256 bits that meet the following:
AES as specified in ISO 18033-3, CCM and CCM-8 as specified in NIST SP
800-38C and no other standards.
6.2.2.9 FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_HTTPS_EXT.1.1The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3If a peer certificate is presented, the TSF shall not establish the connection if
the peer certificate is deemed invalid.
6.2.2.10 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 CTR_DRBG (AES).
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from two software-based noise source, two platform-based
noise source for the F5 devices except 10000 series, one platform-based noise
source for 10000 series F5 devices, one platform-based noise source for the
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 40
VCMP guest platforms with a minimum of 256 bits of entropy at least equal to
the greatest security strength, according to ISO/IEC 18031:2011 Table C.1
“Security Strength Table for Hash Functions”, of the keys and hashes that it will
generate.
6.2.2.11 FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251,
4252, 4253, 4254, 5656, 6668, 8332.
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following user 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
256*1024 bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption algorithms:
aes128-cbc, aes256-cbc, aes128-ctr, aes256-ctr.
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 as its public key
algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses hmac-sha1,
hmac-sha2-256 as its MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that ecdh-sha2-nistp256 and ecdh-sha2-nistp384 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 each encryption key is used
to protect no more than one gigabyte of data. After any of the thresholds are
reached a rekey needs to be performed.
Application Note: TD0631 applies to this SFR definition.
6.2.2.12 FCS_STG_EXT.1 Cryptographic Key Storage
FCS_STG_EXT.1.1 Persistent private and secret keys shall be stored within the TSF using F5
Secure Vault.
6.2.2.13 FCS_TLSC_EXT.1[1] TLS Client Protocol without mutual authentication
(TLS1.1)
FCS_TLSC_EXT.1.1[1] The data plane of the TSF shall implement TLS 1.1 (RFC 4346) and
reject all other TLS and SSL versions. The TLS implementation will support the
following ciphersuites:
○ TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
4492.
FCS_TLSC_EXT.1.2[1] The data plane of the TSF shall verify that the presented identifier
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 41
matches Ipv4 address in CN or SAN.
FCS_TLSC_EXT.1.3[1] When establishing a trusted channel, by default the data plane of the
TSF shall not establish a trusted channel if the server certificate is invalid. The
TSF shall also
• Not implement any administrator override mechanism
.
FCS_TLSC_EXT.1.4[1] The data plane of the TSF shall present the Supported Elliptic
Curves/Supported Groups Extension with the following curves/groups:
secp256r1, secp384r1 and no other curves/groups in the Client Hello.
6.2.2.14 FCS_TLSC_EXT.1[2] TLS Client Protocol without mutual authentication (TLS
1.2)
FCS_TLSC_EXT.1.1[2] The data plane of 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_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
4492
○ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
○ TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
○ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289.
FCS_TLSC_EXT.1.2[2] The data plane of the TSF shall verify that the presented identifier
matches Ipv4 address in CN or SAN.
FCS_TLSC_EXT.1.3[2] When establishing a trusted channel, by default the data plane of the
TSF shall not establish a trusted channel if the server certificate is invalid. The
TSF shall also
• Not implement any administrator override mechanism
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 42
.
FCS_TLSC_EXT.1.4[2] The data plane of the TSF shall present the Supported Elliptic
Curves Extension with the following NIST curves: secp256r1, secp384r1 and no
other curves in the Client Hello.
6.2.2.15 FCS_TLSC_EXT.2 TLS Client support for mutual authentication
FCS_TLSC_EXT.2.1 The data plane of the TSF shall support TLS communication with mutual
authentication using X.509v3 certificates.
6.2.2.16 FCS_TLSS_EXT.1[1] TLS Server Protocol (Data Plane Server – TLS 1.1)
FCS_TLSS_EXT.1.1[1] The data plane of the TSF shall implement TLS 1.1 (RFC 4346) and
reject all other TLS and SSL versions. The TLS implementation will support the
following ciphersuites:
○ TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
4492.
FCS_TLSS_EXT.1.2[1] The data plane of the TSF shall deny connections from clients
requesting SSL 2.0, SSL 3.0, TLS 1.0, and none.
FCS_TLSS_EXT.1.3[1] The data plane of the TSF shall perform key establishment for TLS
using RSA with key size 2048 bits, 3072 bits, ECDHE curves secp256r1 and
secp384r1 and no other curves.
FCS_TLSS_EXT.1.4[1] The data plane of the TSF shall support session resumption based
on session tickets according to RFC 5077.
6.2.2.17 FCS_TLSS_EXT.1[2] TLS Server Protocol (Data Plane Server – TLS 1.2)
FCS_TLSS_EXT.1.1[2] The data plane of 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_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
4492
○ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
○ TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 43
○ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
○ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289.
FCS_TLSS_EXT.1.2[2] The data plane of the TSF shall deny connections from clients
requesting SSL 2.0, SSL 3.0, TLS 1.0, and none.
FCS_TLSS_EXT.1.3[2] The data plane of the TSF shall perform key establishment for TLS
using RSA with key size 2048 bits, 3072 bits,ECDHE curves secp256r1 and
secp384r1 and no other curves.
FCS_TLSS_EXT.1.4[2] The data plane of the TSF shall support session resumption based
on session tickets according to RFC 5077.
6.2.2.18 FCS_TLSS_EXT.1[3] TLS Server Protocol (Control Plane Server – TLS 1.1)
FCS_TLSS_EXT.1.1[3] The control plane of the TSF shall implement TLS 1.1 (RFC 4346)
and reject all other TLS and SSL versions. The TLS implementation will support
the following ciphersuites:
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
4492.
FCS_TLSS_EXT.1.2[3] The control plane of the TSF shall deny connections from clients
requesting SSL 2.0, SSL 3.0, TLS 1.0, and none.
FCS_TLSS_EXT.1.3[3] The control plane of the TSF shall perform key establishment for
TLS using RSA with key size 2048 bits, 3072 bits, ECDHE curves secp256r1 and
secp384r1 and no other curves.
FCS_TLSS_EXT.1.4[3] The control plane of the TSF shall support session resumption
based on session tickets according to RFC 5077.
6.2.2.19 FCS_TLSS_EXT.1[4] TLS Server Protocol (Control Plane Server – TLS 1.2)
FCS_TLSS_EXT.1.1[4] The control plane of 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_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
○ TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
○ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 44
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
○ TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
○ TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288.
FCS_TLSS_EXT.1.2[4] The control plane of the TSF shall deny connections from clients
requesting SSL 2.0, SSL 3.0, TLS 1.0, and none.
FCS_TLSS_EXT.1.3[4] The control plane of the TSF shall perform key establishment for
TLS using RSA with key size 2048 bits, 3072 bits, ECDHE curves secp256r1 and
secp384r1 and no other curves.
FCS_TLSS_EXT.1.4[4] The control plane of the TSF shall support session resumption
based on session tickets according to RFC 5077.
6.2.2.20 FCS_TTTC_EXT.1 Thru-Traffic TLS Inspection Client Protocol
FCS_TTTC_EXT.1.1 The TSF shall implement TLS 1.2 (RFC 5246), TLS 1.0 (RFC 2246), and
TLS 1.1 (RFC 4346) as a client to the requested server that supports the
following cipher suites:
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5288
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC
5246
o TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
o TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_256_CCM as defined in RFC 6655
o TLS_RSA_WITH_AES_256_CCM as defined in RFC 6655
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_128_CCM as defined in RFC 6655
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 45
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5288
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5246
o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
o TLS_RSA_WITH_AES_128_CCM as defined in RFC 6655
o TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5426
o TLS_RSA_WITH_AES_128_CCM_8 as defined in RFC 6655
o TLS_DHE_RSA_WITH_AES_128_CCM_8 as defined in RFC 6655
o TLS_DHE_RSA_WITH_AES_256_CCM_8 as defined in RFC 6655
o TLS_RSA_WITH_AES_256_CCM_8 as defined in RFC 6655
o no other cipher suites
and also supports functionality for
o session renegotiation.
FCS_TTTC_EXT.1.2 The TSF shall verify that the presented identifier matches the reference
identifier of the server requested by the monitored client using methods described
in RFC 6125 section 6 for DNS name types, and via exact, byte-by-byte matching
for IP address name types.
FCS_TTTC_EXT.1.3 The TSF shall validate the certificate presented by the server and terminate
the connection if the certificate is invalid, except as allowed by
FIA_X509_EXT.2.2/STIP.
FCS_TTTC_EXT.1.4 The TSF shall formulate the Client Hello such that it presents the highest
version of the TLS protocol supported by the proxy function in the version field,
and presents the list of cipher suites in descending order of preference associated
with requested server.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 46
6.2.2.21 FCS_TTTC_EXT.4 STIP Client-Side Support for Renegotiation
FCS_TTTC_EXT.4.1 The TSF shall support secure renegotiation on STIP TLS connections
through use of the “renegotiation_info” TLS extension in accordance with RFC
5746.
FCS_TTTC_EXT.4.2 The TSF shall include TLS_EMPTY_RENEGOTIATION_INFO_SCSV
cipher suite in the Client Hello message.
FCS_TTTC_EXT.4.3 The TSF shall ensure that renegotiation is performed before SSL profile
specifies renegotiation period and/or size.
6.2.2.22 FCS_TTTC_EXT.5 Thru-Traffic TLS Inspection Client Support for Supported
Groups Extension
FCS_TTTC_EXT.5.1 The TSF shall present the Supported Groups Extension in the Client Hello
with the supported groups:
o secp256r1
o secp384r1
o ffdhe2048(256)
o ffdhe3072(257)
o ffdhe4096(258).
6.2.2.23 FCS_TTTS_EXT.1 Thru-Traffic TLS Inspection Server Protocol
FCS_TTTS_EXT.1.1 The TSF shall implement TLS 1.2 (RFC 5246), TLS 1.0 (RFC 2246), and
TLS 1.1 (RFC 4346) as a server to the monitored client that supports the
following cipher suites:
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5288
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC
5246
o TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
o TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_256_CCM as defined in RFC 6655
o TLS_RSA_WITH_AES_256_CCM as defined in RFC 6655
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 47
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_DHE_RSA_WITH_AES_128_CCM as defined in RFC 6655
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5288
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5246
o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
o TLS_RSA_WITH_AES_128_CCM as defined in RFC 6655
o TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246
o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5426
o TLS_RSA_WITH_AES_128_CCM_8 as defined in RFC 6655
o TLS_DHE_RSA_WITH_AES_128_CCM_8 as defined in RFC 6655
o TLS_DHE_RSA_WITH_AES_256_CCM_8 as defined in RFC 6655
o TLS_RSA_WITH_AES_256_CCM_8 as defined in RFC 6655
o no other cipher suites
and also supports functionality for
o session renegotiation
.
FCS_TTTS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0,
and no other SSL or TLS versions for through-traffic processing.
FCS_TTTS_EXT.1.3 The TSF shall perform key establishment for TLS with a monitored client
using
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 48
o RSA with key size 2048 bits, 3072 bits;
o Diffie-Hellman groups ffdhe2048, ffdhe3072, ffdhe4096
o EC Diffie-Hellman parameters using elliptic curves secp256r1,
secp384r1 and no other curves.
6.2.2.24 FCS_TTTS_EXT.4 STIP Server-Side Support for Renegotiation
FCS_TTTS_EXT.4.1 The TSF shall support the “renegotiation_info” TLS extension in accordance
with RFC 5746.
FCS_TTTS_EXT.4.2 The TSF shall include the renegotiation_info extension in Server Hello
messages.
6.2.3 User Data Protection (FDP)
6.2.3.1 FDP_CER_EXT.1 Certificate Profiles for Server Certificates
FDP_CER_EXT.1.1 The TSF shall implement a certificate profile function for TLS server
certificates issued by a CA embedded within the TOE, and shall ensure that
issued certificates are consistent with configured profiles.
FDP_CER_EXT.1.2 The TSF shall generate certificates using profiles that comply with
requirements for certificates as specified in IETF RFC 5280, “Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile” as refined below. At a minimum, the TSF shall ensure that:
a) The version field shall contain the integer 2
b) The issuerUniqueID or subjectUniqueID fields are not populated.
c) The serialNumber shall be unique with respect to the issuing
Certification Authority.
d) The validity field shall specify a notBefore value that does not precede
the current time and a notAfter value that does not precede the value
specified in notBefore.
e) The issuer field is not empty and is populated with the Security
Administrator-configured CA name.
f) The signature field and the algorithm in the subjectPublicKeyInfo field
shall contain the OID for a signature algorithm specified in
FCS_COP.1/SigGen in the NDcPP.
g) The following extensions are supported:
a. authorityKeyIdentifier
b. keyUsage
c. extendedKeyUsage
d. certificatePolicy
e. authorityInfoAccess
h) A subject field containing a null Name (e.g., a sequence of zero relative
distinguished names) is accompanied by a populated critical
subjectAltName extension.
i) The authorityKeyIdentifier extension in any certificate issued by the TOE
must be populated and must be the same as the subjectKeyIdentifier
extension contained in the TOE’s embedded CA’s signing certificate.
j) Populated keyUsage and extendedKeyUsage fields in the same certificate
shall contain consistent values reflecting exclusive TLS server use as
follows:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 49
keyUsage extendedKeyUsage
digitalSignature serverAuth
digital Signature,
keyEncipherment
serverAuth
digital Signature, keyAgreement serverAuth
k) no other constraints.
FDP_CER_EXT.1.3 The TSF shall implement the following rules for populating certificate fields
based on constraints imposed by the TOE’s embedded CA’s signing certificate:
• The validity field shall specify a notAfter time that does not exceed the
notAfter time of the CA’s signing certificate.
• The issuer field identifies the subject of the CA’s signing certificate.
• no other rules.
FDP_CER_EXT.1.4 The TSF shall implement the following rules for populating certificate fields
based on the validated certificate and constraints imposed by the Security
Administrator:
a) The Subject/Subject Alternative Name shall be copied from validated
server certificate.
b) The notBefore field shall not precede the notBefore field of the validated
server certificate.
c) The notAfter field shall not exceed the notAfter field of the validated
server certificate.
d) The notAfter field shall not exceed the current time by more than a
maximum validity duration value as configured by a Security
Administrator user.
e) If the basicConstraints field is configured to be present, it shall be
populated with the value cA=False.
f) The subject public key shall be generated in accordance with
FCS_CKM.1.1 in the NDcPP.
g) no additional rules.
6.2.3.2 FDP_CER_EXT.2 Certificate Request Matching of Server Certificates
FDP_CER_EXT.2.1 The TSF shall establish and record a linkage from validated certificates to
issued certificates.
6.2.3.3 FDP_CER_EXT.3 Certificate Issuance Rules for Server Certificates
FDP_CER_EXT.3.1 The TSF shall issue certificates in response to a validated server certificate
according to the following rules: The issued certificate is in compliance with a
current certificate profile defined in accordance with FDP_CER_EXT.1 and
• The TLS session establishment policy is configured to allow inspection
of TLS sessions between monitored clients and a requested server
authenticated to the TSF by the validated certificate,
• A valid certificate for the same subject is not present in cache.
FDP_CER_EXT.3.2 The TSF shall reject all certificate requests originating external to the TOE
6.2.3.4 FDP_CSIR_EXT.1 Certificate Status Information Required
FDP_CSIR_EXT.1.1 The TSF shall only issue certificates with validity period of less than 24
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 50
hours.
6.2.3.5 FDP_PPP_EXT.1 Plaintext Processing Policy
FDP_PPP_EXT.1.1 The TSF shall enforce the TLS plaintext processing policy on information
flows containing plaintext produced by inspection processing of the TOE
between TLS session termination points and internal inspection processing
functional components and an interface to external inspection processing
environment.
FDP_PPP_EXT.1.2 The TSF shall allow the definition of TLS plaintext processing policy rules
using destination address, destination port, TLS server certificate message
attributes, no indicators of inspection processing results and distinct interfaces.
FDP_PPP_EXT.1.3 The TSF shall allow the following operations to be associated with the
plaintext processing policy: permit, block, and bypass, with the capability to log
the operation.
FDP_PPP_EXT.1.4 The TSF shall allow the Plaintext Processing Policy to be applied at each
information flow control point between inspection processing functional
components, including any network interface used to support external inspection
processing.
FDP_PPP_EXT.1.5 The TSF shall
• drop Information flows between inspection processing components,
including any interface to external inspection processing components,
that cannot be associated to an existing TLS session thread.
• inform the TLS session establishment policy of the TLS session thread
associated to any information flow that is blocked by the plaintext
processing policy
6.2.3.6 FDP_PRC_EXT.1 Plaintext Routing Control
FDP_PRC_EXT.1.1 The TSF shall control the routing of information flows containing plaintext
within a TLS session thread in accordance with the configured Plaintext
Processing Policy identified in FDP_PPP_EXT.1.
FDP_PRC_EXT.1.2 The TSF shall separate information flows containing plaintext within
different TLS session threads.
FDP_PRC_EXT.1.3 The TSF shall not expose plaintext within a TLS session thread except to
inspection processing functional components identified in, and as authorized by
the configured Plaintext Processing Policy, as described in FDP_PPP_EXT.1.
6.2.3.7 FDP_RIP.1 Subset Residual Information Protection
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the allocation of the resource to the following objects: all
objects.
6.2.3.8 FDP_STG_EXT.1 Certificate Data Storage
FDP_STG_EXT.1.1 The TSF shall use access controlled storage to protect the trusted public keys
and certificates (trust store elements) used to validate local logon, trusted
channel, and external communication to the STIP.
6.2.3.9 FDP_STIP_EXT.1 SSL/TLS Inspection Proxy Functions
FDP_STIP_EXT.1.1 The TSF shall be capable of performing the Inspection Operation consisting
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 51
of establishing a TLS session between TOE and the requested server according to
FCS_TTTC_EXT.1, establishing a TLS session between the monitored client and
the TOE according to FCS_TTTS_EXT.1, and routing decrypted application data
from either of these TLS sessions to or between inspection processing functional
components within the TOE, or between the TOE and external inspection
processing functional components to a unique TLS session thread, according to
FDP_PPP_EXT.1 and FDP_PRC_EXT.1.
FDP_STIP_EXT.1.2 The TSF shall obtain a certificate from the TOE CA that represents the
requested server for establishment of the TLS session with the monitored client
when performing an inspect operation.
FDP_STIP_EXT.1.3 The TSF shall require administrator confirmation of consent prior to sending
decrypted TLS application data from a monitored client to inspection processing
functional component as part of an inspection operation.
FDP_STIP_EXT.1.4 The TSF shall provide the Bypass operation functionality by forwarding
traffic between the monitored client and requested server such that monitored
client can establish and maintain a TLS connection to the requested server.
FDP_STIP_EXT.1.5 When initiating a Block operation, the TSF shall be capable of providing a
TLS error response, block page to the monitored client associated with the
blocked TLS session.
6.2.3.10 FDP_TEP_EXT.1 SSL/TLS Inspection Proxy Policy
FDP_TEP_EXT.1.1 The TSF shall perform SSL/TLS Inspection Proxy functions and enforce
SSL/TLS Inspection Proxy rules on TLS traffic received by the TSF from
monitored clients and servers requested by monitored clients, and on TLS traffic
controlled by the TSF to be sent to monitored clients and servers requested by
monitored clients.
FDP_TEP_EXT.1.2 The TSF shall allow the definition of SSL/TLS Inspection Proxy rules based
on the following attributes of each monitored client and requested server:
• Network Protocol fields: Ipv4, Ipv6:
o Source address
o Destination address
o Source Port
o Destination Port
o no other fields
• TLS Client Hello handshake message:
o Server_name extension of the requested server
o Client side interface
• TLS Server Certificate message:
o Issuer
o Subject
o SubjectAlternateName
• Distinct Interface
• no other attributes
.
FDP_TEP_EXT.1.3 The TSF shall allow the following operations to be associated with SSL/TLS
Inspection Proxy rules: block, bypass, or inspect, with the capability to log the
operation.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 52
FDP_TEP_EXT.1.4 The TSF shall be able to define monitored clients, requested servers, and
specific client-server connections in terms of the attributes associated with the
SSL/TLS Inspection Proxy function.
FDP_TEP_EXT.1.5 The TSF shall be able to associate a monitored client, requested server, and
specific client-server connections with the allowed TLS version or versions, TLS
cipher suites (including TLS key exchange algorithms and key sizes), the
supported groups per FCS_TTTC_EXT.5.1, and mutual authentication block-
bypass, requested server certificate revocation status unavailable that shall be
used when performing the SSL/TLS Inspection Proxy operations.
FDP_TEP_EXT.1.6 The TSF shall allow the SSL/TLS Inspection Proxy rules to be assigned to
each distinct network interface.
FDP_TEP_EXT.1.7 The TSF shall perform a block, bypass operation on the session when
receiving a TLS certificate request message from the requested server when
establishing the TLS in accordance with FCS_TTTC_EXT.1.
FDP_TEP_EXT.1.8 The TSF shall
• Block the connection if the monitored client does not support a TLS
version, cipher suite, key exchange, and key size that are in its allowed
set as defined in FDP_TEP_EXT.1.5
• Block the connection if the requested server does not negotiate a TLS
version, cipher suite, key exchange, and key size that are in its allowed
set as defined in FDP_TEP_EXT.1.5
• Either block, or require administrative approval to inspect or bypass the
connection if the requested server does not negotiate a TLS version,
cipher suite, key exchange, and key size that are in the set proposed by
the monitored client in its Client Hello message
• Block or inspect the connection if TOE certificate processing indicates
revocation information is not available for a requested server or no other
entity
• Block or no other rule a connection if TOE certificate processing
indicates an uninterpretable critical extension is present in the certificate
of a requested server.
FDP_TEP_EXT.1.9 The TSF shall enforce the following default SSL/TLS Inspection Proxy rules
on all SSL/TLS network traffic received from interfaces associated with
monitored clients and requested servers:
• The TSF shall drop and be capable of logging invalid TLS messages
• The TSF shall drop and be capable of logging TLS Client Hello
messages for which no valid client can be determined
• The TSF shall drop a TLS Client Hello message for which no valid
server attribute can be determined
• The TSF shall drop and be capable of logging TLS messages other than a
Client Hello if the message is not associated with an existing TLS session
thread established via the inspection operation or a TLS encrypted data
flow established via a bypass operation
• The TSF shall terminate a TLS session thread if it receives a fatal TLS
error message from the monitored client
• The TSF shall attempt to terminate the TLS session thread and provide a
TLS error message to the monitored client associated to the TLS session
thread if it receives a fatal TLS error message on the TLS session to the
requested server
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 53
• The TSF shall terminate a TLS session thread established via the inspect
operation, and terminate a TLS encrypted data flow established by the
bypass operation, if the TSF receives no traffic from the associated
monitored client for a configurable period
• The TSF shall transition a TLS session thread state from inspect
operation to block operation, when indicated to do so by the TLS
plaintext processing policy.
FDP_TEP_EXT.1.10 The TSF shall block all connections for which an Inspection or Bypass
operation is not defined.
6.2.4 Identification and Authentication (FIA)
6.2.4.1 FIA_AFL.1 Authentication Failure Management
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within
1 – 10 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 Administrator from successfully establishing
a remote session using any authentication method that involves a password until
an Administrator defined time period has elapsed.
6.2.4.2 FIA_ENR_EXT.1 Certifícate Enrollment
FIA_ENR_EXT.1.1 The TSF shall be able to generate a certificate request to an external
certification authority to receive a certificate for the TOE’s embedded CA’s
signing key using PKCS#10 in accordance with FIA_X509_EXT.3.
6.2.4.3 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 255
characters.
6.2.4.4 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1The 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;
• no other actions
FIA_UIA_EXT.1.2The 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.
6.2.4.5 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.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 54
6.2.4.6 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.
6.2.4.7 FIA_X509_EXT.1/Rev X.509 Certificate Validation3
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 basicConstraints extension with the CA flag set
to TRUE.
• The TSF shall validate the revocation status of the certificate using Certificate
Revocation list (CRL) as specified in RFC 5759 Section 5.
• 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.
6.2.4.8 FIA_X509_EXT.1/STIP Certificate Validation (STIP)
FIA_X509_EXT.1.1/STIP The TSF shall validate certificates used for connections supporting
STIP functions 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 basicConstraints extension with the CA
flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using the
3
This requirement is used for certificates associated with functions other than TLS connections between the
TOE and monitored clients/requested servers.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 55
Online Certificate Status Protocol (OCSP) as specified in RFC 6960.
• The TSF shall validate the extendedKeyUsage field according to the
following rules depending on the certificate type and purpose:
o Server certificates presented in a TLS certificate message for Thru-
Traffic processing TLS shall have meet one of the following checks:
§ There is no extendedKeyUsage field,
§ The extendedKeyUsage field is present and contains the
Server Authentication purpose (id-kp 1 with OID
1.3.6.1.5.5.7.3.1),
§ The extendedKeyUsage field is present and contains the
‘any’ purpose (id-…)
o Server certificates presented for TLS not associated with the Thru-
Traffic processing include an extendedKeyUsage field that contains
the ServerAuthentication purpose (id-kp 1 with OID
1.3.6.1.5.5.7.3.1),
o Code-signing certificates include the extendedKeyUsage field that
contains the CodeSigning purpose
o Client certificates presented for TLS for any purpose shall include
the extendedKeyUsage field that contains 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.
o All other certificates used for any other purpose include an
extendedKeyUsage field that DOES NOT contain the ‘any’ purpose.
• The TSF shall validate all extensions marked as critical and verify the value
is appropriate for the functionality that uses the value.
FIA_X509_EXT.1.2/STIP 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.
6.2.4.9 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 TLS, HTTPS, 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 allow the Security Administrator to choose whether to
accept the certificate in these cases.
Application Note: This SFR is used to define this function in the context of the NDcPP functionality
(e.g., non-STIP trusted channels).
6.2.4.10 FIA_X509_EXT.2/STIP X.509 Certificate Authentication
FIA_X509_EXT.2.1/STIP The TSF shall use X.509v3 certificates as defined by RFC 5280 to
support authentication for TLS and no additional uses
FIA_X509_EXT.2.2/STIP When the TSF cannot establish a connection to determine the
revocation status of a certificate, the TSF shall accept the certificate.
Application Note: This SFR is iterated from its definition in the NDcPP to define the
implementation of this function specifically with respect to STIP functionality.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 56
6.2.4.11 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.
6.2.5 Security Management (FMT)
6.2.5.1 FMT_MOF.1/ManualUpdate Management of security functions behavior
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to
perform manual updates to Security Administrators.
6.2.5.2 FMT_MOF.1/Services Management of security functions behavior
FMT_MOF.1.1/Services The TSF shall restrict the ability to start and stop services to Security
Administrators.
6.2.5.3 FMT_MOF.1/STIP Management of security functions behavior
FMT_MOF.1.1/STIP The TSF shall restrict the ability to modify the behaviour of the functions
identified in the Management Functions and Privileges table to the roles defined
in the Management Functions and Privileges table.
Management Function Security
Administrator
Auditor
Ability to manage user accounts √
Ability to manage remote audit mechanism √ √
Ability to perform on-demand integrity tests √
Ability to import and remove X.509v3 certificates used for
STIP into or from the Trust Anchor Database
√
Ability to configure identifying information for the TOE’s
embedded CA
√
Ability to configure a maximum certificate validity duration √
Ability to manage inspection policy √
Ability to configure inspection processing details √
Ability to configure local audit behavior √ √
Ability to configure and manage certificate profiles √
Ability to modify the OCSP configuration √
Table 6: Management Functions and Privileges
6.2.5.4 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.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 57
6.2.5.5 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.
6.2.5.6 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;
• Ability to start and stop services;
• Ability to configure audit behavior;
• Ability to manage the cryptographic keys;
• Ability to configure the cryptographic functionality;
• Ability to configure thresholds for SSH rekeying;
• Ability to set the time which is used for time-stamps.
6.2.5.7 FMT_SMF.1/STIP Specification of Management Functions (STIP)
FMT_SMF.1.1/STIP The TSF shall be capable of performing the following management functions
in support of STIP operations:
• Ability to manage user accounts;
• Ability to manage remote audit mechanism;
• Ability to perform on-demand integrity tests;
• Ability to import and remove X.509v3 certificates used for STIP into or from
the Trust Anchor Database;
• Ability to configure identifying information for the TOE’s embedded CA;
• Ability to configure a maximum certificate validity duration;
• Ability to manage inspection policy;
• Ability to configure inspection processing service connectors;
• Ability to configure local audit behavior;
• Ability to configure and manage the certificate profiles;
• Ability to modify the OCSP configuration.
6.2.5.8 FMT_SMR.2 Restrictions on security roles
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;
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 58
• The Security Administrator role shall be able to administer the TOE
remotely
are satisfied.
6.2.5.9 FMT_SMR.2/STIP Restrictions on security roles (STIP)
FMT_SMR.2.1/STIP The TSF shall maintain the roles:
• Security Administrator,
• Auditor.
FMT_SMR.2.2/STIP The TSF shall be able to associate users with roles.
FMT_SMR.2.3/STIP The TSF shall ensure that the conditions
• All roles shall be able to administer the TOE locally,
• All roles shall be able to administer the TOE remotely,
• No identity is authorized to assume both an Auditor role and any of the
other roles in FMT_SMR.2/STIP
are satisfied.
6.2.6 Protection of TSF (FPT)
6.2.6.1 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.
6.2.6.2 FPT_FLS.1 Failure with Preservation of Secure State
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur:
DRBG failure, integrity test failure, external audit server is unavailable, no other
potential TSF failures.
6.2.6.3 FPT_KST_EXT.1 No Plaintext Key Export
FPT_KST_EXT.1.1 The TSF shall prevent the plaintext export of embedded CA’s private key,
private key of forged server certificate, TLS RSA private key, TLS ECDSA private
key, TLS EC Diffie-Hellman private key, TLS pre-master secret and master
secret, TLS session keys, SSH shared secrets (session keys), SSH EC Diffie-
Hellman private key, SSH RSA private key, SSH ECDSA private key.
6.2.6.4 FPT_KST_EXT.2 TSF Key Protection
FPT_KST_EXT.2.1 The TSF shall prevent the unauthorized use of all TSF private and secret
keys.
6.2.6.5 FPT_RCV.1 Manual Trusted Recovery
FPT_RCV.1.1 After DRBG failure, integrity test failure the TSF shall enter a maintenance mode
where the ability to return to a secure state is provided.
6.2.6.6 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.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 59
6.2.6.7 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 allow the Security Administrator to set the time.
Application Note: TD0632 applies to this SFR defintion.
6.2.6.8 FPT_TST_EXT.1/PowerOn TSF Testing (Extended)
FPT_TST_EXT.1.1/PowerOn The TSF shall run a suite of the following self-tests during initial
start-up (on power on), at the conditions reboot to demonstrate the correct
operation of the TSF: BIOS Power On at power on only for F5 Devices and
vCMP, OpenSSL integrity at power on and reboot, software integrity at power on
and reboot, cryptographic algorithm at power on and reboot.
6.2.6.9 FPT_TST_EXT.1/OnDemand TSF Testing (Extended)
FPT_TST_EXT.1.1/OnDemand The TSF shall run a suite of the following self-tests
periodically during normal operation, at the request of the authorised user to
demonstrate the correct operation of the TSF: software integrity.
6.2.6.10 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 the most recently
installed version of the TOE firmware/software.
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.
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to
the TOE using a digital signature prior to installing those updates.
6.2.7 TOE Access (FTA)
6.2.7.1 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.
6.2.7.2 FTA_SSL.3 TSF-initiated Termination (Refinement)
FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
6.2.7.3 FTA_SSL.4 User-initiated Termination (Refinement)
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s
own interactive session.
6.2.7.4 FTA_TAB.1 Default TOE Access Banners (Refinement)
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.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 60
6.2.8 Trusted path/channels (FTP)
6.2.8.1 FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall be capable of using TLS and no other protocols to provide a
trusted communication channel between itself and authorized IT entities
supporting the following capabilities: audit server, TLS session proxying, 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.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for establishment of
TLS proxy connections, transmission of syslog records to syslog audit servers.
6.2.8.2 FTP_TRP.1/Admin Trusted Path 4
FTP_TRP.1.1/Admin The TSF shall be capable of using SSH, TLS, 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.
6.3 TOE Security Assurance Requirements
The security assurance requirements (SARs) provide grounds for confidence that the TOE meets its
security objectives (for example, configuration management, testing, and vulnerability assessment).
The table below identifies the security assurance requirements drawn from CC Part 3: Security
Assurance Requirements that are required by the NDcPP.
Assurance Class
Assurance
Component ID
Assurance Component Name
ADV: Development ADV_FSP.1 Basic functional specification
AGD: Guidance
documents
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life-cycle support
ALC_CMC.1 Labeling of the TOE
ALC_CMS.1 TOE CM coverage
ASE: Security Target ASE_CCL.1 Conformance claims
4
Note: The STIPM modified the definition of this requirement from the NDcPP.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 61
Assurance Class
Assurance
Component ID
Assurance Component Name
evaluation
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
ATE: Tests ATE_IND.1 Independent testing – sample
AVA: Vulnerability
assessment
AVA_VAN.1 Vulnerability survey
Table 7: Security Assurance Requirements
In addition, the TOE will provide the evidence necessary for the evaluators to perform the evaluation
activities defined in the Evaluation Activities for Network Device cPP document.
6.4 Security Requirements Rationale
This Security Target makes no modifications or additions to the NDcPP and STIPM security problem
definition, security objectives, or security assurance requirements. The security functionality
requirements claimed in this ST include all of the required SFRs from the NDcPP and STIPM,
selected optional SFRs from the NDcPP and STIPM, and the mandatory selection-based SFRs from
the NDcPP and STIPM. There are no additional SFRs or SARS included in this ST. Operations
performed on the SFRs comply the corresponding Application Notes in the NDcPP and STIPM.
6.4.1 Security Functional Requirement Dependencies
All of the security functional requirements claimed in this Security Target are taken directly from the
NDcPP version 2.2e or STIPM version 1.1, and all operations on the SFRs have been completed
correctly. Therefore, the dependency rationale used by the NDcPP version 2.2e or STIPM version 1.1
is considered applicable and acceptable since the NDcPP and STIPM has been validated and
approved.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 62
7 TOE Summary Specification
This section presents a description of how the TOE SFRs are satisfied.
7.1 Security Audit
BIG-IP uses syslog functionality to generate audit records, including the start-up and shut-down of the
audit functions themselves. BIG-IP is a standalone TOE storing audit data locally and transmitting audit
data to external syslog hosts. BIG-IP implements one audit logging mechanism, namely syslog, for all
auditable events.
7.1.1 Audit Generation
BIG-IP systems generate different log types that capture different types of audit records. The audit
records include:
• audit events
events related to the security and administrative functionality implemented by the TOE; this
type of audit log captures most of the events specified in this ST
• system events
events related to the TOE operating system as well as status of TOE components, such as the
syslog-ng daemon
• packet filter events
events related to packet filtering applied by the TOE
• local traffic events
events related to network traffic handled by the system, including some events related to
packet filtering
• certificate generation events
events related to the creation of forged (issued or generated) certificates, containing the
forged certificate hash, DN, and server SID
The TOE provides the ability to configure syslog levels per daemon that generates the respective audit
records. The Configuration utility GUI and tmsh provide interfaces to set those log levels.
Depending upon the exact audit record, the outcome is included in the description and / or the status
code.
Table 8 shows the information included in the different types of audit logs.
Log content Log type
System
Packet
Filter
Local
Traffic
Audit
(mcp)
Audit
(other)
Certificates
Timestamp The time and date that the system logged
the event message.
X X X X X X
Log Level Provides log level detail X
Host name The host name of the system that logged
the event message.
X X X X X
Service The service that generated the event. X X X X X
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 63
Log content Log type
System
Packet
Filter
Local
Traffic
Audit
(mcp)
Audit
(other)
Certificates
Status code The status code associated with the event. X X
Session ID The ID associated with the user session. X
Description The description of the event that caused
the system to log the message.
X X X X X X
User Name The name of the user who made the
configuration change
X X
Transaction
ID
The identification number of the
configuration change initiated by another
recorded event. This number can be used
to trace back to the initiating audit entry
and the associated user name.
X
Event A description of the configuration change
that caused the system to log the message.
X X
Table 8: Audit Logs and Their Content
The TOE includes within each audit record the information required by FAU_GEN.1.2 and specified
in Table 4 and required by FAU_GEN.1.2/STIP and specified in Table 5.
7.1.2 Audit Storage
The certificate key file object name is logged to identify the relevant key in audit records recording
the administrative task of generating/import of, changing, or deleting of cryptographic keys.
This functionality implements FAU_GEN.1, FAU_GEN.1/STIP and FAU_GEN.2.
BIG-IP supports (and the evaluated configuration mandates) logging to external syslog hosts. Audit
records in transit to the remote host are protected by TLS channels.
The syslog mechanism provided by the underlying Linux system (which is the operating system of the
TOE) is used for the creation and forwarding of audit records. In the evaluated configuration, all audit
records are sent to both local and remote storage automatically. The audit records are sent to the remote
storage immediately. In addition, BIG-IP implements a high-speed logging mechanism for data traffic
(logging packet filter events and local traffic events) in TMM that is compatible with syslog. The TOE
supports TLS channels to audit servers for the protection of audit records sent from the TOE to an
external audit server.
The TOE periodically checks the availability of the remote syslog host. If the remote syslog host
becomes unavailable, audit records are stored locally in syslog files managed, and protected against
unauthorized access, by using file permission bits in the underlying Linux host. The TOE will attempt
to periodically reestablish the connection with the remote syslog host indefinitely. The TOE retries
within seconds of each connection failure. The TOE implements a buffer to store audit records collected
during the period of time when the remote syslog host is unavailable. If the connection to the remote
syslog host is reestablished before the local audit buffers overflow, no audit records are lost. If the
remote syslog host is unavailable and the local audit buffers are full, the BIG-IP system enters a
degraded mode of operation, traffic processing is halted, and only auditable actions performed by the
Security Administrator are allowed.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 64
Locally stored audit records are also available for review through the administrative interfaces of the
TOE. Only users in the Administrator role can modify those records. The TOE does not support deletion
of audit records even by authorized users.
BIG-IP logs a warning if the local space for syslog files on the box exceeds a configurable maximum
size. The TOE implements a local syslog file rotation scheme that numbers the locally archived syslog
files. The TOE will delete the oldest syslog file once the maximum size for local syslog file space is
exceeded. A cron job runs every two minutes to check the audit trail storage partition in order to
accomplish this. The evaluated configuration requires allocation of 7 GB of audit storage, and a warning
to be logged when 90 % of the storage space are exhausted. The administrator receives the warnings
when reviewing the log files as instructed the CC guidance document.
This functionality implements FAU_STG.1, FAU_STG.4, FAU_STG_EXT.1, and
FAU_STG_EXT.3/LocSpace.
7.1.3 Certificate Repository
The BIG-IP stores the forged (also known as issued or generated) certificates in the syslog audit trail
which is stored on the external audit server. The syslog protocol is used by the TOE to store the
forged certificates.
This functionality implements FAU_GCR_EXT.1.
7.2 Cryptographic Support
The TOE utilizes cryptographic algorithms that have been validated using the NIST CAVS tests.
Higher-level protocol stacks can use the F5 cryptographic module (OpenSSL) in order to implement
trusted traffic communications:
• Management GUI (browser client to TOE)
• SSH session for tmsh (SSH client to SSH server on TOE)
• Remote logging via syslog (TOE to syslog server)
• TLS user traffic intended to pass through the TOE to servers
Replay detection (and rejection) is inherent to the protocols used by BIG-IP to establish
communications of a trusted nature, i.e. TLS/HTTPS and SSH.
7.2.1 Key Generation and Establishment
The asymmetric keys are generated upon the request of an administrator by a Key Generator process
that invokes the OpenSSL library on the Linux host.
The TOE generates asymmetric cryptographic keys that are compliant with FIPS PUB 186-4 and meet
the following:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 65
Key
Generation
Scheme
Key Establishment
Scheme
Key sizes /
NIST curves
Usage
RSA RSA
NIST SP 800-56B
Key sizes:
2048, 3072
TLS certificate
TLS ephemeral session keys
SSH key pair
The TLS static keys are created once,
imported to the TOE, and stored on disk
until the Administrator creates a new key.
The SSH key pair is created on first boot.
The TOE can act as a receiver or both
sender and receiver depending upon the
deployment.
When acting as a receiver, decryption
errors are handled in a side channel
resistant method and reported as MAC
errors.
ECC ECC
NIST SP 800-56A
NIST curves:
P-256, P-384
For ECDHE and ECDSA in TLS.
The TOE can act as a receiver or both
sender and receiver depending upon the
deployment.
Table 9: Key generation in the TOE
The TOE also generates TLS session keys and SSH shared secrets (session keys) while setting up the
communication session.
The TOE offers administrative interfaces for creating a private key and certificate signing request
(CSR). See Section 7.4.2 for more information on CSRs.
This implements FCS_CKM.1 and FCS_CKM.2.
7.2.2 Zeroization of Critical Security Parameters
“Cryptographic Critical Security Parameters” are defined in FIPS 140-2 as “security-related
information (e.g., secret and private cryptographic keys, and authentication data such as passwords and
PINs) whose disclosure or modification can compromise the security of a cryptographic module.” Only
the TLS and SSH session keys are stored in plaintext form. The persistent private and secret STIP keys
are stored on disk encrypted with a passphrase that is stored in the F5 Secure Vault. The rest of the keys
are stored in encrypted format. The encrypted keys are stored using the F5 Secure Vault. The F5 Secure
Vault uses a Primary Key and a Unit Key to protect sensitive configuration attributes. The Primary Key
is a single, symmetric key that is stored with the data and is used to protect the data. All sensitive
configuration attributes, including passwords and passphrases, are encrypted with the Primary Key
using 128-bit AES encryption. On F5 devices and vCMP, the Unit Key (a key-encrypting-key) is a
symmetric key stored in the EEPROM that is associated with the device and is used to protect the
Primary Key. The Primary Key is encrypted with the Unit Key using 256-bit AES encryption. If the
Unit Key is replaced, the old Unit Key is cleared by overwriting it with random data and then the new
Unit Key is written.
The following table discusses how the F5 cryptographic module (i.e. OpenSSL used by both data plane
and control plane) zeroize critical security parameters that are not needed for operation of the TSF
anymore. OPEN_SSL_cleanse() is used to zeroize data, and this routine has been updated to overwrite
with zeros, not with pseudo-random data. This also includes key material used by the TSF that is stored
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 66
outside of the F5 cryptographic module. Keys in volatile and non-volatile storage are destroyed by
performing a single overwrite consisting of zeroes.
Application Key type Storage
Location
Volatile/
Non-
volatile
Zeroized
when?
Description
Key
generation
seeds,
prime
numbers
Stack/heap Volatile After each
key has been
generated.
These are zeroized in OpenSSL
by calling
OPENSSL_cleanse(), which
overwrites the memory upon
release.
TLS
SSLO
Premaster
secret
Master
Secret
Not
persistent
Stack/heap Volatile After session
has ended
Control Plane:
The TLS secrets are created
within OpenSSL during session
initiation. These are zeroized
in OpenSSL by calling
OPENSSL_cleanse(), which
overwrites the memory upon
release.
Data Plane (TMM):
TLS secrets are created as part
of TMM’s SSL handshake
establishment. These are
deleted when the handshake
terminates. The memory is
zeroized via a call to
crypto_buf_zeroize() which
cryptographically zeroizes the
contents therein.
TLS
SSLO
Session
keys
Not
persistent
Stack/heap Volatile After session
is no longer
in use
Control Plane:
The TLS session keys are
created within OpenSSL during
session initiation. These are
zeroized in OpenSSL by calling
OPENSSL_cleanse(), which
overwrites the memory upon
release.
Data Plane (TMM):
TLS session keys are created as
part of TMM’s SSL handshake
establishment. The session
keys are deleted when the
session is no longer in use. The
memory is zeroized via a call to
memset().
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 67
Application Key type Storage
Location
Volatile/
Non-
volatile
Zeroized
when?
Description
TLS
SSLO
private
keys in
TLS
certificates
On the disk Non-
volatile
Upon
deletion by
administrator.
Private keys are zeroized when
they are deleted by the
administrator. Zeroization is
done by overwriting the file
once with zeroes and deleting
the file. The API used for
zeroization is the write(2)
system call which is called with
buffer filled with zeros as
input.
SSH Shared
Secrets
(session
keys)
Not
persistent
Stack/heap Volatile After session
has ended
The SSH shared secrets
(session keys) are created
within OpenSSL during session
initiation.
These are zeroized in OpenSSL
by calling
OPENSSL_cleanse(), which
overwrites the memory upon
release
SSH SSH
private
keys
On the disk Non-
volatile
Upon
deletion by
administrator.
SSH keys are zeroized when
using the key-swap utility.
Zeroization is done by
overwriting the file once with
zeroes and deleting the file.
The API used for zeroization is
the shred(1) Linux command
which uses the write(2) system
call which is called with buffer
filled with zeros as input.
SSLO Embedded
CA private
key
On the disk
or
on the
HSM
Non-
volatile
Upon
deletion or
replacement
by
administrator.
Private keys are zeroized when
they are deleted by the
administrator. Zeroization is
done by overwriting the file
once with zeroes and deleting
the file. The API used for
zeroization is the write(2)
system call which is called with
buffer filled with zeros as
input.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 68
Application Key type Storage
Location
Volatile/
Non-
volatile
Zeroized
when?
Description
SSLO Private key
of forged
server
certificate
Memory Volatile Upon re-
issuance of
the forged
server
certificate
The private key for forged
server certificates are created
when there is no previous valid
forged certificate for that
server.
These are zeroized in OpenSSL
by calling
OPENSSL_cleanse(), which
overwrites the memory upon
release
Table 10: Zeroization of Critical Security Parameters
This implements FCS_CKM.4 and FCS_STG_EXT.1.
7.2.3 Cryptographic operations in the TOE
The following table summarizes the implementation of cryptographic operations in the TOE:
Algorithm Key length (bits) Purpose Reference SFR
AES
(CBC,
CTR,
GCM
modes)
128
256
payload
encryption
AES as specified
by ISO 18033-3
CBC as specified
in ISO 10116
CTR as specified
in ISO 10116
GCM as
specified in ISO
19772
FCS_COP.1/DataEncryption
AES
(CCM,
CCM-8
modes)
128
256
Payload
encryption for
STIP support
AES as specified
by ISO 18033-3
CCM and CCM-
8 as specified by
NIST SP 800-
38C
FCS_COP.1/STIP
RSA Modulus of 2048,
3072
certificate-
based
authentication,
key exchange
FIPS PUB 186-4
Section 5.5 using
RSASSA-
PKCS1v1_5,
ISO/IEC 9796-2
FCS_COP.1/SigGen
ECDSA 256, 384 bits
NIST curves: P-
256, P-384, and no
other
certificate-
based
authentication,
key exchange
FIPS PUB 186-4
Section 6 and
Appendix D
ISO/IEC 14888-
3 Section 6.4
FCS_COP.1/SigGen
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 69
Algorithm Key length (bits) Purpose Reference SFR
SHA-1
SHA-256
SHA-384
none certificate-
based
authentication /
digital
signature
verification
ISO/IEC 10118-
3:2004
FCS_COP.1/Hash
HMAC-
SHA-1
Key sizes: ≥ 160
bits
Hash Function:
SHA-1
Message digest
sizes: 160 bits
Block size: 512 bits
Output MAC
length: 160 bits
message
integrity
ISO/IEC 9797-
2:2011, Section
7
FCS_COP.1/KeyedHash
HMAC-
SHA-256
Key sizes: ≥ 256
bits
Hash Function:
SHA-256
Message digest
sizes: 256 bits
Block size: 512 bits
Output MAC
length: 256 bits
message
integrity
ISO/IEC 9797-
2:2011, Section
7
FCS_COP.1/KeyedHash
HMAC-
SHA-384
Key sizes: ≥ 384
bits
Hash Function:
SHA-384
Message digest
sizes: 384 bits
Block size: 1024
bits
Output MAC
length: 384 bits
message
integrity
software
integrity
ISO/IEC 9797-
2:2011, Section
7
FCS_COP.1/KeyedHash
Random
Bit
Generation
none key generation ISO/IEC
18031:2011
using CTR
DRBG (AES)
FCS_RBG_EXT.1
Table 11: Cryptographic primitives in the TOE
7.2.4 Random Number Generation
The TOE transfers one or more random bit-streams from the defined entropy sources to the Linux
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 70
operating system’s entropy pool. The entropy pool is used as a seed source for a digital random
number generator (DRNG) via the /dev/random and /dev/urandom special file interfaces. The bit-
stream will be transferred as necessary during system operation. On F5 devices and vCMP, the
defined sources will be specific to the hardware available on each platform but will include one or
more of the following: the jitterentropy-engine, Cavium Nitrox III hardware, Intel QAT hardware, and
the Intel rdrand instruction.
The random bit stream from the entropy source will be fed to the Linux DRNG on demand, such that
If the entropy in the Linux DRNG runs low (and thus the threshold that causes /dev/random to block
will reached soon), fresh entropy is inserted and the entropy estimate in the Linux RNG is increased.
This will attempt to ensure that sufficient entropy is available in the Linux DRNG to avoid blocking
applications that read from /dev/random, or will release any applications that have become blocked.
Since the /dev/urandom interface also draws from the Linux kernel entropy pool input of the random
bit stream will also ensure that /dev/urandom is initialized and reseeded. The increase in the entropy
estimate caused by the transfer of the random bit stream is not equal to the number of bits transferred,
rather it scaled by a factor which is dependent on the entropy source.
This implements FCS_RBG_EXT.1.
7.2.5 SSH
The TOE implements a SSH v2 server and a SSH v2 client. The SSH client is not used for
communication with trusted external IT entities and will be disabled in the TOE. Administrators can
connect to the TOE remotely using SSH via a dedicated network interface. Administrators are
authenticated locally by user name and password; remote authentication (via LDAP or AD) is not
supported by the TOE.
The SSH implementation is compliant with RFCs 4251, 4252, 4253, 4254, 5656, 6668, 8332.
SSH connections to the TO’'s command line interface are protected using SSH version 2, using the
cryptographic algorithms identified in Table 12.
Usage Algorithm
Transport encryption algorithm AES CBC and CTR mode with 128 and 256 bit-sizes keys
Transport data integrity protection
hashing algorithm
HMAC-SHA1 and HMAC-SHA2-256
Public key authentication algorithms ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
Key exchange (hard-coded) ecdh-sha2-nistp256 and ecdh-sha2-nistp384
Table 12: SSH Algorithms
The SSH implementation monitors packet size on all channels and limits packet size as suggested in
RFC 4253 Section 6.1; the maximum packet size is (256*1024) bytes with larger packets being silently
dropped. Additionally, 70ertife-hellman-group1-sha1 key exchange is intentionally disabled in the SSH
implementation.
The SSH connection session key will be renegotiated after either of two thresholds has been reached.
SSH connection session keys will be renegotiated after one hour of use. In addition, the SSH
connection session key will be renegotiated after an administrator-configured maximum amount of
data, the RekeyLimit, is transmitted over the connection. The administrative guidance will instruct the
user to not set the RekeyLimit to a value greater that 1 GB.
This functionality implements FCS_SSHS_EXT.1.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 71
7.2.6 TLS Protocol
The TOE implements both the TLS server and TLS client protocol.
Administrators remotely connect to the TOE via an HTTPS server implementing TLS over a
dedicated network interface used to administer the TOE. Administrators are authenticated locally by
user name and password; remote authentication (via LDAP or AD) is not supported by the TOE.
Administrator sessions that use the web-based Configuration utility, SOAP protocol (iControl API),
or the REST API (iControl REST API) are protected by TLS. TLS sessions are limited to TLS
versions 1.2 and 1.1, using the cipher suites identified in Table 13. The TLS server implementation in
the TOE is configured to deny SSL 1.0, SSL 2.0, SSL 3.0, and TLS 1.0 session requests.
The TOE implementation of TLS client is capable of presenting a certificate to a TLS server for TLS
mutual authentication. The TLS client implemented by the data plane of the TOE is used to
communicate with the external audit server.
The following table summarizes the cipher suites supported by the evaluated configuration for TLS
connections. All other proposed cipher suites are rejected.
Cipher Data Plane
Client
Data Plane
Server
Control
Plane Server
TLS_RSA_WITH_AES_128_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
N/A
TLS_RSA_WITH_AES_256_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
N/A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
N/A
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS v1.1
TLS v1.2
TLS v1.1
TLS v1.2
N/A
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS v1.2 TLS v1.2 TLS v1.2
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS v1.2 TLS v1.2 TLS v1.2
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS v1.2 TLS v1.2 TLS v1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS v1.2 TLS v1.2 TLS v1.2
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 72
Cipher Data Plane
Client
Data Plane
Server
Control
Plane Server
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS v1.2 TLS v1.2 TLS v1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS v1.2 TLS v1.2 TLS v1.2
TLS_RSA_WITH_AES_128_GCM_SHA256 N/A N/A TLS v1.2
TLS_RSA_WITH_AES_256_GCM_SHA384 N/A N/A TLS v1.2
Table 13: Cipher suites
When acting as a TLS server, BIG-IP does not operate on or process reference identifier fields in the
BIG-IP certificate. It's up to an Administrator to load the desired X.509 certificate and up to TLS
clients to verify it.
The TLS server supports session resumption based on session tickets according to RFC 5077. These
session tickets adhere to the structural format described in Section 4 of RFC 5077. These session
tickets are encrypted using the AES with CBC mode symmetric algorithm with 128 bit key length as
defined in FCS_COP.1/DataEncryption.
Session establishment creates a session ID. When a new context is started and a session ID is offered,
the session ID is verified to be acceptable to allow session resumption by checking the validity of the
session ID in the session ID table, the age of the session ID, the cipher suite offered in the session ID,
configuration settings of the session ID, and the Server Name Indication (SNI). Any failure in these
validation steps listed below would trigger a full handshake.
Multiple contexts are supported for session resumption. A session can be constructed in one context
and resumed in another context. The context which constructs the session ID during full handshake is
the owner of that session ID and also validates the session ID and session state. Contexts which
resume a session request that the originating context session owner validate the session ID and session
state. If the originating context session validation response does not validate the session, a full
handshake is triggered. Contexts validate sessions by requesting that the originating owner of a
session validate a session before resumption can continue. If a session is not validated, a full
handshake is triggered.
When acting as a TLS server, BIG-IP generates key establishment parameters using RSA with key
size 2048 and 3072 bits, and ECDH parameters over NIST curves secp256r1 and secp384r1. The TLS
server key exchange message parameters (ECDH) are as defined / required by RFC 5246 Section
7.4.3 for TLS 1.2, RFC 4346 Section 7.4.3 for TLS 1.1, and RFC 4492. For example, its classic
ECDH using named curves with predefined parameters. The TOE does not support DHE_RSA cipher
suites, so server key exchange messages are not sent.
For BIG-IP acting as TLS client, the TOE checks Common Name (CN) and DNS name. The CN or
SAN in the certificate is compared by requiring an exact string match of the authenticate name against
the iPv4 address in the certificate. The reference identifiers do not need to be converted by the TOE to
perform this comparison.
The BIG-IP TLS client supports ECDH in the Client Hello by default. This can optionally be disabled
by removing the corresponding cipher suites, although individual curves cannot be configured.
Use of wildcards for reference identifiers constructed by the TOE and certificate pinning for TLS
client connections are not supported by the TOE.
This functionality implements FCS_TLSC_EXT.1[1] – [2], FCS_TLSC_EXT.2,
FCS_TLSS_EXT.1[1]-[4].
7.2.7 HTTPS Protocol
The BIG-IP provides three interfaces for remote administrators that communicate over HTTPS:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 73
Configuration Utility, iControl API, and iControl REST API. HTTP over TLS (HTTPS) is an
application-level protocol for distributed, collaborative, hypermedia information systems transmitted
over a TLS connection.
The TOE implements HTTPS per RFC 2818, HTTP over TLS. The HTTPS implementation is
designed to comply with all mandatory portions of RFC 2818 (as denoted in the RFC by keywords
“MUST”, “MUST NOT”, and “REQUIRED”). The optional portions of the RFC are denoted in the
RFC by keywords “SHOULD”, “SHOULD NOT”, and “MAY”. Connection Initiation, Connection
Closure, Client Behavior, Server Behavior, and Server Identity are implemented. For Connection
Closure, the TOE includes a configuration setting in the SSL profile that controls alert protocols and
the session close behavior. By default, the TOE is configured to close the underlying TCP
connections without exchanging the required TLS shutdown close notify. The TOE can be configured
to perform a clean shutdown of all TLS connections by sending a close notify.
This functionality implements FCS_HTTPS_EXT.1.
7.2.8 Thru-Traffic TLS Inspection
The BIG-IP SSL forward proxy functionality is implemented by creating Client SSL profiles and
Server SSL profiles (also known as SSL forward proxy profiles) as specified in the guidance and
configuring a virtual server with Client and Server SSL profiles for SSL forward proxy functionality.
The TOE implementation of thru-traffic TLS inspection supports session renegotiation, but not
mutual authentication. In the evaluated configuration, the profiles are configured with the allowed
cipher suites and protocols.
The BIG-IP Client SSL profile enables the BIG-IP system to accept and terminate client requests that
are sent using a fully SSL-encapsulated protocol. It also provides a number of configurable settings
for managing client-side SSL connections. For the Client SSL profile, the BIG-IP server is the server
side of the SSL connection.
The BIG-IP Server SSL profile enables the BIG-IP system to initiate secure connections to your SSL
servers by using a fully SSL-encapsulated protocol and providing configurable settings for managing
server-side SSL connections. For the Server SSL profile, the BIG-IP server is the client side of the
SSL connection.
7.2.8.1 Thru-Traffic TLS Inspection Client Protocol
Thru-traffic TLS inspection client protocol refers to the SSL implementation when the BIG-IP is a
client to a requested server. The BIG-IP Server SSL profile defines the parameters for this connection.
The BIG-IP thru-traffic TLS inspection implements TLS 1.2, TLS 1.1, and TLS 1.0 as a client to the
requested server and supports the ciphers listed in FCS_TTTC_EXT.1.1. The Ciphers setting in the
Server SSL profile (that is attached to the SSLO virtual server) controls the cipher suites that are
included in the Client Hello message sent to the requested server.
Server SSL certificate validation supports matching the server name identification, which is sent in
the Client Hello message to the requested server, against the end entity certificate’s subject common
name and certificate’s subject alternative names in the certificates extension received in the certificate
message from the requested server. The TOE also supports wildcard matching on subject alternative
names. The TOE does not support IP address matching.
The BIG-IP validates the certificate provide by the requested server. If the certificate is revoked or
status is unknown and SSL forward proxy is enabled, the Server SSL performs the action configured
in the Server SSL profile; the default value is set to ignore. The possible actions taken when the
Server SSL cannot validate the certificate are:
• drop or abort the handshake,
• ignore allows the handshake to continue causing the client SSL to send a forged certificate
with revoked status to the monitored client, or
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 74
• mask allows the handshake to continue causing the client SSL to send a valid forged server
certificate to the monitored client.
In the evaluated configuration, the cipher suites presented in the Client Hello message are set to the
ciphers listed in FCS_TTTC_EXT.1.1 in descending order with the most secure cipher suite listed
first. The Security Administrator can change the order of the ciphers presented.
This functionality implements FCS_TTTC_EXT.1.
Either party in the TLS transaction is allowed to renegotiate the handshake using new cryptographic
parameters. Session renegotiation can be enabled or disabled in BIG-IP using the Server SSL and
Client SSL profiles. When session renegotiation is enabled, the BIG-IP processes mid-stream SSL
renegotiation requests. When disabled, the system terminates the connection or ignores the request
depending upon the settings in the SSL profile. By default, session renegotiation is enabled. The
Server SSL profiles provide the following options to specify when renegotiation occurs:
• Renegotiation period, which controls the amount of time, in seconds, that the system waits
before renegotiation the SSL session
• Renegotiation size, which controls the amount of data exchange, in megabytes, before the
system renegotiates the SSL session
• Maximum record delay, which specifies the number of delayed records allowed during
renegotiation
• Secure renegotiation which specifies the method of secure renegotiation. The values for this
setting are:
o Request (requests secure renegotiation of SSL connections)
o Require (renegotiation requests to unpatched servers fail)
o Require Strict (renegotiation requests to unpatched servers fail)
Note: Withing the context of the Server SSL profile, there is no behavioral difference
between Require and Require Strict settings.
The default value for the Secure Renegotiation setting in the Server SSL profile is Require
Strict.
This functionality implements FCS_TTTC_EXT.4.
Use of supported groups extension in the Client Hello message can be configured using the Cipher
Group setting in the Server SSL and Client SSL profiles. The available supported groups are
secp256r1, secp384r1, ffdhe2048(256), ffdhe3072(257), ffdhe4096(258).
This functionality implements FCS_TTTC_EXT.5
7.2.8.2 Thru-Traffic TLS Inspection Server Protocol
Thru-traffic TLS inspection server protocol refers to the SSL implementation when the BIG-IP is a
server to the monitored client. The BIG-IP Client SSL profile defines the parameters for this
connection.
The BIG-IP thru-traffic TLS inspection implements TLS 1.2, TLS 1.1, and TLS 1.0 as a server to the
monitored client and supports the ciphers listed in FCS_TTTS_EXT.1.1. BIG-IP denies connections
from clients requesting SSL 2.0 and SSL 3.0.
BIG-IP implements the TLS protocols as specified in the corresponding RFCs: TLS 1.0 (RFC 2246),
TLS 1.1 (RFC 4346), and TLS 1.2 (RFC 5246). Section 7 of these RFCs describe the handshake
messages used by the protocols. The default option for the Client SSL and Server SSL profiles is to
enable the “Generic Alert” option which sends a generic fatal alert 40 (handshake_failure) in all error
conditions. If the “Generic Alert” option is disabled, more specific alerts will be sent. The following
table identifies the possible alerts with a brief description:
Alert Description
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 75
SSL_A_CLOSE_NOTIFY Normal closes pending
SSL_A_UNEXPECTED_MSG Unexpected handshake message type
SSL_A_BAD_RECORD_MAC Record MAC verification error
SSL_A_DECRYPTION_FAILED Decryption failure
SSL_A_RECORD_OVERFLOW Record length too large
SSL_A_DECOMP_FAILURE Decompression error
SSL_A_HANDSHAKE_FAILURE No possible mutual configuration
SSL_A_NO_.CERT_RESERVED No certificate reserved
SSL_A_BAD_CERT Bad certificate
SSL_A_UNSUPPORTED_CERT Unsupported certificate signature
SSL_A_CERT_REVOKED Certificate in our CRL
SSL_A_CERT_EXPIRED Certificate no longer valid
SSL_A_CERT_UNKNOWN Unidentifiable certificate
SSL_A_ILLEGAL_PARAM Invalid field value
SSL_A_UNKNOWN_CA Unknown certificate agent
SSL_A_ACCESS_DENIED Authorization failure
SSL_A_DECODE_ERROR Record parsing error
SSL_A_DECRYPT_ERROR Generic cryptographic failure
SSL_A_EXPORT_RESTRICTION Options violate export laws
SSL_A_PROTOCOL_VERSION Peer's protocol version refused
SSL_A_INSUFFICIENT_SECURITY Client's offered ciphers too weak
SSL_A_INTERNAL_ERROR Generic internal failure
SL_A_INAPPROPRIATE_FALLBACK Warning: Handshake canceled unrelated to a
protocol failure
SSL_A_USER_CANCELLED Impatient user
SSL_A_NO_RENEGOTIATION Renegotiation not allowed
SSL_A_MISSING_EXTENSION Missing extension
SSL_A_UNSUPPORTED_EXTENSION Unsupported extension
SSL_A_CERTIFICATE_UNOBTAINABLE Certificate Unobtainable
SSL_A_UNRECOGNIZED_NAME Unrecognized name
SSL_A_BAD_CERTIFICATE_STATUS_RESPONSE Bad certificate status response
SSL_A_BAD_CERTIFICATE_HASH_VALUE Bad certificate hash value
SSL_A_NO_APPLICATION_PROTOCOL No application protocol
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 76
Table 14: TLS Server Error Alerts
The Cipher Group setting in the Server SSL and Client SSL profiles can be configured to limit the key
agreement parameters used in a server key exchange message with a monitored client. BIG-IP is
capable of performing TLS key establishment with a monitored client using one of the following:
• RSA with key size 2048 bits, 3072 bits;
• Diffie-Hellman groups ffdhe2048, ffdhe3072, ffdhe4096
• EC Diffie-Hellman parameters using elliptic curves secp256r1, secp384r1 and no other
curves.
This functionality implements FCS_TTTS_EXT.1.
Either party in the TLS handshake is allowed to renegotiate with new cryptographic parameters.
Session renegotiation can be enabled or disabled in BIG-IP using the Server SSL and Client SSL
profiles. When session renegotiation is enabled, the BIG-IP processes mid-stream SSL renegotiation
requests. When disabled, the system terminates the connection or ignores the request depending upon
the settings in the SSL profile. By default, session renegotiation is enabled. The Client SSL profiles
provide the following options to specify when renegotiation occurs:
• Renegotiation period, which controls the amount of time, in seconds, that the system waits
before renegotiation the SSL session
• Renegotiation size, which controls the amount of data exchange, in megabytes, before the
system renegotiates the SSL session
• Maximum record delay, which specifies the number of delayed records allowed during
renegotiation
• Secure renegotiation which specifies the method of secure renegotiation. The values for this
setting are:
o Request (requests secure renegotiation of SSL connections)
o Require (initial SSL handshakes from clients are permitted, but renegotiation requests
from clients that do not support secure renegotiation are terminated)
o Require Strict (initial SSL handshakes from clients that do not support secure
renegotiation are denied)
The default value for the Secure Renegotiation setting is Require in the Client SSL profile.
This functionality implements FCS_TTTS_EXT.4.
7.3 User Data Protection
7.3.1 Forged Certificate Issuance
The BIG-IP SSL forward proxy mechanism can encrypt all traffic between a monitored client and
BIG-IP using a certificate and encrypt all traffic between the BIG-IP and the server using a different
certificate. The BIG-IP SSL forward proxy functionality is implemented by creating Client SSL and
Server SSL forward proxy profiles and configuring a virtual server with Client and Server SSL
profiles for SSL forward proxy functionality. The Server SSL profiles are compliant with the
certificate issuance requirements defined in FDP_CER_EXT.1.
A monitored client establishes a three-way handshake and SSL connection with the wildcard IP
address of the BIG-IP virtual server. The BIG-IP then establishes a three-way handshake and SSL
connection with the server and receives and validates the server certificate (while maintaining a
separate SSL connection with the monitored client). The BIG-IP uses the server certificate to create a
forged server certificate that is consistent with the configured SSL profiles to send to the client. The
monitored client receives the forged server certificate from the BIG-IP and recognizes the forged
certificate as originating directly from the server.
This functionality implements FDP_CER_EXT.1.
The BIG-IP audit trails records when the following events occur:
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 77
• Creation of the forged SSL certificate which includes the session ID and a hash of the original
server certificate
• SSL handshake for the forged server which includes the session ID and a hash of the forged
server certificate
An administrator can search the audit trail for the SSL certificate forgery event, identify the session
ID, and then search using that session ID for the corresponding SSL handshake. Finding the two audit
records described above identifies the corresponding server certificates providing linkage between the
original server certificate and the forged server certificate for that session ID.
This functionality implements FDP_CER_EXT.2.
The BIG-IP embedded CA within the SSL forward proxy only accepts certificate signing requests
(CSRs) generated internally by BIG-IP; externally generated CSRs are not accepted. All CSRs are
generated internally within the SSL stack and submitted to the embedded CA within the SSL forward
proxy.
This functionality implements FDP_CER_EXT.3.
When BIG-IP is configured according to the CC guidance, forged certificates will have a certificate
validity of less than 24 hours. The TOE does not generate certificate status information.
This functionality implements FDP_CSIR_EXT.1.
7.3.2 Residual Information Protection
Data buffers used to implement STIP functions, including decrypted TLS payloads, are freed as soon
as cryptographic processing is completed. The buffers are freed by the cryptographic module,
OpenSSL, and mcpd. Buffers are overwritten with zeros when freed.
This functionality implements FDP_RIP.1
7.3.3 Certificate Data Storage
The BIG-IP includes the following trusted public keys and certificates: embedded CA, forged server,
TLS RSA, TLS ECDSA, TLS EC Diffie-Hellman, SSH EC Diffie-Hellman, SSH RSA, SSH ECDSA.
CA certificates are stored in files in BIG-IP. This file can be updated automatically through a BIG-IP
upgrade or manually. The TOE will not provide the ability to directly access the certificate and key
files. These files can only be modified through the command line interface ("tmsh") or the web-based
GUI. The storage containing the certificates file is protected by the TOE not providing an interface to
access the filesystem directly.
This functionality implements FDP_STG_EXT.1
7.3.4 TLS Establishment Policy
The BIG-IP initialization (start-up) process encompases the following:
1. Power on system and the CPU begins executing firmware
2. Bootloader executes
3. System initialization scripts are executed which initialize hardware, auditing, entropy, and F5
specific initialization scripts.
4. Standard OS features are initialized, including httpd
5. OpenSSL is initialized
a. BIG-IP DB variables CommonCriteria and SecurityFIPSConfig are checked. If
enabled, OpenSSL is initialized in FIPS mode.
b. If in FIPS-mode, entropy is initialized and self-tests are executed
c. Ciphers and hash algorithms are loaded
d. Error strings are loaded
e. Set the TLS protocol version and create the SSL context structure
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 78
6. BIG-IP daemons are launched
a. TMM is launched and reads the DB variable commoncriteria.stip. If it’s enabled,
TMM will enforce STIP requirements (e.g. specific certificate forging behavior in
SSL forward proxy, use specific ciphers per STIP spec, etc…)
b. Prior to TMM entering ready state, TLS messages are dropped by BIG-IP.
c. Once TMM enters ready state, it begins processing data plane traffic and TLS session
processing
Be default, the TOE is deployed in intercept mode. The TLS stack within TMM, openSSL, and the
cryptographic module are involved in processing TLS messages. If any of these components fail, the
failure is fatal and the TLS handshake and connection are terminated. By default, the SSL forward
proxy is designed to not trigger TSL handshake bypass in the case of a component failure. The
Server-SSL profile can be configured to trigger a dynamic bypass in the event that one of the
following scenarios occur:
• If backend server requests a client certificate in TLS handshake and Server SSL is not
configured with one, the administrator can turn on “Bypass on Client Certificate Failure” in
SSL configurations Server SSL profile advanced settings section. This will trigger a dynamic
bypass in case SSL Forward Proxy needs to send original client certificate to the backend
server.
• If Server SSL handshake fails with a Handshake Alert, there is an option to trigger dynamic
bypass “Bypass on Handshake Alert” in SSL configurations Server SSL profile advanced
settings section. This will trigger a dynamic bypass if Server SSL TLS handshake fails with
Alert #40.
In both Dynamic Bypass cases, a WARNING log message will be logged for auditing purposes in
/var/log/ltm. Other than above mentioned two dynamic bypass settings, a Bypass operation on TLS
handshake can only be triggered when configured in SSL profile directly or via Policy rules.
BIG-IP recognizes the TLS protocol at both the client and server side by parsing the bytes of
incoming TLS message to identify the record layer version and handshake protocol version of the
TLS handshake Client hello message. The Client SSL and Server SSL profile options-list can be
configured to disable some TLS protocol versions for connecting to SSLO.
There are no non-configurable rules for implementing TLS session establishment policies. The virtual
server configured by the administrator defines a specific IP version on which that virtual server
intercepts traffic. SSLO listens on either an IPv4 or IPv6 virtual server and is able to read all
corresponding IPv4 or IPv6 traffic. An SSLO policy is used to implement TLS session establishment
policy rules based on the network protocol. Rules based on other subject attributes of the monitored
client and server are configurable via iRules. There is a default rule (block, allow, send to chain) that
is configurable. All session establishment policies are configurable.
The SSLO Security Policy rules can match on the following:
• client IP
• client port
• server IP
• server port
• server name in TLS Client Hello
• client VLANS
• server certificate (issuer DN, subject DN, or SANs)
For each match, the administrator specifies a policy action (allow, reject, block/abort), an SSL proxy
action (bypass, intercept), and a configured service chain (which can be none). The administrator can
enable logging block/abort and bypass operations by setting the log level for Per-Request Policy in
the Log Settings menu to Information. This log setting applies to all security policy rules.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 79
The administrator can configure the Client SSL and Server SSL profiles options list to define rules for
TLS versions used for TLS handshakes. Rules for cipher suites and DH groups can be defined using
cipher rules and groups to attach to the profile.
Revocation status may be unavailable for a variety of reasons. If server returns an UNKNOWN OCSP
response, the administrator can configure whether SSLO forges the UNKNOWN response to client
for inspection and decision by client or drop the connection by setting the unknown-cert-status-
response-control option in Server-SSL profile to ignore or drop respectively. If revocation status is
not available due to OCSP responder being offline, SSL Forward Proxy will forge a response
status SSL_OCSP_RESP_STATUS_TRYLATER with cert
status SSL_OCSP_CERT_STATUS_NONE. The decision will be left to monitored client on whether
to continue with the connection. In other words, unknown-cert-status-response-control controls
specific unknown OCSP response.
Mutual authentication for thru-traffic processing is not supported by the TOE.
TLS protocol errors are handled as described below.
TLS Protocol Error Mechanism
Block the connection if the monitored
client does not support a TLS version,
cipher suite, key exchange, and key
size that are in its allowed set
(including the supported groups
secp256r1, secp384r1,
ffdhe2048(256), ffdhe3072(257),
ffdhe4096(258))
Controlling the cipher-string/cipher group on the Client-
SSL profile of SSL forward proxy can result in blocking
this connection. When the device is in CC/STIP mode,
there is a separate CC/STIP cipher string (and also a
cipher group) that sets the cipher list to this string. By
default, the cipher suites are presented in the Client Hello
message in the descending order of security (i.e. most
secure cipher suite first). If the ciphers advertised by
monitored client in the ClientHello does not match the
ones set in Client-SSL profile, the TLS session will not be
established with appropriate error code sent to client.
Administrators can also configure options like “No
TLSv1.1” etc in options-list of the Client-SSL profile to
limit the TLS protocols allowed for the client.
Block the connection if the requested
server does not negotiate a TLS
version, cipher suite, key exchange,
and key size that are in its allowed set
(including the supported groups
secp256r1, secp384r1,
ffdhe2048(256), ffdhe3072(257),
ffdhe4096(258))
Similar to the approach above, but control the cipher-
string/cipher-group or options-list of the Server-SSL
profile attached to SSL Forward Proxy.
Block the connection if the requested
server does not negotiate a TLS
version, cipher suite, key exchange,
and key size that are in the set
proposed by the monitored client in
its Client Hello message
SSL Forward Proxy server-side connection is independent
from client-side in terms of cipher suite selection. So to
use cipher from monitored client’s ClientHello, the cipher-
string or cipher-group should allow very few ciphers to
make this happen. This can be controlled by modifying
cipher-string/cipher-group and options-list of the Client-
SSL and Server-SSL profiles.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 80
Block or inspect the connection if
TOE certificate processing indicates
revocation information is not
available for a requested server
If a server returns an UNKNOWN OCSP response,
administrators can control whether SSL Forward proxy
forges the UNKNOWN response to client for inspection
and decision by client or wehter the connection is dropped
by setting the unknown-cert-status-response-control option
in Server-SSL profile to ignore or drop respectively.
The TOE implements the following default SSL/TLS Inspection Proxy rules on all SSL/TLS network
traffic received from interfaces associated with monitored clients and requested servers:
• drop and be capable of logging invalid TLS messages
• drop and be capable of logging TLS Client Hello messages for which no valid client can be
determined
• drop a TLS Client Hello message for which no valid server attribute can be determined
• drop and be capable of logging TLS messages other than a Client Hello if the message is not
associated with an existing TLS session thread established via the inspection operation or a
TLS encrypted data flow established via a bypass operation
• terminate a TLS session thread if it receives a fatal TLS error message from the monitored
client
• attempt to terminate the TLS session thread and provide a TLS error message to the
monitored client associated to the TLS session thread if it receives a fatal TLS error message
on the TLS session to the requested server
• terminate a TLS session thread established via the inspect operation, and terminate a TLS
encrypted data flow established by the bypass operation, if the TSF receives no traffic from
the associated monitored client for a configurable period
• transition a TLS session thread state from inspect operation to block operation, when
indicated to do so by the TLS plaintext processing policy.
All connections for which an Inspection or Bypass operation is not defined are blocked.
This functionality implements FDP_TEP_EXT.1.
7.3.5 Plaintext Processing and Routing
The Security Policy includes a set of rules that determines which TLS flows are decrypted and sent to
inspection service processing using either TCP/IP or UDP/IP. The inspection processing functional
components are external systems. The configured rules consist of conditions which match a flow
against a configured set of parameters based on any of the following: destination address, destination
port, TLS server certificate message attributes, SNI, DN, and distinct interfaces. When a match
occurs, the rules define the action to be taken: Allow, Abort (Block), Reject, Intercept (decrypt)
Bypass (do not decrypt), and send to service chain combination. The service chain combination
determines if plaintext traffic is sent to services in the service chain. If the flow matches a Security
Policy Rule with a Service Chain action, the decrypted plaintext is sent to external inspection services
using a service chaining mechanism in defined in the Security Policy. A service chain includes an
ordered group of services capable of processing plaintext messages.
If the data forwarded to the inspection processing functional component is not malicious, the data is
returned to the TOE for processing. If the data is determined to be malicious or malformed, the data is
dropped or the connection is rejected.
This functionality implements FDP_PPP_EXT.1, FDP_PRC_EXT.1
7.3.6 SSL/TLS Inspection Proxy Functions
BIG-IP SSLO implements TLS 1.2, TLS 1.0, and TLS 1.1 with session renegotiation as a client to the
requested server that supports the cipher suites defined in FCS_TTTC_EXT.1. BIG-IP SSLO also
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 81
implements TLS 1.2, TLS 1.0, and TLS 1.1 with session renegotiation as a server to the monitored
client that supports the cipher suites defined in FCS_TTTS_EXT.1. TLS traffic transmitting between
these two TLS sessions is decrypted by the BIG-IP SSLO, assigned a unique TLS session ID and
routed to a chain of inspection services, which can be internal or external to the TOE, as configured in
the security policy.
This functionality implements FDP_STIP_EXT.1.1.
To implement the SSLO forward proxy capability, the TOE uses the server name value (SNI) from
the TLS ClientHello message sent by the monitored client as a lookup key to search the internal
certificate cache within TMM for a previously forged server certificate issued by the embedded CA. If
the TOE does not locate a previously forged server certificate, the original server’s certificate is used
as a template to create a forged server’s certificate. This newly forged server’s certificate is saved in
the internal cache using the SNI as a key. If the monitored client does not send an SNI in the TLS
ClientHello, the IP address is used as a lookup key.
This functionality implements FDP_STIP_EXT.1.2.
The ccmode script executed during system installation, instructs the administrator to revoke
inspection consent by setting the ‘inspectionconsent’ DB variable to ‘no’ if the administrator does not
consent to having the system intercept and inspect TLS traffic. The administrator must confirm to
continue with intercepting SSL/TLS encrypted traffic.
This functionality implements FDP_STIP_EXT.1.3.
By default, SSL forward proxy intercepts all encrypted traffic except when policy (e.g. Security
Policy or iRule) sets a bypass action dynamically based on matching rules set by administrator.
Bypassing the inspection operation is achieved by setting the SSL layer to pass-through mode. If
server-side connection exists, it will be torn down and a new server-side connection will be
established. Then, the Client Hello message sent by the client will be forwarded to the server.
This functionality implements FDP_STIP_EXT.1.4.
The TOE generates different error messages when initiating a Block operation depending on what
conditions in the policy initiates the Block. If the block operation is triggered at the TCP or HTTP
protocol layer, a TCP RST packet is sent to the monitored client. If the block operation is triggered
based on client or server TLS property, a TLS Alert message at the fatal level will be sent to the
monitored client, followed by a TCP RST packet. The alert code in the Alert message is Handshake
Failure (40 if Generic Alert is enabled in the client SSL profile; otherwise the alert code is Access
Denied (49).
This functionality implements FDP_STIP_EXT.1.5.
7.4 Identification and Authentication
Administrative users (i.e., all users authorized to access the TO’’s administrative interfaces) are
identified by a user name and authenticated by an individual password associated with that user account.
This is true regardless of how the administrative user interfaces with the TOE. If the supplied user name
and password match the user name and password pair maintained by the TOE, the administrative session
is successfully established. Otherwise, the user receives an error and the session is not established. In
addition, the TOE displays warning banners for interactive sessions as described in Section 7.6.5.
This functionality implements FIA_UIA_EXT.1, FIA_UAU_EXT.2.
For interactive user authentication at the web-based Configuration utility via HTTPS and the command
line tmsh via SSH, BIG-IP obscures passwords entered by users.
This functionality implements FIA_UAU.7.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 82
7.4.1 Password policy and user lockout
The TOE can enforce a password policy for all user accounts managed locally, other than those in the
Administrator role. This includes the definition of a minimum password length and required character
types (numeric, uppercase, lowercase, others). The minimum password length default value is 15; the
valid range is from 15 to 255. This policy is enforced when users change their own passwords.
The TSF allows passwords to contain the following special characters: “!”, “@”, “#”, “$”, “%”, “^”,
“&”, “*”, “(“, “)”, “`”, “~”, “-“, “+”, “=”, “[“, “]”, “{“, “}”, “;”, “’”, “:”, “””, “, “, “.”, “/”,
“<”, “>”, “”, “|”, “\”.
Other aspects of the authentication policy include the minimum and maximum lengths of time that
passwords can be in effect, and the number of previous passwords that BIG-IP should store to prevent
users from re-using former passwords.
• The minimum duration specifies the minimum number of days before which users cannot
change their passwords; the default is 0 and the valid range is from 0 to 255.
• The maximum duration specifies the maximum number of days a password is valid; users must
change their passwords before the maximum duration is reached, the default is 99999 days.
o User accounts whose password has expired, based on the administrator-defined
maximum password duration, are locked and require an administrator to reset them.
• Password memory specifies that the system records the specified number of passwords that the
user has used in the past. Users cannot reuse a password that is in the list. The default is 0 and
the valid range is from 0 to 127.
Both local and remote access to the TOE for individual users can be disabled “”locke””) after a
configured number of consecutive, failed authentication attempts on that user account. In the
evaluated configuration, the default is 3 consecutive, failed authentication attempts with a valid range
from 1 to 10. For each administrative interface (local and remote interfaces), a single centralized
module in the TOE verifies user identification and authentication. That module returns authentication
success or failure decisions and maintains the user lockout feature. A counter of failed authentication
attempts is maintained for each user. If too many failed authentication attempts occur, the associated
user account is locked out and access is denied. A counter is kept for each user to track consecutive
authentication failures. When a successful authentication occurs, the counter is reset to zero.
In the evaluated configuration, an administrator-configured time value determines the duration of a
user’s lock out time. The default is 10 minutes (600 seconds).
In the evaluated configuration, it is not possible for all administrative users to be locked out of the TOE,
because the primary administrative user account is permitted to login to the local console even if it is
locked out when attempting to login through any remote interface.
This functionality implements FIA_AFL.1, FIA_PMG_EXT.1.
7.4.2 Certificate Enrollment
During initial system setup, the administrator must either import or generate an asymmetric key pair
and CA certificate signed by a trusted external CA to the embedded CA. The administrator has two
options:
1) generate a key pair and CA certificate on an external system, then import the key pair and
certificate onto BIG-IP
2) generate a key pair on the BIG-IP, generate a CSR on the BIG-IP, send the CSR to an external
CA to create a signed CA certificate, then import that CA certificate on to the BIG-IP
The private key for the embedded CA is stored on the file system encrypted with a passphrase stored in
the F5 Secure Vault or if the key pair is generated by an HSM, it is stored on the HSM. The guidance
instructs the installer to configure the system to include a key pair and CA certificate for the embedded
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 83
CA using one of these methods. This process can be repeated by an authorized administrator at any
time the system is running to update or change the CA certificate for the embedded CA.
This functionality implements FIA_ENR_EXT.1.
7.4.3 TLS Certificate Validation
For TLS client sessions on the data plane, the TOE implements certificate validation using the OpenSSL
crypto library. The TLS client in the data plane supports TLS with mutual authentication for trusted
communication channels with the external audit server.
The TOE supports validation of X.509 digital certificates using a certificate revocation list (CRL) as
specified in [RFC 5280] Section 5. Administrators create profiles which are used to define the
parameters used to communicate with an external entity. These parameters include the ability to require
the use of TLS and peer or mutual authentication and a definition of the certificate to use for
authentication. This capability is used to create a mutually authenticated connection with the external
audit server. The external audit server provides a certificate to the TOE during establishment of the TLS
connection in order to authenticate the external audit server.
The TOE offers administrative interfaces for creating a private key and certificate signing request
(CSR). The CSR may include the following information: public key, common name, organization,
organizational unit, country, locality, state / province, country, e-mail address, subject alternative
name. After the CSR is created, the administrator must export the CSR outside the TOE. Outside the
scope of the TOE, the administrator provides the CSR to the CA and then the CA returns the
certificate to the administrator. Using the administrative interface, the administrator can then import
the certificate into the TOE.
The only method supported by the TOE for obtaining a CA certificate is for the administrator to save a
Certificate to a text file and import it into the TOE. The certificates are stored in a text file. The TOE is
capable of importing X.509v3 certificates and certificates in the PKCS12 format. The TOE is also
capable of creating and using a self-signed certificate.
The TOE checks the validity of the certificates when the profile using the certificate is loaded and when
the certificate is used by the TOE, including during authentication. If the certificates are modified, the
digital signature verification would detect that the certificate had been tampered with and the certificate
would be invalid. Administrators can ensure that the certificates presented have not been revoked by
importing a certificate revocation list (CRL) into the TOE.
A certificate chain includes the root CA certificate, certificates of intermediate cAs, and the end entity
certificate. The certificate chain consists of all the certificates necessary to validate the end certificate.
Administrators can upload trusted device certificates (root CA certificates) into the TOE to identify
which certificates are trusted. The TOE performs full certificate chain checking using Public Key
Infrastructure X.509, verifies the expiration of the certificate (assuming a reliable time), and verifies its
revocation using CRLs.
When the validity of a certificate cannot be established, the TOE will allow the administrator to choose
whether or not to accept the certificate.
This implements FIA_X509_EXT.1/Rev, FIA_X509_EXT.2, FIA_X509_EXT.2/STIP,
FIA_X509_EXT.3.
7.4.4 Thru-Traffic Processing Certificate Validation
Received certificates are verified in TMM immediately upon receipt by BIG-IP during the TLS
handshake. The certificate verification includes building a trust chain, validating the certificate not-
before and not-after dates, and then verifying that the signature on each certificate in the chain is
performed by its issuer. The TLS certificate validity is checked first and thereafter, the OCSP
certificate validity check occurs.
Certificate authentication used by thru-traffic processing functions the same as it does for standard
TLS traffic.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 84
This implements FIA_X509_EXT.1/STIP.
7.5 Security Function Management
The TOE provides the ability to administer the TOE both locally and remotely. Local administration
is performed via the serial port console. Remote access to the management interfaces is only made
available on the dedicated management network port of a BIG-IP system.
The TOE offers administrators four different methods to configure and manage the TSF. They are:
• Configuration Utility (Web-based GUI) –- browser-based GUI interface with normal GUI
panels and selections. The client browser talks to the Apache HTTP server over HTTPS; then
the request passes through tomcat and to the BIG-IP.
• tmsh shell commands – provide a command line interface, accessible through an SSH client
• iControl API – SOAP-based programming interface over HTTPS.
• iControl REST API – REST-based programming interface over HTTPS.
These management interfaces are implemented in the background by a central management control
program daemon (mcpd) that provides configuration information to individual TOE parts and
coordinates its persistent storage.
The first three interfaces are independent. The tmsh interface is the most complete; though none of the
three are proper subsets of each other. iControl REST APIs utilize tmsh shell command(s) to perform
the desired operation, so it is basically a front-end to the tmsh shell commands. As such, the functions
provided by the iControl REST API are a proper subset of the set of tmsh commands.
Management Function tmsh Configuration
Utility (Web-
based GUI)
iControl
App
iControl
REST API
Ability to manage user accounts X X X X
Ability to manage remote audit
mechanism
X X X X
Ability to perform on-demand integrity
tests
X
Ability to import and remove X.509v3
certificates used for STIP into or from
the Trust Anchor Database
X X X X
Ability to configure identifying
information for the TOE’s embedded
CA
X X X X
Ability to configure a maximum
certificate validity duration
X X X X
Ability to manage inspection policy X
Ability to configure inspection
processing service connectors
X
Ability to configure local audit
behavior
X X X X
Ability to configure and manage the
certificate profiles
X X X X
Ability to modify the OCSP
configuration
X X X X
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 85
Table 15: BIG-IP Management Functions per interface
Remote use of these interfaces is performed over protected communication paths as described in
Section 7.8. These four administrative interfaces require users to identify and authenticate themselves
prior to performing any administrative functions.
The TOE comes with a pre-defined “admin” user with the Administrator role assigned that cannot be
deleted. A password is assigned to the “admin” user during setup of the TOE. Local user accounts are
managed by administrators in the Administrator or User Manager role and stored in the TO’’s local user
database. Management includes creating and deleting users, as well as changing another use’’s
password (every user can change their own password), role, or partition the user has access to, and
enabling or disabling terminal access for the user. However, User Managers that have access to only
one partition cannot change the partition access of other users, and cannot change their own partition
access or role. (More information on roles can be found in Section 7.5.1.)
Some general configuration options include:
• definition of an administrative IP address for the TO’’s management network interface
• configuration of remote logging
• configuration of auditing
• configuration of TOE security functions
• start/stop services
• manage TSF data, configure the login access banner
• configure session inactivity timeout
• manage cryptographic keys
• configure cryptographic functionality
• configure the RekeyLimit which defines how much data can be transmitted within an SSH
connection before rekeying
• configuration of trusted updates
• set the time period for rejecting logins from an Administrator who has reached the maximum
number of unsuccessful authentication attempts, and
• set the time which is used for time stamps.
BIG-IP uses the concept of virtual servers to define destinations that BIG-IP accepts (client) traffic for.
Virtual servers are represented by an IP address and service (such as HTTP). The actual resources that
BIG-IP forwards the traffic to are referred to as nodes, represented by their IP address. Nodes can be
grouped into pools, for example for the purpose of load balancing. (A client sends an HTTP request to
BIG-I’’s virtual server address, and BIG-IP will then select a node from the pool associated with the
virtual server to forward the request to.) Virtual servers are a management tool used to simplify the
configuration of filtering and processing incoming network requests.
In order to determine the treatment of different types of traffic, such as requiring client authentication
or inspection of HTTP code at the application layer, administrators can assign profiles to virtual servers.
Profiles contain detailed instructions on how the different traffic management-related security functions
of the TOE are applied to matching traffic.
The Security Administrator is able to start and stop the following services using the “bigstart <stop,
start, restart> <service>” command or the following tmsh command “tmsh <stop, start, restart> /sys
service <service>”. The list of services that can be started and stopped are found in
https://support.f5.com/csp/article/K67197865.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 86
The BIG-IP restricts the ability to modify the behavior of the management functions listed in Table 6
to the Security Administrator and/or Auditor as identified in that table.
This functionality implements FMT_MOF.1/Services, FMT_MOF.1/STIP, FMT_SMF.1,
FMT_SMF.1/STIP.
7.5.1 Security Roles
Access of individual users to the web-based Configuration utility, tmsh, iControl API, and iControl
REST API is restricted based on pre-defined roles. Role enforcement is the same for each of these
management interfaces. These roles define which type of objects a user has access to and which type of
tasks he or she can perform. The role definitions cannot be changed by TOE administrators. Table 16
contains the definition of user roles.
The TOE allows security administrators to define the type of terminal access that individual users have,
i.e. whether they have access to the tmsh via SSH or not. The TOE can be administered either locally
or remotely. Administering the TOE locally entails connecting a device to the management port on the
BIG-IP via an Ethernet cable
The tasks that users can perform on objects, depending on their role, are grouped into hierarchical access
levels:
• write: create, modify, enable and disable, and delete an object
• update: modify, enable, and disable an object
• enable/disable: enable and disable an object
• read: view an object
In addition to roles, the TOE implements the concept of partitions for restricting access to objects.
Configuration objects that deal with the individual traffic management functions offered by the TOE
are stored in partitions (either the Common partition, or administrator-defined partitions. Objects
(including users, server pools, etc.) can be created in different partitions by administrators, and users
can be assigned a partition they have access to ("partition access"). As a result, users will only have the
type of access defined by their assigned role to objects in the partition that is defined by their partition
access. (With certain exceptions documented in the tables below.) It is possible to assign a user access
to "all" partitions, in which case the user will have access to objects in all partitions as defined by their
role (referred to in the guidance documentation as "universal access").
Note: The fact that a user account is created in a specific partition does not mean that the user will
automatically have access to other objects in that partition.
The TOE comes with a pre-defined "Common" partition, which cannot be deleted. New objects created
by users are either placed in the user's partition, or - if the user has access to all partitions - are placed
in the Common partition unless the user explicitly chooses otherwise. The pre-defined "admin" user
with the Administrator role is located in the Common partition.
Even users who are located in a partition other than Common have certain access to objects in the
Common partition, as follows:
• Administrator always has access to all objects defined in the TOE.
• User Managers have write access to user account objects in the Common partition, except those
with the Administrator role assigned to them.
• Resource Administrators, Managers, Certificate Managers, Application Editors, Operators, and
Guests have read access to all objects in the Common partition.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 87
Role Associated rights
Administrator This role grants users complete access to all partitioned and non-partitioned objects on
the system, manage remote user accounts and change their own passwords. This
includes trusted updates and the management of all security functions and TSF data.
Resource
Administrator
This role grants users complete access to all partitioned and non-partitioned objects on
the system, except user account objects. Additionally, users with this role can change
their own passwords. This includes management of all security functions and TSF
data, including remote users, remote roles, but not other user management functions.
User Manager Users with the User Manager role that have access to all partitions can create, modify,
delete, and view all user accounts except those that are assigned the Administrator
role, or the User Manager role with different partition access. However, User
Managers cannot manage user roles for remote user accounts. Users with the User
Manager role that have access only to a single partition can create, modify, delete, and
view only those user accounts that are in that partition and that have access to that
partition only.
User accounts with the User Manager role can change their own passwords.
Manager This role grants users permission to create, modify, and delete virtual servers, nodes,
pools, pool members, custom profiles, and custom monitors. Users in this role can
view all objects on the system and change their own passwords.
Certificate
Manager
This role grants users permission to manage device certificates and keys, as well as
perform Federal Information Processing Standard (FIPS) operations.
Application
Editor
This role grants users permission to modify nodes, pools, pool members, monitors and
change their own passwords. These users can view all objects on the system.
Operator This role grants users permission to enable or disable nodes and pool members. These
users can view all objects.
Auditor This role grants users permission to view all configuration data on the system,
including logs and archives. Users with this role cannot create, modify, or delete any
data, nor can they view TLS keys or user passwords. (Note: Because this is BIG-IP
user role only grants read-only access, it does not meet the STIPM Auditor role
definition.)
Log Manager This role grants users permission to view all configuration data on the system,
including logs and archives. The role also grants permission to modify the system log
configuration settings, including remote logging, log filters, destinations, and
publishers.
Guest This role grants users permission to view all objects on the system in their partition
and Common partition.
No Access This role prevents users from accessing the system.
Table 16: BIG-IP User Roles
The Security Administrator role as defined in FMT_SMR.2 is provided by a combination of the BIG-
IP user roles defined in Table 16, except for the Log Manager, Guest and No Access roles.
Administrative users may be assigned different combinations of BIG-IP user roles, so some
administrative users may not have the role(s) necessary to perform all of the administrative functions.
The Auditor role as defined in FMT_SMR.2/STIP is provided by the Log Manager BIG-IP user role
defined in Table 16. If a user is assigned to any of the following roles, they cannot be simultaneously
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 88
assigned to another BIG-IP user role: Log Manager, Administrator, Resource Administrator or Auditor
role.
The BIG-IP restricts the ability to modify the behavior of the management functions listed in Table 6
to the Security Administrator and/or Auditor as identified in that table.
The “tmsh sys crypto key” command can be used by the Security Administrator to manage
cryptographic keys on the TOE. The Security Administrator can manage the SSH key pairs, TLS key
pairs, and pre-shared keys. The Security Administrator is able to perform the following operations on
the keys:
• Importing of SSH public keys
• Generating SSL keys
• Changing keys
• Deleting keys
• Installing keys
This functionality implements FMT_MOF.1/ManualUpdate, FMT_MOF.1/STIP,
FMT_MTD.1/CryptoKeys, FMT_MTD.1/CoreData, FMT_MTD.1/AdminAct, FMT_SMF.1,
FMT_SMF.1/STIP, FMT_SMR.2, FMT_SMR.2/STIP.
7.6 Protection of the TSF
7.6.1 Protection of Sensitive Data
The TOE protects passwords used for the authentication of administrative users as follows:
• In storage for local user authentication, the TOE’s administrative interfaces do not offer any
interface to retrieve user passwords or configuration files.
• In transit between remote users and the TOE, the TOE implements SSH and TLS to protect the
communication.
Pre-shared keys (such as credentials for remote servers), symmetric keys, and private keys are stored in
the TOE's configuration files. The TOE does not offer an interface to retrieve the contents of its
configuration files. Passwords are stored in a salted hashed format.
This functionality implements FPT_APW_EXT.1 and FPT_SKP_EXT.1.
7.6.2 Self-tests
The following self-tests are implemented by the TOE:
• On F5 devices and vCMP. the BIOS Power-On Self-Test POST test is only run at power on
• The OpenSSL integrity tests are run at power on and reboot (during OpenSSL initialization)
for OpenSSL.
• The software integrity check (i.e., sys-eicheck.py utility) is run at power on, reboot, and once
daily to check the integrity of the RPMs. This self-test can also be run on demand at any time.
• The cryptographic algorithm self-tests provided by OpenSSL are run at power on and reboot
(during OpenSSL initialization).
The BIOS POST is a diagnostic program that checks the basic components required for the hardware
to operate, tests the memory, and checks the disk controller, the attached disks, and the network
controllers. The BIOS POST tests cannot be run on demand.
The fipscheck utility is a standard Open Source utility for verifying the integrity of OpenSSL during
initialization.
The sys-eicheck.py utility provides HMAC integrity testing. When a discrepancy is detected, the
utility reports that discrepancy. The utility can be run at any time during system operation, and will
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 89
just report errors. In addition, the HMAC integrity test is executed during every reboot and will halt
the boot if errors are found.
The TOE will execute self-tests at power-on to test the cryptographic algorithms and random number
generation using known answer tests for each of the algorithms. If a power-on test fails, the boot process
will halt.
The self-tests implemented by the TOE which are described in this section cover all aspects of the TSF
are therefore and are sufficient for demonstrating that the TSF is operating correctly in the intended
environment.
This functionality implements FPT_TST_EXT.1/PowerOn and FPT_TST_EXT.1/OnDemand.
7.6.3 Update Verification
While the evaluated configuration of the TOE is limited to the specific version and patch level of BIG-
IP covered in this ST, the TOE nevertheless provides functionality that supports administrators in
verifying the integrity and authenticity of updates provided by F5. The Configuration Utility or tmsh
can be used to query the TOE version.
On F5 devices and vCMP, the TOE is able to validate digital signatures of updates provided by F5; F5
places the ISO files (updates) and signature files on their website. The administrative guidance instructs
the customer to:
• Download the ISO and digital signature file
• Verify the ISO using that file
• Install the update
A signature file exists for each ISO, software change update or image file provided by F5. The content
of the signature file is a digital signature of a SHA256 digest of the ISO image file. The private and
public keys are generated using the OpenSSL utility. The signing key is a 2048 bit RSA private key
that is stored at F5 CM and only available for official F5 builds. The public key is included in the TMOS
filesystem and is available on the F5 official site adjacent to the software archives. Note: The update
verification implementation does not utilize certificates; only digital signatures.
The BIG-IP verifies the SHA256 hash of software archives, using 2048-bit RSA digital signature
algorithm. If the signature is verified, the software update is installed. If the signature does not verify,
the software update installation fails / aborts. The administrative guidance will instruct the customer to
download the update again or contact F5 support.
This functionality implements FPT_TUD_EXT.1.
7.6.4 Time Source
The TOE provides reliable time stamps for its own use, in particular in audit records and other time-
sensitive security functionality. For F5 devices and vCMP, the TOE hardware includes a hardware-
based clock and the TOE’s operating system makes the real-time clock available through a mcpd-
maintained time stamp. Administrators have the ability to set the hardware-based clock on F5 devices
and vCMP.
The security functions that rely on this time stamp in the evaluated configuration include:
• generation of audit records
• session locking for administrative users
• timeouts for remote sessions
• certificate validation / revocation
This functionality implements FPT_STM_EXT.1.
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 90
7.6.5 Preservation of Secure State and Trusted Recovery
The BIG-IP system is in a secure state when the DRBG and integrity tests pass, the remote audit
server is available, and the BIG-IP can connect to the remote audit server.
During the BIG-IP system boot-up sequence, the cryptographic module performs power-up self-tests,
including DRBG and integrity tests. BIG-IP performs continuous random number generator tests. BIG-
IP runs software integrity tests (detecting unauthorized changes) during power up and reboots. When
BIG-IP detects a DRBG or integrity failure, the BIG-IP system reboots to prohibit any further
cryptographic operations. During the boot-up sequence, the cryptographic module performs power-up
self-tests and conditional self-tests to ensure that the module is functioning properly. If the self-test
fails, the configured threshold number of times (the default is three), the BIG-IP system enters an Error
state by halting the system. If the BIG-IP is in an Error state that caused the system to halt, BIG-IP must
be booted to another volume or reinstalled to recover and reload the configuration.
BIG-IP periodically checks the availability of the external audit server. If the remote audit server is
unavailable, BIG-IP stores the audit records locally on disk and attempts to reconnect with the remote
audit server within seconds of each failed attempt. In addition, while the remote server is unavailable,
BIG-IP collects the audit records in a buffer. If the connection to the remote audit server is reestablished
before the buffer overflows, the audit records in the buffer are sent to the remote audit server and no
audit records are lost. If the buffer overflows before the connection to the remote audit server is
reestablished, BIG-IP enters a degraded state in which traffic processing is halted and only auditable
actions by the Security Administrator are allowed.
This functionality implements FPT_FLS.1, FPT_RCV.1.
7.6.6 Key Protection
The following different types of keys are stored on the TOE:
• embedded CA’s private and pubic key
• public and private key of forged server certificate
• TLS RSA private and public key,
• TLS ECDSA private and public key
• TLS EC Diffie-Hellman private and public key
• TLS pre-master secret and master secret
• TLS session keys
• SSH shared secrets (session keys)
• SSH EC Diffie-Hellman private key
• SSH RSA private key
• SSH ECDSA private key
In the CC evaluated configuration, the system is in appliance mode. Appliance mode disables root
access to the TOE operating system and disables bash shell. None of the private or secret keys can be
exported, modified, or deleted; only the public keys can be exported using the Configuration utility
(web-based GUI). The keys are protected using file system permissions.
This functionality implements FPT_KST_EXT.1 and FPT_KST_EXT.2.
7.7 TOE Access
For interactive user authentication at the web-based Configuration utility via HTTPS and the
command line tmsh via SSH or the serial port console, BIG-IP implements the display of
administrator-defined banners to users.
This functionality implements FTA_TAB.1.
The TOE terminates local and remote administrative user sessions (Console, Configuration Utility or
tmsh) after an administrator-defined period of inactivity. Users can also actively terminate their
sessions (log out).
F5 BIG-IP 16.1.3.1 SSLO ST December 22, 2023
ã 2023 F5, Inc. All Rights Reserved. 91
This functionality implements FTA_SSL_EXT.1, FTA_SSL.3.
Lastly, administrators are able to actively terminate these sessions (i.e., to log out and therefore close
an authenticated session).
This functionality implements FTA_SSL.4.
7.8 Trusted Path/Channels
The TOE acts as the TLS client when communicating with audit servers for the protection of audit
records sent from the TOE to an external audit server. As described in Section 7.4.2, the TOE is
configured to require a mutually authenticated connection with the external audit server. The external
audit server provides a certificate to the TOE during establishment of the TLS connection in order to
authenticate the external audit server.
This functionality implements FTP_ITC.1.
Network administrators connect to the TOE remotely via a dedicated network interface to administer
the TOE. Administrators are authenticated locally by user name and password; remote authentication
(via LDAP or AD) is not supported by the TOE. The TOE implements the following trusted paths,
which are logically distinct from other communication paths and provide assured identification of both
end points, as well as protecting the transmitted data from disclosure and providing detection of
modification of the transmitted data:
• TLS Connections to the TOE via the web-based Configuration utility, iControl API and the
iControl REST API are protected by TLS. TLS sessions are limited to TLS versions 1.1 and
1.2, using the cipher suites identified in FCS_TLSS_EXT.1[3]-[4].
• SSH Connections to the TOE's command line interface are protected using SSH version 2 as
defined in FCS_SSHS_EXT.1. Additionally, the SSH implementation has hard-coded ecdh-
sha2-nistp256 and ecdh-sha2-nistp384 key exchange; diffie-hellman-group1-sha1 key
exchange is intentionally disabled.
This functionality implements FTP_TRP.1/Admin.