© 2026 F5, Inc. All Rights Reserved.
F5 BIG-IP®
17.5.0 including SSLO
Security Target
Document Number: CC2024-ASE_ST-003
Document Version: 17.61
Date: April 17, 2026
Prepared By:
Saffire Systems
Carmel, IN 46032
Prepared For:
F5, Inc.
801 Fifth Avenue
Seattle, WA 98104
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 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.2.1.1 Physical Network Devices ................................................................................................................................ 2
1.2.1.2 Virtual Network Devices................................................................................................................................... 3
1.3 DOCUMENT TERMINOLOGY..............................................................................................................................5
1.3.1 ST Specific Terminology ........................................................................................................................5
1.3.2 Acronyms ...............................................................................................................................................6
1.4 TOE TYPE........................................................................................................................................................6
1.5 TOE OVERVIEW...............................................................................................................................................6
1.6 TOE DESCRIPTION ...........................................................................................................................................8
1.6.1 Introduction ...........................................................................................................................................8
1.6.2 Architecture Description........................................................................................................................8
1.6.3 Physical Boundaries ............................................................................................................................12
1.6.3.1 Physical boundaries......................................................................................................................................... 12
1.6.3.2 Guidance Documentation................................................................................................................................ 13
1.6.4 Logical Boundaries..............................................................................................................................14
1.6.4.1 Security Audit ................................................................................................................................................. 15
1.6.4.2 Cryptographic Support.................................................................................................................................... 15
1.6.4.3 Identification and Authentication.................................................................................................................... 17
1.6.4.4 Security Management...................................................................................................................................... 17
1.6.4.5 Protection of the TSF ...................................................................................................................................... 17
1.6.4.6 TOE access...................................................................................................................................................... 17
1.6.4.7 Trusted Path/Channels..................................................................................................................................... 18
1.6.4.8 User Data Protection ....................................................................................................................................... 18
1.6.5 Delivery ...............................................................................................................................................19
1.6.5.1 F5 Devices ...................................................................................................................................................... 19
1.6.5.2 Documentation................................................................................................................................................ 19
2 CONFORMANCE CLAIMS ..........................................................................................................................20
2.1 CC CONFORMANCE CLAIMS ..........................................................................................................................20
2.2 PP AND PACKAGE CLAIMS .............................................................................................................................20
2.3 CONFORMANCE RATIONALE ..........................................................................................................................22
3 SECURITY PROBLEM DEFINITION.........................................................................................................23
3.1 THREAT ENVIRONMENT .................................................................................................................................23
3.2 THREATS........................................................................................................................................................24
3.3 ORGANISATIONAL SECURITY POLICIES..........................................................................................................26
3.4 ASSUMPTIONS ................................................................................................................................................27
4 SECURITY OBJECTIVES.............................................................................................................................29
4.1 SECURITY OBJECTIVES FOR THE TOE ............................................................................................................29
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT.....................................................................30
5 EXTENDED COMPONENTS DEFINITION...............................................................................................32
6 SECURITY REQUIREMENTS .....................................................................................................................34
6.1 CONVENTIONS................................................................................................................................................36
6.2 SECURITY FUNCTIONAL REQUIREMENTS .......................................................................................................36
6.2.1 Security Audit (FAU) ...........................................................................................................................36
6.2.1.1 FAU_GCR_EXT.1 Generation of Certificate Repository............................................................................... 36
6.2.1.2 FAU_GEN.1 Audit Data Generation - Mandatory.......................................................................................... 36
6.2.1.3 FAU_GEN.1/STIP Audit Data Generation (STIP).......................................................................................... 39
6.2.1.4 FAU_GEN.2 User Identity Association - Mandatory...................................................................................... 40
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. ii
6.2.1.5 FAU_STG.1 Protected Audit Trail Storage - Optional ................................................................................... 41
6.2.1.6 FAU_STG.4 Prevention of Audit Data Loss................................................................................................... 41
6.2.1.7 FAU_STG_EXT.1 Protected Audit Event Storage - Mandatory..................................................................... 41
6.2.1.8 FAU_STG_EXT.3 Action in case of possible audit data loss - Optional........................................................ 41
6.2.2 Cryptographic Support (FCS)..............................................................................................................41
6.2.2.1 FCS_CKM.1 Cryptographic Key Generation - Mandatory............................................................................. 41
6.2.2.2 FCS_CKM.2 Cryptographic Key Establishment - Mandatory........................................................................ 42
6.2.2.3 FCS_CKM.4 Cryptographic Key Destruction - Mandatory............................................................................ 42
6.2.2.4 FCS_COP.1/DataEncryption Cryptographic operation (AES Data Encryption/Decryption) - Mandatory ..... 42
6.2.2.5 FCS_COP.1/SigGen Cryptographic operation (Signature Generation and Verification) - Mandatory ........... 43
6.2.2.6 FCS_COP.1/Hash Cryptographic operation (Hash Algorithm) - Mandatory.................................................. 43
6.2.2.7 FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash Algorithm) - Mandatory ............................ 43
6.2.2.8 FCS_COP.1/STIP Cryptographic operation (Data Encryption/Decryption in Support of STIP) .................... 43
6.2.2.9 FCS_HTTPS_EXT.1 HTTPS Protocol - Selection ......................................................................................... 44
6.2.2.10 FCS_NTP_EXT.1 NTP Protocol - Selection................................................................................................... 44
6.2.2.11 FCS_RBG_EXT.1 Random Bit Generation - Mandatory ............................................................................... 44
6.2.2.12 FCS_SSH_EXT.1 SSH Protocol – Selection .................................................................................................. 44
6.2.2.13 FCS_SSHS_EXT.1 SSH Protocol - Server – Selection................................................................................... 45
6.2.2.14 FCS_STG_EXT.1 Cryptographic Key Storage............................................................................................... 45
6.2.2.15 FCS_TLSC_EXT.1 TLS Client Protocol - Selection...................................................................................... 45
6.2.2.16 FCS_TLSC_EXT.2 TLS Client support for mutual authentication - Optional................................................ 47
6.2.2.17 FCS_TLSS_EXT.1[1] TLS Server Protocol (Data Plane Server) - Selection ................................................. 47
6.2.2.18 FCS_TLSS_EXT.1[2] TLS Server Protocol (Control Plane Server) - Selection............................................. 49
6.2.2.19 FCS_TTTC_EXT.1 Thru-Traffic TLS Inspection Client Protocol.................................................................. 49
6.2.2.20 FCS_TTTC_EXT.4 STIP Client-Side Support for Renegotiation................................................................... 51
6.2.2.21 FCS_TTTC_EXT.5 Thru-Traffic TLS Inspection Client Support for Supported Groups Extension .............. 51
6.2.2.22 FCS_TTTS_EXT.1 Thru-Traffic TLS Inspection Server Protocol ................................................................. 51
6.2.2.23 FCS_TTTS_EXT.4 STIP Server-Side Support for Renegotiation .................................................................. 53
6.2.3 User Data Protection (FDP) ...............................................................................................................53
6.2.3.1 FDP_CER_EXT.1 Certificate Profiles for Server Certificates........................................................................ 53
6.2.3.2 FDP_CER_EXT.2 Certificate Request Matching of Server Certificates......................................................... 55
6.2.3.3 FDP_CER_EXT.3 Certificate Issuance Rules for Server Certificates............................................................. 55
6.2.3.4 FDP_CSIR_EXT.1 Certificate Status Information Required .......................................................................... 55
6.2.3.5 FDP_PPP_EXT.1 Plaintext Processing Policy................................................................................................ 55
6.2.3.6 FDP_PRC_EXT.1 Plaintext Routing Control ................................................................................................. 56
6.2.3.7 FDP_RIP.1 Subset Residual Information Protection....................................................................................... 56
6.2.3.8 FDP_STG_EXT.1 Certificate Data Storage.................................................................................................... 56
6.2.3.9 FDP_STIP_EXT.1 SSL/TLS Inspection Proxy Functions .............................................................................. 56
6.2.3.10 FDP_TEP_EXT.1 SSL/TLS Inspection Proxy Policy..................................................................................... 57
6.2.4 Identification and Authentication (FIA)...............................................................................................59
6.2.4.1 FIA_AFL.1 Authentication Failure Management - Selection ......................................................................... 59
6.2.4.2 FIA_ENR_EXT.1 Certifícate Enrollment ....................................................................................................... 59
6.2.4.3 FIA_PMG_EXT.1 Password Management - Selection ................................................................................... 59
6.2.4.4 FIA_UAU.7 Protected Authentication Feedback - Selection.......................................................................... 59
6.2.4.5 FIA_UIA_EXT.1 User Identification and Authentication - Mandatory.......................................................... 59
6.2.4.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation - Selection ................................................................... 60
6.2.4.7 FIA_X509_EXT.1/STIP Certificate Validation (STIP) .................................................................................. 60
6.2.4.8 FIA_X509_EXT.2 X.509 Certificate Authentication - Selection.................................................................... 61
6.2.4.9 FIA_X509_EXT.2/STIP X.509 Certificate Authentication............................................................................. 61
6.2.4.10 FIA_X509_EXT.3 X.509 Certificate Requests - Selection............................................................................. 62
6.2.5 Security Management (FMT)...............................................................................................................62
6.2.5.1 FMT_MOF.1/ManualUpdate Management of security functions behavior - Mandatory................................ 62
6.2.5.2 FMT_MOF.1/Services Management of security functions behavior - Selection ............................................ 62
6.2.5.3 FMT_MOF.1/STIP Management of security functions behavior.................................................................... 62
6.2.5.4 FMT_MTD.1/CoreData Management of TSF Data - Mandatory.................................................................... 63
6.2.5.5 FMT_MTD.1/CryptoKeys Management of TSF Data - Selection .................................................................. 63
6.2.5.6 FMT_SMF.1 Specification of Management Functions - Mandatory............................................................... 63
6.2.5.7 FMT_SMF.1/STIP Specification of Management Functions (STIP) .............................................................. 63
6.2.5.8 FMT_SMR.2 Restrictions on security roles - Mandatory ............................................................................... 64
6.2.5.9 FMT_SMR.2/STIP Restrictions on security roles (STIP) ............................................................................... 64
6.2.6 Protection of TSF (FPT)......................................................................................................................64
6.2.6.1 FPT_APW_EXT.1 Protection of Administrator Passwords - Selection.......................................................... 64
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. iii
6.2.6.2 FPT_FLS.1 Failure with Preservation of Secure State.................................................................................... 65
6.2.6.3 FPT_KST_EXT.1 No Plaintext Key Export ................................................................................................... 65
6.2.6.4 FPT_KST_EXT.2 TSF Key Protection........................................................................................................... 65
6.2.6.5 FPT_RCV.1 Manual Trusted Recovery .......................................................................................................... 65
6.2.6.6 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) - Mandatory ......................... 65
6.2.6.7 FPT_STM_EXT.1 Reliable Time Stamps - Mandatory .................................................................................. 65
6.2.6.8 FPT_TST_EXT.1 TSF Testing - Mandatory................................................................................................... 65
6.2.6.9 FPT_TUD_EXT.1 Trusted Update - Mandatory............................................................................................. 66
6.2.7 TOE Access (FTA) ...............................................................................................................................66
6.2.7.1 FTA_SSL.3 TSF-initiated Termination - Mandatory...................................................................................... 66
6.2.7.2 FTA_SSL.4 User-initiated Termination - Mandatory ..................................................................................... 66
6.2.7.3 FTA_SSL_EXT.1 TSF-initiated Session Locking - Selection ........................................................................ 66
6.2.7.4 FTA_TAB.1 Default TOE Access Banners - Mandatory................................................................................ 66
6.2.8 Trusted path/channels (FTP)...............................................................................................................66
6.2.8.1 FTP_ITC.1 Inter-TSF trusted channel - Mandatory........................................................................................ 66
6.2.8.2 FTP_TRP.1/Admin Trusted Path - Mandatory................................................................................................ 67
6.3 TOE SECURITY ASSURANCE REQUIREMENTS ................................................................................................67
6.4 SECURITY REQUIREMENTS RATIONALE .........................................................................................................68
6.4.1 Security Functional Requirement Dependencies .................................................................................68
7 TOE SUMMARY SPECIFICATION ............................................................................................................69
7.1 SECURITY AUDIT ...........................................................................................................................................69
7.1.1 Audit Generation .................................................................................................................................69
7.1.2 Audit Storage .......................................................................................................................................70
7.1.3 Certificate Repository..........................................................................................................................71
7.2 CRYPTOGRAPHIC SUPPORT.............................................................................................................................71
7.2.1 Key Generation and Establishment .....................................................................................................72
7.2.2 Zeroization of Critical Security Parameters........................................................................................72
7.2.3 Cryptographic operations in the TOE .................................................................................................76
7.2.4 Random Number Generation...............................................................................................................77
7.2.5 SSH ......................................................................................................................................................78
7.2.6 TLS Protocol........................................................................................................................................79
7.2.6.1 TLS Client....................................................................................................................................................... 80
7.2.6.2 TLS Server...................................................................................................................................................... 80
7.2.7 HTTPS Protocol...................................................................................................................................81
7.2.8 NTP Protocol.......................................................................................................................................81
7.2.9 Thru-Traffic TLS Inspection ................................................................................................................82
7.2.9.1 Thru-Traffic TLS Inspection Client Protocol.................................................................................................. 82
7.2.9.2 Thru-Traffic TLS Inspection Server Protocol ................................................................................................. 83
7.3 USER DATA PROTECTION...............................................................................................................................85
7.3.1 Forged Certificate Issuance.................................................................................................................85
7.3.2 Residual Information Protection..........................................................................................................86
7.3.3 Certificate Data Storage......................................................................................................................86
7.3.4 TLS Establishment Policy ....................................................................................................................86
7.3.5 Plaintext Processing and Routing........................................................................................................89
7.3.6 SSL/TLS Inspection Proxy Functions...................................................................................................90
7.4 IDENTIFICATION AND AUTHENTICATION........................................................................................................90
7.4.1 Password policy and user lockout .......................................................................................................91
7.4.2 Certificate Enrollment .........................................................................................................................92
7.4.3 Certificate Validation ..........................................................................................................................92
7.4.4 Thru-Traffic Processing Certificate Validation...................................................................................93
7.5 SECURITY FUNCTION MANAGEMENT.............................................................................................................93
7.5.1 Security Roles ......................................................................................................................................95
7.6 PROTECTION OF THE TSF...............................................................................................................................98
7.6.1 Protection of Sensitive Data ................................................................................................................98
7.6.2 Self-tests...............................................................................................................................................98
7.6.3 Update Verification..............................................................................................................................98
7.6.4 Time Source .........................................................................................................................................99
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. iv
7.6.5 Preservation of Secure State and Trusted Recovery............................................................................99
7.6.6 Key Protection ...................................................................................................................................100
7.7 TOE ACCESS................................................................................................................................................100
7.8 TRUSTED PATH/CHANNELS..........................................................................................................................101
List of Tables
Table 1: Supported Physical Network Devices.............................................................................................3
Table 2: Supported Virtual Network Devices...............................................................................................5
Table 3: Guidance Documentation .............................................................................................................14
Table 4: Security Functional Requirements................................................................................................35
Table 5: Security Functional Requirements and Auditable Events............................................................39
Table 6: STIP Security Functional Requirements and Auditable Events ..................................................40
Table 7: Management Functions and Privileges.........................................................................................63
Table 8: Security Assurance Requirements ...............................................................................................68
Table 9: Audit Logs and Their Content ......................................................................................................70
Table 10: Key generation in the TOE.........................................................................................................72
Table 11: Zeroization of Critical Security Parameters................................................................................75
Table 12: Cryptographic primitives in the TOE .........................................................................................77
Table 13: SSH Algorithms..........................................................................................................................78
Table 14: TLS v1.2 Ciphersuites ................................................................................................................79
Table 15: TLS Server Error Alerts..............................................................................................................84
Table 16: BIG-IP Management Functions per interface.............................................................................94
Table 17: BIG-IP User Roles......................................................................................................................97
List of Figures
Figure 1: BIG-IP Subsystems for F5 iSeries and VIPRION Devices in Application Delivery Controller
Deployments ........................................................................................................................................9
Figure 2: BIG-IP Subsystems for F5 rSeries and VELOS Devices in Application Delivery Controller
Deployments ......................................................................................................................................10
Figure 3: Architectural aspects of BIG-IP – F5 iSeries and VIPRION Devices in Application Delivery
Controller Deployments.....................................................................................................................11
Figure 4: Architectural aspects of BIG-IP – F5 rSeries and VELOS Devices in Application Delivery
Controller Deployments.....................................................................................................................12
Figure 5: BIG-IP SSLO Traffic ..................................................................................................................16
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 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 17.5.0 including SSLO Security Target
Version: 17.61
Publication Date: April 17, 2026
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 17.5.0 including SSLO (Build
Hotfix-BIGIP-17.5.0.0.190.15-ENG, also referred to as 17.5) running on any of the devices identified in
Section 1.2.1.
BIG-IP runs in two different environments:
• A physical Network Device (pND) running directly on the iSeries or VIPRION hardware
• A virtual network device (vND) running as a tenant on F5OS running on rSeries or VELOS
hardware
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
BIG-IP runs in two different environments on F5 devices. BIG-IP operates as a physical Network Device
(pND) running directly on the iSeries or VIPRION hardware. BIG-IP operates as a virtual Network
Device (vND) running as a tenant on F5OS on the rSeries or VELOS hardware.
The following provides an explanation of table columns in the F5 devices tables below.
SKU (stock-keeping unit). A set of product SKUs define the hardware and software that is licensed and
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 2
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).
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.
1.2.1.1 Physical Network Devices
When BIG-IP is running directly on the iSeries or VIPRION hardware, the TOE consists of any of the
hardware appliances listed in Table 1 installed with LTM+SSLO with appliance mode software.
SKU Part # Model Series
iSeries
F5-BIG-LTM-I15600
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
500-0042-00 i15000
F5-BIG-LTM-I15800
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
500-0042-00 i15000
F5-BIG-LTM-I15820-DF
F5-ADD-BIG-SSLO-5
F5-ADD-BIG-MODE
500-0043-00 I15000-DF
VIPRION
F5-VPR-LTM-C2400-AC
F5-VPR-LTM-B2250
F5-ADD-VPR-SSLOC2X00
F5-ADD-BIG-MODE
F5-ADD-VPR-VCMP-2400
400-0028-12
400-0039-03
C2400
B2250
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 3
SKU Part # Model Series
F5-VPR-LTM-C4480-AC
F5-VPR-LTM-B4450
F5-ADD-VPR-SSLOC44X0
F5-ADD-BIG-MODE
F5-ADD-VPR-VCMP-4480
400-0033-04
400-0053-11
C4480
B4450
Table 1: Supported Physical Network Devices
Each of the hardware platforms includes a third party proprietary cryptographic acceleration card. All
iSeries hardware platforms and the VIPRION B4450 include the Intel Coleto Creek (8955). The
VIPRION B2250 model includes the Cavium Nitrox (CN3540-500-C20).
1.2.1.2 Virtual Network Devices
When BIG-IP is running as a tenant on F5OS running on rSeries or VELOS hardware, the TOE runs on
any of the hardware appliances listed in Table 2 installed with LTM+SSLO with appliance mode
software.
SKU Part # Model Series
rSeries
F5-BIG-LTM-R4600
F5-ADD-BIG-SSLOR4XXX
F5-ADD-BIG-MODE
200-0417-03 R4000
F5-BIG-LTM-R4800
F5-ADD-BIG-SSLOR4XXX
F5-ADD-BIG-MODE
200-0417-03 R4000
F5-BIG-LTM-R5600
F5-ADD-BIG-SSLOR5XXX
F5-ADD-BIG-MODE
200-0411-03 R5000
F5-BIG-LTM-R5800
F5-ADD-BIG-SSLOR5XXX
F5-ADD-BIG-MODE
200-0411-03 R5000
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 4
SKU Part # Model Series
F5-BIG-LTM-R5900
F5-ADD-BIG-SSLOR5XXX
F5-ADD-BIG-MODE
200-0411-03 R5000
F5-BIG-LTM-R5920-DF
F5-ADD-BIG-SSLOR5XXX
F5-ADD-BIG-MODE
200-0421-03 R5000
F5-BIG-LTM-R10600
F5-ADD-BIGSSLOR10XXX
F5-ADD-BIG-MODE
200-0413-05 R10000
F5-BIG-LTM-R10800
F5-ADD-BIGSSLOR10XXX
F5-ADD-BIG-MODE
200-0411-05 R10000
F5-BIG-LTM-R10900
F5-ADD-BIGSSLOR10XXX
F5-ADD-BIG-MODE
200-0411-05 R10000
F5-BIG-LTM-R10920-DF
F5-ADD-BIGSSLOR10XXX
F5-ADD-BIG-MODE
200-0420-02 R10000
F5-BIG-SSLO-R12600DS 200-0424-03 r12000
F5-BIG-SSLO-R12800DS 200-0424-03 r12000
F5-BIG-SSLO-R12900DS 200-0424-03 r12000
VELOS
F5-VEL-LTM-BX110
F5-VEL-CX410-AC
F5-ADDVELSSLOCX410
400-0086-04
400-0096-00
BX110
CX410
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 5
SKU Part # Model Series
F5-VEL-LTM-BX520
F5-VEL-CX410-AC
F5-ADDVELSSLOCX410
400-0093-03
400-0096-00
BX520
CX410
F5-VEL-LTM-BX520
F5-VEL-CX1610-AC
F5-ADDVELSSLOCX1610
400-0093-03
400-0091-05
BX520
CX1610
Table 2: Supported Virtual Network Devices
Each of the hardware platforms includes a third party proprietary cryptographic acceleration card. The
rSeries and VELOS models include Intel QAT.
Note that BIG-IP on the rSeries and VELOS hardware platforms does not run directly on the hardware
but on a platform layer – F5OS-A 1.5.3 for all rSeries models except the r12000, F5OS-A 1.8.0 for all
ofthe rSeries models, and F5OS-C 1.8.1 for VELOS. The hardware appliances and platform layer are part
of the Virtualization System (VS) included in the TOE environment.
The VELOS hardware platforms consist of one or two chassis controllers and one or more blades. The
hypervisor runs on the chassis controller(s) and the tenants run on the blades.
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 6
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
SSLO SSL Orchestrator
SOAP Simple Object Access Protocol
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
VE Virtual Edition
1.4 TOE Type
The TOE type is a Networking Device. When running on iSeries and VIPRION devices, the TOE is a
physical Network Device. When running on F5OS on rSeries or VELOS devices, the TOE is a virtual
Network Device.
1.5 TOE Overview
The TOE is a standalone TOE consisting of a single component (i.e., it is not a distributed TOE). When
running on iSeries and VIPRION devices, the TOE consists of the BIG-IP software and the iSeries or
VIPRION hardware devices. When running on F5OS on rSeries or VELOS devices, the TOE is
represented by the virtual network device alone and does not include the virtualization system.
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, or hardware and platform layer, provided by F5
listed in Section 1.2.1.
The TOE is located between a monitored client and a requested server enabling the TOE to intercept TLS
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 7
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 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,
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 8
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
• 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. The cryptographic
functionality implemented in the TOE is provided by OpenSSL.
The TOE is divided into the following subsystems:
• F5 Device Hardware,
• F5 platform layer for rSeries or VELOS devices,
• Traffic Management Operating System (TMOS),
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 9
• 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. 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.
Figure 1: BIG-IP Subsystems for F5 iSeries and VIPRION Devices in Application Delivery
Controller Deployments
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 10
Figure 2: BIG-IP Subsystems for F5 rSeries and VELOS Devices in Application Delivery
Controller Deployments
TMOS is a Linux operating system that runs directly on device hardware or directly on the platform layer.
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.
• 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 11
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 3 and Figure 4. 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 3 and Figure 4.
Figure 3: Architectural aspects of BIG-IP – F5 iSeries and VIPRION Devices in Application
Delivery Controller Deployments
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 12
Figure 4: Architectural aspects of BIG-IP – F5 rSeries and VELOS Devices 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
BIG-IP version 17.5 is the software component of the TOE. When BIG-IP version 17.5 is running on one
of the F5 iSeries and VIPRION devices identified in Section 1.2.1.1, the TOE is a physical Network
Device and includes hardware and software physical components as identified in Section 1.2.1.1.
When BIG-IP version 17.5 runs on one of the F5 rSeries and VELOS devices, the TOE is a virtual
Network Device, includes only software, and the Virtualization System includes hardware and platform
layer components as identified in Section 1.2.1.2.
The evaluated configuration of BIG-IP Version 17.5.0 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 13
The following required components can be found in the operating environment of the TOE on systems other
than those hosting the TOE:
• 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
K000149875: Common Criteria Certification for BIG-IP 17.5.0
BIG-IP Common Criteria Evaluation Configuration Guide BIG-IP Release 17.5.0 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
F5 SSL Orchestrator Deployment Guide - Version 11
F5 Secure Vault: Administration
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 – 17.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 – 17.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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 14
K48615077: BIG-IP Daemons (15.x – 17.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
K7752: Licensing the BIG-IP system
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)
K01770517: Configuring the cipher strength for SSL profiles (14.x - 17.x )
K14120: Define advanced NTP configurations on the BIG-IP system (11.x - 17.x)
K34556595: Managing login failures for a local user account on the BIG-IP system
Hotfix-BIGIP-17.5.0.0.190.15-ENG.readme
Traffic Management Shell (tmsh) Reference Guide (versions 17.0.0 and 12.0.01
)
Platform-specific References – Hardware
Platform Guide: i2000/i4000 Series
Platform Guide: i5000/i7000/i10000/i11000 Series
Platform Guide: i15000 Series
Platform Guide: r2000/r4000 Series
Platform Guide: r5000/r10000 Series
Platform Guide: VELOS CX Series
Platform Guide: VIPRION® 2200
Platform Guide: VIPRION® 4400 Series
Table 3: 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
1
The tmsh reference guide version 17.x zipfile contains the pages for each of the tmsh commands. The 12.0.0 pdf
contains additional general information that is still valid in 17.x but not reproduced in the 17.x zipfile.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 15
• 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.
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)
o Remote (i.e., SSH) access to the Lights Out / Always On Management2
capabilities of the
system is disabled. (applicable to F5 devices)
o TLS v1.1
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 older 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.
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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 16
For TLS sessions, the TOE implements certificate validation using the OpenSSL crypto library. Time
synchronization with an NTP server uses SHA-1 message digests to verify the integrity of the NTP packets.
The TOE utilizes cryptographic algorithms that have been validated using the NIST ACVP tests.
For F5 devices, 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, 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, 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
• 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 5: BIG-IP SSLO Traffic
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 17
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.
• 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. Time is provided by a
local real-time clock managed by either the Security Administrator setting the time or synchronizing with
an NTP server.
1.6.4.6 TOE access
The TOE implements session inactivity time-outs for Configuration utility and tmsh sessions and displays
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 18
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
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 and ecdsa-sha2-
nistp384
• The transport data integrity algorithm is limited to 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 19
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
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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 20
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_NDcPP-
STIP_V2.0), Version 2.0, 2024-04-25
CFG_NDcPP-STIP_V2.0 consists of the following components:
• collaborative Protection Profile for Network Devices (NDcPP), Version 3.0e, 06-December-2023
• PP-Module for SSL/TLS Inspection Proxy (STIPM), Version 1.1, 2022-11-17
The ST is compliant with the following NDcPP technical decisions:
NIAP TD Applicability
TD0990 - NIT Technical Decision: CTR_DRBG in
FCS_RBG_EXT.1.2
Applicable
TD0923 - NIT Technical Decision: Auditable event for
FAU_STG_EXT.1 in FAU_GEN.1.2
Applicable
TD0921 - NIT Technical Decision: Addition of FIPS PUB 186-5
and Correction of Assignment
Applicable
TD0900 - NIT Technical Decision: Clarification to Local
Administrator Access in FIA_UIA_EXT.1.3
Applicable
TD0899 - NIT Technical Decision: Correction of Renegotiation
Test for TLS 1.2
Applicable
TD0886 - Clarification to FAU_STG_EXT.1 Test 6 Applicable.
TD0880 - NIT Decision: Removal of Duplicate Selection in
FMT_SMF.1.1
Applicable.
TD0879 - NIT Decision: Correction of Chapter Headings in
CPP_ND_V3.0E
Applicable.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 21
NIAP TD Applicability
TD0868 - NIT Technical Decision: Clarification of time frames
in FCS_IPSEC_EXT.1.7 and FCS_IPSEC_EXT.1.8
Not applicable. The TOE does not
claim FCS_IPSEC_EXT.1.
TD0836 - NIT Technical Decision: Redundant Requirements in
FPT_TST_EXT.1
Applicable.
The ST is compliant with the following STIPM TDs:
STIPM Technical Decision Applicability
TD0831 - Aligning MOD_STIP 1.1 with NDcPP 3.0E Applicable.
TD0808 - Clarification on EKU Fields for FIA_X509_EXT.1/STIP Applicable.
TD0774 – Correction to Supported Cipher Suite in
FCS_TTTC_EXT.1.1 and FCS_TTTS_EXT.1.1
Applicable.
TD0741 – Arbitrary Ciphers in FCS_TTTC/S_EXT Applicable.
The ST claims exact conformance to the following packages:
• Functional Package for Secure Shell (SSH) (PKG_SSH), Version 1.0, 2021-05-13
The ST is compliant with the following SSH technical decisions:
NIAP TD Applicability
TD0967 - Allowance of Kex-strict in PKG_SSH_V1.0 Applicable
TD0909 - Updates to FCS_SSH_EXT.1.1 App Note in SSH FP 1.0 Applicable.
TD0777 - Clarification to Selections for Auditable Events for
FCS_SSH_EXT.1
Applicable.
TD0732 - FCS_SSHS_EXT.1.3 Test 2 Update Applicable.
TD0695 - Choice of 128 or 256 bit size in AES-CTR in SSH
Functional Package
Applicable.
TD0682 - Addressing Ambiguity in FCS_SSHS_EXT.1 Tests Applicable.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 22
The ST was also evaluated against the individual evaluation activities
• Evaluation Activities for Network Device cPP, Version 3.0e, 06-December-2023
• Supporting Document Mandatory Technical Document PP-Module for SSL/TLS Inspection
Proxy, Version 1.1, 2022-11-17
• Evaluation activities found in PKG_SSH.
2.3 Conformance Rationale
The ST claims exact conformance to the CFG_NDcPP-STIP_V2.0 and PKG_SSH V1.0.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 23
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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 24
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. 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
tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly
designed protocols or poor key management to successfully perform man-in-the-middle attacks,
replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the
critical network traffic, and potentially could lead to a compromise of the Network Device itself.
T.WEAK_AUTHENTICATION_ENDPOINTS
Threat agents may take advantage of secure protocols that use weak methods to authenticate the
endpoints – e.g., 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 25
T.UNDETECTED_ACTIVITY
Threat agents may attempt to access, change, and/or modify the security functionality of the
Network Device without Administrator awareness. This could result in the attacker finding an
avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the
Administrator would have no knowledge that the device has been compromised.
T.SECURITY_FUNCTIONALITY_COMPROMISE
Threat agents may compromise credentials and device data enabling continued access to the
Network Device and its critical data. The compromise of credentials includes replacing existing
credentials with an attacker’s credentials, modifying existing credentials, or obtaining the
Administrator or device credentials for use by the attacker. Threat agents may also be able to take
advantage of weak administrative passwords to gain privileged access to the device.
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 26
T.CREDENTIALS
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 Administrators 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 27
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 or interfere with the device’s physical
interconnections and correct operation. This protection is assumed to be sufficient to protect the
device and the data it contains. As a result, the cPP will not include any requirements on physical
tamper protection or other physical attack mitigations. The cPP will not expect the product to
defend against physical access to the device that allows unauthorized entities to extract data,
bypass other controls, or otherwise manipulate the device. 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).
If a virtual TOE evaluated as a pND, following Case 2 vNDs as specified in Section 1.2, the VS is
considered part of the TOE with only one vND instance for each physical hardware platform. The
exception being where components of a distributed TOE run inside more than one virtual
machine (VM) on a single VS. In Case 2 vND, no non-TOE guest VMs are allowed on the
platform.
The assumed functionality of the TOE includes the behavior needed to satisfy the functional
claims of STIPM.
A.NO_THRU_TRAFFIC_PROTECTION
A standard/generic Network Device does not provide any assurance regarding the protection of
traffic that traverses it. The intent is for the Network Device to protect data that originates on or is
destined to the device itself, to include administrative data and audit data. Traffic that is
traversing the Network Device, destined for another network entity, is not covered by the NDcPP.
It is assumed that this protection will be covered by cPPs 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).
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 28
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
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).
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 29
4 Security Objectives
This chapter describes 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 30
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
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 31
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.
Residual information is expanded to include information relevant to STIP operation (e.g. decrypted
SSL/TLS payload, ephemeral keys).
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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 32
5 Extended Components Definition
The extended components used in this ST are taken from the NDcPP, STIPM, and/or PKG_SSH.
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
Cryptographic Support (FCS)
FCS_HTTPS_EXT.1
FCS_NTP_EXT.1
FCS_RBG_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_X509_EXT.1/Rev
FIA_X509_EXT.2
FIA_X509_EXT.3
Protection of the TSF (FPT)
FPT_APW_EXT.1
FPT_SKP_EXT.1
FPT_STM_EXT.1
FPT_TST_EXT.1
FPT_TUD_EXT.1
TOE Access (FTA)
FTA_SSL_EXT.1
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 33
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
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
PKG_SSH defines the following extended security functional requirements (SFRs). Refer to the
PKG_SSH for the definition of these extended SFRs since they are not redefined in this ST.
Cryptographic Support (FCS)
FCS_SSH_EXT.1
FCS_SSHS_EXT.1
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 34
6 Security Requirements
The security requirements that are levied on the TOE are specified in this section of the ST. If the security
requirement includes “_EXT” at the end of the security requirement name, it is an extended security
requirement; otherwise it is taken from CC Part 2. The table below identifies the source of each claimed
security functional requirement (SFR). Each of the security requirements is drawn from NDcPP or
PKG_SSH .
TOE Security Functional Requirements
(from CC Part 2)
Source
FAU_GCR_EXT.1 Generation of Certificate Repository STIPM
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
FAU_STG_EXT.1 Protected Audit Event Storage NDcPP
FAU_STG_EXT.3 Action in case of Possible Audit Data Loss NDcPP
FCS_CKM.1 Cryptographic Key Generation NDcPP
FCS_CKM.2 Cryptographic Key Establishment NDcPP
FCS_CKM.4 Cryptographic Key Destruction NDcPP
STIPM
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
FCS_HTTPS_EXT.1 HTTPS Protocol NDcPP
FCS_NTP_EXT.1 NTP Protocol NDcPP
FCS_RBG_EXT.1 Random Bit Generation NDcPP
FCS_SSH_EXT.1 SSH Protocol PKG_SSH
FCS_SSHS_EXT.1 SSH Protocol - Server PKG_SSH
FCS_STG_EXT.1 Cryptographic Key Storage STIPM
FCS_TLSC_EXT.1 TLS Client Protocol NDcPP
FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication NDcPP
FCS_TLSS_EXT.1[1]-[2] TLS Server Protocol 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 35
TOE Security Functional Requirements
(from CC Part 2)
Source
FDP_PRC_EXT.1 Plaintext Routing Control STIPM
FDP_RIP.1 Subset Residual Information Protection 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_AFL.1 Authentication Failure Management NDcPP
FIA_ENR_EXT.1 Certificate Enrollment STIPM
FIA_PMG_EXT.1 Password Management NDcPP
FIA_UAU.7 Protected Authentication Feedback NDcPP
FIA_UIA_EXT.1 User Identification and Authentication NDcPP
FIA_X509_EXT.1/Rev X.509 Certificate Validation NDcPP
STIPM
FIA_X509_EXT.1/STIP Certificate Validation (STIP) STIPM
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 NDcPP
STIPM
FMT_MOF.1/ManualUpdate Management of Security Functions
Behavior/ManualUpdate
NDcPP
FMT_MOF.1/Services Management of Security Functions Behavior/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_APW_EXT.1 Protection of Administrator Passwords NDcPP
FPT_FLS.1 Failure with Preservation of Secure State STIPM
FPT_KST_EXT.1 No Plaintext Key Export STIPM
FPT_KST_EXT.2 TSF Key Protection STIPM
FPT_RCV.1 Manual Trust Recovery STIPM
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric
keys)
NDcPP
FPT_STM_EXT.1 Reliable Time Stamps NDcPP
FPT_TST_EXT.1 TSF Testing NDcPP
FPT_TUD_EXT.1 Trusted Update NDcPP
FTA_SSL.3 TSF-initiated Termination NDcPP
FTA_SSL.4 User-initiated Termination NDcPP
FTA_SSL_EXT.1 TSF-initiated Session Locking NDcPP
FTA_TAB.1 Default TOE Access Banners NDcPP
FTP_ITC.1 Inter-TSF Trusted Channel NDcPP
FTP_TRP.1/Admin Trusted Path NDcPP
Table 4: Security Functional Requirements
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 36
6.1 Conventions
The CC defines four operations on security functional requirements. The SFRs claimed in this ST
have been drawn from the NDcPP, STIPM, or PKG_SSH. The CC operations already performed
in the NDcPP, STIPM, or in the PKG_SSH are reproduced in plain text and not denoted in this
ST. Instead, the requirements have been copied from the NDcPP, STIPM, or PKG_SSH 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
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 - Mandatory
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 Administrator account shall be
logged if individual 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 Administrator account shall be
logged),
• starting and stopping services;
d) Specifically defined auditable events listed in Table 5.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 37
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 5.
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 Configuration of local
audit settings.
Identity of account
making changes to
the audit
configuration.
FAU_STG_EXT.3 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.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_HTTPS_EXT.1 Failure to establish a HTTPS Session Reason for failure.
FCS_NTP_EXT.1 • Configuration of a new time
server
• Removal of configured time
server.
Identity if new/removed time
server
FCS_RBG_EXT.1 None. None.
FCS_SSH_EXT.1 Failure to establish SSH connection Reason for failure and Non-
TOE endpoint of attempted
connection (IP Address)
Application Note: TD0777
applies to this Auditable
Event definition.
FCS_SSH_EXT.1 Establishment of SSH connection, Non-TOE endpoint of
connection (IP Address)
FCS_SSH_EXT.1 Termination of SSH connection Non-TOE endpoint of
connection (IP Address)
FCS_SSH_EXT.1 Dropping of packet(s) outside defined
size limits
Packet size
FCS_SSHS_EXT.1 None. None.
FCS_TLSC_EXT.1 Failure to establish a TLS Session Reason for failure.
FCS_TLSC_EXT.2 None. None.
FCS_TLSS_EXT.1[1]-[2] 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 38
Requirement Auditable Events Additional Audit Record
Contents
FIA_UAU.7 None. None.
FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
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/ManualUpdate Any attempt to initiate a manual
update
None.
FMT_MOF.1/Services None. 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_APW_EXT.1 None. None.
FPT_SKP_EXT.1 None. None.
FPT_STM_EXT.1 Discontinuous changes to time –
either Administrator actuated or
changed via an automated process.
(Note that no continuous changes to
time need to be logged. See also
application note on
FPT_STM_EXT.1 in the NDcPP.)
For discontinuous changes to
time: The old and new values
for the time.
Origin of the attempt to
change time for success and
failure (e.g., IP address).
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or failure)
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_SSL_EXT.1
(if “terminate the session” is
selected)
The termination of a local session by
the session lock.
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
• None
• None
• Reason for failure
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 39
Requirement Auditable Events Additional Audit Record
Contents
FTP_TRP.1/Admin • Initiation of the trusted path.
• Termination of the trusted path.
• Failure of the trusted path
functions.
• None
• None
• Reason for failure
Table 5: 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 6,
d. applicable auditable events defined in Auditable Events for Selection-based
Requriements table Table 6.
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 6,
d. additional information defined in applicable auditable events in Auditable Events
for Selection-based Requriements table Table 6,
e. additional information defined in Auditable Events table Table 6 for each
auditable event, where applicable.
Requirement Auditable Events Additional Audit Record
Contents
FAU_GCR_EXT.1 None. None.
FAU_STG.4 None. None.
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 40
Requirement Auditable Events Additional Audit Record
Contents
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
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 6: STIP Security Functional Requirements and Auditable Events
6.2.1.4 FAU_GEN.2 User Identity Association - Mandatory
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 41
6.2.1.5 FAU_STG.1 Protected Audit Trail Storage - Optional
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
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 - Mandatory
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 maintain a log file of audit records in the event that an interruption
of communication with the remote audit server occurs.
FAU_STG_EXT.1.4 The TSF shall be able to store persistent audit records locally with a minimum
storage size of 7 GB of audit storage.
FAU_STG_EXT.1.5 The TSF shall overwrite previous audit records according to the following rule:
log files are numbered and the older log file(s) is deleted when the local storage
space for audit data is full.
FAU_STG_EXT.1.6 The TSF shall provide the following mechanisms for administrative access to
locally stored audit records ability to view locally.
6.2.1.8 FAU_STG_EXT.3 Action in case of possible audit data loss - Optional
FAU_STG_EXT.3.1 The TSF shall generate a warning to inform the Administrator before the audit
trail exceeds the local audit trail storage capacity.
6.2.2 Cryptographic Support (FCS)
6.2.2.1 FCS_CKM.1 Cryptographic Key Generation - Mandatory
FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm:
• RSA schemes using cryptographic key sizes of 2048, 3072, 4096 bits that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix
B.3 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", A.1;
• ECC schemes using ‘NIST curves’ P-256, P-384 that meet the following: FIPS
PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4, or FIPS PUB
186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3,
“IT Security techniques - Digital signatures with appendix - Part 3: Discrete
logarithm based mechanisms”, Section 6.6.;
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 42
• FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special
Publication 800-56A Revision 3, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and RFC
7919.
ST Application Note: TD0921 applies to the SFR definition.
6.2.2.2 FCS_CKM.2 Cryptographic Key Establishment - Mandatory
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 8017, “Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2”;
• Elliptic curve-based key establishment schemes that meet the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”;
• FFC Schemes using “safe-prime” groups that meet the following: NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and groups
listed in RFC 7919.
6.2.2.3 FCS_CKM.4 Cryptographic Key Destruction - Mandatory
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 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 the EEPROM on F5 Devices, logically addresses the storage
location of the key and performs a single overwrite consisting of random
data;
o instructs a part of the TSF to destroy the abstraction that represents the key
that meets the following: no standard.
6.2.2.4 FCS_COP.1/DataEncryption Cryptographic operation (AES Data
Encryption/Decryption) - Mandatory
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 43
6.2.2.5 FCS_COP.1/SigGen Cryptographic operation (Signature Generation and
Verification) - Mandatory
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm
• RSA Digital Signature Algorithm,
• Elliptic Curve Digital Signature Algorithm
and cryptographic key sizes
• For RSA: modulus 2048, 3072, 4096 bits,
• For ECDSA: 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 or FIPS PUB 186-5, "Digital Signature
Standard (DSS)", Section 5.4 using PKCS #1 v2.2 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 implementing P-256, P-384 curves that meet the following:
FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix
D, Implementing “NIST Recommended curves”; or FIPS PUB 186-5, "Digital
Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1,
Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques -
Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms",
Section 6.6.
ST Application Note: TD0921applies to the SFR definition.
6.2.2.6 FCS_COP.1/Hash Cryptographic operation (Hash Algorithm) - Mandatory
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 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) -
Mandatory
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 44
6.2.2.9 FCS_HTTPS_EXT.1 HTTPS Protocol - Selection
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.
6.2.2.10 FCS_NTP_EXT.1 NTP Protocol - Selection
FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) NTP v4 (RFC 5905).
FCS_NTP_EXT.1.2 The TSF shall update its system time using
• Authentication using SHA1 as the message digest algorithm(s).
FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or multicast
addresses.
FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time sources in the
Operational Environment.
6.2.2.11 FCS_RBG_EXT.1 Random Bit Generation - Mandatory
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 F5 devices except 10000 series, one platform-based noise source for F5
10000 series devices 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”.
ST Application Note: TD0990 applies to the SFR definition.
6.2.2.12 FCS_SSH_EXT.1 SSH Protocol – Selection
FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a server in accordance with that
complies with RFCs 4251, 4252, 4253, 4254, 5656, 6668, 8332 and no other
standard.
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods:
• “password” (RFC 4252),
• “publickey” (RFC 4252):
o ecdsa-sha2-nistp256 (RFC 5656),
o ecdsa-sha2-nistp384 (RFC 5656),
and no other methods.
FCS_SSH_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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 45
FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the
following mechanisms:
aes128-ctr (RFC 4344),
aes256-ctr (RFC 4344),
aes128-cbc (RFC 4253),
aes256-cbc (RFC 4253),
and no other mechanisms.
FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion
using:
• hmac-sha2-256 (RFC 6668),
and no other mechanisms.
FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using:
• ecdh-sha2-nistp256 (RFC 5656),
• ecdh-sha2-nistp384 (RFC 5656),
and no other mechanisms.
FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in
• RFC 5656 (Section 4)
to derive the following cryptographic keys from a shared secret: session keys.
FCS_SSH_EXT.1.8 The TSF shall ensure that
• a rekey of the session keys,
occurs when any of the following thresholds are met: one hour connection time no
more than one gigabyte of transmitted data, or no more than one gigabyte of received
data.
ST Application Note: TD0909 applies to the SFR definition.
6.2.2.13 FCS_SSHS_EXT.1 SSH Protocol - Server – Selection
FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using:
• ecdsa-sha2-nistp256 (RFC 5656),
• ecdsa-sha2-nistp384 (RFC 5656).
6.2.2.14 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.15 FCS_TLSC_EXT.1 TLS Client Protocol - Selection
FCS_TLSC_EXT.1.1 The data plane of the TSF shall implement TLS 1.3 (RFC 8446), TLS 1.2 (RFC
5246) supporting the following ciphersuites:
• Supported ciphersuites for TLS 1.2 from List 1:
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 46
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
o TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 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_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
• Select supported ciphersuites for TLS 1.3 from List 2:
o TLS_AES_128_GCM_SHA256
o TLS_AES_256_GCM_SHA384
and no other ciphersuites.
FCS_TLSC_EXT.1.2 The data plane of the TSF shall verify that the presented identifier matches IPv4
address in the CN or in the SAN.
FCS_TLSC_EXT.1.3 The data plane of the TSF shall not establish a trusted channel if the server
certificate is invalid
• without any administrator override mechanism.
FCS_TLSC_EXT.1.4 The data plane of the TSF shall present the Supported Groups Extension with
the following curves/groups: secp256r1, secp384r1, ffdhe2048, ffdhe3072, ffdhe4096
and no other curves/groups in the Client Hello.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 47
FCS_TLSC_EXT.1.5 The data plane of the TSF shall
• present the signature_algorithms extension with support for the following
algorithms:
o rsa_pkcs1 with sha256(0x0401),
o rsa_pkcs1with sha384(0x0501),
o rsa_pkcs1 with sha512(0x0601),
o ecdsa_secp256r1 with sha256(0x0403),
o ecdsa_secp384r1 with sha384(0x0503),
o rsa_pss_rsae with sha256(0x0804),
o rsa_pss_rsae with sha384(0x0805),
o rsa_pss_rsae with sha512(0x0806),
and no other algorithms.
FCS_TLSC_EXT.1.6 The data plane of the TSF provides the ability to configure the list of supported
ciphersuites as defined in FCS_TLSC_EXT.1.1.
FCS_TLSC_EXT.1.7 The data plane of the TSF shall prohibit the use of the following extensions:
• Early data extension
• Post-handshake client authentication according to RFC 8446, Section 4.2.6.
FCS_TLSC_EXT.1.8 The data plane of the TSF shall not use PSKs.
FCS_TLSC_EXT.1.9 The data plane of the TSF shall support TLS 1.2 secure renegotiation through
use of the “renegotiation_info” TLS extension in accordance with RFC 5746, reject
TLS 1.3 renegotiation attempts.
6.2.2.16 FCS_TLSC_EXT.2 TLS Client support for mutual authentication - Optional
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.17 FCS_TLSS_EXT.1[1] TLS Server Protocol (Data Plane Server) - Selection
FCS_TLSS_EXT.1.1[1] The data plane of the TSF shall implement TLS 1.3 (RFC 8446), TLS
1.2 (RFC 5246) and reject all other TLS and SSL versions. The TLS implementation
will support the following ciphersuites:
• Select supported ciphersuites for TLS 1.2 from List 1:
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
8422
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
8422
o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 48
o TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
RFC 5289
o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 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_256_GCM_SHA384 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
• Select supported ciphersuites for TLS 1.3 from List 2:
o TLS_AES_128_GCM_SHA256
o TLS_AES_256_GCM_SHA384
and no other ciphersuites.
FCS_TLSS_EXT.1.2[1] The data plane of the TSF shall authenticate itself using X.509
certificate(s) using RSA with key size 2048, 3072, 4096 bits; ECDSA over NIST
curves secp256r1, secp384r1 and no other curves.
FCS_TLSS_EXT.1.3[1] The data plane of the TSF shall perform key exchange using:
• RSA key establishment with key size 2048, 3072, 4096 bits;
• EC Diffie-Hellman key agreement over NIST curves secp256r1, secp384r1
and no other curves;
• Diffie-Hellman parameters ffdhe2048, ffdhe3072, ffdhe4096.
FCS_TLSS_EXT.1.4[1] The data plane of the TSF shall support no session resumption, session
resumption based on session tickets according to RFC 5077 (TLS 1.2), session
resumption according to RFC 8446 (TLS 1.3).
FCS_TLSS_EXT.1.5[1] The data plane of the TSF provides the ability to configure the list of
supported ciphersuites as defined in FCS_TLSS_EXT.1.1[1].
FCS_TLSS_EXT.1.6[1] The data plane of the TSF shall prohibit the use of the following
extensions:
• Early data extension
FCS_TLSS_EXT.1.7[1] The data plane of the TSF shall not use PSKs.
FCS_TLSS_EXT.1.8[1] The data plane of the TSF shall support secure renegotiation in
accordance with RFC 5746 by always including the “renegotiation_info” TLS
extension in TLS 1.2 ServerHello messages, reject TLS 1.3 renegotiation attempts.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 49
6.2.2.18 FCS_TLSS_EXT.1[2] TLS Server Protocol (Control Plane Server) - Selection
FCS_TLSS_EXT.1.1[2] 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:
• Select supported ciphersuites for TLS 1.2 from List 1:
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 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_128_CBC_SHA256 as defined in
RFC 5289
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
RFC 5289
and no other ciphersuites.
FCS_TLSS_EXT.1.2[2] The control plane of the TSF shall authenticate itself using X.509
certificate(s) using RSA with key size 2048, 3072, 4096 bits; ECDSA over NIST
curves secp256r1, secp384r1 and no other curves.
FCS_TLSS_EXT.1.3[2] The control plane of the TSF shall perform key exchange using:
• RSA key establishment with key size 2048, 3072, 4096 bits;
• EC Diffie-Hellman key agreement over NIST curves secp256r1, secp384r1
and no other curves.
FCS_TLSS_EXT.1.4[2] The control plane of the TSF shall support no session resumption,
session resumption based on session tickets according to RFC 5077 (TLS 1.2).
FCS_TLSS_EXT.1.5[2] The control plane of the TSF provides the ability to configure the list of
supported ciphersuites as defined in FCS_TLSS_EXT.1.1[2].
FCS_TLSS_EXT.1.6[2] The control plane of the TSF shall prohibit the use of the following
extensions:
• Early data extension
FCS_TLSS_EXT.1.7[2] The control plane of the TSF shall not use PSKs.
FCS_TLSS_EXT.1.8[2] The control plane of the TSF shall support secure renegotiation in
accordance with RFC 5746 by always including the “renegotiation_info” TLS
extension in TLS 1.2 ServerHello messages.
6.2.2.19 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 50
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
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 51
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 5246
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.
ST Application Note: TD0774 applies to the SFR definition.
6.2.2.20 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.21 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.22 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 52
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
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 53
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 5246
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
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.
ST Application Note: TD0774 applies to the SFR definition.
6.2.2.23 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 54
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:
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 55
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 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 56
• 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 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 57
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.
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,
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 58
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
• 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 59
6.2.4 Identification and Authentication (FIA)
6.2.4.1 FIA_AFL.1 Authentication Failure Management - Selection
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 the
lockout reset action is taken by an Administrator; 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 - Selection
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_UAU.7 Protected Authentication Feedback - Selection
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.5 FIA_UIA_EXT.1 User Identification and Authentication - Mandatory
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.
FIA_UIA_EXT.1.3The TSF shall provide the following remote authentication mechanisms Web GUI
password, SSH password, SSH public key and no other mechanism. The TSF shall
provide the following local authentication mechanisms password-based.
FIA_UIA_EXT.1.4The TSF shall authenticate any administrative user’s claimed identity according to
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 60
each authentication mechanism specified in FIA_UIA_EXT.1.3.
ST Application Note: TD0900 applies to the SFR definition.
6.2.4.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation - Selection3
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 DTLS/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 DTLS/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.7 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.
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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 61
• 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 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 meet one of the following conditions:
▪ 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) and
▪ There is no extendedKeyUsage field,
▪ 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.
ST Application Note: TD0808 applies to the SFR definition.
6.2.4.8 FIA_X509_EXT.2 X.509 Certificate Authentication - Selection
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for HTTPS, TLS and no additional uses.
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall accept the certificate.
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.9 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 62
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.
6.2.4.10 FIA_X509_EXT.3 X.509 Certificate Requests - Selection
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be
able to provide the following information in the request: public key and 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 -
Mandatory
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 - Selection
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 √ √
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 63
Management Function Security
Administrator
Auditor
Ability to configure and manage certificate profiles √
Ability to modify the OCSP configuration √
Table 7: Management Functions and Privileges
6.2.5.4 FMT_MTD.1/CoreData Management of TSF Data - Mandatory
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security
Administrators.
6.2.5.5 FMT_MTD.1/CryptoKeys Management of TSF Data - Selection
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 - Mandatory
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
• Ability to administer the TOE remotely;
• Ability to configure the access banner;
• Ability to configure the remote session inactivity time before session termination;
• Ability to update the TOE, and to verify the updates using digital signature
capability prior to installing those updates;
• Ability to start and stop services;
• Ability to configure local audit behaviour (e.g. changes to storage locations for
audit; changes to behaviour when local audit storage space is full; changes to
local audit storage size);
• 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;
• Ability to configure NTP;
• Ability to administer the TOE locally;
• Ability to configure the local session inactivity time before session termination or
locking;
• Ability to configure the authentication failure parameters for FIA_AFL.1;
• Ability to manage the trusted public keys database.
ST Application Note: TD0880 applies to the SFR definition.
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:
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 64
• 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 - Mandatory
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 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 - Selection
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 65
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 symmetric keys) -
Mandatory
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and
private keys.
6.2.6.7 FPT_STM_EXT.1 Reliable Time Stamps - Mandatory
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, synchronise time
with an NTP server.
6.2.6.8 FPT_TST_EXT.1 TSF Testing - Mandatory
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests:
• During initial start-up (on power on) to verify the integrity of the TOE firmware
and software;
• Prior to providing any cryptographic service and at power-up to verify correct
operation of cryptographic implementation necessary to fulfil the TSF;
• on-demand, at the conditions periodically during normal operation self-tests
TOE Software Integrity Verification.
• Start-up self-tests BIOS Power-On Self-Test (POST) on F5 devices.
to demonstrate the correct operation of the TSF.
ST Application Note: TD0836 applies to the SFR definition.
FPT_TST_EXT.1.2 The TSF shall respond to all failures by halting the TOE for all self-test failures
except TOE software integrity test errors executed during normal operation result in
reporting the errors.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 66
6.2.6.9 FPT_TUD_EXT.1 Trusted Update - Mandatory
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.3 TSF-initiated Termination - Mandatory
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.2 FTA_SSL.4 User-initiated Termination - Mandatory
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own
interactive session.
6.2.7.3 FTA_SSL_EXT.1 TSF-initiated Session Locking - Selection
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.4 FTA_TAB.1 Default TOE Access Banners - Mandatory
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.
6.2.8 Trusted path/channels (FTP)
6.2.8.1 FTP_ITC.1 Inter-TSF trusted channel - Mandatory4
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, the authorized IT entities to initiate communication
4
Note: The STIPM modified the definition of this requirement from the NDcPP.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 67
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.
ST Application Note: TD0831 applies to the SFR definition.
6.2.8.2 FTP_TRP.1/Admin Trusted Path - Mandatory
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
evaluation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.1 Security objectives for the operational environment
ASE_REQ.1 Stated security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1* TOE summary specification
ATE: Tests ATE_IND.1 Independent testing – conformance
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 68
Assurance Class
Assurance
Component ID
Assurance Component Name
AVA: Vulnerability
assessment
AVA_VAN.1 Vulnerability survey
Table 8: Security Assurance Requirements
ASE_TSS.1 is refined by the NDcPP as noted below:
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR. In
the case of entropy analysis, the TSS is used in conjunction with required supplementary
information on Entropy.
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, STIPM, and PKG_SSH security
problem definition, security objectives, or security assurance requirements. The security functionality
requirements claimed in this ST include:
• all of the required/mandatory SFRs from the NDcPP,
• selected optional SFRs from the NDcPP,
• mandatory selection-based SFRs from the NDcPP,
• all of the required/mandatory SFRs from the PKG_SSH,
• mandatory selection-based SFRs from the PKG_SSH,
• all of the required/mandatory SFRs from the STIPM,
• selected optional SFRs from the STIPM,
• mandatory selection-based SFRs from the 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, STIPM, and/or PKG_SSH.
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 3.0e, STIPM version 1.1 or PKG_SSH v1.0. All operations on the SFRs have been
completed correctly. Therefore, the dependency rationale used by the NDcPP version 3.0e or STIPM
version 1.1 is considered applicable and acceptable since the NDcPP and STIPM have been validated and
approved.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 69
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 9 shows the information included in the different types of audit logs.
Log content Log type
System
Packet
Filter
Local
Traffic
Audit
(mcp)
Audit
(other)
Certificate
Description The description of the event that caused
the system to log the message.
X X X X X X
Event A description of the configuration change
that caused the system to log the message.
X X
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 70
Log content Log type
System
Packet
Filter
Local
Traffic
Audit
(mcp)
Audit
(other)
Certificate
Host name The host name of the system that logged
the event message.
X X X X X
Log Level Provides log level detail X
Service The service that generated the event. X X X X X
Session ID The ID associated with the user session. X
Status code The status code associated with the event. X X
Timestamp The time and date that the system logged
the event message.
X X X X 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
User Name The name of the user who made the
configuration change
X X
Table 9: Audit Logs and Their Content
The TOE includes within each audit record the information required by FAU_GEN.1.2 and specified in
Table 5 and required by FAU_GEN.1.2/STIP and specified in Table 6.
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.
7.1.2 Audit Storage
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 71
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.
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 older syslog file(s) 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 80%
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.
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.
The TOE also uses the SHA-1 message digest algorithm for authenticating NTP servers.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 72
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:
Key
Generation
Scheme
Key
Establishment
Scheme
Key sizes /
NIST curves
Usage
RSA RSA
NIST SP 800-56B
Key sizes:
2048, 3072,
4096
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
Revision 3
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.
FFC FFC
NIST SP 800-56A
Revision 3 and
groups listed in
RFC 7919
Safe-prime
groups:
ffdhe2048,
ffdhe3072,
ffdhe4096
For data plane TLS key exchange.
Table 10: 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 73
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, 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 Primary Key can be replaced using the tmsh
command “modify sys crypto master-key”.
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 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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 74
Application Key type Storage
Location
Volatile/
Non-
volatile
Zeroized
when?
Description
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().
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 75
Application Key type Storage
Location
Volatile/
Non-
volatile
Zeroized
when?
Description
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.
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 11: Zeroization of Critical Security Parameters
This implements FCS_CKM.4 and FCS_STG_EXT.1.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 76
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, 4096
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
SHA-1
SHA-256
SHA-384
none certificate-
based
authentication /
digital signature
verification /
NTP
authentication
ISO/IEC 10118-
3:2004
FCS_COP.1/Hash
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 77
Algorithm Key length (bits) Purpose Reference SFR
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 12: 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
operating system’s entropy pool. The entropy pool is used as a seed source for a digital random number
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 78
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, 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 is not used to implement any of the security functions claimed in the
TSF. The administrative guidance will instruct the user to not use the SSH Client on 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 TOE's command line interface are protected using SSH version 2, using the
cryptographic algorithms identified in Table 13.
Usage Algorithm
Transport encryption algorithm AES CBC and CTR mode with 128 and 256 bit-sizes keys
Transport data integrity protection
hashing algorithm
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 13: 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, diffie-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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 79
set the RekeyLimit to a value greater that 1 GB.
This functionality implements FCS_SSH_EXT.1 and FCS_SSHS_EXT.1.
7.2.6 TLS Protocol
The TOE implements both the TLS server and TLS client protocol. In the evaluated configuration, the
TLS server protocol is implemented in both the data plane and the control plane, and the TLS client
protocol is implemented only in the data plane.
TLS 1.3 is implemented by the data plane; not the control plane. The only ciphersuites supported by TLS
1.3 are TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384.
Table 14 summarizes the ciphersuites supported by the evaluated configuration for TLS 1.2 connections
for both the control plane and the data plane.
Cipher Data Plane
Client
Data Plane
Server
Control
Plane Server
TLS_RSA_WITH_AES_128_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_RSA_WITH_AES_256_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS v1.2 TLS v1.2 N/A
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS v1.2 TLS v1.2 N/A
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS v1.2 TLS v1.2 N/A
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
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
Table 14: TLS v1.2 Ciphersuites
All other proposed ciphersuites are rejected. The TOE provides a mechanism for configuring the list of
supported ciphersuites for both the TLS server and TLS client.
The TLS implementations do not permit out-of-band provisioning of pre-shared keys (PSKs) in the
evaluated configuration.
The TLS 1.2 implementation supports secure renegotiation through use of the “renegotiation_info” TLS
extension in accordance with RFC 5746. The TLS 1.3 implementation rejects secure renegotiation
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 80
attempts
This functionality implements FCS_TLSC_EXT.1, FCS_TLSS_EXT.1[1]-[2].
7.2.6.1 TLS Client
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.
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 ciphersuites, although individual curves cannot be configured.
The TLS client implementation indicates which signature/hash algorithm pairs it can support in digital
signatures in handshake messages (and in certificates since no signature_algorithms_cert is present) using
the signature_algorithms extension. The BIG-IP TLS client supports the following algorithms in the
signature_algorithms extensions:
• rsa_pkcs1 with sha256(0x0401),
• rsa_pkcs1with sha384(0x0501),
• rsa_pkcs1 with sha512(0x0601),
• ecdsa_secp256r1 with sha256(0x0403),
• ecdsa_secp384r1 with sha384(0x0503),
• rsa_pss_rsae with sha256(0x0804),
• rsa_pss_rsae with sha384(0x0805),
• rsa_pss_rsae with sha512(0x0806),
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, FCS_TLSC_EXT.2.
7.2.6.2 TLS Server
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. Both the data and control plane support TLS 1.2 sessions. The data
plane also supports TLS 1.3. The TLS server implementation in the TOE is configured to deny SSL 1.0,
SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 session requests.
When acting as a TLS server, BIG-IP does not operate on or process reference identifier fields in the
BIG-IP certificate. It is up to an Administrator to load the desired X.509 certificate and up to TLS clients
to verify it.
The TLS 1.2 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. The TLS 1.3 server supports session resumption as defined in RFC 8446
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 81
Section 2.2. In addition, both the TLS 1.2 and TLS 1.3 servers support no session resumption.
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 ciphersuite 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.
The TLS 1.2 and TLS 1.3 implementations authentication themselves using X.509 certificates using RSA
with key size 2048, 3072, and 4096 bits or ECDSA over NIST curves secp256r1 and secp384r1.
When acting as a TLS server, BIG-IP generates key establishment parameters using RSA with key size
2048, 3072, and 4096 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, and RFC 4492. For example, its classic ECDH using named curves with predefined parameters.
The TOE does not support DHE_RSA ciphersuites, so server key exchange messages are not sent. For the
data plane TLS 1.3 implementation the server key exchange parameters are as defined / required by RFC
8446 Section 7.4.2.
This functionality implements FCS_TLSS_EXT.1[1]-[2].
7.2.7 HTTPS Protocol
The BIG-IP provides three interfaces for remote administrators that communicate over HTTPS:
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 NTP Protocol
Administrators can configure BIG-IP to use NTP v4 to synchronize the real-time clock with an external
NTP time source. The authenticity of the timestamps is ensured by verifying the integrity of the NTP
packets using the SHA-1 message digest algorithm. BIG-IP does not update the system time from broadcast
and/or multicast addresses. It is recommended that administrators configure at least 3 NTP time sources.
This functionality implements FCS_NTP_EXT.1.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 82
7.2.9 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 ciphersuites
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.9.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 ciphersuites 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
• 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 ciphersuites 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 ciphersuite 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 83
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.9.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
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 84
Alert Description
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
Table 15: 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:
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 85
• 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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 86
• 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 encompasses 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 87
c. Ciphers and hash algorithms are loaded
d. Error strings are loaded
e. Set the TLS protocol version and create the SSL context structure
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)
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 88
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.
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 ciphersuites 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,
ciphersuite, 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 ciphersuites
are presented in the Client Hello message in the descending
order of security (i.e. most secure ciphersuite 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, ciphersuite, 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, ciphersuite, 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 ciphersuite 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 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 89
TLS Protocol Error Mechanism
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 90
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 ciphersuites defined in FCS_TTTC_EXT.1. BIG-IP SSLO also
implements TLS 1.2, TLS 1.0, and TLS 1.1 with session renegotiation as a server to the monitored client
that supports the ciphersuites 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
All management interfaces support the ability for administrative users (i.e., all users authorized to access
the TOE's administrative interfaces) to be identified by a user name and authenticated by an individual
password associated with that user account. 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.
For SSH public key authentication, the administrative user creates the key pair and sends the public key to
BIG-IP for storage in the local user’s authorized_keys file. The SSH server sends an encrypted challenge
request to the SSH client requesting a connection using the user’s shared public key. The SSH client uses
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 91
the private key to decrypt the challenge request and responds to the SSH server. If the SSH client response
is cryptographically correct, the client is granted access.
This functionality implements FIA_UIA_EXT.1.
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.
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 can be defined by the Security
Agministrator. The default minimum password length 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 ("locked") 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 addition, an Administrator can issue a lockout
reset command to reset the user’s failed authentication attempt counter, allowing the user’s lockout time to
be reset immediately.
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 92
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 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 Certificate Validation
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 93
X.509, verifies the expiration of the certificate (assuming a reliable time), and verifies its revocation using
CRLs.
When the TSF cannot establish a connection to determine the validity of a certificate, 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.
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
API
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 94
Management Function tmsh Configuration
Utility (Web-
based GUI)
iControl
API
iControl REST
API
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
Table 16: 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 TOE's local user
database. Management includes creating and deleting users, as well as changing another user'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 TOE'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,
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 95
• 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,
• configure NTP, 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-IP'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.
The BIG-IP restricts the ability to modify the behavior of the management functions listed in Table 7 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 17 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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 96
• 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.
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.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 97
Role Associated rights
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 BIG-IP user role only
grants read-only access, it does not meet the STIPM Auditor role definition.)
Log Manager This role grants users the 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 17: 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 17, 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 17. If a user is
assigned to any of the following roles, they cannot be simultaneously 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 7 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/CoreData, FMT_MTD.1/CryptoKeys, FMT_SMF.1, FMT_SMF.1/STIP, FMT_SMR.2,
FMT_SMF.2/STIP.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 98
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. 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 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.
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 99
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, 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 includes two digital signatures of the ISO image file: one SHA256 digest and one SHA384
digest. The private and public keys are generated using the OpenSSL utility. The signing key is a 2048 bit
or 3072 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 or the SHA384 hash of software
archives using 3072-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, 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 can manually set the time or configure BIG-IP to use NTP to synchronize the time with an
external NTP time source. When manually setting the time, Administrators set the hardware-based clock
on F5 devices. Refer to Section 7.2.8 for more information on NTP.
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 FCS_NTP_EXT.1, FPT_STM_EXT.1.
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
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 100
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).
This functionality implements FTA_SSL_EXT.1, FTA_SSL.3.
Lastly, administrators are able to actively terminate these sessions (i.e., to log out of the administrative
interface in use and therefore close an authenticated session).
This functionality implements FTA_SSL.4.
F5 BIG-IP 17.5 SSLO ST April 17, 2026
© 2026 F5, Inc. All Rights Reserved. 101
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.3, 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 1.2, using the ciphersuites
identified in FCS_TLSS_EXT.1[2].
• 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.