EPS Protection for Signalling and User Data
8.6 Emergency Call Handling
Although protection is typically independent of the protected content, so that all data is protected in similar manner, there is one notable exception: emergency calls and, more generally, IP Multimedia Subsystem (IMS) emergency sessions. Regulations on emer-gency calls vary between different countries, such as whether unauthenticated emeremer-gency calls are permitted or not. Regulations of some countries require that it is possible to always make an emergency call with UE, even when there is no valid Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM) inserted.
If there is no USIM in the UE then there is no way to authenticate the user in LTE.
Furthermore, there is no key agreement and, consequently, neither confidentiality nor integrity protection is possible. All this implies that emergency calls become an attractive target for attackers. It is vital that the system guarantees that it is not possible to use a call for anything else but emergency purposes when the UE is unauthenticated.
A specific state, called limited service state, is used to describe situations in which a UE cannot obtain normal service [TS23.122]. An idle UE without a valid USIM enters limited service state. There are also situations where a UE that contains a valid USIM would enter limited service state, such as when there are no cells available from the selected Public Land Mobile Network (PLMN). In the latter case, the UE tries automatically to re-select a PLMN but this could fail for normal service, for example in roaming situations.
No other services than emergency services are provided for a UE that is in limited service state.
Specific functions for emergency call handling have been added to EPS in Release 9, whereas in Release 8 only normal procedures are available for emergency purposes. A voice solution for EPS is provided by IMS (see Chapter 12). In IMS, IMS emergency sessions are used for emergency calls [TS23.167]. On the bearer level, there are specific emergency bearers that support IMS emergency sessions. These bearers are available for normally attached UEs, and in addition to UEs in limited service state when the local regulation requires support for unauthenticated emergency calls. Altogether, there are four different ways in which a network may provide support for emergency bearers [TS23.401].
• Support is available only for normally attached UEs, with valid subscription and authen-ticated by the network. There is no support for UEs in limited service state.
• Support is provided only for authenticated UEs, with valid International Mobile Sub-scriber Identity (IMSI) and subscription, but the UE may be in limited service state owing to being in a location where it is restricted from service.
• Support is provided only for UEs that have a valid IMSI but authentication may be skipped or it can fail.
• Support is provided to all UEs, even UEs without a USIM or without an IMSI. If there is no IMSI the IMEI (International Mobile Equipment Identity) may be used to identify the UE for emergency call purposes.
For all emergency bearer services, the MME uses a specific emergency Access Point Name (APN) to derive the correct Packet Data Network Gateway (PDN GW) for emer-gency purposes. Note that this GW is always in the visited network in case of roaming UEs. The motivation for this arrangement is clear: it is also the local Public Safety Answering Point (PSAP) that is typically in a better position to handle the emergency situation than a faraway PSAP.
The PDN connection that is associated with the emergency APN is totally dedicated to IMS emergency sessions and no other services are allowed. In particular, the PDN GW blocks all traffic associated with this APN that is not to or from an IMS network entity providing emergency services.
On the IMS system, there is a specific Call Session Control Function (CSCF) devoted to emergency sessions, called Emergency Call Session Control Function (E-CSCF) [TS23.167]. One of its duties is to handle the communication towards a PSAP. The Proxy Call Session Control Function (P-CSCF) has also a key role in handling emergency sessions. Among other duties, the P-CSCF ensures that only registrations for emergency purposes are accepted from emergency PDN connections. Moreover, the P-CSCF blocks all non-emergency session requests that are related to an emergency registration.
All of the special arrangements discussed here guarantee, when taken together, that it is not possible to misuse emergency support to make normal but still unauthenticated calls:
• UE in limited service state can only use emergency bearers.
• Emergency bearers are limited to an emergency APN and a specific emergency-aware PDN GW.
• This specific PDN GW allows only traffic to and from IMS entities that handle emer-gency services.
EPS Protection for Signalling and User Data 153
• The P-CSCF on the IMS side checks that all IMS traffic to and from the specific PDN GW is indeed for emergency purposes, and selects a suitable E-CSCF for the further handling of the requests, including finding an appropriate PSAP for the session.
Emergency calls are also supported in handovers between IMS calls over E-UTRAN and IMS calls over other 3GPP systems. Emergency calls are, however, not supported in Single Radio Voice Call Continuity (SRVCC) handovers (cf. Chapter 12). Special handling is needed in cases of unauthenticated calls.
For the case of non-3GPP access to the EPC, specifications starting from Release 9 support handover of an emergency session from E-UTRAN to High Rate Packet Data (HRPD) (see Section 11.2). The reverse direction is not supported, though, because net-work coverage for HRPD is assumed to be better than that of E-UTRAN still for quite some time in the future. The E-UTRAN also provides an indication to the HRPD side about whether the UE has been authenticated in E-UTRAN [TS23.402]. The local regula-tions affect the handling of unauthenticated emergency sessions for the HRPD, similarly as for E-UTRAN.
8.6.1 Emergency Calls with NAS and AS Security Contexts in Place
Here we consider the case where the UE and the MME share a NAS security context that can be used to protect an emergency bearer.
In the most typical case, the UE making an emergency call can indeed be successfully authenticated in EPS during the establishment of the emergency call, and the NAS Security Mode Command procedure can be run, or a previously established NAS security context already exists when the emergency call is set up. In both cases, keys are available for ciphering and integrity protection purposes and can be applied normally, on both AS and NAS levels. If an integrity check fails afterwards then the handling of this situation is the same as in the case of non-emergency calls: signalling messages with a wrong MAC will be discarded and eventually the call can terminate.
But, even when a NAS security context already exists, the MME may decide, accord-ing to its authentication policy, to initiate an EPS Authentication and Key Agreement (AKA) run at any time. As explained above, depending on its policy, the network may allow an emergency call to go forward when authentication fails. This case is handled in Section 8.6.3.
8.6.2 Emergency Calls without NAS and AS Security Contexts
We next look at the case where UE cannot be authenticated in EPS during the emergency call set-up, and there is no previously established NAS security context. A similar situation occurs when an unauthenticated emergency call is handed over to E-UTRAN.
In both cases, there are no established keys available, so there cannot be any ciphering or integrity protection on either the AS level or the NAS level. However, as, for normal service, integrity protection of AS and NAS signalling is mandatory; it turned out to be procedurally easier to define a ‘dummy’ integrity protection function for emergency services rather than define an exceptional case of not sending a NAS security mode
command at all. This ‘dummy’ function is called NULL Integrity Algorithm and denoted by EIA0. It simply adds a constant MAC of 32 zeros to every message. This null integrity protection function is only allowed for UEs that are in limited service state and not successfully authenticated in EPS. Similarly, a NULL Encryption Algorithm EEA0 has been defined for emergency calls in limited service state.
8.6.3 Continuation of the Emergency Call When Authentication Fails
As already mentioned above, there is a possibility that an emergency call is allowed to proceed even when AKA was run but it ended in failure, either during the set-up of an emergency call or while the emergency call already is in progress. Now we have two different scenarios: either
• UE and MME already share a security context from a previous (successful) AKA run or
• there is no such shared security context.
In the first case, both UE and the MME may continue using the existing EPS security context after the failed AKA. For this case, it is worth noting the contrast to a failed integrity check. Both AKA and integrity check perform authentication: the AKA for entity authentication and integrity check for message authentication (see Section 2.3).
However, the emergency call proceeds even when the authentication (by means of EPS AKA) fails while the call can terminate if an integrity check fails.
When there is no shared security context, the MME sends a NAS SMC message with null ciphering algorithm EEA0 and null integrity algorithm EIA0 chosen.
Note that all non-emergency bearers would be released after authentication fails.