Authentication Failure is mostly related to wrong AUTN value in Authentication Request message. There are three main parameters including AUTN value and these main parameter would cause three different failure cause as follows.

Every example on this page uses the same test USIM and the same RAND, and only the AUTN changes. That is deliberate. Holding everything else still is what lets you see which single field the UE objected to. Each example below differs from a correct vector in one place.

• Which failure does the UE report, and who checks what ?
• Example : Invalid MAC Code
• Example : Invalid Separation Bit
• What about #21 synch failure ?
• More vectors you can build for the same test USIM
• A directly corrupted MAC
• A wrong K does not always look like a wrong K
• Which bit of AMF actually matters
• Reference

Which failure does the UE report, and who checks what ?

The table below pairs each parameter with the cause value it produces, and it is the quickest way to read a failure off a log. What the table does not say is where each check happens. Two of the three run inside the USIM, and the third runs in the ME. That split is why one of them exists only in LTE.

33.102 clause 6.3.3 sets out what the USIM does with AUTN, and the order is fixed. It computes the anonymity key AK from RAND, recovers SQN from the SQN Xor AK field, then computes XMAC over SQN, RAND and AMF. If XMAC does not match the MAC carried in AUTN, the USIM stops there and the UE returns #20. The USIM checks that SQN sits in the correct range only when the MAC matches. A failure at that point returns #21.

The separation bit is different. 33.401 clause 6.1.1 puts that check in the ME rather than the USIM, and defines the bit as bit 0 of the AMF field. A USIM built for UMTS has no reason to look at it, so the check belongs where the LTE side controls it. That is why #26 has no UMTS equivalent while #20 and #21 both do.

One consequence is worth carrying into the examples below. A single AUTN can be wrong in more than one way, and the cause value names one check. 24.301 clause 5.4.2.6 lists the three cases separately and does not fix a precedence between the USIM's checks and the ME's. So a vector that is wrong in two places may come back as either cause, depending on the implementation. When you stage a test, change one field at a time. Both examples below do exactly that.

• The USIM checks MAC and SQN : 33.102 clause 6.3.3 fixes that order, so a bad MAC stops the procedure before SQN is examined.
• The ME checks the separation bit : 33.401 puts that one outside the USIM, which is why #26 has no UMTS equivalent.
• AMF is an input to the MAC as well as a field of AUTN : changing AMF changes the expected MAC too. The second example below shows it.
• Change one field per test : the specifications fix no precedence between the two checks. A vector wrong in two places can report either cause.

Example : Invalid MAC Code

Following example is for Invalid MAC Code and this test is based on the following test USIM. This test USIM uses 3GPP Test Algorithm specifed in 34.108

Correct Parameters :

SQN=000000000000
AMF=8000
K=  00112233445566778899AABBCCDDEEFF
--------------------------------------------
RAND=31323131353836343132313135383634
IK=  1302716D5043B9AB9B8AF9E5D8CB3123
CK=  231302716D5043B9AB9B8AF9E5D8CB31
AUTN=02716D5043B9800031231302716DD043

Invalid Parameters used for Test :

SQN=FFFFFFFFFFFF
AMF=8000
K=  00112233445566778899AABBCCDDEEFF
--------------------------------------------
RAND=31323131353836343132313135383634
IK=  1302716D5043B9AB9B8AF9E5D8CB3123
CK=  231302716D5043B9AB9B8AF9E5D8CB31
AUTN=FD8E92AFBC458000CEDCECFD8E92D043

1) Authentication Request

< Authentication Request > RRC and NAS capture. Field values come from a live capture, not from the specification.

DL-DCCH-Message
    message: c1 (0)
        c1: dlInformationTransfer (1)
            dlInformationTransfer
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: dlInformationTransfer-r8 (0)
                        dlInformationTransfer-r8
                            dedicatedInfoType: dedicatedInfoNAS (0)
                                dedicatedInfoNAS: 0752033132313135383634313231313538363410fd8e92af...
                                    Non-Access-Stratum (NAS)PDU
                                        0000 .... = Security header type: Plain NAS message, not security protected (0)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
                                        NAS EPS Mobility Management Message Type: Authentication request (0x52)
                                        0000 .... = Spare half octet: 0
                                        .... 0... = Type of security context flag (TSC): Native security context
                                                    (for KSIasme)
                                        .... .011 = NAS key set identifier:  (3) ASME
                                        Authentication Parameter RAND - EPS challenge
                                            RAND value: 31323131353836343132313135383634
                                        Authentication Parameter AUTN (UMTS and EPS authentication challenge)
                                                                 - EPS challenge
                                            Length: 16
                                            AUTN value: fd8e92afbc458000cedcecfd8e92d043
                                                SQN xor AK: fd8e92afbc45
                                                AMF: 8000
                                                MAC: cedcecfd8e92d043

2) Authentication Failure

< Authentication Failure > RRC and NAS capture. Field values come from a live capture, not from the specification.

UL-DCCH-Message
    message: c1 (0)
        c1: ulInformationTransfer (9)
            ulInformationTransfer
                criticalExtensions: c1 (0)
                    c1: ulInformationTransfer-r8 (0)
                        ulInformationTransfer-r8
                            dedicatedInfoType: dedicatedInfoNAS (0)
                                dedicatedInfoNAS: 1792f6a1a905075c14
                                    Non-Access-Stratum (NAS)PDU
                                        0001 .... = Security header type: Integrity protected (1)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
                                        Message authentication code: 0x92f6a1a9
                                        Sequence number: 5
                                        0000 .... = Security header type: Plain NAS message, not security protected (0)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
                                        NAS EPS Mobility Management Message Type: Authentication failure (0x5c)
                                        EMM cause
                                            Cause: MAC failure (20)

It is worth working out why this particular AUTN produces a MAC failure. The arithmetic is short, and the answer is not the obvious one. Take the transmitted AUTN apart first. Its SQN Xor AK field is FD8E92AFBC45, its AMF is 8000, and its MAC is CEDCECFD8E92D043.

The UE starts from K and RAND, and both are correct here. So it derives the same AK as the network, 02716D5043B9. Undoing the exclusive-or gives the sequence number the UE believes it received. FD8E92AFBC45 Xor 02716D5043B9 comes to FFFFFFFFFFFC, and not the FFFFFFFFFFFF named in the parameter list above.

That one byte is the whole test. The UE now computes XMAC over the sequence number it recovered, which gives CEDCECFD8E91D043. The AUTN carries CEDCECFD8E92D043, which the network computed over FFFFFFFFFFFF. The two differ in a single byte, the comparison fails, and the UE answers with cause #20.

So the injected fault is not a corrupted MAC. The MAC is exactly right for the sequence number the network used. What is inconsistent is the pair. The SQN Xor AK field and the MAC field were built from different sequence numbers. The USIM notices because it recomputes the MAC from the field it was given, not from the value the network intended.

• The MAC itself is not corrupted : it is a correct f1 output for SQN FFFFFFFFFFFF. The fault is that the SQN Xor AK field decodes to FFFFFFFFFFFC.
• The USIM recomputes from what it received : it uses the sequence number it recovers from AUTN, never the value the network meant to send.
• K and RAND are untouched : both sides derive the same AK of 02716D5043B9, which is what makes the comparison meaningful.
• One byte is enough : XMAC comes out as CEDCECFD8E91D043 against a received CEDCECFD8E92D043, and the UE returns cause #20.

Example : Invalid Separation Bit

Following example is for Invalid Separation Bit and this test is based on the following test USIM. This test USIM uses 3GPP Test Algorithm specifed in 34.108

Correct Parameters :

SQN=000000000000
AMF=8000
K=  00112233445566778899AABBCCDDEEFF
--------------------------------------------
RAND=31323131353836343132313135383634
IK=  1302716D5043B9AB9B8AF9E5D8CB3123
CK=  231302716D5043B9AB9B8AF9E5D8CB31
AUTN=02716D5043B9800031231302716DD043

Invalid Parameters used for Test :

SQN=000000000000
AMF=0000
K=  00112233445566778899AABBCCDDEEFF
--------------------------------------------
RAND=31323131353836343132313135383634
IK=1302716D5043B9AB9B8AF9E5D8CB3123
CK=231302716D5043B9AB9B8AF9E5D8CB31
AUTN=02716D5043B9000031231302716D5043

1) Authentication Request

< Authentication Request > RRC and NAS capture. Field values come from a live capture, not from the specification.

DL-DCCH-Message
    message: c1 (0)
        c1: dlInformationTransfer (1)
            dlInformationTransfer
                rrc-TransactionIdentifier: 0
                criticalExtensions: c1 (0)
                    c1: dlInformationTransfer-r8 (0)
                        dlInformationTransfer-r8
                            dedicatedInfoType: dedicatedInfoNAS (0)
                                dedicatedInfoNAS: 075200313231313538363431323131353836341002716d50...
                                    Non-Access-Stratum (NAS)PDU
                                        0000 .... = Security header type: Plain NAS message, not security protected (0)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
                                        NAS EPS Mobility Management Message Type: Authentication request (0x52)
                                        0000 .... = Spare half octet: 0
                                        .... 0... = Type of security context flag (TSC): Native security context (
                                                     for KSIasme)
                                        .... .000 = NAS key set identifier:  (0) ASME
                                        Authentication Parameter RAND - EPS challenge
                                            RAND value: 31323131353836343132313135383634
                                        Authentication Parameter AUTN (UMTS and EPS authentication challenge)
                                                     - EPS challenge
                                            Length: 16
                                            AUTN value: 02716d5043b9000031231302716d5043
                                                SQN xor AK: 02716d5043b9
                                                AMF: 0000
                                                MAC: 31231302716d5043

2) Authentication Failure

< Authentication Failure > RRC and NAS capture. Field values come from a live capture, not from the specification.

UL-DCCH-Message
    message: c1 (0)
        c1: ulInformationTransfer (9)
            ulInformationTransfer
                criticalExtensions: c1 (0)
                    c1: ulInformationTransfer-r8 (0)
                        ulInformationTransfer-r8
                            dedicatedInfoType: dedicatedInfoNAS (0)
                                dedicatedInfoNAS: 075c1a
                                    Non-Access-Stratum (NAS)PDU
                                        0000 .... = Security header type: Plain NAS message, not security protected (0)
                                        .... 0111 = Protocol discriminator: EPS mobility management messages (0x07)
                                        NAS EPS Mobility Management Message Type: Authentication failure (0x5c)
                                        EMM cause
                                            Cause: Non-EPS authentication unacceptable (26)

This example is the opposite case to the one above, and the contrast is the point. Run the same arithmetic on the transmitted AUTN and nothing about it is wrong. Its SQN Xor AK field is 02716D5043B9, and undoing the exclusive-or gives a sequence number of 000000000000. Its MAC is 31231302716D5043, and recomputing XMAC over that sequence number and the AMF of 0000 gives the same value. The MAC check passes, and the sequence number is in range.

Notice that the MAC changed anyway. The correct vector carries 31231302716DD043 and this one carries 31231302716D5043, differing in one byte. That is not tampering. AMF is an input to f1. So moving AMF from 8000 to 0000 changes the expected MAC as a matter of course, and both sides compute the same new value.

What fails is the one check that never touches the algorithm. The AMF is 0000, so bit 0 of it is 0, and 33.401 requires that bit to be 1 for E-UTRAN. The ME refuses the vector, and the UE answers with cause #26. A UMTS-only tester would have accepted this same AUTN without complaint, which is exactly what the separation bit was introduced to prevent.

• The vector is cryptographically valid : the MAC matches and the sequence number is in range, so nothing the USIM checks is wrong.
• Changing AMF changes the MAC too : AMF feeds f1, so the expected MAC moves from 31231302716DD043 to 31231302716D5043 on its own.
• Only the ME objects : bit 0 of AMF is 0, 33.401 requires 1 for E-UTRAN, and the UE returns cause #26.
• This is the case UMTS cannot catch : a UMTS-only tester accepts the same AUTN, which is the reason the separation bit exists.

What about #21 synch failure ?

The table at the top of this page lists a third cause, and the page carries no capture for it. That gap is worth explaining rather than leaving. A synch failure is the one case where the UE returns a parameter rather than just a cause value. It is also the hardest of the three to stage on a test USIM.

A synchronisation failure means the MAC was correct and the sequence number was not. 33.102 clause 6.3.3 puts the range check after the MAC check for that reason. The USIM examines SQN only after it is satisfied that the challenge came from a party holding K. If the recovered sequence number falls outside the range the USIM will accept, it abandons the procedure and reports a synchronisation failure.

The payload is what makes this case different. The USIM supplies a re-synchronisation token, AUTS, and 24.301 clause 5.4.2.6 has the UE carry it in the AUTHENTICATION FAILURE message beside EMM cause #21. 33.102 defines AUTS as Conc(SQN_MS) || MAC-S. The concealed counter is SQN_MS Xor f5*K(RAND), and MAC-S is f1*K(SQN_MS || RAND || AMF). Those starred functions exist for this message and for nothing else. The network hands AUTS to the HSS, which recovers the UE's own counter and issues a fresh vector in step with it.

Staging this on a test USIM is harder than the other two, which is the practical reason no capture appears here. A 3GPP test algorithm USIM normally freezes SQN at a fixed value. The check that would reject an old sequence number is then doing no work. Producing a genuine #21 needs a USIM that keeps a live SQN_MS and a network that then issues a vector with an older counter. That is a running condition rather than a single AUTN you can write down in advance. The other two examples on this page are a pair of hex strings, and this one cannot be.

• Synch failure means the MAC was fine : the USIM checks the sequence number only once it trusts that the challenge came from a party holding K.
• It is the only cause that carries a payload : the UE returns AUTS so the HSS can re-synchronise on the UE's own counter.
• AUTS is where f1* and f5* are used : the starred functions produce MAC-S and the concealed counter, and they appear nowhere else.
• A frozen test USIM cannot show it : the 34.108 test algorithm holds SQN fixed. A real #21 needs a USIM that keeps a live counter.

More vectors you can build for the same test USIM

Both examples above needed a tester and a capture to show them. You can build more of them on paper. The 34.108 algorithm is small enough to run by hand. Every vector below was computed rather than recorded, and you can check any of them with nothing more than an exclusive-or.

The recipe is the one the Authentication page works through. Exclusive-or K with RAND to get XDOUT. The anonymity key AK is bytes 3 to 8 of XDOUT. The MAC is the first eight bytes of XDOUT, exclusive-ored with SQN followed by AMF. AUTN is then SQN Xor AK, then AMF, then MAC. Every row below keeps the K and the RAND used by the examples above, and changes exactly one thing.

These are computed values rather than captures. A tester configured with the change in the first column will send the bytes in the second, but nothing on this page recorded them off the air. The three rows worth walking through are below.

A directly corrupted MAC

The Invalid MAC Code example above returns #20 without anyone touching the MAC field, which makes it a poor first test. This vector is the blunt version. Take the correct AUTN and change one byte of the MAC.

Moving the last byte of the MAC from 43 to 42 gives 02716D5043B9800031231302716DD042. The UE recovers a sequence number of 000000000000, exactly as it should, computes XMAC as 31231302716DD043, and compares that with the 31231302716DD042 it received. One byte differs, so the UE returns #20. Nothing else about the vector is unusual, and that is what makes it useful. Send this one when you want to prove a UE reacts to a MAC failure at all. Keep the subtler vector above for when you want to prove the USIM recomputes the MAC from the sequence number it received rather than the one the network meant to send.

A wrong K does not always look like a wrong K

A mis-provisioned K is the most common authentication fault in the field. The obvious expectation is that it always produces a MAC failure. With this algorithm that is only half true, and which half you get depends on which byte of K is wrong.

Look at where K actually reaches. AUTN is built from AK and MAC. AK is bytes 3 to 8 of XDOUT, and MAC is the first eight bytes. So AUTN depends on bytes 0 to 8 of K and on nothing else. CK and IK are rotations of the whole of XDOUT, so they depend on all sixteen bytes.

That split produces two very different failures. Set byte 0 of K to 01 instead of 00, and the network sends 02716D5043B9800030231302716DD043. The UE derives the same AK, recovers a sequence number of 000000000000, computes XMAC as 31231302716DD043, and finds 30231302716DD043 in the message. The MAC check fails and the UE returns #20. That is the behaviour everyone expects from a wrong K.

Now set byte 15 of K to 00 and leave the first nine bytes alone. The network sends 02716D5043B9800031231302716DD043, which is the correct vector byte for byte, and the UE accepts it. RES is the leading bits of XDOUT, so with the usual 64-bit RES the network's check against XRES passes as well and the authentication completes. What differs is the key material. The correct CK is 231302716D5043B9AB9B8AF9E5D8CB31, and this USIM produces 231302716D5043B9AB9B8AF9E5D83431.

So the call fails afterwards, at the Security Mode Command, while the authentication log looks perfect. That is worth knowing before you spend an afternoon reading Authentication Request messages that were never wrong.

Which bit of AMF actually matters

The Invalid Separation Bit example above uses an AMF of 0000, which changes sixteen bits at once. That leaves an obvious question open. Is the UE reacting to the whole field, or to one bit of it ? Two more vectors settle it.

Set AMF to 8001. The network sends 02716D5043B9800131231302716DD042 and the UE accepts it. Bit 0 of AMF is still 1, and the other fifteen bits are free for an operator to use. Notice that the MAC moved from ...D043 to ...D042, because AMF feeds f1 whichever bit of it you change.

Now set AMF to 0001. The network sends 02716D5043B9000131231302716D5042. The MAC is correct and the sequence number is in range, but bit 0 is 0, so the UE returns #26. The field is not zero, and the UE objects anyway.

One more vector fixes the boundary exactly. AMF 7FFF has fifteen bits set and bit 0 clear, and it is refused. AMF 8000 has a single bit set and it is accepted. Only bit 0 is read.

• Every vector here is computed, not captured : the 34.108 algorithm is deterministic, so a tester given the change in the first column sends exactly the bytes in the second.
• A corrupted MAC is the blunt test : flip one byte of the MAC field for a #20 that depends on nothing else in the vector.
• Only bytes 0 to 8 of K reach AUTN : a K wrong in its last seven bytes authenticates cleanly and then breaks ciphering, because CK and IK use all sixteen.
• Only bit 0 of AMF is read : AMF 8001 is accepted and 7FFF is refused, so the other fifteen bits carry no weight in this check.

Reference

The clause numbers sit beside each claim above, so the wording can be checked rather than taken on trust. The key derivation and the algorithm this page's test USIM uses are covered on Authentication.

• 33.102 - 3G Security; Security architecture, v19.1.0. Clause 6.3.3 is the order the USIM checks AUTN in, and the definition of the AUTS re-synchronisation token.
• 33.401 - 3GPP System Architecture Evolution (SAE); Security architecture, v19.2.0. Clause 6.1.1 places the separation bit check in the ME and defines the bit as bit 0 of AMF.
• 24.301 - Non-Access-Stratum (NAS) protocol for EPS; Stage 3, v20.0.0. Clause 5.4.2.6 lists the three causes the UE may return, with EMM causes #20, #21 and #26.