Client-Server Key Identifier

Description

The Client-Server Key Identifier (CSK-ID) is a fundamental component within the 3GPP Generic Bootstrapping Architecture (GBA), a framework that leverages the security credentials of the Universal Subscriber Identity Module (USIM) to establish application-specific security associations. It functions as a unique reference or pointer to a specific shared secret key, known as the Bootstrapping Session Key (Ks), that is derived during the GBA bootstrapping procedure between the User Equipment (UE) and the Bootstrapping Server Function (BSF). The CSK-ID is not the key itself but a cryptographically generated identifier that allows both the UE and a Network Application Function (NAF) to unambiguously identify and reference the specific Ks instance and its associated session context for subsequent authentication and key agreement.

The generation and lifecycle of the CSK-ID are tightly coupled with the GBA bootstrapping procedure. When a UE initiates bootstrapping, it authenticates with the BSF using its USIM credentials (via the Authentication and Key Agreement protocol). Upon successful authentication, the BSF and UE independently derive the master session key Ks. The BSF then generates a Bootstrapping Transaction Identifier (B-TID) and a corresponding CSK-ID. The B-TID is sent to the UE and serves as the primary session identifier. The CSK-ID, however, is specifically intended for use between the UE and a NAF. It is derived from the B-TID and other parameters, ensuring a cryptographically secure binding to the Ks. The BSF stores the Ks, B-TID, and CSK-ID along with the subscriber's identity and key lifetime.

When the UE later needs to access a service provided by a specific NAF (e.g., a Multimedia Telephony Service or an IoT platform), it sends the CSK-ID to that NAF as part of the service request. The NAF, which does not share a direct security association with the UE, forwards this CSK-ID to the BSF for validation. The BSF uses the CSK-ID to look up the corresponding Ks and subscriber profile. It then generates a NAF-specific key, Ks_NAF, derived from Ks and the NAF's unique identifier, and provides this Ks_NAF (or a token derived from it) back to the NAF. The UE independently derives the same Ks_NAF. This establishes a shared secret between the UE and the NAF, enabling mutual authentication and secure communication for that application session, all without the NAF needing to handle the user's long-term USIM credentials.

The architecture involves several key network functions: the UE (client), the BSF (which performs bootstrapping), the Home Subscriber Server (HSS) which provides authentication vectors, and the NAF (the application server). The CSK-ID acts as the critical reference token that connects these entities securely. Its design ensures that different NAFs receive different derived keys (Ks_NAF) even when referencing the same base Ks via the same CSK-ID, providing service isolation. The identifier's format and handling are standardized in 3GPP TS 24.380 (GBA Push) and TS 33.220 (GBA), ensuring interoperability across vendors and network deployments.

Purpose & Motivation

The CSK-ID was created to address the challenge of providing secure, scalable authentication for a multitude of IP-based application services in mobile networks without burdening each service with managing its own user credentials or authentication infrastructure. Prior to GBA, application services often required separate username/password credentials or complex certificate management, which degraded user experience and increased operational overhead. The core problem was how to leverage the strong, SIM-based authentication already present in cellular networks for securing value-added services.

GBA and the CSK-ID solve this by enabling a single, network-assisted bootstrapping event to spawn secure keys for multiple application servers. The CSK-ID provides the essential mechanism for an application server (NAF) to query the network's central security authority (the BSF) and obtain a service-specific key derived from the user's primary credentials. This decouples application security from core network authentication, allowing service providers to offer secure services without direct access to sensitive subscriber data. It facilitates the 'single sign-on' concept for mobile applications, where the network authentication can be reused securely across diverse services.

The creation of the CSK-ID was motivated by the growth of IP Multimedia Subsystem (IMS) and other multimedia services in 3GPP networks, which required a standardized, secure method for HTTP Digest authentication and key establishment. It provides a more flexible and scalable alternative to earlier methods like HTTP Digest using Authentication and Key Agreement (AKA), by centralizing key management in the BSF and using identifiers like the CSK-ID for efficient reference. This architecture is crucial for enabling trusted service delivery in IoT, rich communication services, and any scenario where a network-application trust relationship is needed.

Key Features

• Uniquely identifies a bootstrapping session key (Ks) instance between UE and BSF
• Enables a NAF to request a service-specific key (Ks_NAF) from the BSF without exposing Ks
• Cryptographically derived from the Bootstrapping Transaction Identifier (B-TID)
• Central to the GBA procedure for secure application-layer authentication
• Supports key lifecycle management (e.g., key expiration tied to the CSK-ID context)
• Ensures service isolation by allowing derivation of different Ks_NAF keys for different NAFs from the same CSK-ID reference

Evolution Across Releases

Defining Specifications