9.1.1 Primary authentication and key agreement

38.523-13GPP5GSPart 1: ProtocolRelease 17TSUser Equipment (UE) conformance specification

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

9.1.1.1 EAP based primary authentication and key agreement / EAP-AKA’ related procedures

9.1.1.1.1 Test Purpose (TP)

(1)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends an EAP-Request/AKA’-Identity message within AUTHENTICATION REQUEST }

then { the UE sends an EAP-Response/AKA’-Identity message within AUTHENTICATION RESPONSE }

}

(2)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST with the sequence number in AUTN is not correct }

then { the UE sends an EAP-response/AKA’-synchronization-failure message within AUTHENTICATION RESPONSE }

}

(3)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends an EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST }

then { the UE sends an EAP-response/AKA’-challenge message within AUTHENTICATION RESPONSE }

}

(4)

with { the UE in 5GMM-REGISTERED-INITIATED state and SS initiates an EAP based primary authentication and key agreement procedure }

ensure that {

when { the SS sends an EAP-success message within AUTHENTICATION RESULT }

then { the UE considers the procedure complete and authentication procedure succeed }

}

9.1.1.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.501 clauses 5.4.1.2.2.3, 5.4.1.2.2.4, 5.4.1.2.2.6B, 5.4.1.2.2.8.

[TS 24.501, clause 5.4.1.2.2.6B (TP1)]

Upon receipt of the AUTHENTICATION REQUEST message with EAP-Request/Identity message the UE shall send an AUTHENTICATION RESPONSE message with EAP-Response/Identity to the network. In the EAP-Response/Identity message, the UE shall provide the requested identity according to 3GPP TS 33.501 [24] annex F.2, in the UE identity in the EAP-Response/Identity message as specified in IETF RFC 5448 [40].

Upon receipt of the AUTHENTICATION REQUEST message with EAP-Request/AKA’-Identity message the UE shall send an AUTHENTICATION RESPONSE message with EAP-Response/AKA’-Identity to the network. Based on the attribute received in the EAP-Request/AKA’-Identity, the UE shall provide the requested identity according to 3GPP TS 33.501 [24] annex F.2, in the EAP-Response/AKA’-Identity message, as specified in IETF RFC 5448 [40].

If the EAP-Request/AKA’-Identity carries the AT_PERMANENT_REQ, the UE shall respond with EAP-Response/AKA’-Client-Error with the error code "unable to process packet".

[TS 24.501, clause 5.4.1.2.2.4 (TP2)]

If a USIM is present, the SNN check fails or the UE does not accept AUTN during handling of the EAP-request/AKA’-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA’-authentication-reject message as specified in IETF RFC 5448 [40].

If a USIM is present, the SNN check is successful but the UE detects that the sequence number in AUTN is not correct during handling of the EAP-request/AKA’-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA’-synchronization-failure message as specified in IETF RFC 5448 [40].

If a USIM is present, the SNN check is successful, the sequence number in AUTN is correct and the UE detects another error during handling of the EAP-request/AKA’-challenge message as specified in IETF RFC 5448 [40], the UE shall send an EAP-response/AKA’-client-error message as specified in IETF RFC 5448 [40].

If a USIM is not present, the UE shall send an EAP-response/AKA’-client-error message as specified in IETF RFC 5448 [40].

For any of the above, the UE shall start timer T3520 when the AUTHENTICATION RESPONSE message containing the EAP-response message is sent. Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon receiving an AUTHENTICATION REQUEST message with the EAP message IE containing an EAP-request/AKA’-challenge from the network, the UE shall stop timer T3520, if running, and then process the EAP-request/AKA’-challenge information as normal.

[TS 24.501, clause 5.4.1.2.2.3 (TP3)]

If a USIM is present and the SNN check is successful, the UE shall handle the EAP-request/AKA’-challenge message as specified in IETF RFC 5448 [40]. The USIM shall derive CK and IK and compute the authentication response (RES) using the 5G authentication challenge data received from the ME, and pass RES to the ME. The ME shall derive CK’ and IK’ from CK and IK, and EMSK from CK’ and IK’. Furthermore, the ME may generate K_AUSF from the EMSK, the K_SEAF from the K_AUSF, and the K_AMF from the ABBA received together with the EAP-request/AKA’-challenge message, and the K_SEAF as described in 3GPP TS 33.501 [24], and create a partial native 5G NAS security context identified by the ngKSI value received together with the EAP-request/AKA’-challenge message in clause 5.4.1.2.4.2 in the volatile memory of the ME. If the K_AMF and the partial native 5G NAS security context are created, the ME shall store the K_AMF in the created partial native 5G NAS security context, and shall send an EAP-response/AKA’-challenge message as specified in IETF RFC 5448 [40].

If the EAP-request/AKA’-challenge message contains AT_RESULT_IND attribute, the UE may include AT_RESULT_IND attribute in the EAP-response/AKA’-challenge message as specified in IETF RFC 5448 [40].

[TS 24.501, clause 5.4.1.2.2.8 (TP4)]

Upon receiving an EAP-success message, if the ME has not generated a partial native 5G NAS security context as described in subclause 5.4.1.2.2.3, the ME shall:

a) generate the K_AUSF from the EMSK, the K_SEAF from the K_AUSF, and the K_AMF from the ABBA that was received with the EAP-success message, and the K_SEAF as described in 3GPP TS 33.501 [24];

b) create a partial native 5G NAS security context identified by the ngKSI value in the volatile memory of the ME; and

c) store the K_AMF in the created partial native 5G NAS security context.

The UE shall consider the procedure complete.

9.1.1.1.3 Test description

9.1.1.1.3.1 Pre-test conditions

System Simulator:

– NGC Cell A is configured according to table 6.3.2.2-1 in TS 38.508-1 [4].

UE:

– None

Preamble:

– The UE is in state Switched OFF Mode (state 0N-B) according to TS 38.508-1 [4].

9.1.1.1.3.2 Test procedure sequence

Table 9.1.1.1.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.	–	–	–	–
2-4	The UE establishes RRC connection and initiates registration procedure by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
5	SS transmits an AUTHENTICATION REQUEST message with an EAP-Request/AKA’-Identity message.	<–	5GMM: AUTHENTICATION REQUEST
6	Check: Does the UE respond with an AUTHENTICATION RESPONSE message, with an EAP-Response/AKA’-Identity message?	–>	5GMM: AUTHENTICATION RESPONSE	1	P
7	SS transmits an AUTHENTICATION REQUEST message with an EAP-Request/AKA’-challenge message which contains a not correct sequence number.	<–	5GMM: AUTHENTICATION REQUEST	–	–
8	Check: Does the UE respond with an AUTHENTICATION RESPONSE message, with an EAP-Response/AKA’-synchronization-failure?	–>	5GMM: AUTHENTICATION RESPONSE	2	P
9	SS transmits a correct AUTHENTICATION REQUEST message with an EAP-Request/AKA’-challenge message.	<–	5GMM: AUTHENTICATION REQUEST	–	–
10	Check: Does the UE respond with a correct AUTHENTICATION RESPONSE message, with an EAP-Response/AKA’-challenge message?	–>	5GMM: AUTHENTICATION RESPONSE	3	P
11	SS transmits an AUTHENTICATION RESULT message with an EAP-success message.	<–	5GMM: AUTHENTICATION RESULT	–	–
12-18	The registration procedure is performed by executing steps 8-14 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
19	Check: Does the UE transmits a REGISTRATION COMPLETE message?	–>	5GMM: REGISTRATION COMPLETE	4	P
20	Steps 19a1 of Table 4.5.2.2-2 in TS 38.508-1 [4] are performed	–	–	–	–

9.1.1.1.3.3 Specific message contents

Table 9.1.1.1.3.3-1: Message AUTHENTICATION REQUEST (step 5, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-request/AKA’-Identity	See Table 9.1.1.1.3.3-7	EAP-AKA

Table 9.1.1.1.3.3-2: Message AUTHENTICATION RESPONSE (step 6, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-response/AKA’-Identity	See Table 9.1.1.1.3.3-8	EAP-AKA

Table 9.1.1.1.3.3-3: Message AUTHENTICATION REQUEST (step 7, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-request/AKA’- challenge	The sequence number in AUTN is not correct	EAP-AKA

Table 9.1.1.1.3.3-4: Message AUTHENTICATION RESPONSE (step 8, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-response/AKA’-synchronization-failure		EAP-AKA

Table 9.1.1.1.3.3-5: Message AUTHENTICATION RESPONSE (step 10, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-Response/AKA’-Challenge	RES* equal to the XRES* calculated in the SS with the parameters provided/indicated in the AUTHENTICATION REQUEST	EAP-AKA

Table 9.1.1.1.3.3-6: Message AUTHENTICATION RESULT (step 11, Table 9.1.1.1.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-3
Information Element	Value/Remark	Comment	Condition
EAP message	EAP-Success		EAP-AKA

Table 9.1.1.1.3.3-7: Message EAP-Request/AKA’-Identity (Table 9.1.1.1.3.3-1)

Derivation Path: IETF RFC 4187 [30] clause 9.1, RFC 3748 [32] clause 4
Information Element	Value/Remark	Comment	Condition
Code	1	Request
Length	Set to length of EAP packet
Data
AT_ANY_ID_REQ	AT_ANY_ID_REQ_Def	See Table 9.1.1.1.3.3-9

Table 9.1.1.1.3.3-8: Message EAP-Response/AKA’-Identity (Table 9.1.1.1.3.3-2)

Derivation Path: IETF RFC 4187 [30] clause 9.2, RFC 3748 [32] clause 4
Information Element	Value/Remark	Comment	Condition
Code	2	Response
Length	Set to length of EAP packet
Data
AT_IDENTITY	AT_IDENTITY_Def	See Table 9.1.1.1.3.3-10

Table 9.1.1.1.3.3-9: AT_ANY_ID_REQ_Def (Table 9.1.1.1.3.3-7)

Derivation Path: IETF RFC 4187 [30] clause 10.3
Information Element	Value/remark	Comment	Condition
AT_ANY_ID_REQ	‘0000 1101’B	13
Length	‘0000 0001’B	1
Reserved	‘0000 0000 0000 0000’B

Table 9.1.1.1.3.3-10: AT_IDENTITY_Def (Table 9.1.1.1.3.3-8)

Derivation Path: IETF RFC 4187 [30] clause 10.5
Information Element	Value/remark	Comment	Condition
AT_IDENTITY	‘0000 1110’B	14
Length	Set to the Length of AT_IDENTITY attribute in 4 bytes
Actual Identity Length	Set to the actual length of ‘identity’ in bytes excluding any appended all zero bytes at end
Identity	Value generated according to TS 24.501 [28] clause 9.11.3.4 and shall be a multiple of 4 bytes (appended with 1,2 or 3 bytes of all zero bits when necessary)	SUCI of the UE

9.1.1.2 EAP based primary authentication and key agreement / Reject

9.1.1.2.1 Test Purpose (TP)

(1)

with {the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST with incorrect SNN }

then { the UE sends an EAP-response/AKA’-authentication-reject message within AUTHENTICATION RESPONSE}

}

(2)

with {the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends an EAP-Request/AKA’-notification message within AUTHENTICATION REQUEST }

then { the UE sends an EAP-Response/AKA’-notification message within AUTHENTICATION RESPONSE }

}

(3)

with {the UE in 5GMM-REGISTERED-INITIATED state and SS initiates an EAP based primary authentication and key agreement procedure}

ensure that {

when { the SS sends an EAP-failure message within AUTHENTICATION REJECT }

then { the UE deletes the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI and enter state 5GMM-DEREGISTERED, the USIM is considered invalid until switching off the UE }

}

9.1.1.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.501, clauses 5.4.1.2.2.4, 5.4.1.2.2.6, and 5.4.1.2.2.11.

[TS 24.501, clause 5.4.1.2.2.4]

If a USIM is not present, the UE shall send an EAP-response/AKA’-client-error message as specified in IETF RFC 5448 [40].

[TS 24.501, clause 5.4.1.2.2.6]

Upon receiving an EAP-request/AKA’-notification message, the UE shall send an EAP-response/AKA’-notification message as specified in IETF RFC 5448 [40].

[TS 24.501, clause 5.4.1.2.2.11]

Upon receiving an EAP-failure message, the UE shall delete the partial native 5G NAS security context if any was created as described in subclause 5.4.1.2.2.3.

The UE shall consider the procedure complete.

If the EAP-failure message is received in an AUTHENTICATION REJECT message:

– the UE shall set the update status to 5U3 ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI. The USIM shall be considered invalid until switching off the UE or the UICC containing the USIM is removed; and

– if the UE is operating in single-registration mode, the UE shall handle 4G-GUTI, last visited registered TAI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the authentication procedure is not accepted by the network. The USIM shall be considered as invalid also for non-EPS services until switching off or the UICC containing the USIM is removed.

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any 5GMM signalling procedure, stop any of the timers T3510, T3517 or T3521 (if they were running) and enter state 5GMM-DEREGISTERED.

9.1.1.2.3 Test description

9.1.1.2.3.1 Pre-test conditions

System Simulator:

– NGC Cell A "Serving cell" TS 38.508-1 [4] Table 6.2.2.1-3

UE:

– None

Preamble:

– The UE is in state Switched OFF (state 0N-B) according to TS 38.508-1 [4].

9.1.1.2.3.2 Test procedure sequence

Table 9.1.1.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.	–	–	–	–
2-4	The UE executes steps 2-4 of Table 4.5.2.2-2 in TS38.508-1 [4].	–	–	–	–
5	The SS transmits "EAP-request/AKA’-challenge" message in AUTHENTICATION REQUEST with incorrect SNN.		5GMM: AUTHENTICATION REQUEST	–	–
6	Check: Does the UE transmit an “EAP-response/AKA’-authentication-reject” message in AUTHENTICATION RESPONSE?		5GMM: AUTHENTICATION RESPONSE	1	P
6A	The SS transmits "EAP-failure" message within AUTHENTICATION RESULT message.	<–	5GMM: AUTHENTICATION RESULT	–	–
7	The SS transmits “EAP-request/AKA’-challenge” message in AUTHENTICATION REQUEST.		5GMM: AUTHENTICATION REQUEST	–	–
8	The UE transmit an “EAP-response/AKA’- challenge” message in AUTHENTICATION RESPONSE.		5GMM: AUTHENTICATION RESPONSE	–	–
9	The SS transmits “EAP- request /AKA’-notification“message in AUTHENTICATION REQUEST.		5GMM: AUTHENTICATION REQUEST	–	–
10	Check: Does the UE transmit an “EAP-response/AKA’-notification” message in AUTHENTICATION RESPONSE?		5GMM: AUTHENTICATION RESPONSE	2	P
11	The SS transmits an “EAP-failure” message within AUTHENTICATION REJECT	<–	5GMM: AUTHENTICATION REJECT	–	–
12	SS releases the RRC connection	–	–	–	–
13	Check: Does the UE transmit an RRCSetupRequest message for initial registration procedure within the next 30 seconds?	–>	NR RRC: RRCSetupRequest	3	F
14	The UE is switched off by executing generic procedure in Table 4.9.6.4-1 in TS 38.508-1 [4].	–	–	–	–
15	The UE is switched on.	–	–	–	–
16	Check: Does the UE transmit a REGISTRATION REQUEST message?	–>	5GMM: REGISTRATION REQUEST	3	P
17	The UE executes steps 5-20a1 of Table 4.5.2.2-2 in TS38.508-1 [4] complete registration procedure.	–	–	–	–

9.1.1.2.3.3 Specific message contents

Table 9.1.1.2.3.3-1: AUTHENTICATION REQUEST (step 5, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	“EAP-request/AKA’-challenge”	SNN in EAP message is incorrect or does not match with the PLMN identity saved in the UE.
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-2: AUTHENTICATION RESPONSE (step 6, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	“EAP-response/AKA’-authentication-reject “
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-2A: AUTHENTICATION RESULT (step 6A, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-3
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
ngKSI	The same value as the last AUTHENTICATION REQUEST message
Spare half octet	‘0000’B
EAP message	EAP-failure	EAP-failure
ABBA	‘0000 0000 0000 0000’B
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-3: AUTHENTICATION RESPONSE (step 8, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	“EAP-request/AKA’-challenge”
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-4: AUTHENTICATION REQUEST (step 9, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	“EAP-request /AKA’-notification“	See Table 9.1.1.2.3.3-8
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-5: AUTHENTICATION RESPONSE (step 10, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-2
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	“EAP-response/AKA’-notification“	See Table 9.1.1.2.3.3-9
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-6: AUTHENTICATION REJECT (step 11, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-5
Information Element	Value/Remark	Comment	Condition
Extended protocol discriminator	5GMM
Security header type	’0000’B	Plain 5GS NAS message, not security protected
Spare half octet	‘0000’B
EAP message	EAP-failure	EAP-failure
NOTE: This message is sent within SECURITY PROTECTED 5GS NAS MESSAGE message with Integrity protected and ciphered.

Table 9.1.1.2.3.3-7: REGISTRATION REQUEST (step16, Table 9.1.1.2.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type	‘0000 0010’B	Initial registration
ngKSI
NAS key set identifier	‘111’B	no key is available
TSC	Any allowed value	TSC does not apply for NAS key set identifier value "111"
Last visited registered TAI	Not present
5GS mobile identity	SUCI of the UE

Table 9.1.1.2.3.3-8: EAP-Request/AKA’-Notification (Table 9.1.1.2.3.3-4)

Derivation Path: IETF RFC 4187 [30] clause 9.10, RFC 3748 [32] clause 4
Information Element	Value/Remark	Comment	Condition
Code	1	Request
Length	Set to length of EAP packet
Data
AT_NOTIFICATION	AT_NOTIFICATION_Def	See Table 9.1.1.2.3.3-10

Table 9.1.1.2.3.3-9: EAP-Response/AKA’-Notification (Table 9.1.1.2.3.2-5)

Derivation Path: IETF RFC 4187 [30] clause 9.11, RFC 3748 [32] clause 4
Information Element	Value/Remark	Comment	Condition
Code	2	Response
Length	Set to length of EAP packet
Data	Not present

Table 9.1.1.2.3.3-10: AT_NOTIFICATION_Def (Table 9.1.1.2.3.3-8)

Derivation Path: IETF RFC 4187 [30] clause 10.19
Information Element	Value/remark	Comment	Condition
AT_NOTIFICATION	‘0000 1100’B	12
Length	‘0000 0001’B	1
Notification Code	‘0100 0000 0000 0000’B	Set to “General failure”

9.1.1.3 EAP based primary authentication and key agreement / EAP message transport / Abnormal

9.1.1.3.1 Test Purpose (TP)

(1)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST with ngKSI is already in use }

then { the UE sends an AUTHENTICATION FAILURE message with 5GMM cause #71 "ngKSI already in use" }

}

(2)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the third time SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST with ngKSI is already in use }

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

}

(3)

with { the UE in 5GMM-REGISTERED-INITIATED state, the SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST with ngKSI is already in use and the UE sends an AUTHENTICATION FAILURE message }

ensure that {

when { T3520 times out }

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

}

(4)

Void

(5)

with { the UE in 5GMM-REGISTERED state and initiates a mobility registration update procedure }

ensure that {

when { the SS sends the EAP-request/AKA’-challenge message within AUTHENTICATION REQUEST and the UE fails on transmission of AUTHENTICATION RESPONSE message with the indication from lower layers }

then { the UE re-initiate the mobility registration update procedure }

}

9.1.1.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.501 clauses 5.4.1.2.4.5. Unless otherwise stated these are Rel-15 requirements.

[TS 24.501, clause 5.4.1.2.4.5 (TP1, TP2, TP3, TP4, TP5)]

The following abnormal cases can be identified:

a) Authentication failure (5GMM cause #71 "ngKSI already in use").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #71 "ngKSI already in use", to the network and start the timer T3520 (see example in figure 5.4.1.3.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #71 "ngKSI already in use", the network performs necessary actions to select a new ngKSI and send the same EAP-request message to the UE.

NOTE 1: Upon receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #71 "ngKSI already in use", the network can also re-initiate the EAP based primary authentication and key agreement procedure (see subclause 5.4.1.2.2.2).

Upon receiving a new AUTHENTICATION REQUEST message with the EAP message IE containing an EAP-request message from the network, the UE shall stop timer T3520, if running, process the EAP-request message as normal.

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid ngKSI and EAP-request message is received), the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3510, T3517 or T3521) if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

b) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication from lower layers (if the EAP based primary authentication and key agreement procedure is triggered by a registration procedure for mobility and periodic registration update).

The UE shall stop the timer T3520, if running, and re-initiate the registration procedure for mobility and periodic registration update.

c) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication with TAI change from lower layers (if the EAP based primary authentication and key agreement procedure is triggered by a service request procedure).

The UE shall stop the timer T3520, if running.

If the current TAI is not in the TAI list, the EAP based primary authentication and key agreement procedure shall be aborted and a registration procedure for mobility and periodic registration update shall be initiated.

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing procedure that triggered the EAP based primary authentication and key agreement procedure.

…

e) 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 38.304 [28]). The UE shall start any retransmission timers (e.g. T3510, T3517 or T3521), if they were running and stopped when the UE received the first AUTHENTICATION REQUEST message containing an ngKSI that was already in use.

For item e, whether or not the UE is registered for emergency services:

The UE shall stop timer T3520, if the timer is running and the UE enters 5GMM-IDLE mode, e.g. upon detection of a lower layer failure, release of the N1 NAS signalling connection, or as the result of an inter-system change in 5GMM-CONNECTED mode from N1 mode to S1 mode.

The UE shall deem that the network has failed the authentication check or assume that the authentication is not genuine and proceed as described in item e above if any of the following occurs:

– the timer T3520 expires;

– the UE detects any combination of the EAP-based authentication failures: transmission of AUTHENTICATION FAILURE message with 5GMM cause #71 "ngKSI already in use", transmission of AUTHENTICATION RESPONSE message with an EAP-response message after detecting an error as described in subclause 5.4.1.2.2.4 or with an EAP-response message after not accepting of the server certificate as described in subclause 5.4.1.2.3.1, during three consecutive authentication challenges. The EAP-request/AKA’-challenge challenges shall be considered as consecutive only, if the EAP-request/AKA’-challenge challenges causing the second and third EAP-based authentication failure are received by the UE, while the timer T3520 started after the previous EAP-based authentication failure is running. Not accepting of the server certificate shall be considered as consecutive only, if the EAP-request messages causing the second and third not accepting of the server certificate are received by the UE, while the timer T3520 started after the previous EAP request message causing the previous not accepting of the server certificate is running.

NOTE 2: Reception of an EAP-failure message is not considered when determining the three consecutive authentication challenges or three consecutive not accepting of the server certificate.

…

9.1.1.3.3 Test description

9.1.1.3.3.1 Pre-test conditions

System Simulator:

– NGC Cell A, NGC Cell B, NGC Cell C and NGC Cell D are configured according to table 6.3.2.2-1 in TS 38.508-1 [4].

– System information combination NR-2 as defined in TS 38.508-1 [4] clause 4.4.3.1.2 is used.

UE:

– None

Preamble:

– The UE is in state Switched OFF Mode (state 0N-B) according to TS 38.508-1 [4].

9.1.1.3.3.2 Test procedure sequence

Table 9.1.1.3.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS configures: – NGC Cell A as the "Serving cell". – NGC Cell B, NGC Cell C and NGC Cell D as a "Non-suitable ‘Off’ cell".	–	–	–	–
–	The following messages are to be observed on NGC Cell A unless explicitly stated otherwise.	–	–	–	–
2	The UE is switched on.	–	–	–	–
3-5	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4] and transmits a REGISTRATION REQUEST message.	–>	5GMM: REGISTRATION REQUEST	–	–
6	SS transmits the EAP-request/AKA’-challenge message within an AUTHENTICATION REQUEST message, with ngKSI is already in use in the UE to initiate an EAP-AKA’ procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
7	Check: Does the UE respond with an AUTHENTICATION FAILURE message, with 5GMM cause "ngKSI already in use"?	–>	5GMM: AUTHENTICATION FAILURE	1	P
8	SS transmits the EAP-request/AKA’-challenge message within an AUTHENTICATION REQUEST message, with ngKSI is already in use in the UE to initiate an EAP-AKA’ procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
9	Check: Does the UE respond with an AUTHENTICATION FAILURE message, with 5GMM cause "ngKSI already in use"?	–>	5GMM: AUTHENTICATION FAILURE	1	P
10	The SS configures: – NGC Cell B as the "Serving cell". – NGC Cell A as a "Suitable neighbour intra-frequency cell".	–	–	–	–
11	SS transmits the EAP-request/AKA’-challenge message within an AUTHENTICATION REQUEST message, with ngKSI is already in use in the UE to initiate an EAP-AKA’ procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
11a1	EXCEPTION: The UE may send an AUTHENTICATION FAILURE before locally releasing the RRC Connection	–>	5GMM: AUTHENTICATION FAILURE	–	–
–	The following messages are to be observed on NGC Cell B unless explicitly stated otherwise.	–	–	–	–
12-14	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
15	Check: Does the UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as Initial registration?	–>	5GMM: REGISTRATION REQUEST	2	P
16	SS transmits the EAP-request/AKA’-challenge message within an AUTHENTICATION REQUEST message, with ngKSI is already in use in the UE to initiate an EAP-AKA’ procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
17	The UE responds with an AUTHENTICATION FAILURE message, with 5GMM cause "ngKSI already in use".	–>	5GMM: AUTHENTICATION FAILURE	–	–
17A	The SS starts timer of t_Waits=T3520.	–	–	–	–
18	The SS configures: – NGC Cell C as the "Serving cell". – NGC Cell B as a "Suitable neighbour intra-frequency cell". – NGC Cell A as the "Non-suitable ‘Off’ cell".	–	–	–	–
19	SS responds nothing and waits for the expiration of t_Waits.	–	–	–	–
–	The following messages are to be observed on NGC Cell C unless explicitly stated otherwise.	–	–	–	–
20-22	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
23	Check: Does the UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as Initial registration?	–>	5GMM: REGISTRATION REQUEST	3	P
24-39a1	The registration procedure is successfully completed by executing steps 5 to 20a1 of the generic procedure in TS 38.508-1 [4] Table 4.5.2.2-2.	–	–	–	–
–	The UE is in end state Registered, Idle Mode (1N-A) on NGC Cell C according to TS 38.508-1 [4].	–	–	–	–
40-44	Void	–	–	–	–
45	The SS configures: – NGC Cell D as the "Serving cell", and the tracking area of NGC Cell D is not in the list of tracking areas that the UE previously registered. – NGC Cell C as the “Non-suitable ‘Off’ cell". – NGC Cell B as the "Non-suitable ‘Off’ cell".	–	–	–	–
46-47	Void	–	–	–	–
–	The following messages are to be observed on Cell D unless explicitly stated otherwise.	–	–	–	–
48-50	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
51	The UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as Mobility registration updating.	–>	5GMM: REGISTRATION REQUEST	–	–
52	The SS cuts off the UL grant and RA Response. (Note 1)	–	–	–	–
53	SS transmits the EAP-request/AKA’-challenge message within a correct AUTHENTICATION REQUEST message to initiate an EAP-AKA’ procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
54	SS starts a timer t_Delay = 10s. (Note 2)	–	–	–	–
55	SS locally releases the RRC connection and waits for the expiration of t_Delay.	–	–	–	–
56	The SS turn on the UL grant and RA Response.	–	–	–	–
57-59	The UE establishes RRC connection by executing steps 1-3 of Table 4.9.5.2.2-1 in TS 38.508-1 [4].	–	–	–	–
60	Check: Does the UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as mobility registration updating?	–>	5GMM: REGISTRATION REQUEST	5	P
61-63a1	The registration procedure is successfully completed by executing steps 4 to 6a1 of the generic procedure in TS 38.508-1 [4] Table 4.9.5.2.2-1.	–	–	–	–
Note 1: For transmission of the AUTHENTICATION RESPONSE message, the UE needs to initiate RACH to get UL grant. Since not RA Response, registration failure due to lower layer failure will occur, then timer T3511 will be started. Note 2: Timer t_Delay is derived from timer T3511. During timer t_Delay, UE fails on transmission of the AUTHENTICATION RESPONSE message with the indication from lower layers.

9.1.1.3.3.3 Specific message contents

Table 9.1.1.3.3.3-1: AUTHENTICATION REQUEST (step 6, 8, 11 and 16, Table 9.1.1.3.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
ngKSI	ngKSI	SS shall use the ngKSI is already in use in the UE

Table 9.1.1.3.3.3-2: AUTHENTICATION FAILURE (step 7, 9, 11a1 and 17, Table 9.1.1.3.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-4
Information Element	Value/Remark	Comment	Condition
5GMM cause	‘0100 0111’B	ngKSI already in use

Table 9.1.1.3.3.3-3: REGISTRATION REQUEST (step 15 and step 23, Table 9.1.1.3.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type	‘001’B	Initial registration

Table 9.1.1.3.3.3-4: REGISTRATION REQUEST (step 51 and step 60, Table 9.1.1.3.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type	‘010’B	Mobility registration updating

Table 9.1.1.3.3.3-5: AUTHENTICATION REQUEST (step 53, Table 9.1.1.3.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
ngKSI	ngKSI	Different from the ngKSI assigned in step 24.

9.1.1.4 5G AKA based primary authentication and key agreement / 5G-AKA related procedures

9.1.1.4.1 Test Purpose (TP)

(1)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with invalid MAC code }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #20 "MAC failure" }

}

(2)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with the "separation bit" in the AMF field of AUTN supplied by the core network is set to 0 }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #26 "non-5G authentication unacceptable" }

}

(3)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with the sequence number SQN to be out of range }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM }

}

(4)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST }

then { the UE process the 5G authentication challenge data and respond with an AUTHENTICATION RESPONSE message }

}

(5)

with { the UE in 5GMM-REGISTERED-INITIATED state and sends out an AUTHENTICATION RESPONSE message }

ensure that {

when { the SS proceeds with the registration procedure }

then { the UE consider the authentication procedure complete and succeed }

}

9.1.1.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.501 clauses 5.4.1.3.3, 5.4.1.3.6, 5.4.1.3.7. Unless otherwise stated these are Rel-15 requirements.

[TS 24.501, clause 5.4.1.3.3]

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in subclause 5.4.1.3.5, the UE shall process the 5G authentication challenge data and respond with an AUTHENTICATION RESPONSE message to the network.

Upon a successful 5G authentication challenge, the new K_AMF calculated from the 5G authentication challenge data shall be stored in a new 5G NAS security context in the volatile memory of the ME.

[TS 24.501, clause 5.4.1.3.6]

In the 5G authentication challenge, the UE shall check the 5G authentication challenge data (RAND, AUTN and ngKSI) received in the AUTHENTICATION REQUEST message to verify authenticity of the 5G core network.

The ME shall check that ngKSI received in the AUTHENTICATION REQUEST message is not already in use. The ME shall forward the RAND and AUTN to the USIM to check.

The UE may reject the core network due to an incorrect AUTN or ngKSI parameter. If the UE has to reject the 5G authentication challenge, the UE shall return AUTHENTICATION FAILURE message to the network with a cause value indicating the reason for the failure (see 3GPP TS 33.501 [24]).

Incorrect 5G authentication challenge data contains four 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 5GMM cause #20 "MAC failure". The UE shall then follow the procedure described in subclause 5.4.1.3.7, item c.

b) Non-5G authentication unacceptable:

If the UE finds that the "separation bit" in the AMF field of AUTN supplied by the core network is set to 0, the UE shall send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #26 "non-5G authentication unacceptable" (see subclause 6.1.3 in 3GPP TS 33.501 [24]). The UE shall then follow the procedure described in subclause 5.4.1.3.7, item d.

…

d) SQN failure:

If the UE finds the sequence number 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 5GMM cause #21 "synch failure" and a re-synchronization token AUTS provided by the USIM (see 3GPP TS 33.102 [23]). The UE shall then follow the procedure described in subclause 5.4.1.3.7, item f.

[TS 24.501, clause 5.4.1.3.7]

c) Authentication failure (5GMM cause #20 "MAC failure").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #20 "MAC failure" according to subclause 5.4.1.3.6, to the network and start timer T3520 (see example in figure 5.4.1.3.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #20 "MAC failure", the network may initiate the identification procedure described in subclause 5.4.3. This is to allow the network to obtain the SUCI from the UE. The network may then check that the 5G-GUTI originally used in the 5G authentication challenge corresponded to the correct SUPI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall proceed as specified in subclause 5.4.3.3.

NOTE 1: Upon receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #20 "MAC failure", the network may also terminate the 5G AKA based primary authentication and key agreement procedure (see subclause 5.4.1.3.5).

If the mapping of 5G-GUTI to SUPI 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 T3520, if running, and then process the 5G challenge information as normal. If the mapping of 5G-GUTI to SUPI in the network was correct, the network should terminate the 5G AKA based primary authentication and key agreement procedure by sending an AUTHENTICATION REJECT message (see subclause 5.4.1.3.5).

If the network is validated successfully (an AUTHENTICATION REQUEST message that contains a valid SQN and MAC is received), the UE shall send the AUTHENTICATION RESPONSE message to the network and shall start any retransmission timers (e.g. T3510, T3517 or T3521) if they were running and stopped when the UE received the first failed AUTHENTICATION REQUEST message.

If the UE receives the second AUTHENTICATION REQUEST message, and the MAC value cannot be resolved, the UE shall follow the procedure specified in this subclause, item c, starting again from the beginning, or if the message contains a UMTS authentication challenge, the UE shall follow the procedure specified in item d. If the SQN is invalid, the UE shall proceed as specified in item f.

Figure 5.4.1.3.7.1: Authentication failure during 5G AKA based primary authentication and key agreement procedure

d) Authentication failure (5GMM cause #26 "non-5G authentication unacceptable").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #26 "non-5G authentication unacceptable", to the network and start the timer T3520 (see example in figure 5.4.1.3.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #26 "non-5G authentication unacceptable", the network may initiate the identification procedure described in subclause 5.4.3. This is to allow the network to obtain the SUCI from the UE. The network may then check that the 5G-GUTI originally used in the 5G authentication challenge corresponded to the correct SUPI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall proceed as specified in subclause 5.4.3.3.

NOTE 2: Upon receipt of an AUTHENTICATION FAILURE message from the UE with 5GMM cause #26 "non-5G authentication unacceptable", the network may also terminate the 5G AKA based primary authentication and key agreement procedure (see subclause 5.4.1.3.5).

If the mapping of 5G-GUTI to SUPI 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 T3520, if running, and then process the 5G challenge information as normal. If the mapping of 5G-GUTI to SUPI in the network was correct, the network should terminate the 5G AKA based primary authentication and key agreement authentication procedure by sending an AUTHENTICATION REJECT message (see subclause 5.4.1.3.5).

…

f) Authentication failure (5GMM cause #21 "synch failure").

The UE shall send an AUTHENTICATION FAILURE message, with 5GMM cause #21 "synch failure", to the network and start the timer T3520 (see example in figure 5.4.1.3.7.1). Furthermore, the UE shall stop any of the retransmission timers that are running (e.g. T3510, T3517 or T3521). Upon the first receipt of an AUTHENTICATION FAILURE message from the UE with the 5GMM 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 AMF to delete all unused authentication vectors for that SUPI and obtain new vectors from the UDM/AUSF. When re-synchronisation is complete, the network shall initiate the 5G AKA based primary authentication and key agreement procedure. Upon receipt of the AUTHENTICATION REQUEST message, the UE shall stop the timer T3520, if running.

NOTE 4: Upon receipt of two consecutive AUTHENTICATION FAILURE messages from the UE with 5GMM cause #21 "synch failure", the network may terminate the 5G AKA based primary authentication and key agreement procedure by sending an AUTHENTICATION REJECT message.

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

Upon receipt of an AUTHENTICATION REJECT message, the UE shall perform the actions as specified in subclause 5.4.1.3.5.

9.1.1.4.3 Test description

9.1.1.4.3.1 Pre-test conditions

System Simulator:

– NR cell A.

UE:

– None.

Preamble:

– the UE is in state Switched OFF (state 0N-B) according to TS 38.508-1 [4].

9.1.1.4.3.2 Test procedure sequence

Table 9.1.1.4.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Switch the UE on	–	–	–	–
2-4	The UE establishes RRC connection and initiates registration procedure by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
5	The SS transmits an AUTHENTICATION REQUEST message which contains an invalid MAC code.	<–	AUTHENTICATION REQUEST	–	–
6	Check: Does the UE respond with an AUTHENTICATION FAILURE message with 5GMM cause "MAC failure"?	–>	AUTHENTICATION FAILURE	1	P
7	SS transmits a correct AUTHENTICATION REQUEST message with RAND different to the one send in Step 5	<–	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	4	P
9	SS transmits a NAS SECURITY MODE COMMAND message including the ngKSI of the new 5G NAS security context (as provided in step 7), to proceed with the registration procedure.	<–	SECURITY MODE COMMAND	–	–
10	Check: Does the UE respond with NAS SECURITY MODE COMPLETE message integrity protected and ciphered with the new 5G NAS security context identified by the ngKSI received in the SECURITY MODE COMMAND message in step 9.	–>	SECURITY MODE COMPLETE	5	P
11-20a1	Steps 10-19a1 of the generic procedure (TS 38.508-1 Table 4.5.2.2-2 [4]) are executed to successfully complete the registration procedure.	–	–	–	–
21	Switch off UE in RRC_CONNECTED as described in TS 38.508-1 [4] subclause 4.9.6.3	–	–	–	–
22-25	Steps 1-4 above are repeated	–	–	–	–
26	SS transmits an AUTHENTICATION REQUEST message with "separation bit" in the AMF field is 0.	<–	AUTHENTICATION REQUEST	–	–
27	Check: Does the UE respond with an AUTHENTICATION FAILURE message, with 5GMM cause " Non-5G authentication unacceptable "?	–>	AUTHENTICATION FAILURE	2	P
28	SS transmits a correct AUTHENTICATION REQUEST message with RAND different to the one send in Step 26	<–	AUTHENTICATION REQUEST	–	–
29	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	4	P
30-41a1	Steps 8-19a1 of the generic procedure (TS 38.508-1 Table 4.5.2.2-2 [4]) are executed to successfully complete the registration procedure.	–	–	–	–
42	Switch off UE in RRC_CONNECTED as described in TS 38.508-1 [4] subclause 4.9.6.3	–	–	–	–
43-46	Steps 1-4 above are repeated	–	–	–	–
47	SS transmits AUTHENTICATION REQUEST message with the AMF field in the IE "Authentication parameter AUTN" set to "AMF_RESYNCH" value to trigger SQN re-synchronisation procedure in test USIM	<–	AUTHENTICATION REQUEST	–	–
48	Check: Does the UE respond with an AUTHENTICATION FAILURE message, with 5GMM cause "Synch failure" and Authentication failure parameter?	–>	AUTHENTICATION FAILURE	3	P
49	SS transmits a correct AUTHENTICATION REQUEST message with RAND different to the one send in Step 47.	<–	AUTHENTICATION REQUEST	–	–
50	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	4	P
51-62a1	Steps 8-19a1of the generic procedure (TS 38.508-1 Table 4.5.2.2-2 [4]) are executed to successfully complete the registration procedure.	–	–	–	–

9.1.1.4.3.3 Specific message contents

Table 9.1.1.4.3.3-1: AUTHENTICATION RESPONSE (step 8, step 29 and step 50，Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-2
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 9.1.1.4.3.3-2: AUTHENTICATION REQUEST (step 5, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-1
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.1.4.3.3-3: AUTHENTICATION FAILURE (step 6, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-4
Information Element	Value/remark	Comment	Condition
5GMM cause	‘0001 0100’B	MAC failure

Table 9.1.1.4.3.3-4: AUTHENTICATION REQUEST (step 26, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-1
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.1.4.3.3-5: AUTHENTICATION FAILURE (step 27, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-4
Information Element	Value/remark	Comment	Condition
5GMM cause	‘0001 1010’B	Non-5G authentication unacceptable

Table 9.1.1.4.3.3-6: AUTHENTICATION REQUEST (step 47, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-1

Information Element

Value/remark

Comment

Condition

Authentication parameter AUTN

AMF field set to "AMF_RESYNCH",

AMF_RESYNCH= ‘1111 1111 1111 1111’B

AMF_RESYNCH see TS 34.108, 8.1.2.2

Table 9.1.1.4.3.3-7: AUTHENTICATION FAILURE (step 48, Table 9.1.1.4.3.2-1)

Derivation path: TS 38.508, Table 4.7.1-4
Information Element	Value/remark	Comment	Condition
5GMM cause	‘0001 0101’B	Synch failure
Authentication failure parameter	AUTS	AUTS see TS 34.108, 8.1.2.2

9.1.1.5 5G AKA based primary authentication and key agreement / Reject

9.1.1.5 Test Purpose (TP)

(1)

with { the UE in 5GMM-REGISTERED-INITIATED state and SS initiates a 5G AKA based primary authentication and key agreement procedure }

ensure that {

when { the SS sends an a AUTHENTICATION REJECT message }

then { the UE deletes the stored 5G-GUTI, last visited registered TAI and ngKSI and enter state 5GMM-DEREGISTERED, the USIM is considered invalid until switching off the UE. }

}

9.1.1.5.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.501 clauses 5.4.1.3.5. Unless otherwise stated these are Rel-15 requirements.

[TS 24.501, clause 5.4.1.3.5]

If the authentication response (RES) returned by the UE is not valid, the network response depends upon the type of identity used by the UE in the initial NAS message, that is:

– if the 5G-GUTI was used; or

– if the SUCI was used.

If the 5G-GUTI was used, the network should initiate an identification procedure to retrieve SUCI from the UE and restart the 5G AKA based primary authentication and key agreement procedure with the received SUCI.

If the SUCI was used for identification in the initial NAS message or in a restarted 5G AKA based primary authentication and key agreement procedure, or the network decides not to initiate the identification procedure to retrieve SUCI from the UE after an unsuccessful 5G AKA based primary authentication and key agreement procedure, the network should send an AUTHENTICATION REJECT message to the UE.

Upon receipt of an AUTHENTICATION REJECT message,

1) if the message has been successfully integrity checked by the NAS, the UE shall set the update status to 5U3 ROAMING NOT ALLOWED, delete the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI.

In case of PLMN, the USIM shall be considered invalid until switching off the UE or the UICC containing the USIM is removed. In case of SNPN, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN shall be considered invalid until the UE is switched off or the entry is updated.

– The UE shall set:

i) the counter for "SIM/USIM considered invalid for GPRS services" events and the counter for "SIM/USIM considered invalid for 5GS services over non-3GPP access" events in case of PLMN; or

ii) the counter for "the entry for the current SNPN considered invalid for 3GPP access" events in case of SNPN;

to UE implementation-specific maximum value. If the UE maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the UE shall set this counter to UE implementation-specific maximum value; and

– if the UE is operating in single-registration mode, the UE shall handle 4G-GUTI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the authentication procedure is not accepted by the network. The USIM shall be considered as invalid also for non-EPS services until switching off or the UICC containing the USIM is removed.

2) if the message is received without integrity protection, the UE shall start timer T3247 with a random value uniformly drawn from the range between 30 minutes and 60 minutes, if the timer is not running (see subclause 5.3.20). Additionally, the UE shall:

a) if the message is received over 3GPP access, and the counter for "SIM/USIM considered invalid for GPRS services" events or the counter for "the entry for the current SNPN considered invalid for 3GPP access" events has a value less than a UE implementation-specific maximum value, proceed as specified in subclause 5.3.20, list item 1)-a) of clause 5.3.20.2 (if the UE is not SNPN enabled or is not operating in SNPN access mode) or list item a) of clause 5.30.20.3 (if the UE is operating in SNPN access mode) for the case that the 5GMM cause value received is #3;

b) if the message is received over non-3GPP access, and the counter for "SIM/USIM considered invalid for 5GS services over non-3GPP access" events has a value less than a UE implementation-specific maximum value, proceed as specified in subclause 5.3.20, list item 1)-b) of clause 5.3.20.2 for the case that the 5GMM cause value received is #3.

c) otherwise

i) if the 5GMM cause value is received over 3GPP access, the UE shall:

– set the update status for 3GPP access to 5U3 ROAMING NOT ALLOWED, delete for 3GPP access only the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI. The USIM shall be considered invalid for 5GS services via 3GPP access and non-EPS service until switching off the UE or the UICC containing the USIM is removed or the entry of the "list of subscriber data" with the SNPN identity of the current SNPN shall be considered invalid for 3GPP access until the UE is switched off or the entry is updated.

– The UE shall set the counter for "SIM/USIM considered invalid for GPRS services" events or the counter for "the entry for the current SNPN considered invalid for 3GPP access" events to UE implementation-specific maximum value. If the UE maintains a counter for "SIM/USIM considered invalid for non-GPRS services", then the UE shall set this counter to UE implementation-specific maximum value.

– If the UE is operating in single-registration mode, the UE shall handle 4G-GUTI, TAI list and eKSI as specified in 3GPP TS 24.301 [15] for the case when the authentication procedure is not accepted by the network. The USIM shall be considered as invalid also for non-EPS services until switching off or the UICC containing the USIM is removed; and

ii) if the 5GMM cause value is received over non-3GPP access, the UE shall:

– set the update status for non-3GPP access to 5U3 ROAMING NOT ALLOWED, delete for non-3GPP access only the stored 5G-GUTI, TAI list, last visited registered TAI and ngKSI. The USIM shall be considered invalid for 5GS services via non-3GPP access until switching off the UE or the UICC containing the USIM is removed.

The UE shall set the counter for "SIM/USIM considered invalid for 5GS services over non-3GPP access" events to UE implementation-specific maximum value.

If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any 5GMM signalling procedure, stop any of the timers T3510, T3516, T3517, T3519 or T3521 (if they were running), enter state 5GMM-DEREGISTERED and delete any stored SUCI.

Depending on local requirements or operator preference for emergency services, if the UE initiates a registration procedure with 5GS registration type IE set to "emergency registration" and the AMF is configured to allow emergency registration without user identity, the AMF needs not follow the procedures specified for the authentication failure in the present subclause. The AMF may continue a current 5GMM specific procedure.

9.1.1.5.3 Test description

9.1.1.5.3.1 Pre-test conditions

System Simulator:

– NGC Cell A "Serving cell" TS 38.508-1 [4] Table 6.2.2.1-3

UE:

– None

Preamble:

– The UE is in state Switched OFF (state 0N-B) according to TS 38.508-1 [4].

9.1.1.5.3.2 Test procedure sequence

Table 9.1.1.5.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.	–	–	–	–
2-4	The UE executes steps 2-4 of Table 4.5.2.2-2 in TS38.508-1 [4].	–	–	–	–
5	The SS transmits an AUTHENTICATION REQUEST message		5GMM: AUTHENTICATION REQUEST	–	–
6	The UE transmits an AUTHENTICATION RESPONSE		5GMM: AUTHENTICATION RESPONSE	–	–
7	The SS transmits an AUTHENTICATION REJECT message	<–	5GMM: AUTHENTICATION REJECT	–	–
8	SS releases the RRC connection	–	–	–	–
9	Check: Does the UE transmit an RRCSetupRequest message for initial registration procedure within the next 30 seconds?	–>	NR RRC: RRCSetupRequest	1	F
10	The UE is switched off by executing generic procedure in Table 4.9.6.4-1 in TS 38.508-1 [4].	–	–	–	–
11	The UE is switched on.	–	–	–	–
12	Check: Does the UE transmit a REGISTRATION REQUEST message?	–>	5GMM: REGISTRATION REQUEST	1	P
13-28a1	The UE executes steps 5-20a1 of Table 4.5.2.2-2 in TS 38.508-1 [4] complete registration procedure.	–	–	–	–

9.1.1.5.3.3 Specific message contents

Table 9.1.1.5.3.3-1: REGISTRATION REQUEST (step 4, Table 9.1.1.5.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type
5GS registration type value	‘001’B	initial registration

Table 9.1.1.5.3.3-2: REGISTRATION REQUEST (step 12, Table 9.1.1.5.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type
5GS registration type value	‘001’B	initial registration
ngKSI	‘111’	no key is available
5GS mobile identity	SUCI of the UE	a freshly generated SUCI
Last visited registered TAI	Not present

9.1.1.6 5G AKA based primary authentication and key agreement / Abnormal

9.1.1.6 Test Purpose (TP)

(1)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use }

then { the UE sends an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #71 "ngKSI already in use" }

}

(2)

with { the UE in 5GMM-REGISTERED-INITIATED state }

ensure that {

when { the third time SS initiates 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use }

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

}

(3)

with { the UE in 5GMM-REGISTERED-INITIATED state, the SS sends an AUTHENTICATION REQUEST with ngKSI is already in use and the UE sends an AUTHENTICATION FAILURE message }

ensure that {

when { T3520 times out }

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

}

(4)

Void

(5)

with { the UE in 5GMM-REGISTERED state and initiates a mobility registration update procedure }

ensure that {

when { the SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST and the UE fails on transmission of AUTHENTICATION RESPONSE message with the indication from lower layers }

then { the UE re-initiate the mobility registration update procedure }

}

9.1.1.6.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 24.501 clauses 5.4.1.3.7. Unless otherwise stated these are Rel-15 requirements.

[TS 24.501, clause 5.4.1.3.7]

e) Authentication failure (5GMM cause #71 "ngKSI already in use").

…

g) Network failing the authentication check.

h) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication from lower layers (if the 5G AKA based primary authentication and key agreement procedure is triggered by a registration procedure for mobility and periodic registration update).

The UE shall stop the timer T3520, if running, and re-initiate the registration procedure for mobility and periodic registration update.

…

i) Transmission failure of AUTHENTICATION RESPONSE message or AUTHENTICATION FAILURE message indication with TAI change from lower layers (if the 5G AKA based primary authentication and key agreement procedure is triggered by a service request procedure).

The UE shall stop the timer T3520, if running.

If the current TAI is not in the TAI list, the 5G AKA based primary authentication and key agreement procedure shall be aborted and a registration procedure for mobility and periodic registration update shall be initiated.

If the current TAI is still part of the TAI list, it is up to the UE implementation how to re-run the ongoing procedure that triggered the 5G AKA based primary authentication and key agreement procedure.

…

For items c, d, e, and f whether or not the UE is registered for emergency services:

…

The UE shall deem that the network has failed the authentication check or assume that the authentication is not genuine and proceed as described in item g above if any of the following occurs:

– the timer T3520 expires;

– the UE detects any combination of the 5G authentication failures: 5GMM causes #20 "MAC failure", #21 "synch failure", #26 "non-5G authentication unacceptable" or #71 "ngKSI already in use", during three consecutive authentication challenges. The 5G authentication challenges shall be considered as consecutive only, if the 5G authentication challenges causing the second and third 5G authentication failure are received by the UE, while the timer T3520 started after the previous 5G authentication failure is running.

9.1.1.6.3 Test description

9.1.1.6.3.1 Pre-test conditions

System Simulator:

– NGC Cell A, NGC Cell B, NGC Cell C and NGC Cell D are configured according to table 6.3.2.2-1 in TS 38.508-1 [4].

– The SS configures the NGC Cell A as the "Serving cell" and other NGC Cells as "Non-suitable "Off" cell".

– System information combination NR-2 as defined in TS 38.508-1 [4] clause 4.4.3.1.2 is used.

UE:

– None.

Preamble:

– The UE is in test state 0N-B on NGC Cell A according to TS 38.508-1 [4]. The ngKSI-1 has been assigned and security context has been established.

9.1.1.6.3.2 Test procedure sequence

Table 9.1.1.6.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
–	The following messages are to be observed on NGC Cell A unless explicitly stated otherwise.	–	–	–	–
0	The UE is switched on.	–	–	–	–
0A	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4] and transmits a REGISTRATION REQUEST message.	–>	5GMM: REGISTRATION REQUEST	–	–
1	The SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use (ngKSI-1).	<–	5GMM: AUTHENTICATION REQUEST	–	–
2	Check: Does the UE send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #71 "ngKSI already in use"?	–>	5GMM: AUTHENTICATION FAILURE	1	P
3	The SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use (ngKSI-1).	<–	5GMM: AUTHENTICATION REQUEST	–	–
4	Check: Does the UE send an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #71 "ngKSI already in use"?	–>	5GMM: AUTHENTICATION FAILURE	1	P
5	Void	–	–	–	–
6	The SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use (ngKSI-1).	<–	5GMM: AUTHENTICATION REQUEST	–	–
6a1	EXCEPTION: The UE may send an AUTHENTICATION FAILURE before locally releasing the RRC Connection.	–>	5GMM: AUTHENTICATION FAILURE	–	–
6A	Check: Does the UE transmit a RRCSetupRequest on NGC Cell A in the next 30 seconds? (Note 1)	–>	5G RRC: RRCSetupRequest	2	F
6B	The SS configures: -NGC Cell B as the "Serving cell". -NGC Cell A as a "Suitable neighbour intra-frequency cell".	–	–	–	–
–	The following messages are to be observed on NGC Cell B unless explicitly stated otherwise.	–	–	–	–
7-9	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
10	Check: Does the UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as initial registration?	–>	5GMM: REGISTRATION REQUEST	2	P
11	The SS initiates a 5G AKA based primary authentication and key agreement procedure by sending AUTHENTICATION REQUEST with ngKSI is already in use (ngKSI-1).	<–	5GMM: AUTHENTICATION REQUEST	–	–
12	The UE sends an AUTHENTICATION FAILURE message to the network, with the 5GMM cause #71 "ngKSI already in use".	–>	5GMM: AUTHENTICATION FAILURE	–	–
12A	SS starts timer of t_Waits=T3520.	–	–	–	–
13	Void	–	–	–	–
14	SS waits for the expiration of t_Waits.	–	–	–	–
14A	Check: Does the UE transmit a RRCSetupRequest on NGC Cell B in the next 30 seconds? (Note 1)	–>	5G RRC: RRCSetupRequest	2	F
14B	The SS configures: -NGC Cell C as the "Serving cell". -NGC Cell B as a "Suitable neighbour intra-frequency cell". -NGC Cell A as a "Non-suitable "Off" cell"	–	–	–	–
–	The following messages are to be observed on NGC Cell C unless explicitly stated otherwise.	–	–	–	–
15-17	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS38.508-1 [4].	–	–	–	–
18	Check: Does the UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as initial registration?	–>	5GMM: REGISTRATION REQUEST	3	P
19-34a1	Steps 5-20a1 of Table 4.5.2.2-2 of the generic procedure in TS 38.508-1 [4] are performed.	–	–	–	–
35-39	Void
40	The SS configures: – NGC Cell D as the “Serving cell”. – NGC Cell C as a “Non-suitable "Off" cell “. – NGC Cell B as a "Non-suitable "Off" cell ".	–	–	–	–
41-42	Void
–	The following messages are to be observed on NGC Cell D unless explicitly stated otherwise.	–	–	–	–
43-45	The UE establishes RRC connection by executing steps 2-4 of Table 4.5.2.2-2 in TS 38.508-1 [4].	–	–	–	–
46	The UE transmit a REGISTRATION REQUEST message with the 5GS registration type IE setting as Mobility registration updating.	–>	5GMM: REGISTRATION REQUEST	–	–
47	The SS cuts off the UL grant and RA Response, so that the UE cannot send the AUTHENTICATION RESPONSE to SS.	–	–	–	–
48	SS transmits an AUTHENTICATION REQUEST message with ngKSI-2 to initiate the 5G-AKA procedure.	<–	5GMM: AUTHENTICATION REQUEST	–	–
49	SS starts timer of t_Delay =10s. (Note2).	–	–	–	–
50	SS performs local release.	–	–	–	–
51	Check whether t_Delay is still running, if it’s running, then waiting for timeout.	–	–	–	–
52	SS configures the RA Response.	–	–	–	–
53	Check: Does the test result of generic test procedure in TS 38.508-1 [4] subclause 4.9.5 indicate that the UE is camped on NGC Cell D, with ‘connected without release‘?	–	–	5	P
Note 1: If the cell is not barred, after the transmission of REGISTRATION REQUEST, the UE will start T3510 and T3511. After 25s (T3510+T3511), the UE shall send REGISTRATION REQUEST. Note 2: To send the AUTHENTICATION RESPONSE, the UE will initiate RACH to get UL grant. Since there is no RA Response, registration failure due to lower layer failure will occur, then T3511 will start. Timer t_Delay is derived from T3511. During timer t_Delay, UE fails on transmission of AUTHENTICATION RESPONSE message with the indication from lower layers.

9.1.1.6.3.3 Specific message contents

Table 9.1.1.6.3.3-1: AUTHENTICATION REQUEST (step 1, step 3, step 6 and step 11, Table 9.1.1.6.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
ngKSI	ngKSI-1	The same with the ng-KSI assigned in Preamble.

Table 9.1.1.6.3.3-2: AUTHENTICATION FAILURE (step 2, step 4, step 6a1 and step 12, Table 9.1.1.6.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-4
Information Element	Value/Remark	Comment	Condition
5GMM cause	‘0100 0111’B	ngKSI already in use

Table 9.1.1.6.3.3-3: AUTHENTICATION REQUEST (step 48, Table 9.1.1.6.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-1
Information Element	Value/Remark	Comment	Condition
ngKSI	ngKSI-2	Different from the ng-KSI assigned in step 19

Table 9.1.1.6.3.3-4: REGISTRATION REQUEST (step 10 and step 18, Table 9.1.1.6.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type
5GS registration type value	‘001’B	initial registration

Table 9.1.1.6.3.3-5: REGISTRATION REQUEST (step 46, Table 9.1.1.6.3.2-1)

Derivation path: TS 38.508-1 [4], table 4.7.1-6
Information Element	Value/Remark	Comment	Condition
5GS registration type
5GS registration type value	‘010’B	mobility registration updating