LTE NAS Security Procedure Call Flow
LTE NAS Security is the broader security path that starts with subscriber authentication and ends with active NAS protection for later messages. It bridges LTE Authentication Procedure and LTE Security Mode Procedure into one end-to-end security workflow.
This page is useful when the real question is not only whether Security Mode Command appeared, but whether the whole authentication-to-protection path completed cleanly.
Introduction
The LTE NAS Security procedure covers the complete NAS-side security transition: HSS vector retrieval, AKA challenge, AKA result, algorithm selection, and the first protected NAS continuation. It normally appears during attach, TAU, and other procedures that need fresh NAS security activation.
The main nodes are UE, eNB, MME, and HSS. The eNB only transports the NAS signaling, while the UE, MME, and HSS determine whether the protected security state can be reached.
What Is LTE NAS Security in Simple Terms?
- What starts the procedure: The network needs to authenticate the subscriber and activate protected NAS signaling.
- What the UE and network want to achieve: A verified subscriber and an active NAS integrity and ciphering state for later messages.
- What success looks like: Authentication succeeds, Security Mode succeeds, and the next NAS message is protected.
- What failure means: The path breaks in authentication, Security Mode, or the first protected continuation step.
Why this procedure matters
This is the security checkpoint behind many LTE control-plane procedures. If it is incomplete, later attach or TAU behavior can look partially successful while still failing at the protection boundary.
Quick Fact Sheet
| Procedure name | LTE NAS Security Procedure |
|---|---|
| Domain | EPS NAS authentication and protection activation |
| Main trigger | Attach, TAU, or another NAS path that requires fresh authentication and protection |
| Start state | NAS procedure has started, but the UE is not yet in the active protected NAS state |
| End state | Authentication and NAS protection are complete and later NAS continuation is protected |
| Main nodes | UE, eNB, MME, HSS |
| Main protocols | NAS, S1AP, Diameter |
| Main success outcome | Protected NAS continuation begins after successful Security Mode Complete |
| Main failure outcome | The security path fails before protected continuation becomes usable |
| Most important messages | Authentication Request, Authentication Response, Security Mode Command, Security Mode Complete |
| Main specs | TS 24.301, TS 33.401, TS 29.272, TS 23.401 |
Preconditions
- The UE has already started an LTE NAS procedure.
- The MME can resolve subscriber identity well enough to request vectors.
- The HSS can return usable authentication material.
- Radio and S1 transport can carry both authentication and Security Mode exchange.
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Validates AKA, accepts or rejects NAS security activation, and sends the first protected continuation. |
| eNB | Transports the NAS signaling between UE and MME. |
| MME | Coordinates authentication, chooses NAS security algorithms, and waits for protected continuation. |
| HSS | Provides AKA vectors and subscriber information needed for authentication. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| LTE Uu | UE <-> eNB | Carries downlink and uplink NAS containers. |
| S1-MME | eNB <-> MME | Carries S1AP transport for the NAS exchange. |
| S6a | MME <-> HSS | Carries vector retrieval and subscriber support. |
End-to-end call flow
UE eNB MME HSS
| | |-- AIR / AIA --->|
| | |<-- vectors -----|
|<-- Authentication Request ------- | |
|-- Authentication Response ------> | |
|<-- Security Mode Command -------- | |
|-- Security Mode Complete -------> | |
| first protected NAS continues | |Major phases
| Phase | What happens |
|---|---|
| 1. AKA vector retrieval | The MME gets HSS support for authentication. |
| 2. Authentication | The UE validates the AKA challenge and returns the result. |
| 3. Security Mode | The MME selects algorithms and asks the UE to activate NAS protection. |
| 4. Protected continuation | The next NAS message confirms that the security state is now really usable. |
Step-by-step breakdown
Step 1: Vector retrieval and subscriber preparation
Sender -> receiver: MME <-> HSS
Message(s): Diameter AKA support
Purpose: Give the MME the material needed for authentication and later NAS protection activation.
State or context change: The MME can now challenge the UE and later select a protection context.
Note: Subscriber-profile issues can surface here before any visible NAS failure reaches the UE.
Step 2: Authentication branch
Sender -> receiver: MME -> UE -> MME
Message(s): Authentication Request and Authentication Response or Failure
Purpose: Prove subscriber authenticity through EPS AKA.
State or context change: The path either moves forward into Security Mode or stops on failure.
Note: Do not expect Security Mode if AKA did not really succeed.
Step 3: Security Mode branch
Sender -> receiver: MME -> UE -> MME
Message(s): Security Mode Command and Security Mode Complete or Reject
Purpose: Activate the chosen NAS protection state.
State or context change: Later NAS messages become protected.
Note: This is the point where stale context or capability mismatch becomes visible.
Step 4: First protected continuation
Sender -> receiver: UE -> MME or MME -> UE, depending on scenario
Message(s): The next protected NAS message after Security Mode Complete
Purpose: Prove that the security state is not only nominally complete but also usable.
State or context change: The higher-level procedure continues in protected form.
Note: This is one of the best checkpoints in the full security path.
Important messages
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Authentication Request | NAS | MME -> UE | Starts the AKA challenge branch. | Relation to HSS vectors and failure causes. |
| Authentication Response | NAS | UE -> MME | Closes the positive AKA branch. | Whether Security Mode follows promptly. |
| Security Mode Command | NAS | MME -> UE | Activates the chosen NAS protection state. | Algorithm choice, KSI relation, and UE capability match. |
| Security Mode Complete | NAS | UE -> MME | Confirms protection activation. | Whether the next message is really protected. |
Important parameters to inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| AKA vector continuity | The link between HSS-provided vectors and the actual challenge seen by the UE. | S6a and Authentication Request | Confirms the MME used the expected subscriber material. | Stale vectors, trace merge confusion. |
| NAS KSI | The security context reference used for later protection. | Security Mode Command | Shows which security context is being activated. | Stale context, wrong key set reference. |
| Selected algorithms | The integrity and ciphering algorithms chosen by the network. | Security Mode Command | Explains the expected protected behavior. | Unsupported algorithm, capability mismatch. |
| First protected NAS message | The message immediately after Security Mode Complete. | Post-security continuation | Proves the whole NAS security path actually became usable. | Security path appears complete, but no real protected continuation follows. |
Successful completion of the procedure
Success means the UE is authenticated, NAS protection is active, and the first later NAS message appears in protected form. In many traces, that protected follow-up message is the cleanest proof of success.
Common failures in LTE NAS Security
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Authentication succeeds but Security Mode never starts | Procedure branch broke after AKA or the trace is incomplete. | Immediately after Authentication Response. | Authentication Response, next message | NAS, S1-MME | Check if the MME moved into another branch or stopped unexpectedly. |
| Security Mode Complete appears, but later NAS still fails | The protection branch closed formally, but the next procedure failed. | First protected NAS message. | Security Mode Complete and next message | NAS, S1-MME | Move forward into the next procedure instead of re-debugging authentication. |
| Repeated full security loop | Context loss, retry, or merged attempts in the trace. | KSI changes and repeated AKA/SMC pairs. | Authentication Request, Security Mode Command | NAS, S6a | Separate multiple attempts before diagnosing one loop as broken. |
What to check in logs and traces
- Start at vector retrieval and confirm AKA really succeeded.
- Check whether Security Mode follows immediately after Authentication Response.
- Verify that the first protected NAS message appears after Security Mode Complete.
- Use KSI and selected algorithms to understand context continuity.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
LTE NAS Security is the full path, not just Security Mode. It includes the AKA stage that makes Security Mode meaningful.
The highest-value checkpoint is often the first protected NAS message after Security Mode Complete.
FAQ
What is LTE NAS Security?
It is the combined authentication and NAS protection path used before later protected LTE signaling continues.
How is this different from Security Mode Procedure?
Security Mode is one part of the wider NAS security path. This page covers the whole authentication-to-protection flow.
What should I inspect first?
Check Authentication Response, then Security Mode Command, then the first protected NAS continuation.