BSF

Bootstrapping Server Function

Security →
Introduced in Rel-6 Also in: Core Network

BSF is the Bootstrapping Server Function, a core network element that provides applications and network functions with secure, dynamically generated authentication credentials and cryptographic keys.

Category
Security
Introduced
Rel-6
Where
Security
Also touches
1 segments
Specifications
33 specs
BSF Description Purpose Detected Changes Specifications

Description

The Bootstrapping Server Function (BSF) is a central component of the 3GPP Generic Authentication Architecture (GAA), defined as a security framework for authentication and key agreement. It operates as a standalone network function that interfaces with the Home Subscriber Server (HSS) or Unified Data Management (UDM) to perform bootstrapping procedures. The core principle involves leveraging the existing, strong authentication between the User Equipment (UE) and the mobile network (via the Authentication and Key Agreement (AKA) protocol) to derive application-specific security credentials. This process, known as 'bootstrapping,' establishes a shared secret between the UE and a Network Application Function (NAF) without requiring a prior direct security association.

Architecturally, the BSF is a server-side entity that communicates with the UE (acting as a GAA client) and the NAF. The procedure begins when the UE contacts the BSF to initiate bootstrapping. The BSF then interacts with the HSS/UDM to fetch authentication vectors (e.g., quintets for UMTS AKA or vectors for EPS AKA/5G AKA). It challenges the UE using these vectors. Upon successful mutual authentication, both the BSF and the UE independently compute a shared, session-specific root key called the Bootstrapping Transaction Identifier (B-TID) and associated key material (Ks). This Ks is a long-term key derived from the AKA session.

The BSF's role is to act as a trusted key generator and distributor. After bootstrapping, when the UE needs to access a service provided by a specific NAF (e.g., a Multimedia Broadcast Multicast Service (MBMS) server, a location-based service, or a 3GPP application server), the UE presents the B-TID to the NAF. The NAF then queries the BSF, using the B-TID, to obtain the relevant key material (a NAF-specific key, Ks_NAF, derived from Ks) for that service session. This allows the NAF and UE to establish a secure channel. The BSF thus decouples the core network authentication from application-layer security, enabling a wide range of services to leverage the robust cellular authentication infrastructure.

Key interfaces for the BSF include the Ub interface towards the UE for the bootstrapping procedure, the Zn interface towards the NAF for key distribution, and the Zh interface towards the HSS or UDM for retrieving authentication data. In 5G systems, the BSF aligns with the service-based architecture, potentially exposing its capabilities as a Network Function (NF) service. Its implementation is critical for enabling secure, standardized, and scalable authentication for value-added services across 3GPP, 4G, and 5G networks, forming the backbone for many GAA-based security solutions.

Purpose & Motivation

The BSF was created to address the fundamental problem of how to securely authenticate users and devices to a multitude of application servers (NAFs) without requiring each application to manage its own separate credential database or establish a direct trust relationship with the cellular core network. Prior to GAA, applications either used weak, application-specific passwords or required complex, out-of-band provisioning of certificates or shared keys, which did not scale and were vulnerable to attacks. The BSF provides a standardized, network-operator-controlled method to reuse the strong, subscription-based authentication of the mobile network.

The primary motivation was to enable new, secure mobile services—such as broadcast/multicast content protection (MBMS), secure device management, financial transactions, and lawful interception—by providing them with a reliable source of cryptographic keys derived from the user's SIM/USIM authentication. The BSF solves the key distribution problem in a scalable way. It allows the mobile operator to act as a trusted third party, generating and providing session keys to authorized application providers, thereby creating a business-to-business security framework. This facilitated the secure commercialization of mobile services beyond basic voice and data.

Historically introduced in 3GPP Release 6 as part of GAA, the BSF addressed the security needs of emerging IP Multimedia Subsystem (IMS) services and other network applications. It provided a future-proof architecture that has evolved through 4G and into 5G, where its role remains essential for service-based security, especially in network exposure scenarios. It addresses the limitations of static, pre-configured security by enabling dynamic, on-demand key establishment that is tied to the live network authentication state of the user.

Architecture

In the Network Map

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (44 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 13 changes

In Release 15, the BSF (Bootstrapping Server Function) was formally introduced with its Nbsf_Management service, allowing a PCF to register, deregister, and be discovered by NF service consumers. The release specified that the BSF supports session binding by storing information like UE IP address ranges, SUPIs, or GPSIs, and enables an NF consumer to resolve a UE IP address, DNN, and S-NSSAI triplet to a corresponding SUPI. Furthermore, the release detailed procedures for BSF interaction over the Rx interface and clarified its role in SM Policy establishment, modification, and termination flows.

  • Clean up for BSF TS 23.501CR0158
  • Update and correction of table for AMF, UDM, UDR, NSSF, UDSF and BSF services TS 23.501CR0363
  • TS23.503 Clarification on BSF TS 23.503CR0061
  • BSF procedures over Rx TS 29.513CR0002
  • BSF only stores binding info locally TS 29.513CR0028
  • Correction on BSF and DRA coexistence scenario TS 29.513CR0029

+ 7 more changes

Rel-16 8 changes

In Release 16, the BSF was enhanced to support multiple UE addresses and to provide additional parameters like DNN, S-NSSAI, and IP domain in its registration to the NRF for improved discovery. The release also introduced corrections to PCF discovery via the BSF to properly consider eSBA binding principles and clarified BSF behavior for TSN services. Furthermore, updates were made to the stored information in the NRF to support BSF discovery and to the conditions for BSF service operations.

  • BSF binding update TS 29.513CR0065
  • Updating the stored information in NRF to support BSF discovery TS 23.501CR1677
  • Correction of PCF discovery via BSF to consider eSBA binding principles TS 23.503CR0326
  • Correction of PCF discovery via BSF to consider eSBA binding principles - AF/NEF/SCP re-selection functionality (23.503) TS 23.503CR0385
  • Clarification on BSF behaviour for TSN service TS 23.503CR0482
  • Support multiple UE addresses in BSF TS 29.521CR0046

+ 2 more changes

Rel-17 15 changes

In Release 17, the BSF was enhanced to support PCF discovery and selection specifically for Dynamic AM Policy (DCAMP) and to handle PCF notifications of PDUID changes. The updates included modifications to BSF services, procedures, and its NF profile in the NRF to now support storage and discovery based on SUPI and GPSI ranges or a BSF Group ID. These changes ensured the BSF could properly manage registrations and support session binding for the new DCAMP functionality.

  • DCAMP related update of BSF services (23.501) TS 23.501CR2561
  • BSF enhancement on PCF Discovery for dynamic AM policy TS 23.503CR0506
  • BSF support for the PCF notification of PDUID changes TS 29.513CR0289
  • Completion of the PCF for a UE registration in the BSF TS 29.513CR0302
  • DCAMP related update of BSF services TS 29.521CR0115
  • Update of BSF NF service consumers TS 29.521CR0124

+ 9 more changes

Rel-18 3 changes

In Release 18, the updates to the Bootstrapping Server Function (BSF) primarily focused on procedural corrections and error handling refinements. This included specific corrections to BSF procedures and the definition of error responses for BSF notifications. The work ensured proper operation for session binding where a PCF reports Framed Route information and for scenarios where an NF consumer needs to resolve a UE IP address, DNN, and S-NSSAI triplet to a SUPI via the BSF.

  • Correction to BSF procedures TS 29.513CR0451
  • Error response for BSF notification TS 29.521CR0187
  • Corrections on BSF Notification TS 29.521CR0208
Rel-19 5 changes

In Release 19, the BSF enhancements focused on refining subscription and data management timers, specifically introducing or clarifying parameters for subscription expiry and validity time. The updates also included corrections to BSF API definitions and internal procedures to ensure robustness. Furthermore, improvements were made to the handling of BSF entry expiration, ensuring more reliable session binding and discovery operations.

Explore further

Broader topics and technologies where BSF plays a role.

Defining Specifications

3GPP specifications that define or reference BSF, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 23.503 vk00 5G Policy and Charging Control Framework Rel-20
TS 23.862 vc00 Interworking Solutions for Mobile Operators & Data Apps Rel-12
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19
TS 24.259 vj00 Personal Network Management (PNM) Protocol Details Rel-19
TS 29.309 vj10 Nbsp Service Based Interface for GBA BSF Rel-19
TS 29.513 vj40 5G PCC Signalling Flows & QoS Mapping Rel-19
TS 29.521 vj40 5G Binding Support Management Service Stage 3 Rel-19
TS 29.810 vd00 Diameter Load Control Study Rel-13
TS 29.890 vg00 CT3 5G System Technical Report Rel-16
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TS 33.107 vj00 Lawful Interception Architecture & Functions Rel-19
TS 33.110 vj00 UICC-Terminal Key Establishment Rel-19
TS 33.141 vj00 Security for Presence Service (Ut reference point) Rel-19
TS 33.185 vj00 V2X Security in LTE Rel-19
TS 33.220 vj00 Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Rel-19
TS 33.221 vj00 Subscriber Certificate Distribution via GBA Rel-19
TS 33.222 vj00 Secure HTTP Access in GAA Rel-19
TS 33.223 vj00 GBA Push Function Specification Rel-19
TS 33.246 vj00 MBMS Security Specification Rel-19
TS 33.259 vj00 Key Establishment between UICC Hosting & Remote Device Rel-19
TS 33.303 vj00 ProSe Security Specification for EPS Rel-19
TS 33.503 vj20 Security for Proximity Services (ProSe) in 5G Rel-19
TR 33.739 vi10 Study on security enhancement of support for Rel-18
TS 33.749 vj00 Study on security aspects of edge computing enhancement Rel-19
TS 33.804 vc00 Non-UICC SSO using SIP Digest credentials Rel-12
TS 33.822 v1800 Security Architecture for Inter-Access Mobility Rel-8
TS 33.823 vc20 GBA Web Browser Integration Study Rel-12
TS 33.835 vg10 Study on authentication and key management for apps Rel-16
TR 33.919 vj00 GAA Overview TR Rel-19
TR 33.924 vj00 GBA-OpenID Interworking Specification Rel-19
TR 33.938 vj10 3GPP Cryptographic Inventory for 5G Rel-19
TR 33.980 vj00 GAA & Liberty Alliance Interworking Guidelines Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.