Imagine your phone's connection to the network as a special, secret conversation. NAS security is like a strong shield protecting this conversation. It uses secret codes to make sure only your phone and the network can understand each other. It's like having a special language that no one else knows!
This shield also has watchful guards that look out for anything strange or dangerous. They check if someone is trying to listen in on your conversation or pretend to be your phone. They also make sure no one can break the connection and stop you from making calls or using the internet.
This shield is always getting stronger. It's like getting regular updates to fix any weaknesses and protect against new dangers. This includes stopping bad people from blocking your connection and making sure no one can sneak into the network and cause trouble.
Simply put, NAS security keeps your connection safe and private. It's like a hidden protector that makes sure you can use your phone without worrying about anyone interfering or stealing your information. It's always working in the background to keep your mobile conversations secure.
- Key Components of NAS Security Framework
- Objective of NAS Security
- Key NAS Security Features
- Security Context Establishment
- Security Algorithm Selection
- NAS Security Modes
- NAS Security Procedures
- Key Lifecycle Management
- Attack Mitigation
- Interworking with Other Layers
- NAS Signaling Messages in Security Framework
- How the NAS Keys are Derived
- NAS COUNT and Replay Protection
- Native, Mapped, Current and Non-current Security Contexts
- Reference :
- Links to other notes (on sharetechnote)
Key Components of NAS Security Framework
NAS Security framework is built upon key components, including mutual authentication, encryption, integrity protection, and replay attack mitigation. Through mechanisms such as key derivation, security mode procedures, and algorithm selection, NAS security establishes a reliable and secure environment for signaling communication. By integrating these components, the NAS security framework ensures seamless, secure, and resilient operations, even in complex network scenarios, making it a cornerstone of modern mobile network architecture.
Think of NAS security as a strong building with special features to keep it safe. First, it has a special door lock where both you and the building need to show the right key to open it, making sure only the right people can get in. Then, it uses a secret code that scrambles messages so no one else can understand them, like whispering secrets that only your friend can hear. It also has a special seal that makes sure no one has tampered with a message. If the seal is broken, you know something is wrong. Finally, it stops bad people from recording a message and playing it back later to try and trick the system. It's like checking if a message is fresh and hasn't been used before.
To build this secure building, they use special tools. They create strong, unique keys from a secret password, like making many different keys from one master key. They also have rules that decide how the security features will work together, like a plan that everyone follows to stay safe. And they choose the best tools for the job, like picking the right lock for your door or the best code for your secret message.
By putting all these parts together, NAS security makes sure your connection is safe and strong, even if things get complicated. It's like a reliable fortress that protects your mobile conversations, making it a vital part of how mobile networks work today.
|
Everything on this page is LTE. 5G keeps the same four components and changes them in four places, and all four of those changes live in this section rather than in the message flow.
|
Objective of NAS Security
NAS security is like a bodyguard for your phone's conversations with the network. It's there to protect those important messages from prying eyes and make sure nobody can tamper with them. Think of it as keeping your conversations private and ensuring that they reach the intended recipient without any changes or interference. This protection is crucial because these messages control your connection and allow you to use your phone safely.
The primary goal of NAS security is to:
- Protect signaling messages exchanged between the UE and the Core Network.
- Ensure the integrity, confidentiality, and authenticity of these messages.
- Prevent unauthorized access and eavesdropping.
Key NAS Security Features
To achieve its goal, NAS security has some powerful tools at its disposal. It's like a multi-layered security system. First, it checks the ID of both your phone and the network, like a bouncer at a club making sure everyone is who they say they are. Then, it puts a tamper-proof seal on messages to ensure they haven't been altered in transit, like a special package that shows if it's been opened. It also uses secret codes to scramble messages, making them unreadable to anyone trying to eavesdrop, like whispering secrets in a crowded room. Finally, it has a system to spot and reject any old messages that might be replayed by attackers, preventing them from causing trouble.
NAS security provides:
Authentication : Verifies the identity of the UE and network to each other. (Check this out for further details)Integrity Protection : Ensures signaling messages are not tampered with during transmission. (Check this out for further details)Encryption (Confidentiality) : Protects the signaling data from unauthorized access.Replay Protection : Prevents re-use of captured messages by attackers.
Security Context Establishment
Setting up this secure connection is like a carefully choreographed dance between your phone and the network. It starts with a shared secret, like a password known only to them. This secret is used to create special keys, like different keys for different doors in a house. Then, they exchange secret handshakes to confirm each other's identity, making sure they are who they claim to be. Finally, they use this shared secret and their handshakes to create even more specialized keys, like separate keys for a safe or a secret box. These keys are used to protect the messages and keep them confidential.
The NAS security context is established as part of the EPS/5G-AKA (Authentication and Key Agreement) procedure:
- Key Generation:
- The Authentication Center (AuC) generates a root key (K) shared with the UE.
- Derived keys, such as K_ASME in LTE or K_gNB in 5G, are created for specific purposes.
- Mutual Authentication:
- The UE and Core Network exchange authentication vectors (AVs), enabling both parties to authenticate each other.
- NAS Key Derivation:
- Derived keys for NAS integrity (K_NAS_int) and encryption (K_NAS_enc) are established based on the root key and other parameters (e.g., NAS algorithm identifier, UE security capabilities).
Security Algorithm Selection
It's like choosing the right tools for the job. Your phone tells the network what kind of security locks and codes it can handle. Then, the network picks the best combination from those options, considering its own security rules. Think of it as choosing between different types of locks and keys – some might be simpler, while others are more advanced. The goal is to find the most secure option that both your phone and the network can use.
This selection is done during NAS security setup as follows:
- The UE provides its supported encryption and integrity algorithms.
- The network selects a pair of algorithms (encryption and integrity) based on the UE's capabilities and network policies.
- Common NAS security algorithms include:
- Encryption: EEA0 (null), 128-EEA1 (Snow3G), 128-EEA2 (AES), and others.
- Integrity: EIA0 (null), 128-EIA1 (Snow3G), 128-EIA2 (AES), and others.
|
The 5G lists have the same shape as the EPS lists. The names differ, and two specifications name the same algorithms differently, which is worth knowing before comparing two documents.
|
NAS Security Modes
Imagine NAS security having two different levels of protection. At first, when your phone is just connecting to the network, it's like talking in a public place where anyone could listen. This is called "plaintext mode." But once the connection is secured, it's like switching to a private, encrypted chat where no one can understand your conversation. This is "ciphered mode," where messages are protected with secret codes and tamper-proof seals.
NAS security operates in two main modes:
- Plaintext Mode: Used during the initial attachment or registration process before security context is established.
- Ciphered Mode: Once security is activated, NAS messages are integrity-protected and encrypted.
NAS Security Procedures
Think of it as a security handshake. The network sends a command to your phone, like saying, "Okay, let's switch to our secret code language now." This command tells your phone which codes to use for protection. Then, your phone confirms that it's ready and starts speaking in the secret language. It's like saying, "Got it, I'm now using the codes." And if at any point they realize they're not on the same page, they have a way to reset and make sure they're both using the same secret codes, like checking in with each other to make sure they're still speaking the same language. This keeps the conversation secure even if there's a hiccup along the way.
- NAS Security Mode Command (SMC): The Core Network sends a Security Mode Command to the UE to configure the agreed NAS security algorithms.
- NAS Security Mode Complete: The UE confirms the setup and starts secure communication.
- Re-synchronization: If security context mismatches are detected, re-synchronization ensures continuity and security.
Key Lifecycle Management
Just like you might change your passwords regularly, NAS security also refreshes the secret keys used to protect your connection. It's like changing the locks on your house to keep it secure. This happens from time to time, or when you move between different cell towers, kind of like getting new keys when you move to a new place. And just like you wouldn't leave your old keys lying around, the network securely deletes the old keys to prevent anyone from using them. This ensures that your conversations stay protected even if someone gets hold of an old key.
NAS security includes mechanisms for the followings
- Key Update: Keys are updated periodically or when certain events occur (e.g., handover, TAU).
- Key Deletion: Old keys are securely deleted to prevent potential misuse.
Attack Mitigation
NAS security is like a vigilant guard, always on the lookout for potential threats. To prevent bad guys from reusing old messages, it uses special counters, like numbered tickets, to make sure each message is unique and hasn't been used before. This stops replay attacks, where someone tries to trick the system by repeating an old message. To prevent someone from impersonating the network or your phone, NAS security uses that "security handshake" we talked about earlier, where both sides confirm each other's identity. This stops man-in-the-middle attacks, where someone tries to sneak into the conversation and pretend to be one of the parties. Finally, to prevent eavesdropping, NAS security uses those secret codes to scramble the messages, making them unreadable to anyone trying to listen in. It's like having a private conversation in a crowded room, where only you and the other person can understand what's being said.
NAS security defends against:
- Replay Attacks: Sequence numbers and replay counters ensure old messages cannot be reused.
- Man-in-the-Middle Attacks: Mutual authentication prevents impersonation of the network or UE.
- Eavesdropping: Encryption protects signaling messages from interception.
Interworking with Other Layers
Think of it as teamwork between different security guards. NAS security protects the control center, making sure the overall connection is safe. But there's another team, called AS security, that focuses on protecting the actual data you send and receive, like your messages, pictures, and videos. They work together like different parts of a security system in a building. NAS security is like the guards at the front door and the security cameras monitoring the hallways, while AS security is like the locks on your individual office doors and the safes inside. By working together, they ensure that everything is protected, from the control center to the individual pieces of information being exchanged. This creates a secure path for all your communication, like a secure tunnel protecting everything that travels through it.
- NAS security complements AS (Access Stratum) security, which protects data at the RRC and PDCP layers.
- The combined security framework ensures an end-to-end secure communication path for both signaling and user data
NAS Signaling Messages in Security Framework
Everything above describes what NAS security is for. This section is about the five messages that build it, and about the order they have to arrive in. Each one changes the security state of the connection, so the security header type on each message is different from the one before it. Reading those header values in a log shows how far the procedure progressed, without decoding anything else.
There are a few critical NAS signaling message related to configure various NAS Security parameters and control the process.
These messages are like special commands and confirmations that go back and forth to set things up and keep everything running smoothly.
Think of them as the key pieces of a puzzle that fit together to create a secure connection. They tell the phone and the network what to do, how to behave, and what security measures to use. Without these specific messages, the whole system wouldn't be able to function securely.
It's like having a secret language with specific code words that trigger different actions. Each message has a unique role to play in establishing and maintaining the secure connection, ensuring that everyone is on the same page and following the right procedures.
Those messages handle things like verifying identities, similar to exchanging code words to make sure they're talking to the right person. They also set up the security level and choose the right "secret codes" to use, like agreeing on which cipher to use for their encrypted messages. Additionally, they manage the creation, updating, and deletion of those secret keys, similar to exchanging keys to a safe house and changing them regularly. These messages are crucial for establishing and managing the secure channel, ensuring that only authorized parties can access the information and that it remains confidential and tamper-proof. They're like the behind-the-scenes communication that sets the stage for a secure operation.
Authentication Request (Refer to this note for further details)- Security Header: Plain NAS Message (0) (Refer to this note for further details)
- Purpose: The network challenges the UE to authenticate itself.
- Role in Security:
- Initiates the security process by requesting a response (RES) calculated from the shared key (K) and a random value (RAND).
- Includes the AUTN (Authentication Token), which ensures synchronization and confirms the validity of the network.
Authentication Response (Refer to this note for further details)- Security Header: Plain NAS Message (0) (Refer to this note for further details)
- Purpose: The UE responds to the network's challenge.
- Role in Security:
- Provides the calculated RES, which is compared to the XRES by the network to confirm the UE's identity.
- Successfully completing this exchange establishes the foundation for the security context.
Security Mode Command (SMC) (Refer to this note for further details)- Security Header: Integrity Protected with New Security Context (3) (Refer to this note for further details)
- Purpose: The network configures the security algorithms and activates NAS security.
- Role in Security:
- Specifies the selected encryption (EEA) and integrity (EIA) algorithms.
- Marks the activation of the NAS security context by protecting the message with integrity using the new keys derived from K_ASME.
- Prevents tampering during the critical setup of secure communication.
Security Mode Complete (Refer to this note for further details)- Security Header: Integrity Protected and Ciphered with New EPS Security Context (4) (Refer to this note for further details)
- Purpose: The UE acknowledges the configuration and begins secure communication.
- Role in Security:
- Confirms the UE's agreement to the security mode and algorithms.
- Encrypts and integrity-protects this message using the derived keys (K_NAS_enc and K_NAS_int), demonstrating the successful activation of NAS security.
Authentication Failure (Refer to this note for further details)- Security Header: Plain NAS Message (0) (as no secure context is established yet).
- Purpose: Indicates that the authentication procedure failed.
- Role in Security:
- Ensures that failed authentication attempts are promptly communicated.
- Includes AUTS to help the network synchronize in case of a time mismatch, allowing for a secure retry of the authentication process.
These messages in the context of overall signaling procedure are illustrated in Figure 1 (in case of LTE. NR is almost same except small difference in security header type)
Figure 1 has three columns. The security state is on the left, the signaling message is in the middle, and the security header type is on the right. Read it downward. The messages run from Attach Request to REGISTERED. The two brackets on the right mark the spans over which one header value applies to every NAS message inside them.
Figure 1. Security is activated by two messages, not one. The Security Mode Command and the Security Mode Complete each carry a header value reserved for that single message, and everything after them uses the ordinary protected value.
Three messages run with no protection at all : Attach Request, Authentication Request and Authentication Response all use 0x0, because no security context exists yet.0x3 and 0x4 are single-message values : 24.301 Table 9.3.1 reserves 0x3 for the Security Mode Command and 0x4 for the Security Mode Complete, so seeing either one locates the procedure immediately.NAS security starts before RRC security : the state column changes to NAS Security at the Security Mode Complete, and only becomes NAS/RRC Security after the RRC Security Mode Complete.Attach Accept and Attach Complete use 0x2 : by then the context is established, so they use the ordinary integrity protected and ciphered value rather than a new-context one.
|
The sequence survives almost intact. What changes are the names of two nodes, the name of one message, and one added parameter.
|
How the NAS Keys are Derived
The sections above talk about keys without saying where any of them come from. That gap matters, because most security failures in deployed networks are a key that one side derived differently from the other. Only one secret is ever shared in advance. Everything else is calculated from it on both sides, and never sent anywhere.
That shared secret is K, and it lives in two places only. Those are the USIM in the phone and the HSS in the operator's network. K itself protects nothing and never leaves either store. During AKA the USIM uses it to compute CK and IK, and those two feed a key derivation function that produces K_ASME. From K_ASME the ME and the MME derive the two keys that actually protect NAS messages.
The name is worth expanding before going further, because it describes a role rather than a node. ASME stands for Access Security Management Entity. 33.401 defines that as the entity which receives the top-level keys for an access network from the HSS. It then states that in E-UTRAN the MME assumes the role of the ASME. K_ASME therefore means the key held by whichever entity manages access security, and in LTE that entity is always the MME.
Naming the key after the role rather than the node was deliberate, and 5G shows why. The same position in the hierarchy exists there, but the entity holding it is the AMF, so the key is called K_AMF. 24.301 Table 9.9.3.21.1 carries both names in the same field. A UE moving between the two systems has to say which one its key set identifier refers to. So K_ASME is not a generic term for a top-level key. It is one specific 256 bit key with one specific derivation, and the acronym only tells you who holds it.
Figure 2. Each step down the chain narrows what the key can do. K signs nothing and encrypts nothing, while the keys at the bottom are each tied to one algorithm and one traffic type. A compromised NAS key therefore cannot be used to read RRC traffic.
Figure 2 shows what derives from what. Two things about it need saying that the drawing cannot carry. The first is the naming. Every box is a key rather than an entity, and the names only look inconsistent because they follow three different conventions. The second is that the KDF inputs listed under each box are inputs to the derivation, not labels describing the result.
K_ASME is named after a role : ASME is the Access Security Management Entity, and 33.401 gives that role to the MME in E-UTRAN.K_eNB is named after its recipient : the eNB is where the key is delivered, even though the MME and the ME are what derive it.The NAS and AS keys are named after what they protect : K_NASenc, K_NASint and the four AS keys take their names from the traffic they cover, not from any entity.The algorithm identifier is an input, not a label : K_NASenc and K_NASint are different keys for different algorithms, so changing the selected algorithm changes the key. That is why the Security Mode Command carries the algorithm choice before either side can protect anything with it.K_eNB is bound to the NAS UPLINK COUNT : that ties the access stratum keys to the point in the NAS message stream where the connection was established. It is also the one place where the counter described in the next section feeds into the key hierarchy.
Five names appear together in every description of AKA, and they are easy to read as five steps in a chain. They are not a chain. RAND is the only input, and the rest are computed from it in parallel. Reading them in sequence is what makes the relationship between RES and K_ASME look more complicated than it is.
The home network picks a fresh RAND and computes five values from it. Each uses a different function, and every one of those functions is keyed with K. 33.102 clause 6.3.2 defines them.
Value |
How it is computed |
What it is for |
MAC |
f1K(SQN || RAND || AMF) |
Lets the UE authenticate the network. It travels inside AUTN. |
XRES / RES |
f2K(RAND) |
Lets the network authenticate the UE. The HSS computes XRES, the USIM computes RES, and the MME compares them. |
CK |
f3K(RAND) |
Cipher key. Together with IK it becomes the key material for K_ASME. |
IK |
f4K(RAND) |
Integrity key. Together with CK it becomes the key material for K_ASME. |
AK |
f5K(RAND) |
Anonymity key. It conceals SQN inside AUTN, and it is zero where concealment is not needed. |
Three of those five are packed into the authentication token. 33.102 builds it as SQN xor AK, followed by AMF, followed by MAC. AK is present so that SQN is not sent in the clear, because an exposed sequence number would reveal the identity and the location of the subscriber. That concealment defends against a passive observer only.
The UE unpacks the token in a fixed order, and the order matters. The USIM computes AK first, so that it can recover SQN from the concealed field. It then computes XMAC from SQN, RAND and AMF, and compares that with the MAC carried in AUTN. A mismatch ends the procedure with an authentication failure. If the MAC matches but SQN is outside the accepted range, the USIM answers with a synchronisation failure carrying AUTS instead.
Only after both checks pass does the USIM produce RES, CK and IK. This is where the relationship to K_ASME becomes clear. RES and the two keys are produced alongside each other, not one from another. All three are computed from the same RAND. RES travels back to the network in the Authentication Response and stops there. CK and IK never leave the UE, and they are what K_ASME is built from.
33.401 Annex A.2 gives that derivation exactly. The KDF is keyed with CK concatenated with IK, and it takes two further inputs. Those are the serving network identity, and SQN xor AK. The second one is the same field that concealed the sequence number inside AUTN, used again here for a different purpose. RES appears nowhere in that input list, and that is the part most worth remembering.
Figure 2 says what derives from what. It does not say when, or on which node, and those two questions decide what a trace looks like. Figure 3 puts the same derivations on an attach sequence, with each one marked against the node that performs it.
Figure 3. No key is ever sent over the air. Every box in the sequence is a calculation the UE and the network perform separately, from values each already holds. A mismatch therefore stays invisible until the next message fails.
Three things in Figure 3 are worth reading against a real log. The first is that K_ASME is derived twice, on two different nodes, and never travels between them over the air. The HSS computes it and passes it to the MME inside the authentication vector, which is an interface the UE never sees. The UE computes its own copy from CK and IK. On the network side CK and IK never leave the HSS at all when the separation bit marks the vector as EPS only.
The second is the gap between the Authentication Response and the Security Mode Command. Nothing is protected in that gap, and yet the MME derives K_NASint there. It has to, because 33.401 clause 7.2.4.4 requires the Security Mode Command itself to be integrity protected with the new NAS integrity key. The UE cannot check that message until it has derived the same key, which is why the derivation box sits on the UE lifeline before the verification does.
The third is that the two directions do not start ciphering at the same moment. The MME begins uplink deciphering after it sends the Security Mode Command. It begins downlink ciphering only after it receives the Security Mode Complete. That asymmetry is why the Security Mode Command carries header 0x3, which is integrity protected but not ciphered, while the Security Mode Complete carries 0x4.
K never leaves the USIM or the HSS : it is never transmitted and never used directly, so a captured signalling trace can never contain it.K_ASME is the root of everything in EPS : 33.401 clause 6.2 makes it 256 bits, and both NAS keys and K_eNB descend from it.Keys are algorithm-specific by construction : the algorithm identifier is a KDF input, so each NAS key is bound to the one algorithm it was derived for.The 128 bit keys are truncated, not generated short : derivation produces 256 bits, and the 128 least significant bits are used when the algorithm needs a 128 bit key.K_eNB links the two layers : it is derived from K_ASME and the NAS UPLINK COUNT, which is how AS security inherits from NAS security.Every derivation happens twice : the UE and the network each calculate the same key independently, so no key value is ever carried in a NAS message.The NAS keys exist before the first protected message : both sides derive K_NASint before the Security Mode Command, because that message is already integrity protected with it.RES is not part of the key chain : it is computed from the same RAND as CK and IK, but 33.401 Annex A.2 does not use it to derive K_ASME. It proves identity and nothing else.
|
This is where 5G differs most. EPS goes from CK and IK to the top serving network key in a single step. 5G takes three steps, and the first two happen in the home network.
|
NAS COUNT and Replay Protection
Replay protection is mentioned several times above, always as a property rather than as a mechanism. The mechanism is a counter. It is also a common cause of a connection that authenticates correctly and then fails on the first protected message. A wrong counter and a wrong key produce the same symptom.
Each EPS security context carries two NAS COUNT values, one for uplink and one for downlink. Both are 24 bits internally, and the UE and the MME maintain them independently. 24.301 clause 4.4.3 splits each one into a NAS sequence number in the 8 least significant bits and a NAS overflow counter in the 16 most significant bits.
Only the sequence number travels on the air interface. The overflow counter is never sent. The sender increases the NAS COUNT by one after each new or retransmitted protected NAS message, and increments the overflow counter whenever the sequence number wraps. The receiver estimates the value the sender used, and increments its own overflow counter when the estimated sequence number wraps. Both sides therefore hold 24 bits while exchanging only 8 of them.
That arrangement has a fixed limit, and 24.301 clause 4.4.3.5 says what happens at it. When either counter approaches 2 to the power 24, the MME must act. It either activates a non-current native context whose counters are low enough, or runs a new AKA so that a new K_ASME resets both counters to zero. If neither has happened by the time the counter would wrap, the node that needs to send releases the NAS signalling connection instead. The UE then deletes the eKSI of the current context before its next uplink message.
One exception exists. When EIA0, the null integrity algorithm, is in use, wrap around is allowed and both sides keep using the current context. That is consistent rather than surprising, because nothing is being protected and there is no key to expose.
There is also a question of when the counters start mattering at all, and 33.401 answers it precisely. Neither side needs the NAS COUNTs for a native context until the security mode control procedure runs. The MME sets both counters to zero before it sends the first Security Mode Command for a partial native context. From that message onward they are increased for every NAS message sent under that context.
That connects directly to the previous section. A context created by authentication already has K_ASME, but its counters are still zero and unused. The Security Mode Command is the moment both the keys and the counters begin to be used. That is why a single message failure at that point can have either cause.
The counter is 24 bits but only 8 are sent : the NAS sequence number travels in the message, and the receiver infers the 16 bit overflow counter.Uplink and downlink are counted separately : each EPS security context holds two independent NAS COUNT values, so one direction can advance without the other.A key must never be reused with the same COUNT : that is why approaching wrap around forces either a context switch or a fresh AKA rather than a rollover.Wrap around with no new key releases the connection : the sending node releases the NAS signalling connection, and the UE deletes the eKSI of the current context.EIA0 is the documented exception : with null integrity there is nothing to protect, so 24.301 permits the counters to wrap and the context to continue.
|
Almost nothing changes here, and that is worth stating plainly because so much else does. The counter behaves in 5G exactly as it behaves in EPS.
|
Native, Mapped, Current and Non-current Security Contexts
A UE does not hold one security context. It can hold several at once, and which one protects the next message is not obvious from any single message in a log. Two independent distinctions apply here, and they are easy to confuse because both get described with the same words.
The first distinction is where the context came from. A native context was created by an EPS authentication run in E-UTRAN. A mapped context was derived from keys belonging to another system, which happens on inter-system handover from UTRAN, GERAN or 5GS. The eKSI carries this distinction directly. 24.301 clause 9.9.3.21 puts a type of security context flag next to the three bit value, and that flag reads native or mapped.
The second distinction is how far the context has progressed. A successful authentication creates a partial native context, which means K_ASME exists but the NAS keys are not yet protecting anything. The security mode control procedure takes it into use and makes it a full native context. Independently of that, exactly one context at a time is the current one, and any other the UE keeps is non-current.
The transition rules follow from those two ideas, and 24.301 clause 4.4.2 states them plainly. A new authentication deletes the existing non-current context. Taking a partial native context into use deletes the previously current one. Inter-system handover is the exception worth remembering, because a new mapped context does not delete the previously current native context. That native context becomes non-current instead, and it returns as current when the UE later leaves EMM-REGISTERED.
The reason for keeping it is practical. A native context can be reused on a later connection without running authentication again, and that is what the eKSI is for. 33.401 clause 6.3 gives exactly that as the purpose of KSI_ASME: to let the UE and the MME identify a native K_ASME without invoking the authentication procedure. Seven eKSI values identify key sets, and the eighth, 111, is how the UE says it holds no valid K_ASME.
It helps to know what a context actually contains, because the word suggests something larger than it is. 33.401 defines a partial native context as four things: K_ASME, the key set identifier that names it, the UE security capabilities, and the two NAS COUNT values. Nothing else. A full EPS security context adds the AS part on top of that NAS part, and a non-current context carries no AS part at all.
Two consequences follow from those definitions, and both are easy to check in a log. A partial native context is always non-current, because it has not been through a security mode control procedure yet. A mapped context is the opposite case, since 33.401 states that its NAS part is always full and current. There is no such thing as a partial mapped context waiting to be activated.
Native and mapped describe origin : a native context came from an EPS authentication, and a mapped one was derived from another system's keys on handover.Partial and full describe progress : authentication produces a partial native context, and the security mode control procedure turns it into a full one.Only one context is current at a time : everything else the UE holds is non-current, and a non-current native context is kept precisely so it can be reused.A mapped context does not delete the native one : the previously current native context becomes non-current and returns to use when the UE leaves EMM-REGISTERED.eKSI 111 means no key is available : seven values identify key sets, and the UE sends 111 when it holds no valid K_ASME.
|
The model carries over whole. Native and mapped, current and non-current, partial and full all mean in 5G what they mean in EPS.
|
Reference :
- 24.301 - LTE;5G;Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Source for the security header type values in Table 9.3.1 and the NAS security algorithms in Table 9.9.3.23.1. Also the source for the NAS COUNT and security context rules in clauses 4.4.2 and 4.4.3. The version read was v20.0.0 (Release 20).
- 24.501 -5G;Non-Access-Stratum (NAS) protocol for 5G System (5GS); The 5G equivalents of the same tables, which differ mainly in naming.
- 33.401 - 3GPP System Architecture Evolution (SAE); Security architecture. Source for the key hierarchy in clause 6.2 and the eKSI description in clause 6.3. The version read was v19.2.0 (Release 19).