It seemed that once we have IMS in place we can add the VoWifi service for free. Of course, there is hardly ever anything for free. As we have is in the VoWifi Overview there are quite a few things we need to take into account. In IMS we have to be more sensitive when it comes to routing, forking, location services etc. In the access network we have to make sure that the communication is secure enough and that we can trigger an access transfer when needed. In this post we’ll go through the security part of it and describe the basic flows.
It is not that difficult to get lost among all the security frameworks, protocols and procedures we have implemented in ePDG. In order to establish an IPSec tunnel we have to use IKEv2 for encryption and then some form of EAP for authentication and then we can start with ESP encryption.
So let’s start with a short dictionary:
As defined in the previous post it is a protocol suite for a secure Internet Protocol (IP) communication providing authentication and encryption of IP packets. IPSec supports two modes – tunnel and transport. In case of ePDG we’ll talk only about the tunnel mode.
Internet Key Exchange (IKEv2) is a protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. The v2 has some important enhancements which are more or less a must for a network element connected directly to the public Internet. The IKE is described in the RFC 4306 and RFC 5996.
Diffie–Hellman key exchange is a method for a secure exchange of cryptographic keys over a public channel.
Extensible Authentication Protocol is an authentication framework providing the transport and usage of keying material and parameters generated by EAP methods. There are cca 40 methods, from which the most important (HotSpot 2.0) for us are:
- EAP-SIM (2G)
- EAP-AKA (3,4G)
- EAP-AKA’ (3, 4G)
- EAP-TLS (no SIM)
- EAP-TTLS (no SIM)
Which one is used depends on the capabilities of a client (e.g. if does have a SIM card) and on what is supported by the network. The EAP is defined in RFC 3748 and was updated by RFC 5247.
EAP authentication goes between the UE and AAA. IKEv2 supports the EAP and handles the establishment of unicast security associations (phase 2a in RFC).
Encapsulating Security Payload is a protocol within the IPSec protocol suite which provides authentication, integrity and confidentially of IP packets. As we have seen previously, in a tunnel mode the entire packet is encapsulated within another packet as a payload and it is encrypted by ESP.
Where to start? Firstly the UE has to discover the ePDG node. Based on operator preference either static ePDG IP addresses or FQDN can be configured on UE. Typically we use FQDN, in that case it must be resolvable within the public Internet. The DNS query is done on the Wi-Fi Internet connection using configured Public DNS IP Address. The FQDN format is
The UE shall keep using the same ePDG as long as it is reachable. If the connectivity is lost, the UE starts using another ePDG IP address (either configured or provided by the DNS).
Note, that it is more complex in case of roaming support. Details can be found in GSMA IR.61, 3GPP TS 23.003.
The UE must establish a separate SWu instance (i.e. a separate IPsec tunnel) for each PDN connection. The IPsec tunnel transports the packets of all S2b bearer(s) for the same PDN Connection between the UE and the ePDG. The ePDG must release the SWu instance when the default S2b bearer of the associated PDN connection is released.
The UE and ePDG start to communicate over IKEv2. IKEv2 has only two initial phases of negotiation:
- IKE_SA_INIT Exchange
- IKE_AUTH Exchange
IKE_SA_INIT is the initial exchange in which the peers establish a secure channel via D-H. After they finish the initial exchange, all further communication is encrypted.
This first exchange has to be completed before any further exchanges can happen. It performs three functions in the setup of the IKE-SA:
- Negotiation of security parameters for the IKE-SA
- Sends nonces
- Sends D-H values
Note – the form of IKE_SA_INIT is designed in IKEv2 (in contrast to v1) to be more robust enough against the DOS attacks. There are also other improvements of v2 related to MOBIKE support, NAT Traversal, SCTP support, etc.
After the IKE_SA_INIT exchange is complete, the IKEv2 SA is encrypted. Anyway the remote peer has not been authenticated yet. The IKE_AUTH exchange is used to authenticate the remote peer and create the first IPsec SA.
It performs three required functions:
- Transmition of identities
- Proves knowledge of the secrets related to those identities
- Establishment of the ESP
Basically we distinguish whether or not the UE is able to access the ISIM/USIM modules. For the clients equipped with the SIM card we use the AKA algorithm. For the others we can use EAP-TLS or EAP-TTLS.
The full IKE/EAP-AKA/ESP flow then can look like this:
The IKE or IPSec SAs use secret keys should be used for a limited time and to protect a limited amount of data. This is because we want to make sure that even if an attacker finds out the secret keys (e.g by using some brute force mechanism) the amount of data compromised is limited. After the IKE or IPSec SAs is expired a new security association is established to take place of the expired one. The process is known as “Rekeying”.
The rekeying process could be triggered based on duration or amount of data transferred on existing IPSec tunnel and can be initiated by both ePDG or IKEv2 peer. The rekeying is done using a CREATE_CHILD_SA exchange. If both the IKE and IPSec Security association require rekeying then they are performed separately.
For EAP-SIM/AKA/AKA’ we have an optional but important optimization called fast re-authentication. It is defined by the GSMA IR.61 and TS 33.402. It provides authentication that does not require new vectors from the HLR/HSS. The original master session key (MSK) from the full authentication is used to generate a fresh MSK. That means that the new triplets from the HSS are not necessary. The UE uses the fast re-authentication identity returned by the AAA. Naturally, the fast re-authentication reduces the load on the HLR/HSS.