Network Access Control
Network Access Control (NAC) enables enterprises to enforce a policy consisting of a series of authentication and authorization rules that define which endpoint devices can connect to the enterprise network, and what those devices can access once on the network. Existing enterprise NAC solutions usually consist of a mixture of device level authentication and authorization, and user level authentication that uses a range of authentication and authorization methods such as Mac Auth Bypass, Device Profiling, and 802.1x. As these methods are not currently possible on mobile networks, we have developed an innovative solution which harnesses mobile security methods for authentication, but will integrate with your existing NAC infrastructure for authorization.
This ‘best of both worlds’ approach means that you will get the benefits of tried and tested mobile authentication technology, while still maintaining control of mobile devices’ access to your network via your RADIUS server policy.
Alef Edge and your NAC Infrastructure
Alef Radius Client (ARC)
The ARC will integrate directly with your existing NAC infrastructure. It consists of a standards compliant RADIUS client that will function with any RADIUS server that meets the standards. The ARC is effectively the interface between the Alef Edge Platform and your RADIUS infrastructure, passing RADIUS messages to and from your RADIUS servers, and instructing the Alef Edge Platform to enact the authorization decisions from your RADIUS server on the mobile devices attempting to access your network.
Your dedicated ARC is a component of the Edge Platform, and as such you will connect to it via the dedicated link to the Edge Point, and the ARC will have an IP address on your internal address space. The ARC effectively turns the Alef Edge Platform into a Network Access Device (NAD) from a RADIUS point of view, so you can simply think of the Edge Platform as just another NAD, along with your switches, wifi controllers or wifi APs.
You will use the Alef Enterprise Mobile Connectivity APIs to configure your ARCs and also perform troubleshooting tasks such as viewing live NAC sessions and historic logs directly on the ARC.
The IMSI is a SIM card identifier, and is used with keys to authenticate and authorize the mobile device on the mobile network. In the Alef Edge NAC solution, the IMSI, along with its keys (that will be explained in EAP-AKA below) will be used to authenticate the mobile device to the mobile network. Once this authentication is successful, the IMSI will be passed, via the ARC, to your RADIUS server as the mobile device ID. Therefore, the IMSI is the ID that you will use to authorize a mobile device onto your network.
Authentication on the mobile core
It’s important to understand, first and foremost, that you will not need to manage your own mobile core, nor will you need to manage the mobile core authentication process.
The authentication method used by 4G mobile networks is EPS-AKA. (5G networks tend to use 5G-AKA, or EAP-AKA’). It is a two-way authentication method such that the mobile device authenticates with the mobile core and vice versa. When a mobile device connects to the mobile core, it initially sends the IMSI, which the mobile core uses to look up the correct secret keys for that SIM. EAP-AKA’s high level of security comes from:
- the secret keys held on the SIM and the mobile core itself
- an algorithm that derives dynamic, one-time use keys from the permanent keys at each end
- an exchange mechanism whereby the SIM and mobile core authenticate to each other by exchanging the temporary dynamic keys.
Once the mobile device has successfully authenticated to the mobile network, an encrypted session is set up with integrity checking, and the mobile device is attached to the mobile network. Only once this authentication process is completed does the Alef Radius Client begin the RADIUS authorization process using the IMSI. EPS-AKA is described in more detail in the Mobile Core auth section below.
Enterprise Radius Server
As mentioned above, your ARCs will be configured to be clients of your existing RADIUS servers. According to your configuration, your RADIUS servers will run authentication and authorization logic against an IMSI based RADIUS auth session coming from the ARC.
Just as with your existing NAC logic, you will configure authorization rules based on identity groups (in this case containing IMSIs as IDs), that may either be set up directly on your RADIUS server, or on an external ID store such as Active Directory. The ARC will keep your RADIUS server aware via RADIUS messages of any mobile device that has passed EPS-AKA auth and is attempting to connect to your internal network, or any such device that has reconnected. Therefore, just like with your wifi and wired LAN endpoint auth activity, your RADIUS server will also be the single point of information for all mobile endpoint auth activity on your network.
Enterprise Identity Store
You may currently be using at least one identity store for NAC. Most enterprises tend to use the internal ID store of the RADIUS server for methods such as MAB and device profiling, and AD for the more secure, 802.1x based auth. You can decide whether to populate your IMSI IDs on AD or directly on your RADIUS server. Once you procure your SIMs from Alef, you will import the new IMSIs into IMSI ID groups that you will have set up on your chosen ID store, which can then be used as conditions in your authorization policy.
How it works
There are two main steps to a mobile device gaining access to your internal network. Firstly, the mobile device must auth onto the mobile network with EPS-AKA, then it must be auth’ed onto your private network according to your policy configuration.
Mobile Core Auth
This section is just for information. As mentioned previously, you do not need to configure or support the mobile core auth process, as it all happens between the SIM card and the mobile core.
The Alef Edge Platform harnesses the highly secure EPS-AKA authentication method currently used by 4G mobile networks.
The secure nature of this method comes not from the IMSI itself, but from keys that are held on the SIM card and the mobile core, and an exchange algorithm that enables the SIM to auth to the mobile core, and vice versa, without ever exchanging the actual keys.
The Process is as follows:
- The mobile device attempts to connect to the mobile network by sending a mobile join request that includes the IMSI for the SIM card
- The mobile core looks up the corresponding keys for that IMSI. These will match the keys on the SIM card.
- Values are derived from the keys and are exchanged and matched
- An encrypted and integrity checked session is brought up between the mobile device and mobile core.
Once the mobile auth has succeeded, and the mobile device has attached to the mobile network, you can use your existing NAC infrastructure to control what access, if any, the device has to your internal network.
According to how you configure the policy on your RADIUS server, one of the following will happen when a mobile device attempts to access your network:
Access Reject - the mobile device is not permitted access to the network
Access Accept (no rule list) the mobile device has full access to the network
Access Accept (with rule list) the mobile device has access to the network with a L3-4 rule list filter applied to traffic ingressing your network from the mobile device.
If a rule list that does not exist is invoked by a RADIUS Access Accept response, the session will fail authorization.
The process is as follows:
1a. The ARC is made aware that a successful EPS-AKA mobile auth has occurred.
1b. Traffic from mobile device to enterprise network is blocked.
2. The ARC creates a NAC session for the mobile device, informing the Edge Platform’s Packet Processor (PP) to deny all traffic.
3. ARC sends an auth request to the radius server including the IMSI.
4. Radius server checks the IMSI on the ID store, and makes a policy decision based on the requesting radius client (the ARC) and the IMSI’s group membership.
5. Access-Accept is sent to ARC.
6. Packet Processor begins forwarding traffic according to the authorization profile for that IMSI.
In order to ensure that any SIM attempting to authorize (via IMSI) has successfully authenticated against the mobile core, you must ensure your RADIUS server policy only authorizes IMSI based RADIUS requests that have come from one of your ARCs.
If an Access-Reject is received, the NAC session will be deleted, so traffic from the mobile device will continue to be blocked. There will be a timeout of 2 seconds before another auth attempt from that mobile device is processed.
When the mobile device disconnects from the mobile network, the ARC will be made aware, and will send a RADIUS accounting stop message to the RADIUS server.
Session-timeout The default behavior of the ARC is that the NAC session will restart every 24 hours. This will be non disruptive to the mobile device’s connectivity. This behavior can be overridden for a given authorization profile by including a session-timeout and/or terminate action AV in the authorization profile.
Idle-timeout We do not currently support idle-timeout, as this is managed by the mobile core. If the mobile core disconnects a device due to inactivity, the ARC will be made aware, and an accounting stop will be sent to the Radius server.
PAP password override
We are not relying on PAP for authentication onto the mobile network, instead, as mentioned above, the much more secure EPS-AKA is used. The ARC simply uses PAP as the method to send a successfully authenticated IMSI to your RADIUS server. Your RADIUS server will then perform its own auth against the IMSI. As PAP requires the password field to be populated, we use the IMSI for this also. If a numeric only password is not permitted by your password policy, you can use the ‘PAP password override’ feature to configure a password on the ARC that will be used in the password field of the PAP message for all IMSI based auth, and you will also add this password to all the IMSI IDs on your ID store.