9.1 EMM common procedures
36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification
9.1.1 Void
9.1.1.1 Void
9.1.1.2 Void
9.1.2 Authentication procedure
9.1.2.1 Void
NOTE: The present test (Authentication accepted) is superseded by test case 9.1.2.3 (i.e. all requirements which the present test verified are verified in test case 9.1.2.3).
9.1.2.2 Void
9.1.2.3 Authentication not accepted by the network / GUTI used / Authentication reject and re-authentication
9.1.2.3.1 Test Purpose (TP)
(1)
with { UE having sent an initial NAS message with type of identity GUTI }
ensure that {
when { UE receives an AUTHENTICATION REJECT message as a result of failure of an Authentication procedure initiated by the network }
then { 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 { UE having a NAS signalling connection existing }
ensure that {
when { UE receives an AUTHENTICATION REQUEST message }
then { UE responds with a correct AUTHENTICATION RESPONSE message and establishes correct EPS security context }
}
9.1.2.3.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.1, 5.4.2.3 and 5.4.2.5 and TS 36.331, clause 5.3.8.3. Unless otherwise stated these are Rel-8 requirements.
[TS 24.301, clause 5.4.2.5]
Upon receipt of an AUTHENTICATION REJECT message, 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 AUTHENTICATION REJECT message is received by the UE, the UE shall abort any EMM signalling procedure, stop any of the timers T3410, T3417 or T3430 (if running) and enter state EMM-DEREGISTERED.
[TS 24.301, clause 5.4.2.1]
The UE shall support the EPS authentication challenge only if a USIM is present.
An EPS security context is established in the UE and the network when an EPS authentication is successfully performed. During a successful EPS authentication, the CK and IK keys are computed. CK and IK are then used as key material to compute a new key, KASME. KASME is stored in the EPS security contexts (see 3GPP TS 33.401 [19]) of both the network and the UE, and is the root for the EPS integrity protection and ciphering key hierarchy.
[TS 24.301, clause 5.4.2.3]
The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in subclause 5.4.2.6, the UE shall process the authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network.
Upon a successful EPS authentication challenge, the new KASME calculated from the authentication challenge data shall be stored in a new EPS security context.
[TS 33.401, clause 6.1.1]
UE shall compute KASME from CK, IK, and serving network’s identity (SN id) using the KDF as specified in Annex A. SN id binding implicitly authenticates the serving network’s identity when the derived keys from KASME are successfully used.
…
UE shall respond with User authentication response message including RES in case of successful AUTN verification as described in TS 33.102[4] and successful AMF verification as described above. Otherwise UE shall send User authentication reject message with a proper CAUSE value.
9.1.2.3.3 Test description
9.1.2.3.3.1 Pre-test conditions
System Simulator:
– Cell A.
UE:
– The UE is previously registered on E-UTRAN, and when on E-UTRAN, the UE is last authenticated and registered on cell A using default message contents according to TS 36.508 [18].
Preamble:
– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].
9.1.2.3.3.2 Test procedure sequence
Table 9.1.2.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Switch the UE on |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a GUTI and a PDN CONNECTIVITY REQUEST message |
–> |
ATTACH REQUEST |
– |
– |
3 |
The SS transmits an AUTHENTICATION REQUEST message without integrity protection and ciphering |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
The UE transmits an AUTHENTICATION RESPONSE. |
–> |
AUTHENTICATION RESPONSE |
– |
– |
5 |
The SS transmits an AUTHENTICATION REJECT message without integrity protection and ciphering |
<– |
AUTHENTICATION REJECT |
– |
– |
6 |
SS releases the RRC connection |
– |
– |
– |
– |
7 |
Check: Does the UE transmit an ATTACH REQUEST message in the next 30 seconds? |
–> |
ATTACH REQUEST |
1 |
F |
8 |
Check: Does the test result of the generic procedure defined in clause 6.4.2.5 of 36.508 [18] indicates that the UE responds to paging when paged with S-TMSI include GUTI-1 and with CN domain indicator set to "PS"? |
– |
– |
1 |
– |
9 |
Check: Does the test result of the generic procedure defined in clause 6.4.2.5 of 36.508 [18] indicates that the UE responds to paging when paged with IMSI and with CN domain indicator set to "PS"? |
– |
– |
1 |
– |
10 |
If possible (see ICS) switch off is performed or the USIM is removed. Otherwise the power is removed. |
– |
– |
– |
– |
11 |
The UE is brought back to operation or the USIM is inserted. |
– |
– |
– |
– |
12 |
Check: Does the UE transmit a NOT integrity protected ATTACH REQUEST message including IMSI and a PDN CONNECTIVITY REQUEST message? |
–> |
ATTACH REQUEST |
1 |
P |
13 |
The SS transmits an AUTHENTICATION REQUEST message without integrity protection and ciphering |
<– |
AUTHENTICATION REQUEST |
– |
– |
14 |
The UE transmits an AUTHENTICATION RESPONSE. |
–> |
AUTHENTICATION RESPONSE |
2 |
P |
15 |
SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 3) |
<– |
SECURITY MODE COMMAND |
– |
– |
16 |
Check: Does the UE respond with NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 5 |
–> |
SECURITY MODE COMPLETE |
2 |
P |
17a1-26b1 |
The attach procedure is completed by executing steps 9a1 to 18b1 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
9.1.2.3.3.3 Specific message contents
Table 9.1.2.3.3.3-1a: ATTACH REQUEST (step 2, Table 9.1.2.3.3.2-1)
Derivation Path: 36.508, Table 4.7.2-4 |
|||
Information Element |
Value/remark |
Comment |
Condition |
Old GUTI or IMSI |
GUTI-1 |
GUTI allocated in pre-test conditions. |
Table 9.1.2.3.3.3-1: ATTACH REQUEST (step 12, Table 9.1.2.3.3.2-1)
Derivation Path: 36.508, 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 9.1.2.3.3.3-3: AUTHENTICATION RESPONSE (step 14, Table 9.1.2.3.3.2-1)
Derivation Path: 36.508, 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 |
9.1.2.4 Authentication not accepted by the UE / MAC code failure
9.1.2.4.1 Test Purpose (TP)
(1)
with { a NAS signalling connection existing }
ensure that {
when { the UE receives an AUTHENTICATION REQUEST message with invalid MAC code }
then { the UE shall send an AUTHENTICATION FAILURE message to the network, with the reject cause #20 "MAC failure" }
}
9.1.2.4.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6.
[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.
[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.
…
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.
9.1.2.4.3 Test description
9.1.2.4.3.1 Pre-test conditions
System Simulator:
– Cell A.
UE:
None.
Preamble:
– The UE is in state Switched OFF (State 1) according to TS 36.508 [18].
9.1.2.4.3.2 Test procedure sequence
Table 9.1.2.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Switch the UE on |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message |
–> |
ATTACH REQUEST |
– |
– |
3 |
SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
Check: Does the UE respond with an AUTHENTICATION FAILURE message, with reject cause "MAC failure"? |
–> |
AUTHENTICATION FAILURE |
1 |
P |
5 |
SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type |
<– |
IDENTITY REQUEST |
– |
– |
6 |
The UE responds with a correct IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity |
–> |
IDENTITY RESPONSE |
– |
– |
7 |
SS transmits a correct AUTHENTICATION REQUEST message, RAND different to the one send in Step 3 |
<– |
AUTHENTICATION REQUEST |
– |
– |
8 |
Check: Does the UE respond with a correct AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS? |
–> |
AUTHENTICATION RESPONSE |
1 |
P |
9 |
SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8) |
<– |
SECURITY MODE COMMAND |
– |
– |
10 |
UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9 |
–> |
SECURITY MODE COMPLETE |
– |
– |
11a1-20b1 |
Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
9.1.2.4.3.3 Specific message contents
Table 9.1.2.4.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.4.3.2-1)
Derivation Path: 36.508, 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.102 and use any different value, e.g. correct_MAC+5. |
Table 9.1.2.4.3.3-2: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.4.3.2-1)
Derivation Path: 36.508, 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 |
9.1.2.5 Authentication not accepted by the UE / SQN failure
9.1.2.5.1 Test Purpose (TP)
(1)
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 }
}
(2)
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 }
}
9.1.2.5.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6 and 5.4.2.7.
[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:
…
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.
[TS 24.301, clause 5.4.2.7]
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 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.
9.1.2.5.3 Test description
9.1.2.5.3.1 Pre-test conditions
System Simulator:
– cell A.
UE:
none.
Preamble:
– the UE is in state Switched OFF (State 1) according to TS 36.508 [18].
9.1.2.5.3.2 Test procedure sequence
Table 9.1.2.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Switch the UE on |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message |
–> |
ATTACH REQUEST |
– |
– |
3 |
SS transmits AUTHENTICATION REQUEST message with the AMF field in the IE "Authentication parameter AUTN" set to "AMFRESYNCH" value to trigger SQN re-synchronisation procedure in test USIM |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
Check: Does the UE respond with an AUTHENTICATION FAILURE message, with EMM cause "synch failure"? |
–> |
AUTHENTICATION FAILURE |
1 |
P |
5 |
SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type |
<– |
IDENTITY REQUEST |
– |
– |
6 |
The UE responds with IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity |
–> |
IDENTITY RESPONSE |
– |
– |
7 |
SS transmits AUTHENTICATION REQUEST message (Note 1) |
<– |
AUTHENTICATION REQUEST |
– |
– |
8 |
Check: Does the UE respond with AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS? |
–> |
AUTHENTICATION RESPONSE |
2 |
P |
9 |
SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8) |
<– |
SECURITY MODE COMMAND |
– |
– |
10 |
UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9 |
–> |
SECURITY MODE COMPLETE |
– |
– |
10Aa1-19b1 |
Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
Note 1: The SS shall ensure that the AUTHENTICATION REQUEST message sent in step 7 is sent less than (T3420-10%) sec after the message sent in step 4 otherwise it cannot be ensured that the UE will behave as specified in step 8. |
9.1.2.5.3.3 Specific message contents
Table 9.1.2.5.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.5.3.2-1)
Derivation Path: 36.508, Table 4.7.2-7 |
|||
Information Element |
Value/remark |
Comment |
Condition |
Authentication parameter AUTN |
AMF field set to "AMFRESYNCH" |
Table 9.1.2.5.3.3-2: AUTHENTICATION FAILURE (step 4, Table 9.1.2.5.3.2-1)
Derivation Path: 36.508, 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 9.1.2.5.3.3-3: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.5.3.2-1)
Derivation Path: 36.508, 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 |
9.1.2.6 Abnormal cases / Network failing the authentication check
9.1.2.6.1 Test Purpose (TP)
(1)
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 }
then { UE locally release the RRC connection and treat the active cell as barred }
}
9.1.2.6.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.2.7.
[TS 24.301, clause 5.4.2.7]
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:
– after sending the AUTHENTICATION FAILURE message with the EMM cause #20 "MAC failure" 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.
…
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.331 [22]). 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.
9.1.2.6.3 Test description
9.1.2.6.3.1 Pre-test conditions
System Simulator:
– Cell A and Cell B are configured according to table 6.3.2.2-1 in TS 36.508 [18]
UE:
none.
Preamble:
– the UE is in state Switched OFF (state 1) according to clause [18].
9.1.2.6.3.2 Test procedure sequence
Table 9.1.2.6.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS configures: – Cell A as the "Serving cell". – Cell B as a " Suitable neighbour intra-frequency cell". |
– |
– |
– |
– |
– |
The following messages are to be observed on Cell A unless explicitly stated otherwise. |
– |
– |
– |
– |
2 |
The UE is switched on. |
– |
– |
– |
– |
3 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message. |
–> |
ATTACH REQUEST |
– |
– |
4 |
SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code |
<– |
AUTHENTICATION REQUEST |
– |
– |
5 |
UE responds with an AUTHENTICATION FAILURE message, with reject cause "MAC failure". |
–> |
AUTHENTICATION FAILURE |
– |
– |
6 |
SS responds nothing and waits for the expiration of T3418. |
||||
6A |
The SS configures: – Cell B as the "Serving cell". – Cell A as a " Suitable neighbour intra-frequency cell". |
– |
– |
– |
– |
– |
The following messages are to be observed on Cell B unless explicitly stated otherwise. |
– |
– |
– |
– |
7 |
Check: Does the UE transmit an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message? |
–> |
ATTACH REQUEST |
1 |
P |
8-21b1 |
The attach procedure is completed by executing steps 5 to 18b1 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
9.1.2.6.3.3 Specific message contents
Table 9.1.2.6.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.6.3.2-1)
Derivation Path: 36.508, 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 9.1.2.6.3.3-2: AUTHENTICATION FAILURE (step 5, Table 9.1.2.6.3.2-1)
Derivation Path: 36.508, Table 4.7.2-5 |
|||
Information Element |
Value/remark |
Comment |
Condition |
EMM cause |
‘0001 0100’B |
MAC failure |
|
Authentication failure parameter |
Not present |
Table 9.1.2.6.3.3-3: SystemInformationBlockType1(Cell A, Preamble and all steps)
Derivation Path: 36.508 Table 4.4.3.2-3 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SystemInformationBlockType1 ::= SEQUENCE { |
|||
cellAccessRelatedInfo SEQUENCE { |
|||
cellBarred |
notBarred |
||
intraFreqReselection |
allowed |
||
} |
|||
} |
Table 9.1.2.6.3.3-4: SystemInformationBlockType1-BR-r13 (Cell A, Preamble and all steps when UE under test is CAT M1)
Derivation Path: 36.508 Table 4.4.3.2-3A |
|||
Information Element |
Value/remark |
Comment |
Condition |
SystemInformationBlockType1-BR-r13 ::= SEQUENCE { |
|||
cellAccessRelatedInfo SEQUENCE { |
|||
cellBarred |
notBarred |
||
intraFreqReselection |
allowed |
||
} |
|||
} |
9.1.2.7 Authentication not accepted by the UE/ non-EPS authentication unacceptable
9.1.2.7.1 Test Purpose (TP)
(1)
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 " }
}
9.1.2.7.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6 and 5.4.2.7.
[TS 24.301, clause 5.4.2.6]
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:
…
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.
…
[TS 24.301, clause 5.4.2.7]
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.
…
9.1.2.7.3 Test description
9.1.2.7.3.1 Pre-test conditions
System Simulator:
– cell A.
UE:
none.
Preamble:
– the UE is in state Switched OFF (State 1) according to TS 36.508 [18].
9.1.2.7.3.2 Test procedure sequence
Table 9.1.2.7.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Switch the UE on |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message |
–> |
ATTACH REQUEST |
– |
– |
3 |
SS transmits an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0. |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
Check: Does the UE respond with an AUTHENTICATION FAILURE message, with reject cause "non-EPS authentication unacceptable"? |
–> |
AUTHENTICATION FAILURE |
1 |
P |
5 |
SS transmits an IDENTITY REQUEST message requesting IMSI in the IE Identity type |
<– |
IDENTITY REQUEST |
– |
– |
6 |
The UE responds with a correct IDENTITY RESPONSE message providing its IMSI in the IE Mobile Identity |
–> |
IDENTITY RESPONSE |
– |
– |
7 |
SS transmits a correct AUTHENTICATION REQUEST message, RAND different to the one send in Step 3 |
<– |
AUTHENTICATION REQUEST |
– |
– |
8 |
Check: Does the UE respond with a correct AUTHENTICATION RESPONSE message with RES that is equal to the XRES calculated in the SS? |
–> |
AUTHENTICATION RESPONSE |
1 |
P |
9 |
SS transmits a NAS SECURITY MODE COMMAND message including the KSIASME of the new EPS security context (as provided in step 8) |
<– |
SECURITY MODE COMMAND |
– |
– |
10 |
UE transmits a NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new EPS security context identified by the KSIASME received in the SECURITY MODE COMMAND message in step 9 |
–> |
SECURITY MODE COMPLETE |
– |
– |
10Aa1-19b1 |
Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
9.1.2.7.3.3 Specific message contents
Table 9.1.2.7.3.3-1: AUTHENTICATION REQUEST (step 3, Table 9.1.2.7.3.2-1)
Derivation Path: 36.508, 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 9.1.2.7.3.3-2: AUTHENTICATION FAILURE (step 4, Table 9.1.2.7.3.2-1)
Derivation Path: 36.508, Table 4.7.2-5 |
|||
Information Element |
Value/remark |
Comment |
Condition |
EMM cause |
‘0001 1010’B |
non-EPS authentication unacceptable |
Table 9.1.2.7.3.3-3: AUTHENTICATION RESPONSE (step 8, Table 9.1.2.7.3.2-1)
Derivation Path: 36.508, 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 |
9.1.3 Security mode control procedure
9.1.3.1 NAS security mode command accepted by the UE
9.1.3.1.1 Test Purpose (TP)
(1)
with { successful completion of EPS authentication and key agreement (AKA) procedure }
ensure that {
when { UE receives an integrity protected SECURITY MODE COMMAND message including replayed security capabilities and IMEISV request }
then { UE sends an integrity protected and ciphered SECURITY MODE COMPLETE message including IMEISV and starts applying the NAS Security in both UL and DL }
}
(2)
with { NAS Security Activated and EPS Authentication and key agreement procedure is executed for new Key generation }
ensure that {
when { UE receives an integrity protected SECURITY MODE COMMAND message corresponding to NAS count reset to zero including replayed security capabilities and IMEISV request }
then { UE sends integrity protected and ciphered SECURITY MODE COMPLETE message with NAS count set to zero including IMEISV and starts applying the NAS Security in both UL and DL }
}
9.1.3.1.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.3.1, 5.4.3.1, 5.4.3.2 and 5.4.3.3.
[TS 24.301, clause 4.4.3.1]
Each EPS NAS security context shall be associated with two separate counters NAS COUNT: one related to uplink NAS messages and one related to downlink NAS messages. The NAS COUNT counters use 24 bit internal representation and are independently maintained by UE and MME. The NAS COUNT shall be constructed as a NAS sequence number (8 least significant bits) concatenated with a NAS overflow counter (16 most significant bits).
When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it shall be considered to be a 32-bit entity which shall be constructed by padding the 24-bit internal representation with 8 zeros in the most significant bits.
During the handover from UTRAN/GERAN to E-UTRAN, if the mapped EPS security context is taken into use, the NAS COUNT values for this EPS security context shall be initialized to zero in the UE and the network for uplink and downlink NAS messages.
The NAS sequence number part of the NAS COUNT shall be exchanged between the UE and the MME as part of the NAS signalling. After each new or retransmitted outbound security protected NAS message, the sender shall increase the NAS COUNT number by one. Specifically, on the sender side, the NAS sequence number shall be increased by one, and if the result is zero (due to wrap around), the NAS overflow counter shall also be incremented by one (see subclause 4.4.3.5). The receiving side shall estimate the NAS COUNT used by the sending side. Specifically, if the estimated NAS sequence number wraps around, the NAS overflow counter shall be incremented by one.
[TS 24.301, clause 5.4.3.1]
The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and start NAS signalling security between the UE and the MME with the corresponding NAS keys and security algorithms.
[TS 24.301, clause 5.4.3.2]
The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message to the UE and starting timer T3460 (see example in figure 5.4.3.2.1).
If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message.
The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on KASME or mapped K’ASME indicated by the eKSI included in the message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".
…
The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonceUE if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI).
Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message.
NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it is also be supported for AS.
[TS 24.301, clause 5.4.3.3]
Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure.
If the type of security context flag is set to "native security context" and if the KSI matches a valid native EPS security context held in the UE while the UE has a mapped EPS security context as the current security context, the UE shall take the native EPS security context into use. The UE shall store the native EPS security context, as specified in annex C.
If the security mode command can be accepted, the UE shall reset the uplink NAS COUNT and the UE shall take the new EPS security context into use when:
a) the SECURITY MODE COMMAND message is received further to a successful execution of the authentication procedure; or
b) the type of security context flag is set to "mapped security context" in the NAS KSI IE included in the SECURITY MODE COMMAND message.
If the security mode command can be accepted and the eKSI was included in the SECURITY MODE COMMAND message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS integrity algorithm and the NAS integrity key based on the KASME or mapped K’ASME if the type of security context flag is set to "mapped security context" indicated by the eKSI. If the SECURITY MODE COMMAND message includes the type of security context flag set to "mapped security context" in the NAS KSI IE, nonceMME and nonceUE, the UE shall generate K’ASME from both nonces as indicated in 3GPP TS 33.401 [19] and reset the downlink NAS COUNT to check whether the SECURITY MODE COMMAND can be accepted or not. The UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key based on the KASME or mapped K’ASME indicated by the eKSI. The UE shall set the security header type of the message to "integrity protected and ciphered with new EPS security context".
From this time onwards the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering and NAS integrity algorithms.
If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall include its IMEISV in the SECURITY MODE COMPLETE message.
9.1.3.1.3 Test description
9.1.3.1.3.1 Pre-test conditions
System Simulator:
– Cell A.
UE:
None.
Preamble:
– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].
9.1.3.1.3.2 Test procedure sequence
Table 9.1.3.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE is switched on. |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message. |
–> |
ATTACH REQUEST |
– |
– |
3 |
The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure. |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication. |
–> |
AUTHENTICATION RESPONSE |
– |
– |
5 |
The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV (Note 1). |
<– |
SECURITY MODE COMMAND |
– |
– |
6 |
Check: Does the UE transmit a SECURITY MODE COMPLETE message and does it establish the initial security configuration? |
–> |
SECURITY MODE COMPLETE |
1 |
P |
6Aa1-8Dc1 |
Steps 9a1-16c1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed. |
– |
– |
– |
– |
9 |
The SS transmits an IDENTITY REQUEST message ( Security protected as per the algorithms specified in step 5) |
<- |
IDENTITY REQUEST |
– |
– |
10 |
Check: Does the UE transmit an IDENTIY RESPONSE message (Security Protected as per the algorithms specified in step 5)? |
-> |
IDENTITY RESPONSE |
1 |
P |
11 |
The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure for new key set generation. |
<– |
AUTHENTICATION REQUEST |
– |
– |
12 |
The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication. |
–> |
AUTHENTICATION RESPONSE |
– |
– |
13 |
SS resets UL and DL NAS Count to zero |
– |
– |
– |
– |
14 |
The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV |
<– |
SECURITY MODE COMMAND |
– |
– |
15 |
The UE transmits a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration. |
–> |
SECURITY MODE COMPLETE |
2 |
P |
– |
Exception: Steps 16 and 17 are executed 100 times to check UE is applying security correctly. |
– |
– |
– |
– |
16 |
The SS transmits an IDENTITY REQUEST message (Security protected as per the algorithms specified in step 14) |
<- |
IDENTITY REQUEST |
– |
– |
17 |
Check: Does the UE transmit an IDENTIY RESPONSE message (Security Protected as per the algorithms specified in step 14)? |
-> |
IDENTITY RESPONSE |
2 |
P |
18 A-18D |
IF MULTI_PDN = TRUE (Note 2) THEN steps 10-13 of the generic procedure for network initiated release of additional PDN connectivity specified in TS 36.508 subclause 4.5A.18.3 are performed for the non-IMS PDN. |
– |
– |
– |
– |
19 |
The UE is brought in state Switched OFF (state 1) according to TS 36.508 [18] |
– |
– |
– |
– |
20-29 |
Steps 1 to 10 above are executed again null ciphering algorithm requested in step 5. (Note 1) |
– |
– |
– |
– |
30-33 |
IF MULTI_PDN = TRUE (Note 2) THEN steps 10-13 of the generic procedure for network initiated release of additional PDN connectivity specified in TS 36.508 subclause 4.5A.18.3 are performed for the non-IMS PDN. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
Note 1: This TC verifies the usage of a not null and the null ciphering algorithms. The type of algorithm is specified in the SECURITY MODE COMMAND and then is applied in the messages that follow accordingly. Note 2: MULTI_PDN as defined in TS 36.508 subclause 4.5.2. |
9.1.3.1.3.3 Specific message contents
Table 9.1.3.1.3.3-1: SECURITY MODE COMMAND (Steps 5 and 14, Table 9.1.3.1.3.2-1)
Derivation path: 36.508 [18], table 4.7.2-19 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Selected NAS security algorithms |
|||
Type of ciphering algorithm |
Set according to PIXIT parameter for default ciphering algorithm if it is set to a value different to EEA0, or, set to any value different to EEA0 otherwise |
Non-zero ciphering algorithm |
|
IMEISV request |
Present |
Table 9.1.3.1.3.3-2: SECURITY MODE COMPLETE (Steps 6, 15 and 25, Table 9.1.3.1.3.2-1)
Derivation path: 36.508 [18], table 4.7.2-20 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
IMEISV |
Present |
Table 9.1.3.1.3.3-3: SECURITY MODE COMMAND (Step 24, Table 9.1.3.1.3.2-1)
Derivation path: 36.508 [18], table 4.7.2-19 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Selected NAS security algorithms |
|||
Type of ciphering algorithm |
EEA0 |
Zero ciphering algorithm |
|
IMEISV request |
Present |
9.1.3.2 NAS security mode command not accepted by the UE
9.1.3.2.1 Test Purpose (TP)
(1)
with { successful completion of EPS authentication and key agreement (AKA) procedure[ }
ensure that {
when { UE receives an integrity protected SECURITY MODE COMMAND message including not matching replayed security capabilities}
then { UE sends SECURITY MODE REJECT and does not start applying the NAS security in both UL and DL}
}
9.1.3.2.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 5.4.3.1, 5.4.3.2, 5.4.3.3 and 5.4.3.5.
[TS 24.301, clause 5.4.3.1]
The purpose of the NAS security mode control procedure is to take an EPS security context into use, and initialise and start NAS signalling security between the UE and the MME with the corresponding NAS keys and security algorithms.
[TS 24.301, clause 5.4.3.2]
The MME initiates the NAS security mode control procedure by sending a SECURITY MODE COMMAND message to the UE and starting timer T3460 (see example in figure 5.4.3.2.1).
If the security mode control procedure is initiated further to a successful execution of the authentication procedure, the MME shall use the reset downlink NAS COUNT to integrity protect the SECURITY MODE COMMAND message.
The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on KASME or mapped K’ASME indicated by the eKSI included in the message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".
…
The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonceUE if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI).
Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message.
NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it is also be supported for AS.
[TS 24.301, clause 5.4.3.3]
Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure.
[TS 24.301, clause 5.4.3.5]
If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message, which shall not be integrity protected. The SECURITY MODE REJECT message contains an EMM cause that typically indicates one of the following cause values:
#23: UE security capabilities mismatch;
#24: security mode rejected, unspecified.
.
Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort the ongoing procedure that triggered the initiation of the NAS security mode control procedure.
9.1.3.2.3 Test description
9.1.3.2.3.1 Pre-test conditions
System Simulator:
– Cell A.
UE:
None.
Preamble:
– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].
9.1.3.2.3.2 Test procedure sequence
Table 9.1.3.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE is switched on. |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message. |
–> |
ATTACH REQUEST |
– |
– |
3 |
The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure. |
<– |
AUTHENTICATION REQUEST |
– |
– |
4 |
The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication. |
–> |
AUTHENTICATION RESPONSE |
– |
– |
5 |
The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes un matched replayed security capabilities. |
<– |
SECURITY MODE COMMAND |
– |
– |
6 |
Check: Does the UE transmit a NAS SECURITY MODE REJECT message with cause’#23: UE security capabilities mismatch’? |
–> |
SECURITY MODE REJECT |
1 |
P |
7 |
The SS Transmits an IDENTITY REQUEST message for IMSI (Security not applied) |
<- |
IDENTITY REQUEST |
– |
– |
8 |
Check: Does the UE transmit a non security protected IDENTIY RESPONSE message? |
-> |
IDENTITY RESPONSE |
1 |
P |
9 |
The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV |
<– |
SECURITY MODE COMMAND |
– |
– |
10 |
The UE transmits a SECURITY MODE COMPLETE message and establishes the initial security configuration. |
–> |
SECURITY MODE COMPLETE |
– |
– |
10Aa1-19b1 |
Steps 9a1-18b1 of the generic procedure for UE registration specified in TS 36.508 subclause 4.5.2.3 are performed. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508. |
– |
– |
– |
– |
9.1.3.2.3.3 Specific message contents
Table 9.1.3.2.3.3-1: SECURITY MODE COMMAND (Step 5)
Derivation path: 36.508 table 4.7.2-19 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Replayed UE security capabilities |
Set to mismatch the security capability of UE under test |
Table 9.1.3.2.3.3-2: SECURITY MODE REJECT (Step 6)
Derivation path: 36.508 table 4.7.2-21 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EMM cause |
#23 |
9.1.3.3 No emergency bearer service / NAS security mode command with EIA0 not accepted by the UE
9.1.3.3.1 Test Purpose (TP)
(1)
with { UE not having a PDN connection for emergency bearer services established or not establishing a PDN connection for emergency bearer }
ensure that {
when { UE receives a SECURITY MODE COMMAND message indicating the "null integrity protection algorithm" EIA0 }
then { UE sends SECURITY MODE REJECT and does not start applying the "null integrity protection algorithm" EIA0 }
}
9.1.3.3.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.4.1, 4.4.4.2, 5.4.3.3 and 5.4.3.5.
[TS 24.301, clause 4.4.4.1]
For the UE, integrity protected signalling is mandatory for the NAS messages once a valid EPS security context exists and has been taken into use. For the network, integrity protected signalling is mandatory for the NAS messages once a secure exchange of NAS messages has been established for the NAS signalling connection. Integrity protection of all NAS signalling messages is the responsibility of the NAS. It is the network which activates integrity protection.
The use of "null integrity protection algorithm" EIA0 (see subclause 9.9.3.23) in the current security context is only allowed for an unauthenticated UE. For setting the security header type in outbound NAS messages, the UE and the MME shall apply the same rules irrespective of whether the "null integrity protection algorithm" or any other integrity protection algorithm is indicated in the security context.
[TS 24.301, clause 4.4.4.2]
Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the UE or forwarded to the ESM entity, unless the network has established secure exchange of NAS messages for the NAS signalling connection:
– EMM messages:
– IDENTITY REQUEST (if requested identification parameter is IMSI);
– AUTHENTICATION REQUEST;
…
NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.
All ESM messages are integrity protected.
Once the secure exchange of NAS messages has been established, the receiving EMM or ESM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. The processing of the SECURITY MODE COMMAND message that has not successfully passed the integrity check is specified in subclause 5.4.3.5. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.
[TS 24.301, clause 5.4.3.3]
Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received replayed UE security capabilities and the received nonceUE have not been altered compared to what the UE provided in the initial layer 3 message that triggered this procedure. However, the UE is not required to perform the checking of the received nonceUE if the UE does not want to re-generate the K’ASME (i.e. the SECURITY MODE COMMAND message is to derive and take into use a mapped EPS security context and the eKSI matches the current EPS security context, if it is a mapped EPS security context). When the UE has a PDN connection for emergency bearer services established or the UE is establishing a PDN connection for emergency bearer services, the UE is not required to locally re-generate the KASME (i.e. the SECURITY MODE COMMAND message is used to derive and take into use a native EPS security context where the KSI value "000" is included in the NAS key set identifier IE and the EIA0 and EEA0 are included as the selected NAS security algorithms).
The UE shall accept a SECURITY MODE COMMAND message indicating the "null integrity protection algorithm" EIA0 as the selected NAS integrity algorithm only if the message is received for a UE that has a PDN connection for emergency bearer services established or a UE that is establishing a PDN connection for emergency bearer services.
[TS 24.301, clause 5.4.3.5]
If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message. The SECURITY MODE REJECT message contains an EMM cause that typically indicates one of the following cause values:
#23: UE security capabilities mismatch;
#24: security mode rejected, unspecified.
Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort the ongoing procedure that triggered the initiation of the NAS security mode control procedure.
Both the UE and the MME shall apply the EPS security context in use before the initiation of the security mode control procedure, if any, to protect the SECURITY MODE REJECT message and any other subsequent messages according to the rules in subclauses 4.4.4 and 4.4.5.
9.1.3.3.3 Test description
9.1.3.3.3.1 Pre-test conditions
System Simulator:
– Cell A.
UE:
None.
Preamble:
– the UE is in state Switched OFF (state 1) according to TS 36.508 [18].
NOTE: The preamble is executed with non-null NAS security algorithms indicated in the PIXT.
9.1.3.3.3.2 Test procedure sequence
Table 9.1.3.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE is switched on. |
– |
– |
– |
– |
2 |
The UE transmits an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message. |
–> |
ATTACH REQUEST |
– |
– |
3 |
Void |
– |
– |
– |
– |
4 |
Void |
– |
– |
– |
– |
5 |
The SS transmits a NAS SECURITY MODE COMMAND message; EIA0 (NULL integrity), EEA0 (NULL ciphering), matched replayed security capabilities. Note: ‘matched replayed security capabilities’ shall be sent to ensure that the SECURITY MODE REJECT is not sent due to problem with this information. |
<– |
SECURITY MODE COMMAND |
– |
– |
6 |
Check: Does the UE transmit a NAS SECURITY MODE REJECT message, integrity protected with previous security context? |
–> |
SECURITY MODE REJECT |
1 |
P |
7 |
The SS transmits an IDENTITY REQUEST message for IMSI (Security not applied) |
<- |
IDENTITY REQUEST |
– |
– |
8 |
The UE transmits an integrity protected only IDENTITY RESPONSE message. |
-> |
IDENTITY RESPONSE |
– |
– |
– |
EXCEPTION: Steps 9a1 to 9a2 describe behaviour that depends on UE configuration; the "lower case letter" identifies a step sequence that take place if the UE has ESM information which needs to be transferred. |
– |
– |
– |
– |
9a1 |
The SS transmits an ESM INFORMATION REQUEST message – no integrity protection applied – to initiate exchange of protocol configuration options and/or APN. |
<– |
ESM INFORMATION REQUEST |
– |
– |
9a2 |
Check: Does the UE transmit an ESM INFORMATION RESPONSE message? Note: The UE is expected to discard the ESM INFORMATION REQUEST message without security protection. |
–> |
ESM INFORMATION RESPONSE |
1 |
F |
10 |
The SS transmits an ATTACH ACCEPT message- no integrity protection applied. The ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message is piggybacked in ATTACH ACCEPT message |
<– |
ATTACH ACCEPT |
– |
– |
– |
EXCEPTION: Steps 11a1 to 25a2 describe behaviour that depends on the UE action; the "lower case letter" identifies a step sequence that take place if a particular sequential line of behaviour is manifested. |
– |
– |
– |
– |
11a1 |
Check: Does the UE transmit an ATTACH COMPLETE message? Note: The UE is expected to discard the ATTACH ACCEPT message without security protection. |
–> |
ATTACH COMPLETE |
1 |
F |
11b1 |
Check: Does the UE transmit an ATTACH REQUEST message? Note 1: After timer T3411 expire the UE is expected to re-attempt to attach. Note 2: Steps 11b1 to 11b13 are executed with non-null NAS security algorithms indicated in the PIXIT. |
–> |
ATTACH REQUEST |
1 |
P |
12-25b1- |
The attach procedure is completed by executing steps 5 to 18b1 of the UE registration procedure in TS 36.508 [18] sub clause 4.5.2.3. |
– |
– |
– |
– |
– |
At the end of this test procedure sequence, the UE is in end state E-UTRA idle (E1) according to TS 36.508 [18]. |
– |
– |
– |
– |
9.1.3.3.3.3 Specific message contents
Table 9.1.3.3.3.3-1: Void
Table 9.1.3.3.3.3-2: Void
Table 9.1.3.3.3.3-3: SECURITY MODE COMMAND (Step 5, Table 9.1.3.3.3.2-1)
Derivation path: 36.508 [18], table 4.7.2-19 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Selected NAS security algorithms |
|||
Type of integrity protection algorithm |
EIA0 |
||
Type of ciphering algorithm |
EEA0 |
||
NAS key set identifier |
|||
NAS key set identifier |
‘000’B |
||
TSC |
‘0’B |
native security context (for KSIASME) |
|
Spare half octet |
‘0000’B |
Table 9.1.3.3.3.3-4: SECURITY MODE REJECT (Step 6, Table 9.1.3.3.3.2-1)
Derivation path: 36.508 [18], table 4.7.2-21 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EMM cause |
#23 |
Note 1 |
|
#24 |
Note 1 |
||
Note 1: Any of these two values is allowed. |
NOTE: This message is sent within SECURITY PROTECTED NAS MESSAGE message with previous security context.
9.1.4 Identification procedure
9.1.4.1 Void
9.1.4.2 Identification procedure / IMEI / IMEISV requested
9.1.4.2.1 Test Purpose (TP)
(1)
with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}
ensure that {
when { UE receives an IDENTITY REQUEST message with IMEI in the IE Identity type }
then { UE sends an IDENTITY RESPONSE message providing its IMEI }
}
(2)
with { UE in EMM-REGISTERED state / EMM-CONNECTED mode}
ensure that {
when { UE receives an IDENTITY REQUEST message with IMEISV in the IE Identity type }
then { UE sends an IDENTITY RESPONSE message providing its IMEISV }
}
9.1.4.2.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301, clause 5.4.4.3.
[TS 24.301, clause 5.4.4.3]
A UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode.
Upon receipt of the IDENTITY REQUEST message the UE shall send an IDENTITY RESPONSE message to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network.
9.1.4.2.3 Test description
9.1.4.2.3.1 Pre-test conditions
System Simulator:
– cell A.
UE:
none.
Preamble:
– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].
9.1.4.2.3.2 Test procedure sequence
Table 9.1.4.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits an IDENTITY REQUEST message requesting IMEI in the IE Identity type. |
<– |
IDENTITY REQUEST |
– |
– |
2 |
Check: Does the UE respond with an IDENTITY RESPONSE message providing its IMEI? |
–> |
IDENTITY RESPONSE |
1 |
P |
3 |
SS transmits an IDENTITY REQUEST message requesting the international mobile equipment identity together with the software version number (IMEISV) in the IE Identity type. |
<– |
IDENTITY REQUEST |
– |
– |
4 |
Check: Does the UE respond with an IDENTITY RESPONSE message providing its IMEISV? |
–> |
IDENTITY RESPONSE |
2 |
P |
9.1.4.2.3.3 Specific message contents
Table 9.1.4.2.3.3-1: Message IDENTITY REQUEST (step 1, Table 9.1.4.2.3.2-1)
Derivation Path: 36.508, Table 4.7.2-17 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Identity Type |
0010 |
IMEI |
Table 9.1.4.2.3.3-2: IDENTITY RESPONSE (step 2, Table 9.1.4.2.3.2-1)
Derivation path: 36.508, Table 4.7.2-18 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Mobile Identity |
|||
Type of identity |
010 |
IMEI |
|
Identity digits |
UE’s IMEI |
Table 9.1.4.2.3.3-3: Message IDENTITY REQUEST (step 3, Table 9.1.4.2.3.2-1)
Derivation Path: 36.508, Table 4.7.2-17 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Identity Type |
0011 |
IMEISV |
Table 9.1.4.2.3.3-4: IDENTITY RESPONSE (step 4, Table 9.1.4.2.3.2-1)
Derivation path: 36.508, Table 4.7.2-18 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Mobile Identity |
|||
Type of identity |
011 |
IMEISV |
|
Identity digits |
UE’s IMEISV |
9.1.5 EMM information procedure
9.1.5.1 EMM information procedure
9.1.5.1.1 Test Purpose (TP)
(1)
with { UE in EMM-REGISTERED state and UE supporting the EMM information message }
ensure that {
when { UE receives an EMM Information message }
then { UE accepts the message and uses the contents to update appropriate information stored within the UE }
}
9.1.5.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.5.3.
[TS 24.301, clause 5.4.5.3]
When the UE (supporting the EMM information message) receives an EMM INFORMATION message, it shall accept the message and optionally use the contents to update appropriate information stored within the UE.
9.1.5.1.3 Test description
9.1.5.1.3.1 Pre-test conditions
System Simulator:
– cell A.
UE:
The UE is equipped with a USIM containing default values (as per TS 36.508) except for those listed in Table 9.1.5.1.3.1-1
Table 9.1.5.1.3.1-1: USIM configuration
USIM field |
Priority |
Value |
EFUST |
Services 19 and 51 are not supported |
Preamble:
– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].
9.1.5.1.3.2 Test procedure sequence
Table 9.1.5.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
Void |
– |
– |
– |
– |
– |
EXCEPTION: Steps 0Aa1 and 0Ab1 describe behaviour that depends on the UE release; the "lower case letter" identifies a step sequence that take place if the UE is of particular release. |
– |
– |
– |
– |
0Aa1 |
IF the UE is (Rel-11 or higher) and (pc_DaylightSavingTime or pc_UniversalAndLocalTimeZone) THEN Switch on Time Zone reporting on the UE (Note 3) |
– |
– |
– |
– |
0Ab1 |
IF the UE is lower than Rel-11 THEN configure the UE with automatic time zone update (Note 0) |
– |
– |
– |
– |
1 |
The SS transmits an EMM INFORMATION message. |
<– |
EMM INFORMATION |
– |
– |
2 |
Check: Does the UE transmit in the next 5 seconds an EMM STATUS message with cause #97 "message type non-existent or not implemented"? |
–> |
EMM STATUS |
1 |
F |
– |
EXCEPTION: Steps 2Aa1 to 3d2 describe behaviour that depends on the UE capability; the "lower case letter" identifies a step sequence that takes place if a capability is supported. |
– |
– |
– |
– |
2Aa1 |
IF ( pc_DaylightSavingTime AND pc_ProvideDST_inUse ) THEN Check: Does the UE assume that this daylight saving time applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity? (Note 8) Operator Action: The use of the supported Fields is checked: |
– |
– |
1 |
P |
2Aa2 |
Void |
– |
– |
– |
– |
3a1 |
IF pc_FullNameNetwork THEN Check: Does the UE associate the "full length name of the network" with the MCC and MNC contained in the last visited tracking area identification and is presented to the MS user at the earliest opportunity? Operator Action: |
– |
– |
1 |
P |
3a2 |
Void |
– |
– |
– |
– |
3b1 |
IF pc_ShortNameNetwork THEN Check: Does the UE associate the "abbreviated name of the network" with the MCC and MNC contained in the last visited tracking area identification and is presented to the MS user at the earliest opportunity? Operator Action: |
– |
– |
1 |
P |
3b2 |
Void |
– |
– |
– |
– |
3c1 |
IF pc_LocalTimeZone THEN Check: Does the UE assume that this time zone applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity? Operator Action: The use of the supported Fields is checked: |
– |
– |
1 |
P |
3c2 |
Void |
– |
– |
– |
– |
3d1 |
IF pc_UniversalAndLocalTimeZone THEN Check: Does the UE assume that this time applies to the tracking area of the current cell and is presented to the MS user at the earliest opportunity? (Note 3, Note 8) Operator Action: The use of the supported Fields is checked: Local Time: Month: December Day: 31st |
– |
– |
1 |
P |
3d2 |
Void |
– |
– |
– |
– |
Note 0: AT command +CTZU is assumed to be used. Note 1: AT command +COPS is assumed to be used for check. Note 2: AT command +CCLK is assumed to be used for check. Note 3: AT command +CTZR is assumed to be used for check for Rel-11 onwards. Note 4: Current Year is derived by the SS and the minutes and seconds are not checked. Note 5: Void. Note 6: Void Note 7: If (Rel-11 or higher Release) and Time Zone reporting is enabled at Step 0, the UE returns the result code +CTZE. Note 8: In case of Rel-10 or lower releases: CTZU has been used to trigger UE report. A time zone report in the CTZE structure is expected. Triggering a time zone report in the CTZE structure is only required if pc_DaylightSavingTime or pc_UniversalAndLocalTimeZone are supported. |
9.1.5.1.3.3 Specific message contents
Table 9.1.5.1.3.3-1: EMM INFORMATION (step 1, Table 9.1.5.1.3.2-1)
Derivation Path: 36.508 table 4.7.2-13 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Full name for network |
"C63A9BED0CB7CB31D98C56B3DD70" O |
"FullName12345678", Note 1 |
|
Short name for network |
"5367B85D8EC966" O |
"SName123", Note 1 |
|
Local time zone |
"40" O |
"GMT+1", Note 1, Note 2 |
|
Universal time and local time zone |
"xx211331832540" O |
"<Current Year> 31 December 13:38:52 GMT+1", Note 1, Note 2 |
|
Network daylight saving time |
"01" O |
"+1 hour adjustment for Daylight Saving Time", Note 1 |
|
Note 1: Hard coded values have been chosen to allow for consistent/comparable SS behaviour. Note 2: Daylight Saving Time is included in the Local Time Zone. |
Table 9.1.5.1.3.3-2: Message EMM STATUS (step 2, Table 9.1.5.1.3.2-1)
Derivation path: 36.508 table 4.7.2-14 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EMM cause |
‘0110 0001’B |
Message type non-existent or not implemented |
9.1.5.2 EMM information procedure not supported by the UE
9.1.5.2.1 Test Purpose (TP)
(1)
with { UE in EMM-REGISTERED state }
ensure that {
when { UE receives an EMM Information message }
then { UE ignore the contents of the message and return an EMM STATUS message with cause #97 "message type non-existent or not implemented" }
}
9.1.5.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.4.5.3.
[TS 24.301, clause 5.4.5.3]
If the UE does not support the EMM information message the UE shall ignore the contents of the message and return an EMM STATUS message with cause #97 "message type non-existent or not implemented".
9.1.5.2.3 Test description
9.1.5.2.3.1 Pre-test conditions
System Simulator:
– cell A.
UE:
none.
Preamble:
– the UE is in state Generic RB established (state 3) on cell A according to TS 36.508 [18].
9.1.5.2.3.2 Test procedure sequence
Table 9.1.5.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits an EMM INFORMATION message. |
<– |
EMM INFORMATION |
– |
– |
2 |
Check: Does the UE transmit an EMM STATUS message with cause #97 "message type non-existent or not implemented". |
–> |
EMM STATUS |
1 |
P |
9.1.5.2.3.3 Specific message contents
Table 9.1.5.2.3.3-1: EMM INFORMATION (step 1, Table 9.1.5.2.3.2-1)
Derivation Path: 36.508 table 4.7.2-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
Full name for network |
Not present |
|||
Short name for network |
Not present |
|||
Local time zone |
Not present |
|||
Universal time and local time zone |
Not present |
|||
Network daylight saving time |
‘00’B |
No adjustment for Daylight Saving Time |
Table 9.1.5.2.3.3-2: Message EMM STATUS (step 2, Table 9.1.5.2.3.2-1)
Derivation path: 36.508 table 4.7.2-14 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EMM cause |
‘0110 0001’B |
Message type non-existent or not implemented |