802.1x in the Enterprise Network Harrison Forest ICTN 6823 Abstract: This paper aims to provide a general over view of 802.1x authentication and its growing importance on enterprise networks today. It provides an overview of the mechanics involved with 802.1x framework and RADIUS authentication. The importance of mobile device management and bring your own device and there relations to 802.1x will also be discussed. The history and standardization of 802.1x will be explained to provide background information. Lastly, various dot1x solutions will be discussed and the significant benefits they provide to network and information security. Introduction Mobile devices have carved an enormous niche in today s society. In fact, in 2013 around 31% of all traffic originated from mobile devices (Westdyk 2014). This drastic trend in mobility has caused great concerns in the information security world. However, executives and information systems officers understand the importance of convenience. Being able to bring your own device to work, for instance, provides a level convenience that was at one time not achievable. The familiarity that employees may have with their own machines or devices may provide an advantage in efficiency. An example could include an employee being able to send emails from their smartphones while being connected to corporate Wi-Fi when they are away from their desks. Similarly, the mobility of wireless networks provides hospitals with unprecedented healthcare and patient convenience. It doesn t stop here though. Employees and their non-corporate devices aren t the only ones who need network access. Guest services are growing in demand as well, so there needs to be a way for these individuals to connect securely to networks. With all these advantages it is hard to imagine the trend mentioned above slowing down. In fact, Cisco Systems believes that more than two-thirds of mobile traffic will be comprised of just video data alone by 2018. So instead of fighting the trend information officers need to embrace it and focus on this migration from a security standpoint. There are security plans in place and frameworks for security officers to follow to establish a strong security policy that is specific to their organization. Special Publication 500-169 published by the National Institute of Standards and Technology (NIST) outlines details to create a strong information security policy. 802.1x Introduction
2 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k Policy framework and smooth network operations require one big important factor, standardization. Standardization is what enables all sorts of devices to connect to the internet or network within an enterprise, but even with this standardization issues can still arise. An integral part of network security can be broken down into three components: Authentication, Authorization and Accounting or AAA. AAA provides the basis of network security. Authentication is validating who or what something is. Authorization is how that who or what validates who they are. Lastly, accounting is session related information; for instance, time a user is given access on a corporate network. AAA provides answers to the increasing demands and security concerns with bring your own device (BYOD) network environments. A standard framework that expands AAA abilities is 802.1x. 802.1x (or dot1x) is a layer 2 IEEE standard that provides port based network access control on 802 IEEE media (Ethernet, wireless, etc.). Typically, 802.1x is achieved through Remote Authentication Dial in User Service (RADIUS). One of the larger advantages of 802.1x is it can be deployed without a central authentication server. 802.1x requires several components to function properly. The authenticator is what requires or requests an end device to authenticate. A supplicant provides the means of authentication for the client. A protocol provides the functionality of the supplicant and authenticator. Lastly, an authentication server provides the authentication service. As stated before, dot1x authentication can occur without a centralized authentication server. Dot1x provides the framework for AAA communication between an end device and a RADIUS server. There is an intermediate device that connects the RADIUS server and the end device. This device can be a switch, for example, and relays RADIUS traffic to and from the RADIUS server and relays Extensible Authentication Protocol over LAN (EAPoL) communication between itself and the end device. RADIUS messages are only exchanged between the RADIUS server and the intermediate device. Of course, in order for this to happen the intermediate device must be configured for RADIUS communication. Also, if a device does not support dot1x communication it will be unable to successfully authenticate. For these types of legacy devices different methods of authentication can be used such as MAC authentication bypass (MAB). It is important to understand that dot1x is an encapsulation definition and provides a framework for the authentication protocols that may be involved in any network with configured authentication mechanisms. Dot1x is a layer 2 protocol that transports EAP messages over IEEE 802 media (Ethernet, wireless, etc.). There are several instances of EAP each with unique attributes, but it must be maintained that without the skeleton of dot1x these protocols cannot function properly in an interconnected network.
3 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k I RADIUS/EAP Exchange Pictured above we see the EAP and RADIUS exchanges between an authenticator, client and Radius server. Dot1x functions on the left side specifically in this diagram and handles the EAP message exchange between the authenticator and client. An authenticator simply provides a way to encapsulate EAP over RADIUS messages that can be used to apply policies and ultimately a network enforcement decision. Several different devices can serve as an authenticator in an 802.1x-enabled network, but the most common ones in today s networks are switches and wireless controllers. The ability for multiple Radius servers to sit behind the authenticator device allows for great scalability and load balancing. This also allows for the authenticating of many dot1x supplicants in a centralized environment. Extensible Authentication Protocol Process The Extensible Authentication Protocol (EAP) provides a wide variety of authentication methods within an enterprise network. The variety of authentication methods may include the exchange of X.509 certificates to provide a mutual form of authentication, or establishing secure tunnels to exchange authentication information. When EAP messages travel through the network they are encapsulated with EAP over LAN or EAPoL messages. The format of this encapsulation is detailed within the dot1x functionality. The EAPoL frame consists of the MAC header, Ethernet type, version, and packet type. The MAC header includes the source and destination MAC address. The Ethernet type defines
4 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k the Ethernet frame. Version 2 is the standardized version from 2004 that is used. No new EAPoL version has yet been standardized (RFC 3748). Lastly, the packet type is what determines the current stage of the EAPoL conversation. The EAPoL packet types consist of several different varieties. The EAPoL Start is the packet that is sent by the client to begin the authentication process. Conversely, an EAPoL Logoff is sent by the client to initiate the de-authorization process and ultimately network disconnection. After an EAPoL Start has been received by the authenticator it must then send an EAP Request for the identity of the client device that has initiated the connection. The client device then continues with the authentication process by sending an EAP Response to the identity request from the authenticator. The next steps depend on the configuration of the EAP environment by the security officers. Meaning, there are several different EAP methods that can be used. A common type in regards to the steps listed above is EAP-TLS. This method utilizes X.509 digital certificates and Secure Socket Layer (SSL) technology to establish a secure tunnel. Once the initial EAP messages are exchanged they are encapsulated over RADIUS and sent to the RADIUS server via an access request. The Radius server responds to this and is translated by the authenticator to a server hello. The server hello begins the TLS handshake. Within this server hello the Radius server presents its certificates to validate its identity. This is an essential step because if the client does not trust this certificate the client device may cease communication with the Radius server and will not be able to connect the network. After the TLS handshake is successful and a secure tunnel has been established there can be inner authentication methods configured to begin exchange of additional credentials. This is known as Protected EAP or PEAP. The Challenge Handshake Authentication Protocol was used in conjunction with the legacy TTLS protocol since CHAP passes user credential in clear text the TTLS tunnel was used to protect the credentials. CHAP is not an EAP method so it is not used by dot1x. Microsoft developed their own CHAP method called MS-CHAP and then later developed MS-CHAPv2. In Windows environments MS-CHAPv2 can be used as an inner authentication method with PEAP. Another inner authentication method that can be used with EAP is the Generic Token Card or EAP-GTC. This method carries a token card password to protect the exchange of authentication credentials in clear text through the established tunnel. X.509 Certificate Validation For a certificate to be considered valid it must be signed by a proper root certificate authority. An intermediate certificate is one that has been validated by a root certificate. For instance, GoDaddy.com has a certificate authority (CA) in which network administrators can send their own internal servers certificates to get signed so client devices will trust them. This is known as a certificate signing request. A network administrator would generate a certificate
5 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k signing request for their internal RADIUS server. Once it is signed by Go Daddy they have successfully built an intermediate certificate for their RADIUS server. There are two important fields within a X.509 certificate that are used for certificate validation: The subject key identifier and the authority key identifier. The subject key identifier is used to identify a public key. Alternatively, the authority key identifier is used to identify the public key that is associated with the private key used to sign a certificate. So how does a root certificate validate itself? Simply put, it doesn t. It is signed by itself for validation and is a widely adapted industry-wide certificate authority like the GoDaddy.com one mentioned above. In other words, the authority key identifier matches the subject key identifier of a root certificate. So in order to validate a certificate chain there must be a root certificate signed by a root CA, an intermediate certificate issued by the root certificate and last a client certificate that is issued by the intermediate certificate. This enables a client to trust the certificate chain of the Radius server to complete the TLS handshake. II Certificate Chain Validation Additional EAP Methods There are additional EAP methods that have been developed by Cisco and are proprietary to their network environments. Lightweight EAP is Cisco s wireless EAP technology. LEAP uses MS-CHAP to authenticate mutually between the client and server. LEAP is used when a network administrator does not desire the use of X.509 certificates in a wireless environment. However, Cisco then moved to develop a newer version of this method called EAP-Flexible
6 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k Authentication via Secure Tunneling (EAP-FAST). This is similar in functionality to LEAP but first establishes a TLS tunnel before credentials are exchanged. This tunnel is established by a Protected Authentication Credential or PAC. Identity-type values called type/length/values, TLVs, are then exchanged to determine the entities being authenticated (i.e. user authentication or machine authentication). With EAP-FAST Cisco introduced the innovative concept of EAP Chaining. EAP Chaining is enabled by the EAP-FAST protocol and it works with a Windows environment to authenticate a device connecting to an enterprise network in addition to user credentials. This is accomplished through the aforementioned TLVs. The RADIUS server will send an Identity-Type TLV to the client device authenticating to the network. Depending on the TLV response from the client the RADIUS server will be able to know if this is machine authentication or user-based authentication. The RADIUS server can determine if the client device does support EAP Chaining by the TLV responses it receives from the client. If it does not the EAP-FAST authentication method continues as normal. However, EAP Chaining can only be used if it is supported by both the supplicant on the client device and the RADIUS server involved with the authentication process. Dot1x Supplicants Dot1x supplicants are what provide client devices the ability to authenticate using dot1x. Windows machines come with a native supplicant that provides various dot1x authentication methods. The native supplicant on the Windows machines allows for machine, user and machine or user authentication. Machine authentication is when access is granted to just the machine itself. Meaning, regardless of the user that logs on it will be on the network and will have access to whatever that machine may be granted to. This is a desired setting in an Active Directory environment because network administrators can initiate GPO pushes without worrying about if they are authenticated onto the network or not. Additionally, a user can log on and their credentials will be used to provide authorization onto the network. Regardless of which entity is being authenticated it can only be one or the other. So, EAP Chaining is not supported by the Windows native supplicant. MAC OS X and ios devices have dot1x supplicants as well and can support various EAP methods like EAP-TLS, EAP-FAST, PEAP, etc. The OS X supplicant functions in three modes: user mode, system mode and login window mode. User mode is when the user logs into the network upon being prompted. System mode is similar to the machine authentication setting on the Windows supplicant in that the machine stays logged onto the network regardless if a user is logged in or not. Lastly, login window mode is used when a computer is tied to an external identity source like Active Directory Domain. With this mode a user will login and the machine will first be authenticated onto the network using the credentials entered by the user and 802.1x. Then the login window will authenticate the user through the external identity source. The main
7 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k difference between the OS X supplicant and the Windows supplicant is that it can provide a means of authenticating both a user and a machine onto a network using dot1x. In order to support EAP chaining Cisco has developed their own dot1x supplicant. AnyConnect Secure Mobility Client provides a solid VPN solution but also is a comprehensive dot1x supplicant in the Network Access Manager or NAM module. It is supported by both Windows machines and MAC OS X and supports both wired and wireless mediums. EAP-GTC can be used with NAM which is not available with the Windows native supplicant. The NAM module can be configured and customized to be in accordance with a network s authentication policies. Cisco s Radius server the Identity Services Engine can be integrated with AnyConnect for an even greater amount of security. For instance, the latest release of AnyConnect includes a posture module which allows for an all-in-one solution for device authentication. Devices authenticating onto an enterprise network must also be in accordance with updated anti-virus definition files, etc. This is known as posture checking and client provisioning. These checks are done through attributes that are passed between the client device and Radius server during the dot1x authentication. Conclusion and Considerations As network accessibility grows the concern for network security does as well. The mobility that new technologies are providing us is incredible. There are several different solutions available to network security administrators to help ensure enterprise networks can remain secure while allowing access to a wide variety of technology. Dot1x allows for devices to connect to corporate network environments even though they aren t pre-configured corporate assets. Bring Your Own Device (BYOD) has become an integral part of corporate productivity in that employees can bring their smartphones to the office and connect onto the corporate network and use them for work as well. Dot1x provides a way for these smartphones to connect securely and adhere to existing network security policies that they probably weren t preconfigured for. Posture checking and client provisioning are features that can be used to determine what software are running on these devices. So, during the dot1x exchange we can determine if the devices are compliant with the policies and grant access or if they are not, reject access. There are some solutions that can enable security administrators to grant guests the ability to even register their own devices with the authentication servers on the network. Of course this number can be tailored to one or many. This flexibility helps to ease the burden and worry of possible rouge devices within a network. Dot1x can also be used with mobile device management. MDM servers can communicate with Radius servers to provide 802.1x authentication capabilities.
8 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k When designing a comprehensive dot1x authentication environment it is always important to plan and re-plan. Implementation of various practices like, BYOD, require extensive knowledge on various concepts. Web-redirection is an important aspect of the dot1x process because when a guest device is attempting to connect to the network there is no way the user can authenticate until it has some network access. Another large part of guest services and dot1x is a feature known as Change of Authorization. CoA allows a device to be reauthenticated multiple times while tied to the same accounting session ID. Therefore, it allows the complete dot1x authentication process to take place without dropping the accounting session. Regardless of the approach a network administrator is taking it is important that they realize that every device connecting to their enterprise network adheres to the security policies of their organization. It is equally important that they apply to federal or industry-wide policies as well. For instances how credit card machines are connected to a network securely and able to transfer credit information. There are several configuration practices, security frameworks and guidelines available to help network security personnel gain a solid advantage when implementing a large security solution for network authentication. References: Aboba, B., Microsoft, Blunk, L., Merit Network, Vollbrecht, J., Volbrecht Consulting,... IpUnplugged. (2004). Extensible Authentication Protocol (EAP) RFC 3748. Retrieved July 11, 2015, from IETF.org Apple. (2012). Apple Technical White Paper: 802.1x Authentication. Retrieved July 8, 2015, from http://training.apple.com/pdf/wp_8021x_authentication.pdf Blunk, L., & Vollbrecht, J. (1998). RFC 2284. Retrieved June 29, 2015, from IETF.org Braine, D. (2009). Deep Dive into TrustSec/Demo. Retrieved July 11, 2015, from https://www.cisco.com/web/strategy/docs/gov/preso3-danielb_cisco_trustsec_demo.pdf Burns, J. (2003, April 3). How 802.1x Authentication Works. Retrieved July 10, 2015, from http://www.computerworld.com/article/2581074/mobile-wireless/how-802-1x-authenticationworks.html Cisco AnyConnect Secure Mobility Client Administrator Guide 4.1. (2015). Retrieved July 7, 2015, from http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect41/administrati on/guide/b_anyconnect_administrator_guide_4-1/configure-posture.html#id-1407-00000099 Cisco Systems. (2011, September 1). Wired 802.1x Deployment Guide. Retrieved June 29, 2015. Congdon, P., Hewlett Packard, Aboba, B., Microsoft, Smith, A., Trapeze Networks,... Enterasys. (2003). RFC 3580. IEEE 802.1x Remote Authentication Dial In User Service (RADIUS) Usage Guidelines. Retrieved June 25, 2015, from IETF.org
9 8 0 2. 1 x i n t h e E n t e r p r i s e N e t w o r k Congdon, P. (n.d.). IEEE 802.1x Overview Port Based Network Access Control. IEEE Plenary. Retrieved from ieee802.org CounterACT: 802.1x and Network Access Control. (2013). Retrieved July 10, 2015. EAP Types - Extensible Authentication Protocol Types Information. (n.d.). Retrieved July 15, 2015, from http://www.vocal.com/secure-communication/eap-types/ Gast, M. (n.d.). Inner Authentication Methods. Retrieved July 15, 2015, from http://www.opus1.com/www/whitepapers/8021xinnerauthmethods.pdf Geier, E. (2011, September 30). Tools to Deploy 802.1x on Mobile Devices. Retrieved July 19, 2015. Housley, R., RSA Labs, Polk, W., NIST, Ford, W., VeriSign,... CitiGroup. (2002). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 3280. Retrieved July 20, 2015, from IETF.org Microsoft. (2005, January 21). Undertsanding 802.1x Authentication for Wireless Networks. Retrieved June 30, 2015. Rouse, M. (2005, September 1). 802.1x. Retrieved June 30, 2015, from http://searchmobilecomputing.techtarget.com/definition/8021x Westdyk, T. (2014). A Broader Information Superhighway. Retrieved July 3, 2015, from http://www.cit.com/perspectives/executive-insights/wireless-broadband-trends/index.htm What is EAP-FAST? (n.d.). Retrieved July 2, 2015, from http://www.opus1.com/nac/whitepapers-old/e-eapfast-lv05.pdf Whitman, M., & Mattord, H. (2014). Management of information security (Fourth ed.). Stanford, CT: Cengage Learning. VoCAL. (n.d.). EAPoL - Extensible Authentication Protocol over LAN. Retrieved July 15, 2015, from http://www.vocal.com/secure-communication/eapol-extensible-authenticationprotocol-over-lan/