Expert Reference Series of White Papers

802.1X Implementing and Deploying Methods

1-800-COURSESwww.globalknowledge.com

802.1X- Implementing and Deploying

Jim Thomas, Cisco Security Course Director, CCIE Security #16674

Introduction
A standard to remember, and one that youll have netmares about as you get started with deployment, is the infamous 802.1X. This is an authentication protocol that was designed back in 2001. There are different speculations on why there was such a high rate of failure, whether it is lack of understanding, technologies such as RADIUS Servers that just didnt have the features that were needed, or a combination of the two. 802.1X, or dot1x as its commonly called, is simply an authentication method used by endpoints (Windows, MACs, iDevices, Android) to gain access to the network. You may have already used this protocol with your wireless infrastructure, so now its time to implement it across the board on wired and wireless.

Dot1x History Lesson

Dot1x has gone through three different versions since its inception. The first request for comments (RFC) for the protocol was written in 2001, under the impression that Port Access Entity (PAE) would be used for hardwired clients only. In 2004, there was an update to the RFC that included the use of dot1x on wireless networks. The latest revision, labeled 802.1X-2010, brought the use of MACsec (802.1AE) with the standard. In the 2001 and 2004 versions, it was discovered that attackers could a) insert themselves into the pathway of an already authenticated endpoint to can gain access to the network (authentication of EACH individual MAC was not performed) and b) any host on the same medium could spoof a legitimate users MAC and generate an EAP logoff message, bouncing the user off of the port; a classic disk operating system (DOS.) In the 2010 version, these vulnerabilities were addressed. Primarily, Cisco began using newer IOS switch features, allowing every endpoint (MAC) on a port to require authentication separately and also included the option of layer 2 encryption using MACsec.

Dot1x Layer 2 Authentication Method

Dot1x is a Layer 2 authentication method used on the network and consists of three major components: Supplicant: The middle-ware software that resides on the endpoint and talks to the authenticator. Its responsible for responding to Extensible Authentication Protocol (EAP) messages from the authenticator. Authenticator: The network access device (NAD) that is requesting authentication from the supplicant. This is usually a switch or a wireless LAN controller (WLC). Think about this as a RADIUS client.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

 Authentication Server: The RADIUS server that processes the authentication requests; also responsible for returning attributes, such as access lists and VLANs, to the NAD.

EAPoL Frame Communication

Dot1X is only used between the endpoint and the NAD (Network Access Device) it is trying to get access through, such as a switch or WLC. This communication takes place using a special frame labeled as an EAP over LAN (EAPoL) frame. This frame has the standard Ethernet II headers and trailers, but there is no upper layer information within the frame. The EAPoL frame is the initial 802.1X message that is sent from the Cisco switch (as indicated with the source MAC) to any endpoint that is hanging off of the port. Figure 1 displays a close-up shot of the packet contents.

Figure 1. EAPoL Frame Packet Contents

Notice the Dst: MAC indicates Nearest, which, if you look at the MAC (01:80:c2:00:00:03), it is a reserved MAC. Any endpoint or device that receives traffic destined to this address should process the packet locally. The switch we are using is configured to use the 2010 version of dot1x.

EAPoL Packet Response

The packet is sent from the client to the switch as a response. In fact, youll see the Code field reflects a value of 2, indicating a response to the initial request. The Type field reflects that this packet is still an Identity type. The Identity field reflects the user that is currently logged into the host. 802.1X grabs the currently logged-in, cached credentials and uses them throughout the authentication phase. The thing most of us do not like is that the Identity field can easily be read, since it is clear text. In Figure 1, look at the version of 802.1X being used; this is an up-to-date Windows 7 client. Microsoft still uses the first version of dot1X, which is okay, because as long as the switch supports the newest versions, the network will be protected from those vulnerabilities.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

Figure 2. EAP Payload

The frame in Figure 2 contains no IP addresses and no Layer 4 headers. It containsnothing other than Layer 2 information and a special payload called theEAP. This EAP payload contains the authentication protocol information needed for the endpoint to authenticate to the network. Figure 3 displays the follow-up request from the RADIUS server, where it is requesting Protected EAP (PEAP) (type 25) communication.

Figure 3. RADIUS Server Follow-Up Request

The Version field in Figure 3 indicates a 2010 flavor of 802.1X. The switch that sent the packet is running the latest code and thus supports the latest implementation of the protocol. Also note the Type field indicates a PEAP packet. Now there are many, many different flavors of EAP authentication protocols. PEAP is the most common due to its ease of deployment. Lets face it, dot1x isnt our entire lives; we have other things to do at work. To streamline the configuration of PEAP, we could create Group Policy Objects (GPOs) on our Windows servers and push down the PEAP configuration to our clients. Also, there is no additional supplicant to install, since Windows and other popular operating systems already come shipped with PEAP capabilities. Well talk a little more about PEAP later. For now, know that this is a PEAP request sent from the RADIUS server to our switch, and then the switch proxies that data in an EAPoL packet to our client.

Clients Response to a PEAP Request

What follows this PEAP request is the clients response to initiate the transport layer security (TLS) handshake with the RADIUS server. The following denotes the authentication process:
Copyright 2013 Global Knowledge Training LLC. All rights reserved. 4

1. T  he client send its client hello packet to the RADIUS server. In this packet, the client sends a TLS record with the contents: Random, Cipher Suites, Compression Support, and any Extensions of Capabilities (Figure 4).

Figure 4. Client Hello Packet

2. T  he next packet is from the RADIUS server. The contents (which are three records contained in this packet) are the Server Hello record, the Server Certificate, and the Server Hello Done record (Figure 5). These records contain: a. S  erver Hello: Random data generated on the RADIUS server, Session ID generated on the RADIUS server, Cipher Suite selected, Extensions, and Compression settings.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

Figure 5. Server Hello Packet

b. T  he next record is the Certificate being supplied from the RADIUS server (Figure 6). Notice that the certificate chain, the RADIUS server cert, and the certification authority (CA) that signed the RADIUS servers cert are passed in the record:

Figure 6. Certificate

c. The third record is the Server Done message.

3. T  he next packet sent from the client is an acknowledgement to the PEAP request (Figure 7). Actually, the RADIUS server sends two more packets with the same header values, but the payload changes (notice the byte count changing 1030, 1026, and 232 bytes).

Figure 7. Client Acknowledgement

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

4. N  ext comes the client response, containing three records: Clients Key Exchange, Change Cipher Spec, and Encrypted Handshake Message (Figure 8). The encrypted handshake method is the session key that the client has chosen to use and encrypting it, using the public key of the RADIUS server (this was provided in the identity certificate of the RADIUS server).

Figure 8. Client Response

5. T  he following packet from the RADIUS server is the change cipher spec message and the encrypted handshake message, which is basically the server sending back encrypted information using the shared session key. If all works correctly, the client will be able to decrypt and confirm the message (Figure 9).

Figure 9. Change Cipher Spec Message

6. N  ow that we have negotiated the ciphers and have successfully exchanged session keys, we need to authenticate the client to the RADIUS server using an inner-method of authentication (Figure 10). Commonly, we use MSCHAPv2, but it can also be a client-based certificate sent through this encrypted TLS session. Since this session is truly encrypted, we wont be able to determine the inner method of authentication, but neither would an attacker (unless they did a man-in-the middle attack on the TLS session).

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

Figure 10. Authenticate Client to RADIUS Server

Client Supplicant Configuration

On the client side of the house we have a supplicant. The supplicant that ships with the Windows operating system is the easiest to use and can also be controlled using GPOs, as mentioned earlier. The first thing we need to enable is the Windows service for dot1x (Wired AutoConfig) as seen below in Figure 11 (youll want to set this service to automatically start):

Figure 11. Enable Windows Service for Dot1x

Authentication Tab
Now that the service has been started, go to the NIC properties. Once there, youll notice the Authentication tab and its various options (Figure 12). This is the dot1x configuration.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

Figure 12. Authentication Tab

The Enable IEEE 802.1X authentication option allows you to enable or disable the supplicant. The Settings drop-down box has two values: PEAP method of authentication and Smart Card or other certificate EAPTLS method of authentication. The Remember my credentials for this connection each time Im logged on option allows the credentials to be cached from a user, which, in turn, are supplied during authentication. This option helps if timers have been set to low values, and dot1x requests authentication or re-authentication, and the user doesnt have time to supply credentials. Since PEAP already uses the current users credentials, it would be beneficial to disable this option for environments where computers are being shared. Also note that in the past, with XP, this option was toggled on or off with a registry value, which Win7 does not use. Fallback to unauthorized network access option means that if a client fails authentication using dot1x, instead of just telling the NIC that its done and dead, it keeps the port in an unauthorized state. The Additional Settings button will take you to the more advanced dot1x settings. Here we can select Machine authentication and or User authentication. The thing to remember is that its not an AND that most users want. Actually, its not up to the machine at all. When the EAPoL request is made from the switch, the credentials provided are the cached credentials (machine or user) that the device is currently logged in with.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

If your machine boots up and dot1x immediately requests credentials from your machine, then the machine credentials will be used. Machine authentication happens within the first couple of seconds of the machine booting; basically, by the time you see the Windows logo, its already occurred. At this point, youll get the graphical identification and authentication (GINA) requesting credentials. Your user will supply credentials, and the dot1x process on the machine forwards the new credentials to the switch, which proxies them to the RADIUS server. A key point here is that the client itself can also generate EAPoL packets on the fly, without having the switch request them first. If you want to use both machine and user authentications, its up to the RADIUS server to determine whether this is allowed or not. The policies defined on that server dictate what to look for to determine machine and or user authentication. You can select the Enable Single Sign On option, if you need to have the primarily wireless clients connect to the network before they logon to the workstation or immediately after. This option defines when to supply the credentials. Again, this does not affect the hard-wired clients, because the medium is already present. In wireless, the single sign-on (SSO) option allows you to determine when to supply credentials for the wireless connection. Lets go back to the main Authentication tab. From here, click the Settings button next to PEAP (Figure 13). These settings are crucial for securing the PEAP connection.

Figure 13. PEAP Connection

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

10

First, the Validate server certificate option is enabled by default and should be disabled. The Connect to these servers option is one that is commonly misconfigured. The text in this field needs to match the Issued to field on the RADIUS server certificate. I know that you are thinking about redundancy, right? Well, of course you are, so the answer is yes, you can add multiple entries by separating them out with semi-colons. The following option (Figure 14) allows you to select the Trusted Root CAs for the connection. Heres the kicker: these are always on, and you cannot toggle them on or off. I know, you see the checkbox, but it doesnt do anything.

Figure 14. Trusted Root CAs

The Authentication method drop-down also contains value of interest. MSCHAPv2 is selected by default, but a client-based certificate can also be used for authentication. The thing to remember is that the outer (Phase1) TLS tunnel is used to secure the tunnel for this inner method authentication to take place. If this were a straight EAP-TLS connection, certs would be exchanged without any encryption. However using PEAP-TLS ensures we are encrypted first, then the client presents its certificate. In most cases, youll stick with MSCHAPv2, which eliminates the need for client-based certificates. The Enable Fast Reconnect option allows a users session to quickly resume without having to go through the inner method of authentication. This works because we are using TLS, which supports session-resume. So as long as the users can resume the TLS session, they will be granted access. This is useful for users who frequently roam between access points. The Disconnect if server does not support cryptobinding TLV option is used to prevent man-in-themiddle attacks where information is taken from Phase 1 of the tunnel negotiation and Phase 2 (client authentication). The information is hashed, and the hash is forwarded to the peer. This ensures both Phase 1 and Phase 2 data are sent and received between appropriate peers and that a phase was not compromised.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

11

The last option on the page is the Enable Identity Privacy option. In this field, we can specify any identifying information that will be used prior the Phase 1 tunnel negotiation with PEAP. Remember that this information is supplied in clear text. We can specify anything in this field, if we are worried about eavesdropping on the wire. Right behind that RADIUS packet and after TLS negotiation, we see another RADIUS packet with the inner method of authentication using the actual machine/user credentials. Remember, however, this username will be encrypted.

Conclusion
As time goes on, well be seeing more and more of 802.1X in the environments we support. We have to for due diligence. Allowing trusted and non-trusted hosts to connect to our networks without proper controls is really just turning our head to security. You may have heard concerns or nightmare stories about 802.1X, but with the tools we have today and the method of implementation, this can be seamless in an environment and far exceeds any compliance requirements you may have. I will say this, though; this is one technology you HAVE to take a deep dive on. Its also a case for taking a course to really learn the technology in an environment thats not your production.

Learn More
To learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge, Global Knowledge suggests the following courses: 802.1X - Introduction to 802.1X Operations for Cisco Security Professionals ACS 5.2 - Cisco Secure Access Control System SISE - Implementing and Configuring Cisco Identity Services Engine v1.1 Visit www.globalknowledge.com or call 1-800-COURSES (1-800-268-7737) to speak with a Global Knowledge training advisor.

About the Author

Jim Thomas is a subject matter expert and Cisco Security Course Director for Global Knowledge. He has worked extensively with the various Cisco Business Units (BUs) over the years and has helped develop courseware used worldwide. Although his passion is education, this passion is derived from a need to understand the products hes engaged with. To this end, he has attained the CCIE Security designation. He takes a hands-on approach to learning by contracting to government agencies (Federal, state, and local) and Enterprise networks. He is course director for the following courses: IPS, SSECMGT (CSM), NAC+, ISE, 802.1X, and ACS 5.x.

Copyright 2013 Global Knowledge Training LLC. All rights reserved.

12