EPS Authentication and Key Agreement
7.4 Security Contexts
When two parties engage in security-related communication, for example when running an authentication protocol or exchanging encrypted data, they need an agreed set of security parameters, such as cryptographic keys and algorithm identifiers, for the communication to be successful. Such a set of security parameters is called a security context. There are different types of security context depending on the type of communication, and the state the communicating parties are in.
Note that entities may store security context data locally even when not engaged in communication. The distinction between locally stored security context data and security context shared between two communicating parties for the purpose of running a security protocol is useful in principle, but it is a bit academic and not much adhered to in practice.
As the potential for confusion is low, we follow the common practice and speak only of security contexts.
Several different types of security context have been defined for EPS so as to have shorthand notations available for the various sets of security parameters used in particular situations. Their definitions are a bit tricky, and 3GPP took a while to get them right, but they are useful, and the reader will encounter them throughout the book, so we will dwell on them a little here to have a central place for security context definitions and explanations for reference. But it is true that quite a few of the parameters mentioned in this section are explained only later, notably in Chapters 8, 9 and 11.
As can be seen from the preceding Section 7.3, where the EPS key hierarchy was presented, EPS security is rooted in a permanent key K. The USIM and the AuC share this key K and a set of AKA algorithms, such as MILENAGE as described in Section 4.3. The key K and the set of AKA algorithms are used for UMTS AKA runs over GSM/EDGE Radio Access Network (GERAN) or Universal Terrestrial Radio Access Network (UTRAN), and EPS AKA runs over Long Term Evolution (LTE). The notion of EPS security context, as defined by 3GPP, does not include the key K or identifiers of the AKA algorithms, but only keys and related parameters particular to EPS – from KASME downwards in the EPS key hierarchy.
The following definitions draw heavily on clause 3 of [TS33.401].
7.4.1 EPS Security Context
This context consists of the EPS NAS security context and, when it exists, the EPS AS (Access Stratum) security context. The EPS NAS security context is used for protecting the NAS of EPS between the UE and the MME, and it may even exist when the UE is in de-registered state (see Chapter 9). The EPS AS security context is used for protecting
the AS of EPS between the UE and the eNB, and it only exists when cryptographically protected radio bearers are established and is otherwise void. For an EPS AS security context to exist, the UE needs to be in connected state.
7.4.2 EPS NAS Security Context
This context consists of KASMEwith the associated key set identifier eKSI, the UE security capabilities (this and eKSI are discussed further in this chapter) and the NAS uplink and downlink COUNT values. These counters are relevant also for security as they are used as input parameters to key derivations in certain state and mobility transitions (see Chapters 9 and 11) and, in conjunction with integrity protection, for preventing message replay.
Separate pairs of NAS COUNT values are used for each EPS NAS security context.
The EPS NAS security context is called full if it additionally contains the keys KNASint and KNASenc (‘NAS keys’ for short) and the identifiers of the selected NAS integrity and encryption algorithms, otherwise it is called partial. An EPS security context containing a full or partial EPS NAS security context is also called full or partial, respectively. Note, however, that both KNASint and KNASenc can be derived from the KASME when the NAS integrity and encryption algorithms are known. Thus, they need not necessarily be stored in the memory.
7.4.3 UE Security Capabilities
They are the set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE. This includes capabilities for E-UTRAN, UTRAN and GERAN if these access types are supported by the UE. A network node learns the UE security capabilities from the UE, or from a neighbouring node (more on this in later chapters).
The UE EPS security capabilities are a subset of the supported UE security capabilities relating to algorithms used in EPS.
7.4.4 EPS AS Security Context
This context consists of the cryptographic keys at AS level (i.e. between the UE and the eNB) with their identifiers, the NH, the Next Hop Chaining Counter parameter (NCC) used for NH access key derivation (see Section 9.4), the identifiers of the selected AS level cryptographic algorithms for integrity protection of RRC and (in the context of relay nodes) UP, and ciphering of RRC and UP, and the counters used for replay protection.
7.4.5 Native versus Mapped Contexts
There are different types of EPS security context, namely ‘native’ and ‘mapped’. These types point to the origin of the context: a native EPS security context is a context whose KASME was created during a run of EPS AKA, while a mapped EPS security context is converted from a UMTS security context when the UE moves to LTE from UTRAN or GERAN (see Chapter 11). A mapped EPS security context is always ‘full’, while a
EPS Authentication and Key Agreement 131
native EPS security context may be full or partial. A partial native EPS security context is created by an EPS AKA run, for which no corresponding successful NAS SMC procedure has been run; in other words, a partial native EPS security context is always in state ‘non-current’, as explained in Section 7.4.6. After having been put into use by running a NAS SMC procedure, a partial native EPS security context becomes full as the NAS security algorithms and the NAS keys have been agreed between the UE and the MME.
7.4.6 Current versus Non-current Contexts
There are other states in which EPS security contexts can be: ‘current’ and ‘non-current’.
The current security context is the one that has been activated most recently. A non-current security context is sitting on the side and waiting to replace the non-current one. As mentioned in Section 7.4.5, a partial native EPS security context is non-current, but also a full native EPS security context can be non-current, namely when it has been pushed aside by a mapped EPS security context in a handover from UTRAN or GERAN to EPS. A mapped EPS security context never becomes non-current. The different handling of native and mapped in this respect is explained by the fact that a native context is considered of higher value as it originates from within the EPS itself. It may therefore be used later (again), while a mapped context may be discarded when no longer used as a current context. The type of a context does not change during its lifetime. The state of a context can change, but it can be only in one state at a time.
7.4.7 Key Identification
In E-UTRAN, the NAS Key Set Identifier eKSI identifies the key KASME. It is the purpose of the eKSI to signal which KASME was used to derive the NAS keys, such as when the UE sends a NAS message in moving from idle to connected state. The use of the eKSI ensures key synchronization between the UE and the MME. The NAS Key Set Identifier information element consists of a value of three bits and a type bit. The type indicates whether an EPS security context is a native EPS security context or a mapped EPS security context (‘0’ denotes native, and ‘1’ mapped). The eKSI is the EPS equivalent of the KSI in 3G. The KSI also takes 3-bit values, but has no different types. The KSI points to the set of two keys, CK and IK. In mobility between E-UTRAN and UTRAN, the value of eKSI is mapped to KSI, and vice versa (see Section 11.1). The eKSI is allocated by the MME, and the eKSI is therefore accompanied by the identity GUTI (see Section 7.1). The GUTI tells the receiving MME at which MME the security context of the UE currently resides. The UE can also signal that no key is available by setting the eKSI value to ‘111’.
7.4.8 EPS Security Context Storage
When the USIM is enhanced for EPS, a part of the EPS native security context is stored on the USIM under certain conditions. When the USIM is not enhanced for EPS, the non-volatile part of the ME memory takes on an equivalent role and stores that part of the EPS native security context. The idea is that, in both cases, an EPS native security context shall be kept even when the UE de-registers or is switched off. When the UE registers
again and goes to connected state, the EPS native security context can be retrieved from storage and used to protect the initial NAS message. By re-using the stored context, a new run of EPS AKA can be avoided. A mapped context is never stored on the USIM.
A mapped EPS security context is kept in a transition to idle state, and, if available, is used to protect the initial NAS message when the UE transitions back to connected state.
A mapped EPS security context is deleted when the UE de-registers (see the definition of current and non-current security context in Section 7.4.6).
7.4.9 EPS Security Context Transfer
Parts of the EPS security context may be pushed down from the MME to a base station, or may be transferred between equivalent EPS nodes (e.g. from one MME to another MME, or from one base station to another one). (Of course, base stations get to see only EPS AS security context data.) This is possible even when these nodes lie in different networks, providing the operators’ security policies allow this – see Section 7.2.4. EPS security context shall not, however, be transferred to an entity outside the EPS. In particular, the KASMEshall never be transferred from the Evolved Packet Core (EPC) to an entity outside the EPC. In this way, KASME is not revealed to network entities handling technologies other than E-UTRAN.