Security in Intra-LTE State Transitions and Mobility
9.7 Concurrent Run of Security Procedures
There are many security and mobility-related procedures that both the base station and the MME can initiate, and this may happen concurrently. Whether this is a design or implementation problem does not matter if concurrency rules for the procedures help to avoid errors and reduce complexity in implementations. For example, we know that after EPS AKA there is a new key KASME in the MME, but the NAS keys are still based on the old key KASME. Thus, the MME needs to initiate a NAS Security Mode Command procedure. However, when this occurs during a service request procedure and at the same time the MME sends the KeNBto the base station, there is a race condition between the AS and NAS-level signalling procedures as the UE may derive the KeNB based on the old or the new key KASME, dependent on whether the UE receives the AS-level Security Mode Command before or after the NAS-level Security Mode Command. Next, we describe the 10 concurrency rules listed in [TS33.401].
1. The first rule states that the MME must not initiate any procedure that includes sending a new KeNB to the base station during an ongoing NAS-level security mode
command procedure. The reason is that, otherwise, the UE and MME may derive the new KeNBfrom the different root keys. Note that the new KeNBwill be taken into use with either the AS-level security mode command procedure or with the key change on-the-fly procedure, but not with intercell handovers.
2. Similarly, the second rule states that, if there is a procedure ongoing that includes sending a new KeNB to the base station, the MME must not initiate a NAS security mode command procedure. This rule is similar to the first one, and is required to make sure that the UE and MME derive the KeNB from the same root key.
3. The third rule is also about deriving the KeNBfrom the right{NH, NCC}pair or KeNB key during handovers. If the MME has an ongoing NAS security mode command procedure, the{NH, NCC}pair sent to the target base station during handovers must still be based on the old KASME root key. The reason is that, at the AS level, the KeNB based on the old root key KASME is still used. Only after the MME has sent the new KeNB to the base station, and the base station has successfully taken it into use, the MME can send fresh{NH, NCC}pairs based on the new KASME root key.
4. This is the counterpart rule to the third rule and is for the UE. The UE must continue to use the AS-level parameters based on the old root key KASME, even if the UE has received the NAS security mode command message. Only after the base station has successfully run the RRC Connection Re-configuration procedure for taking the new KeNB from the new KASME root key into use, the UE must use the fresh AS-level parameters for handovers and discard the old AS parameters.
5. The fifth rule says that while there is an ongoing interbase station handover procedure, the base station shall reject any S1 UE Context Modification procedures from the MME (i.e. the procedure that delivers a new KeNB based on a new KASME). This is simply to avoid key synchronization problems. Also, the base station must not initiate any new handover procedures before the current RRC Connection Re-configuration procedure is finished.
6. The sixth rule is similar to rule 5, but is for the MME. It says that the MME must not proceed with an inter-MME handover or inter-RAT (Radio Access Technology) handover signalling while there is an ongoing NAS security mode command proce-dure. The reason is that the NAS-level security context changes as a result of the NAS security mode command procedure. In the inter-MME handover procedure, the source MME sends the NAS-level security context to the target MME. Thus, during the NAS security mode command procedure the NAS-level security context is not well defined. Similar problems would occur in an inter-RAT handover.
7. Similarly to rule 6, the MME must not continue with inter-MME handover signalling before it has finished an ongoing S1 UE Context Modification procedure. The reason is the AS-level parameter synchronization among the base station, the UE and the MME. If during this synchronization the source MME sent new or old NAS-level security context, including the{NH, NCC}pair, to the target MME, the target MME might send different KASMEroot key based parameters to the target base station from what UE and the base station are currently using.
8. Rule 8 describes the case when the MME has taken new NAS keys into use based on the new KASMEroot key but has not yet initiated the S1 UE Context Modification procedure to synchronize the new KeNB with the base station and the UE. If at this point there is an inter-MME handover, the source MME must send both the old
Security in Intra-LTE State Transitions and Mobility 173
and the new KASMEroot key security contexts with corresponding Key Set Identifier (eKSI) to the target MME.
9. As a response to rule 8, the target MME needs to know what to do with the two KASME during inter-MME handover. Rule 9 says that the target MME must use the new KASMEroot key based NAS-level security context for NAS protection, but the old KASME root key based parameters for the AS-level operations. Then the target MME must at some point initiate the S1 UE Context Modification procedure to synchronize the new KeNB based on the new KASMEroot key with the base station and the UE.
10. During inter-MME mobility, the source MME must not send any NAS messages to the UE after it has sent the UE context to the target MME. Only if the handover is cancelled or fails, the source MME can start sending NAS messages to the UE.
These rules are self-evident after the right situations or concurrency cases have been identified. However, it is not easy to come up with a complete list of possible error cases and concurrent run of procedures. These 10 rules help to understand the possible race conditions and error cases better, but also provide guidance on how to implement the system to better avoid them.