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.

The security mode control procedure is a single round trip. The MME sends SECURITY MODE COMMAND, and the UE answers with SECURITY MODE COMPLETE or SECURITY MODE REJECT. The exchange takes an EPS security context into use, so every NAS message after it is integrity protected and ciphered. A small error in the command stops the attach or tracking area update at this point.

Followings are the topics to be covered in this page.

• When network send EMM : Security Mode Command,
• When UE received EMM : Security Mode Command,
• EMM : Security Mode Reject
• Abnormal Cases
• Reference

When network send EMM : Security Mode Command,

The MME builds the SECURITY MODE COMMAND after a successful authentication procedure, or directly after the ATTACH REQUEST or TRACKING AREA UPDATE REQUEST when it reuses an existing context. The UE compares several fields of the command with what it sent earlier. The points below are the ones that most often make that comparison fail.

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

The Replayed UE security capabilities IE is not a copy of one IE. The MME builds it from the EEA and EIA bits of the UE network capability, and from the UEA, UIA and GEA bits of the MS network capability when the UE sent them. 24.301 v20.0.0 clause 9.9.3.36 gives it 2 to 5 octets of contents. Octets 3 and 4 hold the EPS algorithms, and octets 5 to 7 appear only when the UE indicated UTRAN or GERAN algorithms. A bit set differently, or an octet dropped, is a mismatch for the UE.

The NAS key set identifier needs care too. The eKSI in the command identifies the K_ASME to take into use. After a new authentication, that is the KSI the MME sent in the AUTHENTICATION REQUEST. The KSI of the ATTACH REQUEST applies only when the MME takes the existing context of the UE into use without a new authentication.

The clause quoted above is older wording. In 24.301 v20.0.0, the replayed nonceUE is included only when the MME creates a mapped EPS security context. The MME must also replay the UE additional security capabilities when the UE sent them and the MME supports them. The table below lists every IE of the command in Table 8.2.20.1.

The HashMME covers a gap that the replayed capabilities alone cannot close. When the ATTACH REQUEST was not integrity protected, an attacker could have changed IEs other than the security capabilities. The UE compares the HashMME with its own hash of the request. If they differ, the UE returns the whole original request in the Replayed NAS message container of the SECURITY MODE COMPLETE, and the MME continues with that copy.

• Security header type 0011 : integrity protected with new EPS security context, used only for this message.
• Replayed UE security capabilities : rebuilt bit for bit from the UE and MS network capability.
• eKSI : the KSI of the AUTHENTICATION REQUEST after a new authentication.
• HashMME : protects the rest of an unprotected ATTACH or TAU REQUEST.

When UE received EMM : Security Mode Command,

The UE decides whether to accept the command before it answers. These checks are the reason that a wrong replayed value leads to a reject at once, instead of a failure later in the attach.

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.

24.301 v20.0.0 clause 5.4.3.3 adds the replayed UE additional security capabilities to the same check. 33.401 v19.2.0 clause 7.2.4.4 gives the reason: the check protects against a bidding down attack, where an attacker changes the capabilities in the ATTACH REQUEST so that a weaker algorithm is selected. The UE accepts EIA0, the null integrity algorithm, only for emergency bearer services or access to RLOS.

When the command is accepted, the UE takes the new context into use. It resets the uplink NAS COUNT when the context comes from a new authentication. It then sends SECURITY MODE COMPLETE, integrity protected and ciphered with the new keys. From this message onward, every NAS message in both directions is integrity protected and ciphered. The table below shows the security header type that each message of the procedure carries.

The SECURITY MODE COMPLETE also carries what the command asked for. That is the IMEISV when it was requested, and the UE radio capability ID or the coarse location information in the cases above. It also carries the Replayed NAS message container when the HashMME did not match.

• Checks : integrity, replayed security capabilities, replayed additional capabilities and nonceUE.
• Security header type 0100 : SECURITY MODE COMPLETE, integrity protected and ciphered.
• After the complete : all NAS signalling is integrity protected and ciphered.

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.

24.301-5.4.3.5 NAS security mode command not accepted by the UE describes as follows

If the UE cannot accept the SECURITY MODE COMMAND, it responds with a SECURITY MODE REJECT message, indicating one of the following:

• Cause #23: UE security capabilities mismatch.
• Cause #24: Security mode rejected, unspecified.

On receiving this, the MME:

• 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.

24.301 A.3 Causes related to PLMN specific network failures and congestion/authentication failures describes as follows

Cause #23 UE security capabilities mismatch

• 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.

Cause #24 Security mode rejected, unspecified

• 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.

NOTE 1 : One of the common cause of Security Mode Reject Cause #24 would be due to Security Header type violation. The security header type for Security Mode Command should be as 24.301-5.4.3.2 states :

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".

The current text of clause 5.4.3.5 says that the reject cause typically indicates #23 or #24, so other values are possible. Both the UE and the MME protect the SECURITY MODE REJECT with the security context that was in use before the command. When no context existed before, as in a first attach, 33.401 v19.2.0 clause 7.2.4.4 notes that the reject cannot be protected, so it goes out as a plain NAS message.

Annex A.3 ties cause #23 to the Replayed UE security capabilities IE. Cause #24 covers a wrong nonceUE and unspecified reasons, and in practice a failed integrity check usually ends up there too. A good first step is to compare the replayed IE of the command, octet by octet, with the UE network capability of the ATTACH REQUEST in the same log.

• Cause #23 : replayed UE security capabilities differ from what the UE sent.
• Cause #24 : a wrong nonceUE or an unspecified reason, often a failed integrity check.
• Protection of the reject : the previous context, or none if there was no 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.

Abnormal Cases in the UE (24.301-5.4.3.6)

• 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

Abnormal Cases on the Network Side (24.301-5.4.3.7)

• 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.

The two lists follow clauses 5.4.3.6 and 5.4.3.7 of 24.301 v20.0.0, which are unchanged in substance. The T3460 case needs one more detail. When the command creates a mapped context during a change from A/Gb or Iu mode, each retransmission carries the same nonceMME and nonceUE, not new ones. The UE may then receive the same command twice, and it does not need to derive K'_ASME again.

The collision rule favours the UE. When the UE starts an attach, a service request, a tracking area update or a detach while the command is pending, the MME drops the security mode control and handles the new request. The MME can then run the security mode control again inside that procedure.

• T3460 : five expiries in total, four retransmissions, then abort.
• Mapped context retransmission : the same nonceMME and nonceUE are reused.
• Collision with a UE procedure : the MME aborts the security mode control.

Reference

[1] 3GPP TS 24.301 v20.0.0 - clause 5.4.3, Security mode control procedure; clauses 8.2.20 to 8.2.22, Security mode command, complete and reject; clause 9.3.1, Security header type; clause 9.9.3.36, UE security capability

[2] 3GPP TS 33.401 v19.2.0 - clause 7.2.4.4, NAS security mode command procedure