Defending the Whole Path: NAS Protection, Deployment Choices, and Open Gaps
The UE failures identified by CONSET become easier to act on when they are placed beside the network-side security lifecycle for the initial NAS message. This chapter asks what 5G protects during bootstrap, what remains cleartext or deployment-dependent, and which responsibilities still belong to the UE implementation. The result is a practical boundary map: cryptographic NAS protection, semantic RRC validation, safe failure handling, and operational verification reduce different risks and cannot substitute for one another.
That distinction prevents two opposite mistakes. It would be wrong to describe all early 5G traffic as unprotected, because the standards provide a protected NAS container and specialized safeguards for information that must be visible during bootstrap. It would also be wrong to treat a protected NAS exchange as evidence that the UE safely handled every earlier RRC configuration. Security follows the message, state, and owner across the connection procedure.
The NAS bootstrap is protected in layers
The initial NAS message is the first NAS message sent by the UE to the core. It identifies the device and can indicate security capabilities and requested services, so sending everything only after a security context exists would create a bootstrap problem: the core would need information to establish the very context that would protect that information.
NIST's Initial Public Draft describes a two-part design. After the message header, a limited first part contains cleartext information elements needed by the network. The second part is the complete initial NAS message inside an integrity- and confidentiality-protected NAS container when the relevant security context is available or after the security procedure establishes one. The protected copy includes the cleartext elements again, allowing the core to compare the two representations and detect tampering.
This is not merely a formatting choice. It separates information needed to start trust from information that can wait until trust exists. The cleartext part can include subscription identifiers, security capabilities, and the 5G key-set identifier. The core uses such information to identify the UE, understand what protection the UE supports, or locate a context that can be reused. The complete message can contain more sensitive initial-request information once the keys needed for protection are available.
When the UE has no NAS security context, it initially sends only the limited cleartext portion. The core performs Authentication and Key Agreement and establishes a new security context. A Security Mode Command then moves the procedure toward protected signaling. The UE retransmits the complete initial NAS message inside the protected NAS container in the Security Mode Complete. The core can then verify the content that was previously visible and proceed with the request.
When the UE already has a context, the first message can contain both parts: the limited cleartext elements and the complete message in the protected container. If the core has the same context and the integrity check succeeds, it may proceed without repeating the full authentication sequence. If the check fails—for example, because the core cannot locate the context—the procedure falls back to establishing a new context and requesting the protected retransmission. The same high-level connection goal therefore has different protection and message-flow behavior depending on state.
The key-set identifier illustrates what state is being exchanged.