AKA

AKA stands for Authentication and Key Agreement. It is based on RFC 3310 and is adopted by 3GPP for GSM /UMTS/LTE Authentication Algorithm and Authentication Process in IMS Registration. This is basically a shared Key mechanism. The shared key is 'K' value that is distributed to each UE via UICC / ISIM and managed in AuC in Server (Network) side. For the detailed meachanism of AKA besing used in Cellular Network and IMS Registration, refer to following pages.

The name has two halves, and each one names a job. The Authentication half runs in both directions at once, which is the part that separates AKA from what came before it. GSM authenticated only the subscriber, so a handset had no way to tell a real network from an imitation of one.

In AKA each side proves itself to the other in the same exchange. The network proves itself by sending AUTN, which 33.401 describes as the authentication token for network authentication, and only a network holding K could have built it. The UE proves itself by returning RES, which the MME compares against the XRES it was given. Neither proof reveals K.

The Key Agreement half is the second job. The same run that authenticates both ends also leaves them holding the same fresh keying material, without that material ever crossing the air interface. The sections below take the LTE form of this apart.

Mutual is the point : the network authenticates to the UE through AUTN, and the UE to the network through RES.
Authentication and key agreement are one exchange : the run that proves identity also establishes the keys.
K is never revealed by either proof : both sides demonstrate that they hold it rather than showing it.

Followings are the topics :

What does the network actually send?

The shared key K is the whole basis of AKA, and the one thing that must never move. It sits on the UICC and in the AuC, and neither copy is ever transmitted. Everything else in an AKA run exists to prove that both ends hold the same K without either of them revealing it.

In EPS the home network computes an authentication vector and hands it to the MME. 33.401 defines that vector as four items : RAND, AUTN, XRES and K_ASME. The MME never receives K, and it does not receive CK or IK either. What it gets is one intermediate key it can work from.

Figure 1. The EPS authentication vector. Only RAND and AUTN cross the radio interface, and the two ends derive the same K_ASME without that key ever being transmitted.

K never moves : it is permanent, stored on the USIM and in the AuC, and it is not part of any vector.
The MME gets an intermediate key, not the root : K_ASME is derived in the home network and passed on, so a compromised MME does not expose K.
XRES never crosses the radio : the MME keeps it and compares it against the RES the UE sends back.

That structure is a deliberate change from the earlier design, and the 5G vectors continue in the same direction. The table below sets the three side by side, using the definitions in 33.401 and 33.501.

Generation	Vector contents	What the serving network gets
EPS (LTE)	RAND, AUTN, XRES, K_ASME	An intermediate key only. CK and IK never leave the HSS when the separation bit is 1.
5G, home vector	RAND, AUTN, XRES*, K_AUSF	Held in the home network. This is the 5G HE AV.
5G, serving vector	RAND, AUTN, HXRES*, K_SEAF	The 5G AV. The serving network sees a hash of the expected response rather than the response itself.

Each generation keeps the secret further from the serving network : EPS stops CK and IK at the HSS. 5G goes further and keeps the expected response at home, sending only a hash of it.
The names change but the first two items do not : RAND and AUTN appear in every one of them, because they are what the UE has to be given.

What is the separation bit for?

A vector built for LTE must not be usable somewhere else. The separation bit is how that is enforced, and it is a single bit in a field the UE checks before it will answer a challenge at all.

33.401 puts it precisely. The bit is bit 0 of the AMF field carried inside AUTN. When the network type is E-UTRAN the home network shall set it to 1, and an ME accessing E-UTRAN shall check during authentication that it is set to 1. If the bit is 0 the vector is usable in a non-EPS context only, such as GSM or UMTS.

One consequence follows immediately, and it is the reason the EPS vector looks the way it does. For vectors with the separation bit set to 1, the secret keys CK and IK generated during AKA shall never leave the HSS. The bit and the vector shape are the same decision expressed twice.

There is a matching requirement on the card. E-UTRAN access needs a Release 99 or later USIM application on a UICC. Access with a 2G SIM, or with a SIM application on a UICC, shall not be granted. AKA is not optional on LTE the way authentication was optional on GSM.

It is one bit, checked by the ME : bit 0 of the AMF field inside AUTN, verified before the UE responds.
It partitions vectors by domain : 1 means EPS only, 0 means non-EPS only. A vector cannot serve both.
It is why CK and IK stay home : the same rule that sets the bit also keeps those two keys in the HSS.
A 2G SIM will not do : E-UTRAN requires a Rel-99 or later USIM application.

How is K_ASME tied to one serving network?

Handing an intermediate key to the MME raises an obvious question. What stops one serving network from taking a vector and using it while pretending to be another? The answer is that the identity of the serving network is built into the key derivation itself.

33.401 Annex A.2 gives the inputs. K_ASME is derived from CK, IK and the serving network identity. The KDF inputs are FC = 0x10, P0 = SN id at a length of three octets, and P1 = SQN xor AK at a length of six octets. The SN id is the MCC and MNC of the serving network.

Both ends run the same derivation independently. The home network runs it when it builds the vector, and the ME runs it after it has accepted AUTN and computed CK and IK. If the two used different SN ids they would reach different keys, and everything derived from K_ASME would fail. 33.401 describes exactly this effect : SN id binding implicitly authenticates the serving network identity when the derived keys are successfully used.

The second input is worth noticing too. SQN xor AK is not an extra parameter invented for this derivation. It is already being sent to the UE as part of AUTN, so both sides have it without any additional signalling.

The serving network identity is an input, not a label : change the SN id and the derived key changes with it.
Authentication of the network is implicit : nothing verifies the SN id directly. The keys simply stop working if it was wrong.
SQN xor AK is used twice : it travels inside AUTN for freshness, and it is reused as a KDF input.
The USIM is not required to do this : the ME derives K_ASME, and 33.401 notes only that later releases do not preclude a USIM being able to.

What happens when authentication fails?

A failed AKA run is not a single condition, and the distinction matters when reading a log. The UE can reject the network, or the network can reject the UE, and the first case splits again into two causes that look similar and mean very different things.

The USIM checks AUTN first. If that check fails the USIM tells the ME the reason, and the UE returns an authentication failure message carrying a cause value. Two causes are possible. One is that the token itself did not verify, which means the challenge did not come from a network holding K. The other is a synchronisation failure, which means the token verified but the sequence number was out of range.

The second case is recoverable and has its own parameter. On a synchronisation failure the USIM passes AUTS to the ME, and the UE includes AUTS in the failure message so the home network can resynchronise its sequence numbers. A resynchronisation is a normal event rather than an attack, and it is why replayed or stale vectors do not simply lock a subscriber out.

The other direction is simpler. The MME checks that RES equals XRES. If they differ the MME may ask for the identity again or send an authentication reject, depending on what identity the UE used in its initial NAS message.

Two failures, two meanings : a token failure says the network is not genuine, and a synchronisation failure says only that the counters have drifted.
AUTS is the repair path : it is sent by the UE and lets the home network resynchronise rather than reject.
The network side is one comparison : RES against XRES, with the vector supplying XRES.
A rejection is not always final : the MME may request the identity again before rejecting outright.

Reference

Two specifications contain the material added above. The procedure as it runs across the network is on the Authentication page linked at the top, and the key hierarchy that grows out of K_ASME is on the security framework page.

33.401 - 3GPP System Architecture Evolution; Security architecture, v19.2.0. Clause 6.1.1 is the EPS AKA procedure and the separation bit rule, clause 6.1.2 is the vector distribution from HSS to MME, and Annex A.2 is the K_ASME derivation function.
33.501 - Security architecture and procedures for 5G System, v20.2.0. The definitions clause lists the 5G HE AV, 5G AV and 5G SE AV used in the comparison table.
33.102 - 3G Security; Security architecture. This is where AUTN, AUTS and the sequence number handling are defined. It is referenced throughout 33.401 and is the document to read for the internal structure of the authentication token.
Security Framework - the key hierarchy that K_ASME feeds, on this site.