ABBA

Anti-Bidding down Between Architectures

Security →
Introduced in Rel-15

ABBA is a 3GPP security mechanism that prevents bidding-down attacks between different network architectures, ensuring a user's security capabilities are not downgraded when moving between networks like 4G and 5G.

Category
Security
Introduced
Rel-15
Where
Security
Specifications
3 specs
ABBA Description Purpose Detected Changes Specifications

Description

ABBA (Anti-Bidding down Between Architectures) is a critical security parameter defined in 3GPP specifications, primarily within the 5G System (5GS) security framework. It functions as a bit string included in security signaling messages, specifically within the NAS (Non-Access Stratum) security context and authentication procedures. The primary technical role of ABBA is to provide cryptographic binding between the UE's (User Equipment) security capabilities and the serving network's architecture type, preventing an attacker from forcing the UE and network to use security algorithms or procedures from a previous, potentially less secure generation.

Architecturally, ABBA operates within the Authentication and Key Agreement (AKA) procedures defined for 5G. During initial registration or handover procedures involving inter-system mobility (e.g., between 5G Core and 4G Evolved Packet Core), both the UE and the network (specifically the AMF - Access and Mobility Management Function in 5GC, or corresponding MME in EPC) exchange and verify the ABBA parameter. This parameter is constructed to be unique to the network architecture and the security context being established. The UE derives the ABBA value based on information received from the network in the authentication request, and the network independently computes the expected value. A mismatch indicates a potential bidding-down attack, causing the procedure to fail.

Key components involved in ABBA implementation include the UE's security module (USIM), the serving network's security anchor function (SEAF in 5GC, which interacts with the AUSF - Authentication Server Function), and the home network's authentication credentials (stored in the UDM/ARPF - Unified Data Management / Authentication Credential Repository and Processing Function). The ABBA parameter itself is not a standalone message but is embedded within other security containers, such as the Authentication Response message sent from UE to network. Its value is calculated using inputs that include the network's serving network name (SNN) and explicitly indicates the core network type (5GC or EPC) the UE is registering to.

In the broader 5G security architecture, ABBA complements other security mechanisms like SUPI (Subscription Permanent Identifier) protection, integrity protection of NAS signaling, and ciphering of user plane data. Its specific role is to address architectural transition threats that were not fully mitigated in previous generations. By ensuring that security negotiations cannot be manipulated to revert to older, weaker protocols when a UE moves between 4G and 5G coverage areas, ABBA maintains the overall security assurance level of the 5G system, which is a fundamental design principle. This is particularly important in non-standalone (NSA) deployment scenarios where 5G NR radio access connects to a 4G core, and in early migration phases where networks operate dual architectures.

Purpose & Motivation

ABBA was created to solve a specific security vulnerability known as a "bidding-down" or "downgrade" attack in the context of inter-generational network mobility. In 4G (EPS), while security mechanisms existed within a single architecture, the transition between 3G and 4G networks had potential vulnerabilities where an attacker could manipulate signaling to make the UE and network believe the other only supported older, less secure cryptographic algorithms (e.g., forcing a fallback from AES to SNOW 3G). With the introduction of 5G and the expectation of long-term coexistence with 4G EPC networks (especially in Non-Standalone deployments), 3GPP identified that a new form of this attack was possible: an attacker could try to force a UE registering to a 5G Core network to instead use security procedures defined for the 4G Evolved Packet Core, which might have different or weaker security properties.

The historical context is rooted in the evolution of mobile security. Each generation (3G, 4G, 5G) introduced stronger authentication algorithms, key derivation functions, and integrity protection mechanisms. However, for backward compatibility, UEs and networks must support multiple security suites. An active attacker in the radio path could intercept and modify the security capability exchange messages to remove references to newer, stronger algorithms, tricking both ends into agreeing on an older set. ABBA specifically addresses this between architectures (5GC vs. EPC), not just between algorithm sets within one architecture. It ensures that the security context is explicitly bound to the core network type being used.

The limitation of previous approaches, particularly in 4G, was that while algorithm negotiation was protected within the EPS AKA procedure, the architectural context (whether the UE was attaching to EPC or a previous core) was not cryptographically verified in a way that prevented an active attacker from manipulating this association. ABBA fills this gap by making the network architecture a mandatory and verified parameter in the authentication and key agreement process. This was motivated by the 5G design principle of providing stronger security than previous generations, especially for new threat vectors introduced by network slicing, service-based architecture, and increased reliance on untrusted access networks.

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 6 changes

In Release 15, the ABBA (Anti-Bidding down Between Architectures) function was newly introduced as a mandatory information element in the AUTHENTICATION REQUEST message for both the 5G-AKA and EAP-based primary authentication procedures. Its purpose is to enable bidding down protection of security features, and for this release, the network is specified to set the ABBA contents to a fixed 2-octet value of 0000H. The ABBA parameter is used by the SEAF to generate the K_AMF key and is handled by the UE when processing EAP messages.

  • Addition of ABBA in 5G based primary authentication procedure TS 24.501CR0036
  • ABBA handling for 5G-AKA based authentication procedure TS 24.501CR0398
  • ABBA handling when initiating EAP procedures TS 24.501CR0399
  • Add definition and values for ABBA parameter TS 33.501CR0261
  • Clarification of ngKSI and ABBA parameter in 5G-AKA TS 33.501CR0323
  • Clarification for ngksi and ABBA parameter for EAP-AKA' TS 33.501CR0324
Rel-16 1 change

In Release 16, the key enhancement for the ABBA function was the explicit handling of the ABBA parameter with a non-zero value and a length of more than 2 octets, whereas previous specifications mandated a fixed 2-octet length with a value of zero. This change accommodates a more extensive and variable set of security features within the ABBA contents for bidding down protection, as used in both the EAP-based and 5G-AKA based primary authentication and key agreement procedures.

  • Handling of the ABBA parameter with a non-zero value and a length of more than 2 octets TS 24.501CR1164

Explore further

Broader topics and technologies where ABBA plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 33.835 vg10 Study on authentication and key management for apps Rel-16
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.