Description
The Client-Server Key (CSK) is a fundamental security element within the 3GPP Generic Bootstrapping Architecture (GBA). It is a cryptographic key, typically derived from the master session key (Ks) established during the AKA (Authentication and Key Agreement) procedure between the User Equipment (UE) and the Bootstrapping Server Function (BSF). The derivation process uses a key derivation function (KDF) with specific inputs, including the key identifier (B-TID), the Fully Qualified Domain Name (FQDN) of the target Network Application Function (NAF), and other optional parameters. This ensures each CSK is unique to the combination of user, session, and specific application server.
Architecturally, the CSK generation occurs after successful bootstrapping. The UE and the BSF independently derive the same Ks_NAF (a NAF-specific key) from the shared Ks. The CSK is then derived from this Ks_NAF. The BSF provides the necessary keying material (often the Ks_NAF itself or a reference) to the NAF via the Zn interface, while the UE computes the CSK locally. This architecture allows the NAF to verify the UE's identity and establish a secure channel without directly participating in the primary AKA procedure, offloading authentication complexity from application servers.
In operation, the CSK is used to secure the communication link between the UE and the NAF. It can serve as the basis for generating further session keys for confidentiality (encryption) and integrity protection for the application-layer protocol (e.g., HTTPS, SIP). The UE presents its B-TID to the NAF when requesting service. The NAF uses this B-TID to fetch the corresponding key material from the BSF. Both entities then independently derive the same CSK, enabling mutual authentication and the establishment of a secure, encrypted session. This process is detailed in specifications like 3GPP TS 33.220 for GBA and TS 33.222 for NAF-UE security.
The role of the CSK is critical for enabling secure, standardized access to IP-based services (IMS, location services, device management) in 3GPP networks. It provides a scalable and efficient method for service authentication, eliminating the need for the UE to store separate credentials for every service provider. By leveraging the robust security of the USIM-based AKA, the CSK inherits strong cryptographic properties, ensuring that compromise of one service key does not affect others or the core network authentication credentials.
Purpose & Motivation
The CSK was introduced to address the growing need for secure authentication and key agreement for a multitude of IP-based services beyond the core network access. Prior to GBA and the CSK concept, application servers often had to implement their own, potentially weaker, authentication mechanisms (like username/password) or manage complex PKI infrastructures. This created security vulnerabilities, poor user experience due to multiple logins, and increased operational overhead for service providers.
The creation of the CSK was motivated by the desire to leverage the strong, SIM-based authentication of the mobile network for value-added services. It solves the problem of how to securely authenticate a user to a third-party application server without revealing the user's long-term secret (Ki) to that server. The CSK provides a delegated authentication mechanism, where the trust from the core network (HSS/BSF) is propagated securely to the application layer. This enables single sign-on (SSO) capabilities across different services from the same or different providers.
Historically, as 3GPP networks evolved to offer rich multimedia and IoT services (e.g., IMS, M2M communication), a standardized, network-operator-controlled security framework became essential. The CSK, as part of GBA, provided this framework. It addressed limitations of previous ad-hoc approaches by offering a standardized, cryptographically sound method to derive service-specific keys from a single, strong network authentication, thereby enhancing overall ecosystem security and interoperability.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (88 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-14, normative work from Rel-15.
In Release 15, the CSK (Client-Server Key) function was newly introduced to enable remotely initiated private and group calls, allowing a server to trigger a call setup towards a client. It also introduced procedures for managing and using functional aliases in initial SIP INVITE requests between clients and servers. Furthermore, the release added support for the ambient viewing client role and defined specific error codes for authorization and group management failures within these new CSK-enabled procedures.
- MCVideo ambient viewing client procedures TS 24.281CR0033
- Remotely initiated group call client procedures TS 24.379CR0354
- Remotely initiated group call server procedures TS 24.379CR0355
- Remotely initiated private call client procedures TS 24.379CR0356
- Remotely initiated private call server procedures TS 24.379CR0357
- Managing functional alias – client procedures TS 24.379CR0389
+ 8 more changes
In Release 16, the Client-Server Key (CSK) function was enhanced to support service authorization procedures limiting the number of authorized clients per MCData and MCPTT user. It also introduced new client and server procedures for using functional aliases in private calls and for handling MCData Emergency Alerts. Furthermore, the release added procedures for client-side pre-established session establishment and for initiating one-to-one SDS communication using such sessions.
- Client side procedure - Pre-established session establishment TS 24.282CR0082
- Client side procedures – Initiating one-to-one SDS communication using pre-established session TS 24.282CR0084
- Add Message Store Client clause TS 24.282CR0107
- Emergency Alerts for MCData – client procedures TS 24.282CR0127
- Handling of MCData Emergency Alerts at the MCData participating servers TS 24.282CR0128
- Handling of MCData Emergency Alerts at the MCData controlling server TS 24.282CR0129
+ 19 more changes
In Release 17, the CSK function was enhanced to support new client and server procedures for on-network group emergency and imminent peril communications within MCVideo and MCData services. These additions included specific handling for emergency alert area notifications at the client side for both MCVideo and MCData. Furthermore, the release introduced client-side and server-side procedures for unicast media Stop and Resume operations.
- Emergency alert area notification handling at client side for MCVideo TS 24.281CR0112
- Interconnect - MCVideo Gateway Server procedures TS 24.281CR0155
- On-network grp emrgcy and imm peril comms – client procedures TS 24.282CR0209
- On-network grp emrgcy and imm peril comms – server procedures TS 24.282CR0210
- Emergency alert area notification handling at client side for MCData TS 24.282CR0212
- MCData clients supporting procedures for on-network private communication emergency TS 24.282CR0261
+ 19 more changes
In Release 18, the CSK function was enhanced to support location information requests from MCVideo, MCData, and MCPTT clients, and to enable Quality of Service (QoS) for these clients when operating behind MC gateway UEs. Furthermore, the release introduced procedures for delivering emergency alerts to clients affiliating late to a group already in an emergency alert state. These updates also included clarifications on the usage of Public Service Identities (PSIs) and on the hosting of clients by gateway UEs across all three MCX services.
- Location information request from an MCVideo client TS 24.281CR0234
- Enable QoS for MCVideo clients behind MC gateway UEs TS 24.281CR0233
- Emergency alert to MCVideo client affiliating after a group has moved to emergency alert state TS 24.281CR0238
- Location information request from an MCData client TS 24.282CR0375
- Enable QoS for MCData clients behind MC gateway UEs TS 24.282CR0374
- Emergency alert to MCData client affiliating after a group has moved to emergency alert state TS 24.282CR0381
+ 13 more changes
In Release 19, the CSK function was enhanced to support the introduction of an MC Recording Server within the MCXSec4 work item. This included defining new MCVideo client operations, such as the procedure for a client to release an MCVideo call using a pre-established session. These additions expanded the security and service continuity mechanisms for mission-critical services.
- [MCXSec4] 33180 R19 MC Recording Server Introduction TS 33.180CR0213
- Correction in the controlling MCPTT server operation for an MCPTT user not authorized for MCPTT ad hoc group emergency alert participant information TS 24.379CR0990
- IdMS - OIDC Client Registration TS 33.180CR0216
- [MCXSec4] 33180 R19 MC Recording Server Introduction TS 33.180CR0219
- MCVideo client operation to release an MCVideo call using a pre-established session TS 24.281CR0288
Explore further
Broader topics and technologies where CSK plays a role.
Defining Specifications
3GPP specifications that define or reference CSK, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.281 vj40 | MCVideo Signalling Control Specification | Rel-19 |
| TS 24.282 vj50 | MCData Signalling Control Protocols | Rel-19 |
| TS 24.379 vj50 | Mission Critical Push To Talk (MCPTT) call control | Rel-19 |
| TS 24.380 vj10 | MCPTT Media Plane Control Protocol | Rel-19 |
| TS 24.582 vj00 | MCData Media Plane Control Protocols | Rel-19 |
| TS 33.180 vk00 | Security of Mission Critical (MC) Service | Rel-20 |
| TS 33.880 vf10 | Security Study for Enhanced Mission Critical Services | Rel-15 |
| TR 33.938 vj10 | 3GPP Cryptographic Inventory for 5G | Rel-19 |
| TS 37.579 vi40 | Mission Critical services conformance testing | Rel-18 |