802.1x explained - freelists · and androids to work requires some very tight security controls....

1-800-COURSES www.globalknowledge.com

Expert Reference Series of White Papers

802.1X Explained

Copyright ©2012 Global Knowledge Training LLC. All rights reserved. 2

802.1X ExplainedJim Thomas – Cisco Security Course Director, CCIE Security #16674

IntroductionBYOD (Bring your own Device) is the term that we have tried to put in the furthest, darkest place in our mind. A term that, if mentioned in the next IT meeting, would in itself change the very world we know. But why would something that sounds like we should bring it to the next keg party have such a profound impact on our daily activities? The answer, change scares us. And having something like this acronym change us so dramatically seems to cause repression of technology.

Instead of putting this into the darkest dungeon in the mind, we are going to embark on a journey, through sev-eral areas of this technology. Yes, we will jump in head-first and completely immerse ourselves with questions and answers we’ve addressed in the classroom. I suggest you try to read through the entirety of the documents provided in order to truly get a deeper understanding of the newer technology.

We will be using the Global Knowledge lab topology we use in our current ISE course to get a visual representa-tion. What made me want to jump into this white paper in the first place is the passion I have for Cisco’s new flagship security product, the Identity Services Engine (ISE). We’ll be using this product at the heart of our policy decision-making process in relation to 802.1X.


BYOD in itself is not a technology, but the mere thought of allowing users to being their own laptops, iDevices, and Androids to work requires some very tight security controls. I think we are at the point in our careers where we have to agree that a user solely providing valid credentials on any device won’t work anymore. We need to be able to control their environment, whether that is determining the device they are logging in from, to time-of-day, and what the medium they are using to gain access (wireless or wired). These environmental factors are exactly what we will use to properly authorize the endpoint.

Another 802 Standard?To put it bluntly, yes, there is yet another standard to remember. This one, however, sticks out like a sore thumb and it is one that will give you netmares as you get started with deployment. I’m talking about the infamous 802.1X, an authentication protocol that was designed back in 2001. Many have tried to deploy this protocol and many have failed to reap the rewards and have since been forced to pull out of production. There are different speculations on why there was such a high rate of failure, whether it was lack of understanding, technologies such as RADIUS Servers that just didn’t have the necessary features, or just a combination of the two. Whatever the case was its back now. Kind of like running into an old girlfriend in public ……awkward!


802.1X, or dot1x as it’s commonly called, is simply an authentication method used by endpoints (Windows, MACs, iDevices, Androids) to gain access to the network. Most of you have already used this protocol with your wireless infrastructure; now it’s time to implement this across the board on wired and wireless.

Dot1x has gone through three different versions since its inception. In 2001, the first RFC for the protocol was written under the impression Port Access Entity (PAE) would be used for hard-wired 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 about the use of MACsec (802.1AE) with the standard. Discoveries were made in the 2001 and 2004 versions that attackers could

1. 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

2. any host on the same medium could spoof a legit users MAC and generate an Extensible Authenti-cation Protocol (EAP) logoff message, bouncing the user off of the port -- a classic denial of service (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 they also included the option of layer 2 encryption using MACsec -- but you need to use the Cisco Secure Mobility Client, which contains a module for MACsec support for the client. But that’s for another discussion.

Dive! Dive! Dive!On with the technical details. Dot1x is a Layer 2 authentication method used on the network and consists of three major components.

Supplicant – This is the middle-ware software that resides on the endpoint and talks to the authenticator. It’s responsibility is to respond to EAP messages from the authenticator.

Authenticator – The network access device (NAD) that requests authentication from the supplicant. This is usually a switch or a wireless LAN controller (WLC). Think about this as a RADIUS client.


Authentication Server – The RADIUS server that processes the authentication requests. However, not just authentication is performed. The RADIUS server is also responsible for returning attributes to the NAD such as access lists and VLAN assignments.

So that’s it, three components. In current implementations of dot1x, the predominant policy engine making all of the decisions for authentication and authorization is the Cisco ACS. The newer replacement to this policy engine is Cisco ISE. ISE is Cisco’s new flagship security product, and is at the core of their TrustSec architecture. We’ll address ISE in a follow-up document to this one. Let’s first finish the dot1x side of the house.

Dot1X is only used between the endpoint and the NAD it is trying to get access through, such as a switch or WLC. This communication takes place using a special frame labeled as an EAPoL (EAP over LAN) frame. This frame has the standard Ethernet II headers and trailers, but there is no upper layer information within the frame. The following is an example of a live sniffer trace when a user with an 802.1X supplicant enters a network that has 802.1X enabled on a switchport:

This frame is the initial 802.1X message sent from the Cisco switch (as indicated with the source MAC) to any endpoint that is hanging off of the port. Here’s a close-up shot of the packet contents.

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

Now for the response, the following packet is sent from the client to the switch as a response. In fact, you’ll see the Code field reflect a value of 2, indicating a response to the initial request. The Type field reflects that this packet is still an Identity type. However, you’ll see that the following field, Identity, 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 we do not like is that the identity field can easily be read since is clear text. An attacker would have half his work complete by retrieving this packet and attaining the user-


name. Lastly, look at the version of 802.1X being used. This is an up-to-date Windows 7 client. It seems that Microsoft still uses the first version of dot1X, which is fine because as long as the switch supports the newest versions, we’ll be protected from those vulnerabilities discussed earlier. Well, at least the network will, the endpoint is a different story.

No IP addresses, no Layer 4 headers, nothing other than layer 2 information is included within this frame. Well, that and the EAP payload, which contains the authentication protocol information needed for the endpoint to authenticate to the network. Here is a shot of the follow-up request from the RADIUS server where it is request-ing PEAP (type 25) communication.

Notice that the Version field indicates a 2010 flavor of 802.1X. The switch that sent the packet is running the latest code and, therefore, 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. Let’s face it, dot1x isn’t 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. We’ll talk


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.

So what follows this PEAP request is the client’s response to initiate the Transport Layer Security (TLS) hand-shake with the RADIUS server. The following denotes the authentication process.

1. The 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.

2. The next packet is from the RADIUS server. This packet contains three records : the Server Hello record, the Server Certificate, and the Server Hello done record.:

a. Server Hello: Random data generated on the RADIUS server, Session ID generated onthe RADIUS server, Cipher Suite selected, Extensions, and Compression settings.


b. Certificate being supplied from the RADIUS server. Notice that the certificate chain, the RADIUS server cert,and the CA that signed the RADIUS servers cert are passed in the record.

c. Server Done: this is the third record in the message.

3. The next packet sent from the client is an acknowledgement to the PEAP request: 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).


4. Next comes the client response, containing three records: clients key exchange, change cipher spec, and en-crypted handshake message. The encrypted handshake method is the session key that the client has chosen to use and encrypts it using the public key of the RADIUS server (this was provided in the identity certificate of the RADIUS server).

5. The following packet from the RADIUS server is the change cipher spec message and the encrypted hand-shake message; basically, the server is sending back encrypted information using the shared session key. If all works correctly, the client will be able to decrypt the message and confirm the message.

6. Finally, now 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. Commonly, we use MSCHAPv2, but this can also be a client-based certificate sent through this encrypted TLS session. Since this session is truly encrypted, we won’t 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).


Client Supplicant ConfigurationOn the client side of the house is what we call a supplicant. The supplicant that ships with the Windows operat-ing system is the easiest to use and can also be controlled using GPOs as mentioned earlier. Now, the first thing that we need to enable is the Windows service for dot1x (Wired AutoConfig) as seen below (you’ll want to set this service to start automatically).

Now that the service has been started, go to the NIC properties. Once there, you’ll notice the Authentication tab. This is the dot1x configuration.


Here we have is the option to enable and disable the supplicant. The drop-down box has to values: one is the PEAP method of authentication and the other is the Smart Card or other certificate, which is the EAP-TLS method of authentication. The Remember my credentials for this connection each time I’m logged on option allow the credentials to be cached from a user which, in turn, is supplied during authentication. This option helps if timers have been set to low values, dot1x requests authentication or re-authentication, and the user doesn’t have time to supply credentials. Since PEAP already uses the current user’s credentials, it would be beneficial to disable this option for environments where shared computers are being used. Note that in the past with XP, this option was toggled on or off with a registry value, which Win7 does not use.

The Fallback to unauthorized network access option means that if a client fails authentication using dot1x, instead of just telling the NIC that it’s done and dead, it keeps the port in an unauthorized state. Here’s an example. I had a working dot1x connection and then changed the RADIUS key on the switch to purposely fail the authentication. When the Fallback option is checked, the client gave up on authentication after the dot1x timers expired, as it should. The IP address that it kept is the IP that it had prior to failing, as seen here.

The network icon in the system tray also indicated that the connection had no Internet access only and the NIC indicated an authentication failure.

Now, I went back and unchecked the Fallback option and then kicked off another dot1x authentication re-quest. Here is the outcome: the client released its IP, and the media looks like it went dead. Fallback seems to be the optimal solution since keeping the NIC somewhat alive will allow dependent applications to remain func-tional while in that state.


Let’s examine another option on the Authentication tab. Clicking the Advanced button will take you to the more advanced dot1x settings. Here we can select Machine authentication and or User authentication. The thing to remember here is that it’s not an “AND” that most of us wants. Actually it’s 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. Let’s go further. If your machine boots up and dot1x immediately requests credentials from your machine, while you have your back turned getting a cup of coffee, then the machine creds 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, it has already occurred. Once you get back to your desk, you’ll get the graphical identification and authentication (GINA) requesting credentials. At that point 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 gener-ate EAPoL packets on the fly without having the switch request them first.

You may ask, “What if I want to do both?” The answer, “Ok then….do it.” In other words, it’s 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. We’ll put out another whitepaper on that config since its really gaining popularity in the classes and is one of the most commonly asked questions.

The Enable Single-Sign On is the option can be selected if we need to have the primarily wireless clients connect to the network before they logon to the workstation or immediately after. It defines when to supply the credentials. Again, this really doesn’t affect the hard-wired clients because the medium is already present. In wireless, the ESSO option allows you to determine when to supply credentials for the wireless connection.


Let’s go back to the main Authentication tab. From here, click the Settings button next to PEAP. These set-tings are crucial for securing the PEAP connection.

First, the Validate server certificate option is enabled by default and should be changed. It’s self-explanatory.


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 as seen below.

Now, I know that you are thinking about redundancy, right? Well, of course you are. The answer is yes, you can add multiple entries by separating out the entries with a semi-colon.

The following option allows you to select the Trusted Root CAs for the connection. Here’s the kicker. These are always on, and you cannot toggle these on or off. I know you see the checkbox. But it doesn’t do anything.


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, you’ll stick with MSCHAPv2, which eliminates the need for client based certs

The Enable Fast Reconnect option allows a user’s 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. As long as the user can resume the TLS session, he or she will be granted access. This is useful for users who fre-quently roam between access points.

The Disconnect if server does not support cryptobinding TLV option is used to prevent man-in-the-middle attacks where information is taken from Phase 1 of the tunnel negotiation and Phase 2 (client authenti-cation). 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.

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. For example, I’ve entered the following in the field.


The resulting RADIUS debug on the switch shows the user supplied by this client.

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.

ConclusionYou may have heard concerns or nightmare stories about deploying 802.1X, but with the tools we have today and the method of implementation; this can be seamless in an environment and far exceed any compliance requirements one may have. As time goes on, we’ll see more and more of 802.1X in the environments we sup-


port. 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 heads away from security.

Learn MoreTo 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

http://www.globalknowledge.com/training/course.asp?pageid=9&courseid=16806&country=United+States

802.1X - Introduction to 802.1X Operations for Cisco Security Professionals

ACS 5.2 - Cisco Secure Access Control System

ISE - Implementing Cisco Identity Services Engine Secure Solutions v1.0

Visit www.globalknowledge.com or call 1-800-COURSES (1-800-268-7737) to speak with a Global Knowledge training advisor.

About the AuthorJim 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, the passion is a derivative of a need to understand the products he is engaged with and, with this understanding, he has attained the CCIE Security designation. He employs this deep understanding by contracting to Government Agencies (Federal, State, and Local) and Enterprise networks. He also takes a hands-on approach to learning. He is course director for the following courses: IPS, SSECMGT (CSM), NAC+, ISE, 802.1X and ACS 5.x. You can contact Jim at [email protected].




http://www.globalknowledge.com

mailto:[email protected]

802.1x explained - freelists · and androids to work requires some very tight security controls....

Documents