Description in the LTE specification:
In the present document, when the UE is required to delete an eKSI, the UE shall set the eKSI to the value "no key is available" and consider also the associated keys KASME or K'ASME, EPS NAS ciphering key and EPS NAS integrity key invalid (i.e. the EPS security context associated with the eKSI as no longer valid).
Input of TPG:
initiate state: UE has established NAS security context (added by expert)
condition event: UE is required to delete an eKSI
expected operation: UE shall consider EPS security context valid
(negative testing)
Reasoned chain and sentences used:
Reason for condition event
There are two ways to trigger the condition event:
EDG: UE receives SERVICE REJECT with EMM cause #7 --> UE is required to delete an eKSI
sentence:
The UE shall take the following actions depending on the received EMM cause value in the SERVICE REJECT message.
# 7 (EPS services not allowed);
The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUIT, last visited registered TAI, TAI list and eKSI.
>> This means that we can trigger the condition event *UE is required to delete an eKSI* by sending SERVICE REJECT message with EMM cause #7.
EDG: UE receives ATTACH REJECT with EMM cause #7 --> UE is requied to delete an eKSI
sentence: The UE shall take the following actions depending on the received EMM cause value in the ATTACH REJECT message.
# 7 (EPS services not allowed);
The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to subclause 5.1.3.3) and shall delete any GUIT, last visited registered TAI, TAI list and eKSI.
>> This means that we can trigger the condition event *UE is required to delete an eKSI* by sending ATTACH REJECT message with EMM cause #7.
Reason for expected operation
EDG: UE take EPS security context into use == UE shall consider EPS security context valid
by ML model
>> This means that when we observe the event *EPS security context is taken into use*, it indirectly proves the happening of the event *consider EPS security context valid*
EDG: UE take the EPS security context into use --> SECURITY MODE COMMAND message can be accepted
sentence: If the SECURITY MODE COMMAND message can be accepted, the UE shall take the EPS security context indicated in the message into use.
>> This means that when we observe the event *SECURITY MODE COMMAND message can be accepted*, it indirectly proves the happening of the event *UE take the EPS security context into use*
EDG: MME sends SECURITY MODE COMMAND message --> UE receives SECURITY MODE COMMAND message
by ML model
EDG: UE receives SECURITY MODE COMMAND message --> UE accepts SECURITY MODE COMMAND message
by ML model
EDG: SECURITY MODE COMMAND message can be accepted --> UE send a SECURITY MODE COMPLETE message
sentence: 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.
>> This means that when we observe the event *UE sends SECURITY MODE COMPLETE message* after triggering the event *MME sends SECURITY MODE COMMAND* message, it indirectly proves the happening of the event *UE take the EPS security context into use*. Specifically, from the parameters highlighted in the sentences, after triggering the condition event, the testing system shall send a SECURITY MODE COMPLETE message with the previously used EPS NAS integrity key, and then check whether the event *UE sends a SECURITY MODE COMPLETE message* taken place. If the event has been observed, the testing system can determines that the UE fails to comply with the security requirement.
Note: the colored phrase are the messages to transmit and the parameters required to set.