22.5.2 NB-IoT / NAS Security / Handling of null integrity protection and null ciphering algorithms / NAS count reset to zero / Security mode command with not matching replayed security capabilities / Provision of IMEISV and IMEI
36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification
22.5.2.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 requesting "null integrity protection algorithm" EIA0 }
then { UE sends SECURITY MODE REJECT and does not start applying the "null integrity protection algorithm" EIA0 }
}
(2)
with { successful completion of EPS authentication and key agreement (AKA) procedure }
ensure that {
when { UE receives a SECURITY MODE COMMAND message requesting "null ciphering algorithm" EEA0 }
then { UE sends an integrity protected and ciphered SECURITY MODE COMPLETE message and starts applying the NAS Security in both UL and DL }
}
(3)
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 continues using the established before the SECURITY MODE COMMAND message was received EPS security context }
}
(4)
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 }
then { UE sends integrity protected and ciphered SECURITY MODE COMPLETE message with NAS count set to zero and starts applying the NAS Security in both UL and DL }
}
(5)
with { successful completion of EPS authentication and key agreement (AKA) procedure }
ensure that {
when { UE receives a SECURITY MODE COMMAND message requesting IMEISV }
then { UE sends an integrity protected and ciphered SECURITY MODE COMPLETE message including IMEISV }
}
(6)
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 }
}
(7)
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 }
}
22.5.2.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.2.4, 4.4.3.1, 4.4.3.4, 4.4.4.1, 4.4.4.2, 4.4.5, 5.4.3.1, 5.4.3.3, 5.4.3.5, 5.4.4.3. Unless otherwise stated these are Rel-13 requirements.
[TS 24.301, clause 4.4.2.4]
When the MME initiates a re-authentication to create a new EPS security context, the messages exchanged during the authentication procedure are integrity protected and ciphered using the current EPS security context, if any.
Both UE and MME shall continue to use the current EPS security context, until the MME initiates a security mode control procedure. The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS security context to be used. The MME shall send the SECURITY MODE COMMAND message integrity protected with the new EPS security context, but unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity protected and ciphered with the new EPS security context.
The MME can also modify the current EPS security context or take the non-current native EPS security context, if any, into use, by sending a SECURITY MODE COMMAND message including the eKSI of the EPS security context to be modified and including a new set of selected NAS security algorithms. In this case the MME shall send the SECURITY MODE COMMAND message integrity protected with the modified EPS security context, but unciphered. When the UE replies with a SECURITY MODE COMPLETE message, it shall send the message integrity protected and ciphered with the modified EPS security context.
[TS 24.301, clause 4.4.3.1]
Each EPS 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.
The value of the uplink NAS COUNT that is stored or read out of the USIM or non-volatile memory as described in annex C, is the value that shall be used in the next NAS message.
The value of the downlink NAS COUNT that is stored or read out of the USIM or non-volatile memory as described in annex C, is the largest downlink NAS COUNT used in a successfully integrity checked NAS message.
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, except for the initial NAS messages if the lower layers indicated the failure to establish the RRC connection (see 3GPP TS 36.331 [22]). 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 4.4.3.4]
The sender shall use its locally stored NAS COUNT as input to the ciphering algorithm.
The receiver shall use the NAS sequence number included in the received message (or estimated from the 5 bits of the NAS sequence number received in the message) and an estimate for the NAS overflow counter as defined in subclause 4.4.3.1 to form the NAS COUNT input to the deciphering algorithm.
The input parameters to the NAS ciphering algorithm are the constant BEARER ID, DIRECTION bit, NAS COUNT, NAS encryption key and the length of the key stream to be generated by the encryption algorithm. When an initial plain NAS message for transport of user data via control plane (i.e. CONTROL PLANE SERVICE REQUEST message) is to be partially ciphered, the length of the key stream is set to the length of the part of the initial plain NAS message (i.e. the value part of the ESM message container IE or the value part of the NAS message container) that is to be ciphered.
[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 which establishment of emergency bearer services is allowed. 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.
…
When a NAS message needs to be sent both ciphered and integrity protected, the NAS message is first ciphered and then the ciphered NAS message and the NAS sequence number are integrity protected by calculating the MAC. The same applies when an initial NAS message needs to be sent partially ciphered and integrity protected.
NOTE: NAS messages that are ciphered or partially ciphered with the "null ciphering algorithm" EEA0 are regarded as ciphered or partially ciphered, respectively (see subclause 4.4.5).
[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;
– AUTHENTICATION REJECT;
– ATTACH REJECT (if the EMM cause is not #25);
– DETACH ACCEPT (for non switch off);
– TRACKING AREA UPDATE REJECT (if the EMM cause is not #25);
– SERVICE REJECT (if the EMM cause is not #25).
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 4.4.5]
The use of ciphering in a network is an operator option subject to MME configuration. When operation of the network without ciphering is configured, the MME shall indicate the use of "null ciphering algorithm" EEA0 (see subclause 9.9.3.23) in the current security context for all UEs. 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 ciphering algorithm" or any other ciphering algorithm is indicated in the security context.
…
If the "null ciphering algorithm" EEA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.
[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 EPS NAS keys and EPS security algorithms.
Furthermore, the network may also initiate the security mode control procedure in the following cases:
– in order to change the NAS security algorithms for a current EPS security context already in use; and
– in order to change the value of uplink NAS COUNT used in the latest SECURITY MODE COMPLETE message as described in 3GPP TS 33.401 [19], subclause 7.2.9.2.
[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 the latest values that the UE sent to the network. 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.
…
If the SECURITY MODE COMMAND message can be accepted, the UE shall take the EPS security context indicated in the message into use. The UE shall in addition reset the uplink NAS COUNT counter if:
– the SECURITY MODE COMMAND message is received in order to take an EPS security context into use created after a successful execution of the EPS authentication procedure;
…
If the SECURITY MODE COMMAND message can be accepted and a new EPS security context is taken into use and SECURITY MODE COMMAND message does not indicate the "null integrity protection algorithm" EIA0 as the selected NAS integrity algorithm, the UE shall:
– if the SECURITY MODE COMMAND message has been successfully integrity checked using an estimated downlink NAS COUNT equal 0, then the UE shall set the downlink NAS COUNT of this new EPS security context to 0;
…
If the SECURITY MODE COMMAND message can be accepted, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS integrity algorithm and the EPS 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. When the SECURITY MODE COMMAND message includes the type of security context flag set to "mapped security context" in the NAS key set identifier IE, the nonceMME and the nonceUE, then the UE shall either:
– generate K’ASME from both the nonceMME and the nonceUE as indicated in 3GPP TS 33.401 [19];or
– …
Furthermore, if the SECURITY MODE COMMAND message can be accepted, the UE shall cipher the SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the EPS 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 onward 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.
[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.
…
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.
[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.
22.5.2.3 Test description
22.5.2.3.1 Pre-test conditions
System Simulator:
– NB-IoT Ncell 1, default system information.
UE:
None.
Preamble:
– The UE is in State 1-NB "Switched OFF" according to TS 36.508 [18].
22.5.2.3.2 Test procedure sequence
Table 22.5.2.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1-6 |
Steps 1-6 from the Generic procedure ‘NB-IoT UE Attach, Connected mode (State 2-NB)’ as described in TS 36.508 [18], clause 8.1.5.2 take place. NOTE 1: The SS shall send the AUTHENTICATION REQUEST message not secured (i.e. not integrity protected and not ciphered) regardless from whether EPS security context exists (e.g. may have been established during the preamble). The SS shall use an eKSI different from the eKSI received in ATTACH REQUEST (if any was received). NOTE 2: The AUTHENTICATION RESPONSE message may be integrity protected (if the UE has a security context) – the SS needs not to prove if this is valid or not. |
– |
– |
– |
– |
|
7 |
The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security requesting "null integrity protection algorithm" EIA0. NOTE: The message is integrity protected with the EPS security context created by the authentication procedure having taken place in steps 5-6 and the security header type is set to ‘Integrity protected with new EPS security context’ even though the message indicates "null integrity protection algorithm". |
<– |
RRC: DLInformationTransfer-NB NAS: SECURITY MODE COMMAND |
– |
– |
|
8 |
Check: Does the UE transmit a NAS SECURITY MODE REJECT message? NOTE: The message may be integrity protected (if the UE has a security context) – the SS needs not to prove if this is valid or not. |
–> |
RRC: ULInformationTransfer-NB NAS: SECURITY MODE REJECT |
1 |
P |
|
9 |
The SS Transmits an IDENTITY REQUEST message for IMEI. NOTE: The message is not integrity protected nor ciphered. |
<- |
RRC: DLInformationTransfer-NB IDENTITY REQUEST |
– |
– |
|
10 |
Check: Does the UE transmit IDENTITY RESPONSE message in the next 30 sec? |
-> |
RRC: ULInformationTransfer-NB IDENTITY RESPONSE |
1 |
F |
|
11 |
The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security requesting "null ciphering algorithm" EEA0 and a not "null integrity protection algorithm" (i.e. different to EIA0). NOTE: The message is integrity protected with the EPS security context created by the authentication procedure having taken place in steps 5-6 and the integrity protection algorithm included in the message itself, but not ciphered. |
<– |
RRC: DLInformationTransfer-NB NAS: SECURITY MODE COMMAND |
– |
– |
|
12 |
Check: Does the UE transmit a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration? NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
–> |
RRC: ULInformationTransfer-NB NAS: SECURITY MODE COMPLETE |
2 |
P |
|
13a1-18b1 |
Steps 9a1-14b1 from the Generic procedure ‘NB-IoT UE Attach, Connected mode (State 2-NB)’ as described in TS 36.508 [18], clause 8.1.5.2 take place. |
– |
– |
– |
– |
|
19 |
The SS transmits a NAS SECURITY MODE COMMAND message to change the Type of ciphering algorithm for the current EPS security context already in use. The included replayed security capabilities of the UE does not match those provided by the UE. NOTE: The message is integrity protected with the EPS security context created by the authentication procedure having taken place in steps 5-6 and the integrity protection algorithm included in the message itself, but not ciphered. |
<– |
RRC: DLInformationTransfer-NB NAS: SECURITY MODE COMMAND |
– |
– |
|
20 |
Check: Does the UE transmit a NAS SECURITY MODE REJECT message? NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
–> |
RRC: ULInformationTransfer-NB NAS: SECURITY MODE REJECT |
3 |
P |
|
21 |
The SS Transmits an IDENTITY REQUEST message for IMEI. NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
<- |
RRC: DLInformationTransfer-NB IDENTITY REQUEST |
– |
– |
|
22 |
Check: Does the UE transmit IDENTITY RESPONSE message providing its IMEI? NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
-> |
RRC: ULInformationTransfer-NB NAS: IDENTITY RESPONSE |
3,7 |
P |
|
23 |
The SS transmits an AUTHENTICATION REQUEST message to initiate the EPS authentication and AKA procedure for new key set generation. NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
<– |
RRC: DLInformationTransfer-NB NAS: AUTHENTICATION REQUEST |
– |
– |
|
24 |
The UE transmits an AUTHENTICATION RESPONSE message and establishes mutual authentication. NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 5-6 and using the algorithms provided in step 11. |
–> |
RRC: ULInformationTransfer-NB NAS: AUTHENTICATION RESPONSE |
– |
– |
|
25 |
SS resets UL and DL NAS Count to zero. |
– |
– |
– |
– |
|
26 |
The SS transmits a SECURITY MODE COMMAND message to activate NAS security. It is integrity protected and includes request to include IMEISV. NOTE: The message is integrity protected with the EPS security context created by the authentication procedure having taken place in steps 23-24 and the integrity protection algorithm included in the message itself, but not ciphered. |
<– |
RRC: DLInformationTransfer-NB NAS: SECURITY MODE COMMAND |
– |
– |
|
27 |
Check: Does the UE transmit a NAS SECURITY MODE COMPLETE message providing IMEISV? NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 23-24 and using the algorithms provided in step 26, and, respecting the count set in step 25. |
–> |
RRC: ULInformationTransfer-NB NAS: SECURITY MODE COMPLETE |
4,5 |
P |
|
– |
Exception: Steps 26 and 27 are executed 10 times to check UE is applying security correctly taking into account the NAS count. |
– |
– |
– |
– |
|
28 |
The SS transmits an IDENTITY REQUEST message requesting IMEISV. NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 23-24 and using the algorithms provided in step 26. The NAS COUNT number is increased by one after each new message being sent. |
<- |
RRC: DLInformationTransfer-NB NAS: IDENTITY REQUEST |
– |
– |
|
29 |
Check: Does the UE transmit an IDENTITY RESPONSE message providing its IMEISV and increasing the NAS COUNT number by one after each new message being sent? NOTE: The message is integrity protected and ciphered with the EPS security context created by the authentication procedure having taken place in steps 23-24 and using the algorithms provided in step 26. |
-> |
RRC: ULInformationTransfer-NB NAS: IDENTITY RESPONSE |
4,6 |
P |
|
30 |
SS releases the RRC connection |
<– |
RRC: RRCConnectionRequest-NB |
– |
– |
22.5.2.3.3 Specific message contents
Table 22.5.2.3.3-1: SystemInformationBlockType1-NB (All steps)
|
Derivation Path: 36.508 [18], Table 8.1.4.3.2-3, condition ATTACH_WITHOUT_PDN |
Table 22.5.2.3.3-2: SECURITY MODE COMMAND (step 7, Table 22.5.2.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 |
NULL integrity |
|
|
Type of ciphering algorithm |
EEA0 |
NULL ciphering |
|
|
NAS key set identifier |
|||
|
NAS key set identifier |
Set to the value that created at step 5 – step 6 |
||
|
TSC |
‘0’B |
native security context (for KSIASME) |
|
|
Spare half octet |
‘0000’B |
||
Table 22.5.2.3.3-3: SECURITY MODE COMMAND (step 11, Table 22.5.2.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 |
Set according to PIXIT parameter for default integrity protection algorithm if it is set to a value different to EIA0, or, set to any value different to EIA0 otherwise |
NOT NULL integrity protection algorithm |
|
|
Type of ciphering algorithm |
EEA0 |
NULL ciphering |
|
|
NAS key set identifier |
|||
|
NAS key set identifier |
‘ Set to the value that created at step 5 – step 6 |
||
|
TSC |
‘0’B |
native security context (for KSIASME) |
|
|
Spare half octet |
‘0000’B |
||
Table 22.5.2.3.3-4: SECURITY MODE COMMAND (step 19, Table 22.5.2.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 |
Set according to PIXIT parameter for default integrity protection algorithm if it is set to a value different to EIA0, or, set to any value different to EIA0 otherwise |
NOT NULL integrity protection algorithm |
|
|
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 |
|
|
Replayed UE security capabilities |
Set to mismatch the security capability of UE under test |
||
Table 22.5.2.3.3-5: SECURITY MODE COMMAND (step 26, Table 22.5.2.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 |
Set according to PIXIT parameter for default integrity protection algorithm if it is set to a value different to EIA0, or, set to any value different to EIA0 otherwise |
NOT NULL integrity protection algorithm |
|
|
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 22.5.2.3.3-6: SECURITY MODE COMPLETE (step 27, Table 22.5.2.3.2-1)
|
Derivation path: 36.508 [18], Table 4.7.2-20 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
IMEISV |
UE’s IMEISV |
||
Table 22.5.2.3.3-7: Message IDENTITY REQUEST (steps 9 and 21, Table 22.5.2.3.2-1)
|
Derivation Path: 36.508 [18], Table 4.7.2-17 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Identity Type |
0010 |
IMEI |
|
Table 22.5.2.3.3-8: IDENTITY RESPONSE (step 22, Table 22.5.2.3.2-1)
|
Derivation path: 36.508 [18], Table 4.7.2-18 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Mobile Identity |
|||
|
Type of identity |
010 |
IMEI |
|
|
Identity digits |
UE’s IMEI |
||
Table 22.5.2.3.3-9: Message IDENTITY REQUEST (step 28, Table 22.5.2.3.2-1)
|
Derivation Path: 36.508 [18], Table 4.7.2-17 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Identity Type |
0011 |
IMEISV |
|
Table 22.5.2.3.3-10: IDENTITY RESPONSE (step 29, Table 22.5.2.3.2-1)
|
Derivation path: 36.508 [18], Table 4.7.2-18 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Mobile Identity |
|||
|
Type of identity |
011 |
IMEISV |
|
|
Identity digits |
UE’s IMEISV |
||
Table 22.5.2.3.3-11: SECURITY MODE REJECT (steps 8, 20, Table 22.5.2.3.2-1)
|
Derivation path: 36.508 [18], Table 4.7.2-21 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
EMM cause |
Any allowed value |
||