Personally for me, I think this is one of the most complicated procedure and I made so many mistakes creating proper/flexible NAS security mode command (EMM : Security Mode Command) message.
I want to write down some important points to consider to creating EMM : Security Mode Command. Of course, these are not all.. so you may come across some other issues even though you checked everything described in this page.
Most of the contents in this page is based on 24.301 5.4.3 Security mode control procedure. Regarding the Security Algorithm, you need to refer to 33.401.
When network send EMM : Security Mode Command,
The MME shall set the security header type of the message to "integrity protected with new EPS security context".
: This mean that "Security protected NAS message.Security header type.Security header type" IE should be "integrity protected with new EPS security context".
24.301 5.4.3 States as follows
The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed nonceUE if the UE included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set Identifier (eKSI).
: This is the most complicated parts when it comes to creating the EMM : Security Mode Command and has been headache for me for so long. (probably even until now -:)). The list of parameters you have to match or playback in EMM : Security Mode Command is as shown below. (There are corresponding parameters in Tracking Area Update Request as well. If EMM : Security Mode Command comes after Tracking Area Update Request, you have to replay those values from Tracking Area Update Request).
- Attach request.NAS key set identifier
- Attach request.UE network capability
- Attach request.MS network capability
When UE received EMM : Security Mode Command,
When UE received EMM : Security Mode Command message, it goes through some basic process as follows :
- perform the integrity check of the message
- check 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.
EMM : Security Mode Reject
One of the most annoying things for troubleshooting is to fix this Security Mode Reject sent by UE. Of course, you cannot figure out anything from Network Log and even if you look into UE log, it would not tell much details. Then looking into 3GPP specification, following is all that I got. This is also not enough.
- Cause #23: UE security capabilities mismatch.
- Cause #24: Security mode rejected, unspecified.
- Stops timer T3460.
- Aborts the procedure that initiated the NAS security mode control.
- Reverts to the previous EPS security context, if applicable, to protect further communications.
If the UE cannot accept the SECURITY MODE COMMAND, it responds with a SECURITY MODE REJECT message, indicating one of the following:
On receiving this, the MME:
- This EMM cause is sent to the network if the UE detects that the UE security capability does not match the one sent back by the network.
- This EMM cause is sent to the network if the security mode command is rejected by the UE if the UE detects that the nonceUE does not match the one sent back by the network or for unspecified reasons.
Cause #23 UE security capabilities mismatch
Cause #24 Security mode rejected, unspecified
The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on KASME or mapped K'ASME indicated by the eKSI included in the message. The MME shall set the security header type of the message to "integrity protected with new EPS security context".
Abnormal Cases
Abnormal cases happen when something doesn’t work as expected in a system or process. These issues can be caused by problems in the network, limitations in the user’s device (UE), or conflicts between different operations. In telecommunications, it is important to identify and handle these situations to keep the system stable, ensure smooth communication, and avoid interruptions.
Abnormal cases can happen during important tasks like security checks, switching between network areas (handover), or sending important messages between the network and the device. To handle these problems, the system has specific rules to detect the issue, fix it, and continue working without major disruptions. These rules help the network stay strong and provide good service, even when things don’t go as planned.
- Failure in Sending SECURITY MODE COMPLETE or REJECT Messages:
- Triggered by Tracking Area Update (TAU) or Attach Procedure:
- Abort the security mode control.
- Re-initiate the TAU or Attach procedure as applicable.
- Triggered by Service Request Procedure with TAI Change:
- If the current TAI is not in the list, abort and initiate TAU.
- If the TAI is still valid, abort and allow UE implementation to decide how to resume.
- Triggered by Service Request Procedure without TAI Change:
- Abort the security mode control, and the UE decides how to proceed
- Lower Layer Failure Before Message Reception:
- The network aborts the security mode control procedure.
- Timer T3460 Expiry:
- On the first expiry, retransmit SECURITY MODE COMMAND and restart timer T3460.
- Repeat up to four retransmissions; abort the procedure after the fifth expiry.
- Procedure Collisions:
- With Attach, Service Request, TAU, or Detach Procedures (Non-Switch Off):
- Abort the security mode control and proceed with the UE-initiated procedure.
- With Other EMM Procedures:
- Progress both procedures simultaneously.
- Non-Delivery Due to Handover:
- If SECURITY MODE COMMAND cannot be delivered during handover but the target TA is in the list, retransmit after successful handover.
- If handover fails and the S1 signaling connection exists, retransmit.