Attach & Authentication (EPS-AKA) in LTE 4G

Introduction

EPS Attach is the first full NAS procedure a UE runs against an LTE network, and it is the gate everything else passes through. In one continuous run it registers the UE with the MME, authenticates both parties, switches on NAS security, and — piggybacked on the very first message — asks for the first PDN connection so the UE ends up with an IP address and a working default bearer.

It sits at the power-on end of the UE lifecycle. Before attach, the UE is EMM-DEREGISTERED: unknown to the core, unauthenticated, unable to send or receive user data. After a successful attach it is EMM-REGISTERED and ECM-CONNECTED, pageable, secured, and carrying traffic. Every later procedure — Service Request, Tracking Area Update, dedicated-bearer setup, handover — assumes attach already happened.

Attach is a multi-message, multi-node procedure (UE, eNB, MME, HSS, S-GW, P-GW), so when it fails, it fails at an identifiable point: identity resolution, authentication, security mode, the S-GW/P-GW session, or the final accept/complete. Learning to walk it message by message turns "attach failed" into a specific, testable hypothesis.

Why attach is needed

The network must not serve an unauthenticated device, and the UE must not trust a rogue base station — so attach is the one moment where mutual authentication and NAS security are established before any user traffic, paging, or location updates are allowed. It is also the cheapest place to hand the UE its first data pipe: by piggybacking a PDN Connectivity Request on the Attach Request, registration and connectivity complete in a single run rather than two.

What EPS Attach Is

Attach is how a UE registers with the Evolved Packet System. In one continuous run it establishes a NAS signalling relationship with the MME, authenticates both parties, switches on NAS ciphering and integrity, and — piggybacked on the very first message — requests the first PDN connection so the user walks away with an IP address and a working default bearer. Nothing else the UE ever does over LTE happens until attach completes, which is why every design decision here is about establishing trust and state in the fewest possible round trips.

Two protocols share the NAS layer during attach and it pays to keep them separate in your head. EMM (EPS Mobility Management) owns the mobility and security half — Attach Request, Authentication Request, Security Mode Command, Attach Accept. ESM (EPS Session Management) owns the bearer half — PDN Connectivity Request and Activate Default EPS Bearer Context Request. During attach the ESM messages do not travel on their own: they ride inside an ESM message container IE carried by the EMM messages. That nesting is what lets a single Attach Request both register the device and ask for connectivity, and it is the detail that trips up most people reading a NAS trace for the first time.

The Attach Request and Its Contents

The Attach Request is the first NAS message the UE sends, and it is dense. It is delivered to the eNB inside an RRC RRCConnectionSetupComplete, which the eNB forwards to the MME as the NAS payload of an S1AP Initial UE Message. Because it is sent before any security context exists, the message goes out with no ciphering and, on a fresh attach, no integrity protection either — a constraint that shapes everything the network does next.

The IEs that matter most:

• EPS attach type — tells the MME what kind of registration this is: a plain EPS attach, a combined EPS/IMSI attach (for a UE that also wants circuit-switched services via an MSC), or an emergency attach.
• EPS mobile identity — the identity, either an IMSI (permanent) or, far more commonly, a GUTI (temporary) from a prior attach.
• UE network capability — a bitmap of the security algorithms the UE supports: the EPS encryption algorithms (EEA0–EEA3) and integrity algorithms (EIA0–EIA3). The MME uses this list to choose the NAS algorithms it will command later, so it must be delivered before ciphering is on — and it is echoed back protected during Security Mode to defeat bidding-down attacks.
• NAS key set identifier (KSIASME, also written eKSI) — a small index that names a cached security context. If the UE and network still share a valid KASME from a previous run, this lets them skip a fresh authentication entirely.
• ESM message container — the nested PDN Connectivity Request, carrying the requested PDN type (IPv4, IPv6, IPv4v6), an optional APN, and PCO (Protocol Configuration Options) for things like DNS server discovery.

Identity — GUTI First, IMSI Only if Forced

The UE would rather not broadcast its permanent identity. On a very first attach to a network where it holds no temporary identity it must present its IMSI, but whenever it already carries a valid GUTI (Globally Unique Temporary Identity, assigned by an MME on a previous attach) it uses that instead. The GUTI does double duty: it hides the IMSI over the air, and it encodes the identity of the MME that issued it, so a receiving MME can route to the old MME and fetch the existing UE context rather than starting from scratch.

If the MME cannot resolve the identity it was handed — for example a GUTI whose issuing MME is unreachable, or whose context has been purged — it runs the Identity procedure. It sends an Identity Request naming the identity type it needs (typically IMSI), and the UE answers with an Identity Response carrying that value. Only once the MME holds the IMSI can it locate the subscription in the correct HSS and begin authentication. The Identity procedure is therefore conditional: on a clean GUTI-based attach with a reachable old MME, it never runs at all.

EPS-AKA — the Challenge/Response Run

Once the MME knows the IMSI, it authenticates. LTE uses EPS-AKA (Authentication and Key Agreement), a challenge/response scheme rooted in a permanent secret key K that lives in exactly two places: the USIM on the UE side and the HSS/Authentication Centre (AuC) on the network side. The MME never sees K — it only ever handles derived material, which is precisely what makes a compromised MME far less catastrophic than a compromised HSS.

1. Fetch vectors (MME ↔ HSS over S6a). The MME sends an Authentication-Information-Request (AIR) to the HSS over the S6a Diameter interface, including the IMSI, the serving network identity (PLMN), and the number of vectors it wants. The HSS runs the AKA algorithms on K, and returns one or more EPS authentication vectors in the Authentication-Information-Answer (AIA). Each vector is a quadruplet: RAND, AUTN, XRES, KASME. Crucially, the HSS binds KASME to the serving network identity, so a vector minted for one operator cannot be replayed by another.

2. Challenge the UE. The MME picks one vector and sends a NAS Authentication Request containing RAND (the random challenge), AUTN (an authentication token derived from K, a sequence number SQN, and an authentication management field AMF), and the KSIASME that will name the resulting context. It retains XRES and KASME; those never leave the core.

3. UE checks the network. The USIM runs the AKA functions on RAND using K. It first verifies AUTN by recomputing the expected MAC and checking the freshness of SQN. A valid AUTN proves the challenge came from an entity that knows K and that this is not a replay of an old exchange. If verification fails, the UE returns an Authentication Failure with a cause — MAC failure, synch failure (with an AUTS token so the network can resynchronise SQN), or non-EPS authentication unacceptable — and the network has failed to authenticate.

4. UE answers. On success the USIM computes RES and the key material, and the UE returns a NAS Authentication Response carrying RES.

5. Network checks the user. The MME compares the received RES against the XRES from the vector. A match authenticates the user; a mismatch triggers an Authentication Reject (which moves the UE to the deregistered state) or an authentication-failure flow.

The EPS Key Hierarchy — K to KASME to KeNB

Authentication does more than prove identity: it seeds an entire tree of keys. Understanding that tree is what turns "security is on" into a precise mental model of who holds what.

At the root sits K, the permanent subscriber key in the USIM and AuC. During AKA the AuC (and independently the USIM) computes two intermediate keys, the cipher key CK and the integrity key IK, from K and RAND using the AKA functions f3/f4. In classic UMTS these would be used directly; EPS instead folds them one level further. A key derivation function (HMAC-SHA-256) combines CK and IK with the serving network identity and the SQN⊕AK value to produce KASME — the 256-bit anchor that the HSS ships to the MME. Binding to the serving network identity is the step that stops one operator from impersonating another with a stolen vector.

From KASME the tree splits. The MME and UE derive the two NAS keys — KNASenc for ciphering NAS messages and KNASint for integrity-protecting them — each computed with the identifier of the chosen algorithm so that changing algorithms changes the key. Separately, KASME and a NAS uplink count produce KeNB, which the MME hands to the eNB inside the S1AP setup. The eNB then derives the Access Stratum keys from KeNB: KRRCenc and KRRCint for signalling radio bearers, and KUPenc (and optionally KUPint) for user-plane radio bearers. So a single EPS-AKA run feeds both the NAS security world (terminated in the MME) and the AS security world (terminated in the eNB) — this is the LTE key hierarchy in one breath.

NAS Security Mode & the Full Message Sequence

Authentication agrees on KASME but does not by itself protect NAS messages. That is the job of the NAS Security Mode Control procedure. Immediately after a successful EPS-AKA, the MME sends a NAS Security Mode Command — itself integrity-protected with the freshly derived KNASint — that tells the UE which algorithms to use (a selected EEA for ciphering and EIA for integrity), names the context with the KSIASME, and, importantly, echoes back the UE network capability the UE originally sent. The UE compares that echo against what it actually transmitted; a mismatch means someone tampered with the unprotected Attach Request to force weaker algorithms, and the UE aborts. This is the anti-bidding-down check.

The UE verifies the integrity of the command, activates ciphering and integrity, and replies with a NAS Security Mode Complete that is both integrity-protected and ciphered. From this point every NAS message — including the Attach Accept to come — is protected, which is exactly why the network defers anything sensitive (a new GUTI, the bearer configuration) until after this exchange.

Putting identity, vector retrieval, the challenge/response, NAS security, the S-GW/P-GW bearer leg, and the accept/complete handshake together gives the full attach skeleton:

Attach Accept, the Default Bearer & GUTI Reallocation

With authentication done and NAS security on, the MME turns to the ESM half it has been holding since the PDN Connectivity Request. It selects an S-GW and P-GW, then sends a Create Session Request (S11 toward the S-GW, relayed on S5/S8 to the P-GW). The P-GW allocates the UE's IP address, sets up the default bearer's context, and returns it in the Create Session Response. This is where the user's connectivity physically comes into being; everything before it was signalling about trust.

The MME now composes the Attach Accept. It carries the EMM-level results — a freshly allocated GUTI, a TAI list (the set of tracking areas in which the UE may move without re-registering), and mobility timers such as T3412 for periodic TAU — and it nests, inside its ESM message container, an Activate Default EPS Bearer Context Request. That ESM message is what actually creates the default EPS bearer: it names the EPS bearer identity, the APN, the assigned IP address, and the bearer's QoS in the form of a QCI (typically the non-GBR QCI 9 for internet) and an APN-AMBR. The default bearer is "default" precisely because it is created automatically at attach and lives for the whole PDN connection; dedicated bearers, if any, are added later by the network.

The Attach Accept does not travel as a lone NAS message. The MME hands it to the eNB inside an S1AP Initial Context Setup Request, together with KeNB and the bearer's QoS. The eNB uses that to run RRC SecurityModeCommand and RRCConnectionReconfiguration, arming the radio bearers, and delivers the Attach Accept to the UE inside the reconfiguration. The UE responds with an Attach Complete carrying the nested Activate Default EPS Bearer Context Accept, which the eNB relays to the MME. At that instant the UE is EMM-REGISTERED and ECM-CONNECTED, with a working default bearer and an IP address.

The Attach Accept is also the natural home for GUTI reallocation. Because a temporary identity loses its privacy value the more often it is observed, the network refreshes it: on attach, the new GUTI is delivered inside the (now ciphered) Attach Accept and confirmed by the Attach Complete. At other times the same job is done by the standalone GUTI Reallocation Command / GUTI Reallocation Complete pair. Delivering the new GUTI only after NAS security is active is deliberate — it goes out encrypted, so an eavesdropper cannot link the new temporary identity either to the old one or to the IMSI.

Reading attach in the logs

An attach spans several nodes, so a full trace usually stitches the UE NAS log, the MME NAS/S1AP/S6a logs, and the S11/S5 GTP-C logs. Walk it in the procedure order — identity, authentication, security, session, accept/complete — and the first line that does not line up is your root cause. Below is a compressed MME-side view of a clean attach.

Representative MME attach trace — illustrative, values vary by vendor/build:

Summary

EPS Attach is one procedure doing four jobs at once — register, authenticate, secure, connect — and the fastest way to root-cause a failure is to walk those jobs in order. Identity: does the UE present a resolvable GUTI, or is it forced to an IMSI via the Identity procedure? Authentication: did the HSS return vectors over S6a, did AUTN verify at the UE, and did RES match XRES? Security: did the NAS Security Mode Command/Complete switch on KNASint/KNASenc without a bidding-down mismatch? Connectivity: did Create Session bring up the default bearer, and did Attach Accept/Attach Complete close the loop?

Keep the two structural ideas in front of you: EMM carries ESM (so Attach Request/Accept/Complete each wrap a bearer message), and nothing sensitive — the new GUTI, the bearer config — is sent until after NAS security is on. Localise a break to one of the four jobs and a vague "attach failed" becomes a specific, testable cause.