A decade ago, employees of companies would rarely personally own the mobile email device that provided access to corporate resources. In these days Blackberry by RIM was the ruler of the enterprise mobile email landscape with incredibly little competition. Companies loved Blackberry because it provided centralized management, provisioning, and security. They weren’t particularly expensive and the workforce productivity enhancements were incredible. For market reasons, entirely out of the scope of this book, the Blackberry has been increasingly out of favor of users because other more user-friendly devices became available and popular. Specifically the proliferation of Apple iPhones and of Google Android devices is what virtually every enterprise’s user base now prefers. How they voiced this preference when they started ditching their corporate-provided Blackberries and brought into work their own personal phones with the expectation that they’d get company email on it.
As such, BYOD, or Bring Your Own Device, is a huge buzz acronym in the industry today and it is having a big impact on how enterprises provide access to services to users. It means different things to different people and corporations. Most typically, BYOD literally means employees bringing in their own devices and wishing to get access to corporate resources and offload internet data from their cellular connection to Wi-Fi. Corporate resources in this case may include email, internal websites, file shares, and other internal apps. Occasionally BYOD policy may get mixed into company-owned, but nondomain devices such as OSX or company-owned mobile devices. That exact definition is entirely dependent on how your company defines access rules for different classes of devices. For our examples, we’ll stick with what is most common in the field, employees trying to connect their personally owned device to corporate Wi-Fi.
The corporate policy around what network access will be provided to employee-used, but non-company-owned assets from which some level of business may be performed is a huge question. Companies break down generally into the following categories with regard to BYOD policy:
• BYOD devices are not allowed on corporate wired or Wi-Fi or VPN networks ever.
• In the first case, only corporate-owned devices will ever be permitted access. I would call this device trust, with no trust put on the actual end user of the device.
• BYOD devices are unrestricted on corporate wired or Wi-Fi or VPN connections.
• No differentiation is put on the physical device the user is connecting with. The user may connect to corporate resources with their personally owned phone, with the same network access level as their company-owned laptop.
• BYOD devices are allowed some level of access differentiated from what a corporate-owned device may have.
• This is where things get interesting. We want the same user to have differentiated network access controls based on what device they connect from. This is where ISE provides us some really useful tools.
For our design discussion, we’re going to make a couple of assumptions. While every company is different, we generally find the following to be true and reliable:
1. BYOD devices will not be members of the corporate Active Directory or other directory service.
2. Corporate-owned devices most often are members of Active Directory or other directory service.
3. Corporate-owned mobile devices are most often managed by a corporate MDM system.
The thing about BYOD design is that the most important part of BYOD design in my opinion is counterintuitively how you identify corporate devices with an authentication that provide a high fidelity identifying that the device is a corporate asset. What is a high-fidelity authentication? Great question. A high-fidelity authentication for corporate access has the following characteristics:
• Is strong cryptographically
• Has authentication that uses cryptography to secure client credentials
• Provides ability to authenticate that the device is corporate issued
If you rely on PEAP/MS-CHAPv2 domain user-type authentication for corporate-owned devices, you’re never going to efficiently distinguish between domain member and non-domain member devices.
Looking at how a PEAP/MS-CHAPv2 authentication occurs is important:
• EAP session starts.
• RADIUS server (ISE) provides its certificate to the client for authentication.
• TLS tunnel is created.
• Client provides its MS-CHAPv2 credential (username/password).
• Access-accept or access-reject message is sent depending on AuthZ or AuthC.
There is nothing in the credential exchange to establish what is exactly the client device is. Any type of device out there can be set to provide your wireless (or wired) network a username/password. While you can do profiling to determine what the device is, there are two issues with that. First, if you’re presuming that all your internal devices are Windows devices and you want to preclude non-Windows devices from connections, you still can’t differentiate between a corporate Windows PC and a noncorporate Windows PC. Second, a determined attacker would have to do very little to bypass your AuthZ policy if user credentials are otherwise allowed to authenticate while obfuscating their actual device’s OS. Basic ISE MS Windows profile policy at the time of this writing simply uses DHCP attributes that may be easily manipulated and this won’t tell you if the device is actually corporate owned.
Because of this, PEAP/MS-CHAPv2 user authentication generally is insufficient to allow for a robust BYOD network access policy. The next two chapters will discuss a couple of aspects of deploying ISE to achieve robust access policy.
Chapter 12 is devoted to configuring strong network access policy with ISE and other components to strongly authenticate corporate devices. This, in my experience performing ISE implementations, is often the more challenging part.
Chapter 13 is devoted to discussing methods of authenticating BYOD-type devices to allow for effective differentiation.