22.5.1 NB-IoT / Authentication not accepted by the network, GUTI used / Authentication not accepted by the UE, SQN failure / Authentication not accepted by the UE, non-EPS authentication unacceptable / Network failing the authentication check

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

22.5.1.1 Test Purpose (TP)

(1)

with { UE having sent an initial NAS message with type of identity GUTI }

ensure that {

when { as a result of failure of an Authentication procedure initiated by the network the UE receives an AUTHENTICATION REJECT message }

then { the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME and enter state EMM-DEREGISTERED }

}

(2)

with { a NAS signalling connection existing }

ensure that {
when { the UE receives an AUTHENTICATION REQUEST message with SQN out of range }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with EMM cause "synch failure" and a re-synchronization token }

}

(3)

with { UE having sent an AUTHENTICATION FAILURE message to the network, with EMM cause "synch failure" }

ensure that {
when { the UE receives a new correct AUTHENTICATION REQUEST message while T3420 is running }

then { the UE sends a correct AUTHENTICATION RESPONSE message }

}

(4)

with { a NAS signalling connection existing }

ensure that {

when { the UE receives an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0 }

then { the UE shall send an AUTHENTICATION FAILURE message to the network, with the reject cause #26 "non-EPS authentication unacceptable" }

}

(5)

with { UE having sent an AUTHENTICATION FAILURE message to the network, with EMM cause "non-EPS authentication unacceptable" }

ensure that {
when { the UE receives a new correct AUTHENTICATION REQUEST message while T3420 is running }

then { the UE sends a correct AUTHENTICATION RESPONSE message }

}

(6)

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}

ensure that {

when { UE receives an AUTHENTICATION REQUEST message but UE deems that the network failed the authentication check (it has been deemed by the UE that the source of the authentication challenge is not genuine) }

then { UE locally releases the RRC connection and treats the active cell as barred }

}

22.5.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.5, 5.4.2.6, 5.4.2.7, 4.7, TS 36.304, clause 5.3.1. Unless otherwise stated these are Rel-13 requirements.

[TS 24.301, clause 5.4.2.5]

Upon receipt of an AUTHENTICATION REJECT message,

a) if the message has been successfully integrity checked by the NAS, the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME. The USIM shall be considered invalid until switching off the UE or the UICC containing the USIM is removed. If the UE maintains a counter for "SIM/USIM considered invalid for GPRS services", then the UE shall set this counter to UE implementation-specific maximum value.

[TS 24.301, clause 5.4.2.6]

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network.

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 3GPP TS 33.401 [19]). This parameter contains three possible causes for authentication failure:

a) MAC code failure:

If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 "MAC failure". The UE shall then follow the procedure described in subclause 5.4.2.7, item c.

b) Non-EPS authentication unacceptable:

If the UE finds that the "separation bit" in the AMF field of AUTN supplied by the core network is 0, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #26 "non-EPS authentication unacceptable" (see subclause 6.1.1 in 3GPP TS 33.401 [19]). The UE shall then follow the procedure described in subclause 5.4.2.7, item d.

c) SQN failure:

If the UE finds the SQN (supplied by the core network in the AUTN parameter) to be out of range, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [18]). The UE shall then follow the procedure described in subclause 5.4.2.7, item e.

If the UE returns an AUTHENTICATION FAILURE message to the network, the UE shall delete any previously stored RAND and RES and shall stop timer T3416, if running.

[TS 24.301, clause 5.4.2.7]

c) Authentication failure (EMM cause #20 "MAC failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #20 "MAC failure" according to subclause 5.4.2.6, to the network and start timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #20 "MAC failure", the network may initiate the identification procedure described in subclause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

…

It can be assumed that the source of the authentication challenge is not genuine (authentication not accepted by the UE) if any of the following occur:

– the timer T3418 expires;

…

When it has been deemed by the UE that the source of the authentication challenge is not genuine (i.e. authentication not accepted by the UE), the UE shall proceed as described in item f.

…

d) Authentication failure (EMM cause #26 "non-EPS authentication unacceptable"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #26 "non-EPS authentication unacceptable", to the network and start the timer T3418 (see example in figure 5.4.2.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with EMM cause #26 "non-EPS authentication unacceptable", the network may initiate the identification procedure described in subclause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The network may then check that the GUTI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the IDENTITY RESPONSE message.

…

If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST message from the network, the UE shall stop the timer T3418, if running, and then process the challenge information as normal. If the GUTI/IMSI mapping in the network was correct, the network should terminate the authentication procedure by sending an AUTHENTICATION REJECT message (see subclause 5.4.2.5).

…

e) Authentication failure (EMM cause #21 "synch failure"):

The UE shall send an AUTHENTICATION FAILURE message, with EMM cause #21 "synch failure", to the network and start the timer T3420 (see example in figure 5.4.2.7.2). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with the EMM cause #21 "synch failure", the network shall use the returned AUTS parameter from the authentication failure parameter IE in the AUTHENTICATION FAILURE message, to re-synchronise. The re-synchronisation procedure requires the MME to delete all unused authentication vectors for that IMSI and obtain new vectors from the HSS. When re-synchronisation is complete, the network shall initiate the authentication procedure. Upon receipt of the AUTHENTICATION REQUEST message, the UE shall stop the timer T3420, if running.

…

If the network is validated successfully (a new AUTHENTICATION REQUEST message is received which contains a valid SQN and MAC) while T3420 is running, the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

…

f) Network failing the authentication check:

If the UE deems that the network has failed the authentication check, then it shall request RRC to locally release the RRC connection and treat the active cell as barred (see 3GPP TS 36.304 [21]). The UE shall start any retransmission timers (e.g. T3410, T3417, T3421 or T3430), if they were running and stopped when the UE received the first AUTHENTICATION REQUEST message containing an invalid MAC or SQN.

[TS 36.304, clause 5.3.1]

When cell status "barred" is indicated or to be treated as if the cell status is "barred",

– The UE is not permitted to select/reselect this cell, not even for emergency calls.

– The UE shall select another cell according to the following rule:

…

– else

…

– else

– If the field intraFreqReselection in field cellAccessRelatedInfo in SystemInformationBlockType1 (or SystemInformationBlockType1-NB) message is set to "allowed", the UE may select another cell on the same frequency if re-selection criteria are fulfilled.

– The UE shall exclude the barred cell as a candidate for cell selection/reselection for 300 seconds.

– If the field intraFreqReselection in field cellAccessRelatedInfo in SystemInformationBlockType1 (or SystemInformationBlockType1-NB) message is set to "not allowed" the UE shall not re-select a cell on the same frequency as the barred cell;

– The UE shall exclude the barred cell and the cells on the same frequency as a candidate for cell selection/reselection for 300 seconds.

[TS 24.301, clause 4.7]

A UE in NB-S1 mode (see 3GPP TS 36.331 [22]) shall calculate the value of the applicable NAS timers:

– indicated in table 10.2.1 plus 240s; and

– indicated in table 10.3.1 plus 180s.

The timer value obtained is used as described in the appropriate procedure subclause of this specification. The NAS timer value shall be calculated at start of a NAS procedure and shall not re-calculate the use of the multiplier until the NAS procedure is completed, restarted or aborted.

22.5.1.3 Test description

22.5.1.3.1 Pre-test conditions

System Simulator:

– 2 NB-IoT cells, Ncell 1 and Ncell 11, default system information

– Ncell 1, set to "Serving cell"

– Ncell 2, set to "Non-Suitable cell"

UE:

None.

Preamble:

– The UE is in NB-IoT UE Attach, Connected mode (State 11-NB) on Ncell 1 according to TS 36.508 [18].

22.5.1.3.2 Test procedure sequence

Table 22.5.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits an AUTHENTICATION REQUEST message intended to establish a new EPS security context.

NOTE: The message is integrity protected and ciphered with the EPS security context established during the preamble.

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

2

The UE transmits an AUTHENTICATION RESPONSE message.

NOTE: Because step 3 sends reject regardless of whether the AUTHENTICATION RESPONSE message is correct or not, the correctness of the AUTHENTICATION RESPONSE message e.g. integrity protection, ciphering, content, etc. needs not to be checked.

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION RESPONSE

–

–

3

The SS transmits an AUTHENTICATION REJECT message.

NOTE: The message is integrity protected and ciphered with the EPS security context established during the preamble.

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REJECT

–

–

4

SS releases the RRC connection

<–

RRC: RRCConnectionRelease-NB

–

–

5

Check: Does the UE transmit an RRCConnectionRequest-NB message in the next 30 seconds?

–>

RRC: RRCConnectionRequest-NB

1

F

6

SS sends a Paging message to the UE on the appropriate paging block, and including the UE identity in one entry of the IE pagingRecordLists.

<–

RRC: Paging-NB

–

–

7

Check: Does the UE transmit an RRCConnectionRequest-NB message in the next 30 seconds?

–>

RRC: RRCConnectionRequest-NB

1

F

8

If possible (see ICS) switch off is performed or the USIM is removed.

Otherwise the power is removed.

–

–

–

–

9

The UE is brought back to operation or the USIM is inserted.

–

–

–

–

10

The Generic procedure ‘NB-IoT UE Attach, Connected mode (State 2-NB)’ specified in TS 36.508 [18], clause 8.1.5.2 takes place.

–

–

–

–

11

SS transmits AUTHENTICATION REQUEST message with the AMF field in the IE "Authentication parameter AUTN" set to "AMFRESYNCH" (SQN out of range) value to trigger SQN re-synchronisation procedure in test USIM

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

12

Check: Does the UE respond with an AUTHENTICATION FAILURE message, with EMM cause "synch failure"?

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION FAILURE

2

P

13

SS waits for 5 sec.

–

–

–

–

14

The SS transmits a correct AUTHENTICATION REQUEST message (this simulates re-synchronisation).

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

15

Check: Does the UE respond with AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS?

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION RESPONSE

3

P

16

SS waits for 5 sec.

–

–

–

–

17

SS transmits an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0.

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

18

Check: Does the UE respond with an AUTHENTICATION FAILURE message, with reject cause "non-EPS authentication unacceptable"?

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION FAILURE

4

P

19

The SS transmits an IDENTITY REQUEST message.

<–

RRC: DLInformationTransfer-NB

NAS: IDENTITY REQUEST

–

–

20

The UE transmit an IDENTITY RESPONSE message.

–>

RRC: ULInformationTransfer-NB

NAS: IDENTITY RESPONSE

–

–

21

The SS transmits an AUTHENTICATION REQUEST message.

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

22

Check: Does the UE respond with AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS?

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION RESPONSE

5

P

23

SS waits for 5 sec.

–

–

–

–

24

SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code.

NOTE: Change the RAND value.

<–

RRC: DLInformationTransfer-NB

NAS: AUTHENTICATION REQUEST

–

–

25

UE responds with an AUTHENTICATION FAILURE message, with reject cause "MAC failure".

–>

RRC: ULInformationTransfer-NB

NAS: AUTHENTICATION FAILURE

6

P

25A

SS starts timer T3418 (20s+240s)

–

–

–

–

26

SS waits for the expiration of T3418 (20s+240s).

NOTE: After T3418 expires the UE shall consider the cell as "barred".

–

–

–

–

27

SS sends a Paging message to the UE on the appropriate paging block, and including the UE identity in one entry of the IE pagingRecordLists.

<–

RRC: Paging-NB

–

–

28

Check: Does the UE transmit an RRCConnectionRequest-NB message in the next 30 seconds?

–>

RRC: RRCConnectionRequest-NB

6

F

29

The SS configures:

– Ncell 2 as the "Serving cell".

– Ncell 1 as a "Suitable cell".

–

–

–

–

30a

The Generic procedure “Test procedure to check that NB-IoT UE is camped on a new NB-IOT cell” specified in 36.508[18], clause 8.1.5A.5 takes place on Ncell11
22.5.1.3.3 Specific message contents

Table 22.5.1.3.3-1: SystemInformationBlockType1-NB (all cells, Preamble and all steps)

Derivation Path: 36.508 [18], Table 8.1.4.3.2-3, condition ATTACH_WITHOUT_PDN

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1-NB ::= SEQUENCE {

cellAccessRelatedInfo-r13 SEQUENCE {

cellBarred-r13

notBarred

intraFreqReselection-r13

allowed

}

}

Table 22.5.1.3.3-2: ATTACH REQUEST (step 10, Table 22.5.1.3.2-1; steps 4a1 or 4b1 TS 36.508, Table 8.1.5.2.3-1)

Derivation Path: 36.508 [18], Table 4.7.2-4

Information Element

Value/remark

Comment

Condition

NAS key set identifier

‘111’B

no key is available

Old GUTI or IMSI

IMSI

Last visited registered TAI

Not Present

Table 22.5.1.3.3-3: AUTHENTICATION REQUEST (step 11, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

AMF field set to "AMFRESYNCH"

SQN out of range

Table 22.5.1.3.3-4: AUTHENTICATION FAILURE (step 12, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 0101’B

Synch failure

Authentication failure parameter

‘1111 1111 1111 1111’B

AMFRESYNCH see TS 34.108, 8.1.2.2

Table 22.5.1.3.3-5: AUTHENTICATION RESPONSE (step 15, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-8

Information Element

Value/remark

Comment

Condition

Authentication response parameter

RES equal to the XRES calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST

Table 22.5.1.3.3-6: AUTHENTICATION REQUEST (step 17, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

"separation bit"=0

The "separation bit" in the AMF field of AUTN supplied by the core network is 0.

Table 22.5.1.3.3-7: AUTHENTICATION FAILURE (step 18, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 1010’B

non-EPS authentication unacceptable

Table 22.5.1.3.3-8: AUTHENTICATION REQUEST (step 24, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-7

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

Invalid MAC

SS shall calculate the correct MAC value as specified in TS 33.401 and use any different value, e.g. correct_MAC+5.

Table 22.5.1.3.3-9: AUTHENTICATION FAILURE (step 25, Table 22.5.1.3.2-1)

Derivation Path: 36.508 [18], Table 4.7.2-5

Information Element

Value/remark

Comment

Condition

EMM cause

‘0001 0100’B

MAC failure

Authentication failure parameter

Not present