OK. Let me dive straight into the subject without any preamble. You landed on this page because you are not very clear on what these are and more importantly, how these technologies work together and what do they achieve in today's security landscape. Let me first give you an overview of these and then show you how they work hand-in-hand to achieve what they are made to achieve.
Before anything, I assume that you are a network/security engineer/architect and have a good understanding of basic networking and security technologies.
Please note that what I have explained is a lot simplified versions, so that you understand the basic concepts behind these technologies. In real life networks, there will be more complex exchange of messages and more advanced features might be implemented. I have not covered these in this blog. This blog aims to give you just the basic concepts behind these technologies.
Please note that what I have explained is a lot simplified versions, so that you understand the basic concepts behind these technologies. In real life networks, there will be more complex exchange of messages and more advanced features might be implemented. I have not covered these in this blog. This blog aims to give you just the basic concepts behind these technologies.
IEEE 802.1X
IEEE 802.1X is a port-based authentication mechanism. Let me explain what it means. You walk up to your desk on Monday morning at 8:00 AM and connect your laptop to the RJ-45 plug in your cubicle. Voila, you are on the corporate network and start your day's work; viewing your e-mails, surfing the Internet, processing orders for your company etc. How did this happen? The moment you connect your laptop to the switchport, say Gi1/3, the switch immediately granted you access to the corporate network. Your corporate network does not recognize you, from what device (Windows PC or Mac OS or Linux etc.) are you connecting etc. This is what happens when IEEE 802.1X authentication is not enabled on the switch. Absolutely no security, no questions asked, the switch simply connects you to the corporate network.
Wouldn't it be nice for the switch (and hence the network) to know who the user that is connecting to Gi1/3, so that the network can apply appropriate network security policies pertaining to that user? If the user is Sam from HR, then the network can dynamically put that switchport in VLAN 30 (the HR VLAN) and apply an ACL (the HR ACL) that will only allow him to access the HR payroll database and not the Financial Forecast data of your organization. Wouldn't this be a more secure way to provide network access to your employees instead of simply granting full access to anyone? You agree, right? Great. Now the question is, how will the network know about the user sitting behind the device? This is where IEEE 802.1X comes into the picture.
IEEE 802.1X is an authentication framework that helps the network to gather user information from the devices such as Windows PCs etc. and also control (open and close) the switchport where the user is connected. This is how it works:
IEEE 802.1X has three entities for it to function;
The Supplicant: This is a small piece of software that resides on the endpoints such as Windows PC. This piece of software will recognize the IEEE 802.1X authentication request messages from the switch
The Authenticator: This is the network device where the PC gets connected to. In our case, this is the access layer switch. For wireless connectivity, this will be the Wireless LAN Controller or an Access Point.
The Authentication Server: This is the server that is responsible for making the authentication decisions and also decides the level of access (VLAN, ACL etc.) to be granted to a user. This is typically a RADIUS Server residing somewhere in the Data Center. This server is the one that has the user credentials (such as username, password etc.) and also has the authorization level to be granted to the users (or user groups).
OK. Its time to put all this together. Once the switch is enabled for 802.1X authentication, the switchports will be in an 'unauthorized' (closed) state and no data traffic can pass through the switchport. The port will move to an 'authorized' state after the user successfully authenticates with the authentication server. The port will allow data traffic to pass through it in the authorized state. This is analogous to putting a security guard at the front door of your office. If someone walks up to your office, he/she will have to prove his/her identity before the security guard opens the door for him/her. If they cannot prove their identity, the security guard keeps the door closed. This prevents unauthorized access to your office. IEEE 802.1X provides similar security to you network and prevents unauthorized access to your network.
Simple, right? Now let's look at the sequence of events that take place when someone, say Sam, tries to connect to the network Monday morning at 8:00 AM. We will assume that Sam's credentials are already present in the authentication server.
1. User Sam connects his laptop to the switch and the link between the switch and the laptop comes up. (show interface Gi1/3 will show hardware up and line protocol up on the switch side)
2. Because the switch is enabled for 802.1X, the port is in an 'unauthorized' state and does not permit any traffic through it, even DHCP packets. The switch now requests the laptop to provide the identity of the user. This request message is conveyed to the laptop through the EAP-Request/Identity message. EAP messages are sent over Layer 2 frames called EAPOL frames (EAPoverLAN) and hence no IP address is needed for this communication. Remember, at this point, the laptop does not have an IP address. (Don't worry about EAP now, I have explained it later in this blog)
3. Even though the laptop does not have an IP address yet, its NIC card is up and active. (see step 1). Therefore, it can receive Layer 2 frames from the switch. The laptop is running IEEE 802.1X supplicant, which recognizes the EAP Request/Identity message from the switch. (Note: If the laptop does not run 802.1X supplicant, it would not recognize EAP messages and would simply drop them). After receiving the EAP-Request/Identity message, the supplicant running in the laptop will prompt the user for a username and password. Sam will type in his username and password and click submit.
4. The supplicant will take the username/password and pass them on to the switch in the EAP-Response/Identity message. This message is also carried over EAPOL Layer 2 frames. Even though the switch port is in an 'unauthorized' state, it will receive EAPOL frames. EAPOL frames are the only frames the switch will allow in the "unauthorized" state.
5. The switch being the authenticator, does not have the user credentials to verify Sam's username and password. The username/password should be sent to the authentication server for validation. To do this, the switch will encapsulate the EAP-Response/Identity message into a RADIUS Access_Request message and sends it to the authentication server. Here the switch is the RADIUS Client and the authentication server is the RADIUS server. RADIUS works over UDP/IP and therefore can easily communicate over the Corporate Network. (See below for overview on RADIUS)
6. After receiving the RADIUS Access_Request message from the switch, the authentication server will extract the username/password from the message and will attempt to validate the username/password combination. This validation can be done by the authentication server itself if it has the user credentials or it can take help from external sources such as Microsoft Active Directory or LDAP server.
7. If the authentication succeeds (that is, Sam supplied his username and password correctly), the authentication server will convey the results of the authentication to the switch through RADIUS Access_Accept Message.
8. On getting the RADIUS Access_Accept message from the authentication server, the switch knows that the authentication was successful and will now move the port where Sam's laptop is connected from "unauthorized" state to "authorized" state. Remember, the port will pass traffic normally only in an "authorized" state. The switch then conveys the good news to the supplicant through the EAP Success message.
9. After receiving the EAP success message, the supplicant knows that the authentication was successful and it starts sending data over the connection to the switch. Remember, until this point, the supplicant was holding all communication from the laptop, including the DHCP requests. Now the laptop can send DHCP request to obtain an IP address and then happily communicates with the rest of the network.
10. The port will remain in the "authorized" state as long as Sam stays connected to that switchport. If Sam disconnects his laptop to go home, the line will go into down/down state and the switch port will move to the "unauthorized" state. If Sam connects back again to the same (or different port), all the steps from 1 to 9 will be repeated before he can access the network.
11. In step 7, if authentication had failed, that is, Sam had not supplied his password correctly, the authentication server will send RADIUS Access-Reject message to the switch. Upon receiving this message, the switch will keep the port in "unauthorized" state and will convey the bad news to the supplication through the EAP Failure message. Upon receiving EAP-Failure message, the supplicant knows that the authentication wasn't successful and will attempt to authenticate again. It will continue to hold any IP communication until it receives an EAP Success message.
2. Because the switch is enabled for 802.1X, the port is in an 'unauthorized' state and does not permit any traffic through it, even DHCP packets. The switch now requests the laptop to provide the identity of the user. This request message is conveyed to the laptop through the EAP-Request/Identity message. EAP messages are sent over Layer 2 frames called EAPOL frames (EAPoverLAN) and hence no IP address is needed for this communication. Remember, at this point, the laptop does not have an IP address. (Don't worry about EAP now, I have explained it later in this blog)
3. Even though the laptop does not have an IP address yet, its NIC card is up and active. (see step 1). Therefore, it can receive Layer 2 frames from the switch. The laptop is running IEEE 802.1X supplicant, which recognizes the EAP Request/Identity message from the switch. (Note: If the laptop does not run 802.1X supplicant, it would not recognize EAP messages and would simply drop them). After receiving the EAP-Request/Identity message, the supplicant running in the laptop will prompt the user for a username and password. Sam will type in his username and password and click submit.
4. The supplicant will take the username/password and pass them on to the switch in the EAP-Response/Identity message. This message is also carried over EAPOL Layer 2 frames. Even though the switch port is in an 'unauthorized' state, it will receive EAPOL frames. EAPOL frames are the only frames the switch will allow in the "unauthorized" state.
5. The switch being the authenticator, does not have the user credentials to verify Sam's username and password. The username/password should be sent to the authentication server for validation. To do this, the switch will encapsulate the EAP-Response/Identity message into a RADIUS Access_Request message and sends it to the authentication server. Here the switch is the RADIUS Client and the authentication server is the RADIUS server. RADIUS works over UDP/IP and therefore can easily communicate over the Corporate Network. (See below for overview on RADIUS)
6. After receiving the RADIUS Access_Request message from the switch, the authentication server will extract the username/password from the message and will attempt to validate the username/password combination. This validation can be done by the authentication server itself if it has the user credentials or it can take help from external sources such as Microsoft Active Directory or LDAP server.
7. If the authentication succeeds (that is, Sam supplied his username and password correctly), the authentication server will convey the results of the authentication to the switch through RADIUS Access_Accept Message.
8. On getting the RADIUS Access_Accept message from the authentication server, the switch knows that the authentication was successful and will now move the port where Sam's laptop is connected from "unauthorized" state to "authorized" state. Remember, the port will pass traffic normally only in an "authorized" state. The switch then conveys the good news to the supplicant through the EAP Success message.
9. After receiving the EAP success message, the supplicant knows that the authentication was successful and it starts sending data over the connection to the switch. Remember, until this point, the supplicant was holding all communication from the laptop, including the DHCP requests. Now the laptop can send DHCP request to obtain an IP address and then happily communicates with the rest of the network.
10. The port will remain in the "authorized" state as long as Sam stays connected to that switchport. If Sam disconnects his laptop to go home, the line will go into down/down state and the switch port will move to the "unauthorized" state. If Sam connects back again to the same (or different port), all the steps from 1 to 9 will be repeated before he can access the network.
11. In step 7, if authentication had failed, that is, Sam had not supplied his password correctly, the authentication server will send RADIUS Access-Reject message to the switch. Upon receiving this message, the switch will keep the port in "unauthorized" state and will convey the bad news to the supplication through the EAP Failure message. Upon receiving EAP-Failure message, the supplicant knows that the authentication wasn't successful and will attempt to authenticate again. It will continue to hold any IP communication until it receives an EAP Success message.
EAP (Extensible Authentication Protocol)
Now, for EAP, I am going to keep it really simple. In the above example, Sam authenticated to the network using his username and password. Is that the only way a user can authenticate? How about using a Digital Certificate or even biometric methods? Different organizations use different ways to authenticate users. Also, why did the authentication server agree to authenticate using username/password? Why not using Digital Certificates? How did the supplicant and the authentication server agree to use username/password for authentication? This is where EAP comes into the picture. EAP tells how exactly the supplicant will authenticate to the authentication server.
In real networks, the supplicant and the authentication server must first negotiate and agree on a method (username/password, Digital Certificates, OTP etc.) to authenticate the user. Only if they both agree on a common method, the authentication process will move to the next step. For example, if the supplicant is configured to use username/password to authenticate and the authentication server is configured for Digital Certificate based authentication only, then the negotiations will fail.
You configure an EAP method on the supplicant and the authentication server must also support the same EAP method. (The authentication server might support more than one EAP methods to support different types of clients). There are many EAP methods available, but I list some of the common ones here:
EAP-TLS - Used for Certificate based authentication
PEAP-MSCHAPv2 - Used in username/password based authentication in Microsoft environments
If you noticed, in the above example, the actual authentication was happening between the supplicant and the authentication server. The switch (the authenticator) was just acting as an intermediate device simply encapsulating the EAP messages into RADIUS messages. The switch does not care how the supplicant authenticates to the authentication server, it is only interested in the results (Access_Accept or Access_Reject) of the authentication. In other words, the switch does not care what EAP methods the supplicant and the authentication server negotiates. In fact, there is no need to configure or enable EAP on the authenticator (the switch/WLC). It is enabled and configured only on the supplicant and the authentication server.
RADIUS (Remote Authentication for Dial-In User Service)
First of all, let's understand why is RADIUS protocol called so.
Around 15 years ago, as a home user in India, I used PSTN (the phone network) to connect to the Internet. My PC was connected to a modem, which in turn was connected to the PSTN network. The other end of the PSTN also had a modem (modem bank to be precise) and the modem was connected to a router (or Network Access Server, NAS), as shown.
Here is the sequence of events that took place before I could access the Internet from my home.
1. From my PC, using the software provided to me by my ISP, I dial-in to my ISP's modem and get connected to the Network Access Server (NAS) on the remote end. NAS is a router.
2. A PPP (Point-to-Point) connection is established between my PC and the NAS. The NAS prompts me for username and password, which I type on my PC's console.
3. Through PPP, the NAS collects my username/password. Using the RADIUS protocol, it verifies my credentials with a RADIUS server to make sure that I am a paid customer of the ISP. My username/password was added to the RADIUS server database at the time I purchased the service.
4. The NAS being the RADIUS Client here, uses RADIUS Access_Request message to pass on my credentials to the RADIUS server. If my credentials are valid, the RADIUS server replies with the RADIUS Access_Accept message to the NAS.
5. Upon receiving the RADIUS Access_Accept message, the NAS connects me to the Internet. I browse happily thereafter.
6. If my credentials are not valid, the RADIUS server replies with the RADIUS Access_Reject message and NAS does not connect me to the Internet. I had to repeat the authentication until I supply the correct credentials. What a sad day!
This is how RADIUS was used in olden days. RADIUS is a very mature protocol and has been there for more than 25 years. It was used to authenticate remote dial-in users (like me in this example) and hence the name.
Even though we don't use dial-in technology that much today, the RADIUS protocol is still used in the same way today. The only thing that has changed is that instead of PPP we are using IEEE 802.1X to get the credentials from the client.
RADIUS is a very simple client-server protocol and has only 4 basic messages.
1. Access_Request - This message always goes from the client to the server, requesting to start an authentication process. This message is also used to convey any additional parameters to the server from the client. This message is also used during the EAP negotiations.
2. Access_Challenge - This message always goes from the server to the client, when the server needs any additional information from the client, such as requesting a digital certificate etc. This message is also used during the EAP negotiations.
3. Access_Accept - This message conveys that the authentication request was successful and always goes from the server to the client.
4. Access_Reject - This message conveys that the authentication request was not successful and always goes from the server to the client.
Summary
In summary,
IEEE 802.1X specifies that the authentication is needed for the switch to "authorize" (open) the port and helps in getting the credentials from the supplicant.
EAP decides how the supplicant and the authentication server should authenticate. The authenticator (switch) is only interested in the outcome of the authentication, not in how exactly the supplicant authenticates to the authentication server. There is no need to enable EAP on the authenticator. It is enabled only on the supplicant and the authentication server, with at least one common EAP method.
RADIUS is the protocol that is used between the authenticator (switch) and the authentication server such as Cisco ISE or Microsoft RADIUS server.
Always Remember;
1. The supplicant and the authentication server should be configured/enabled with at least one common EAP method.
2. The authenticators are not configured or enabled with any EAP method because they are not interested in what EAP method was used in authentication, but only interested in the outcome of the authentication process.
3. Your laptop or the PC is not the RADIUS client. Your authenticator (switch/WLC) is the RADIUS client. Your PC/laptop does not run RADIUS. They only run the IEEE 802.1X supplicant.
4. If your laptop/PC is enabled for IEEE 802.1X supplicant, it can communicate with the switch even if the switch port is in an "unauthorized" state. Remember, an unauthorized port can send and receive Layer 2 EAPOL frames.
5. IEEE 802.1X/EAP/RADIUS works almost in a similar fashion on wireless networks, with some minor changes. I will explain this in a separate blog.
I hope you enjoyed reading this and hopefully got some basic understanding. Please feel free to share your thoughts and comments. Also if you find any mistakes or room for improving this blog, please let me know.
Have a Great Day!!!
In real networks, the supplicant and the authentication server must first negotiate and agree on a method (username/password, Digital Certificates, OTP etc.) to authenticate the user. Only if they both agree on a common method, the authentication process will move to the next step. For example, if the supplicant is configured to use username/password to authenticate and the authentication server is configured for Digital Certificate based authentication only, then the negotiations will fail.
You configure an EAP method on the supplicant and the authentication server must also support the same EAP method. (The authentication server might support more than one EAP methods to support different types of clients). There are many EAP methods available, but I list some of the common ones here:
EAP-TLS - Used for Certificate based authentication
PEAP-MSCHAPv2 - Used in username/password based authentication in Microsoft environments
If you noticed, in the above example, the actual authentication was happening between the supplicant and the authentication server. The switch (the authenticator) was just acting as an intermediate device simply encapsulating the EAP messages into RADIUS messages. The switch does not care how the supplicant authenticates to the authentication server, it is only interested in the results (Access_Accept or Access_Reject) of the authentication. In other words, the switch does not care what EAP methods the supplicant and the authentication server negotiates. In fact, there is no need to configure or enable EAP on the authenticator (the switch/WLC). It is enabled and configured only on the supplicant and the authentication server.
RADIUS (Remote Authentication for Dial-In User Service)
First of all, let's understand why is RADIUS protocol called so.
Around 15 years ago, as a home user in India, I used PSTN (the phone network) to connect to the Internet. My PC was connected to a modem, which in turn was connected to the PSTN network. The other end of the PSTN also had a modem (modem bank to be precise) and the modem was connected to a router (or Network Access Server, NAS), as shown.
1. From my PC, using the software provided to me by my ISP, I dial-in to my ISP's modem and get connected to the Network Access Server (NAS) on the remote end. NAS is a router.
2. A PPP (Point-to-Point) connection is established between my PC and the NAS. The NAS prompts me for username and password, which I type on my PC's console.
3. Through PPP, the NAS collects my username/password. Using the RADIUS protocol, it verifies my credentials with a RADIUS server to make sure that I am a paid customer of the ISP. My username/password was added to the RADIUS server database at the time I purchased the service.
4. The NAS being the RADIUS Client here, uses RADIUS Access_Request message to pass on my credentials to the RADIUS server. If my credentials are valid, the RADIUS server replies with the RADIUS Access_Accept message to the NAS.
5. Upon receiving the RADIUS Access_Accept message, the NAS connects me to the Internet. I browse happily thereafter.
6. If my credentials are not valid, the RADIUS server replies with the RADIUS Access_Reject message and NAS does not connect me to the Internet. I had to repeat the authentication until I supply the correct credentials. What a sad day!
This is how RADIUS was used in olden days. RADIUS is a very mature protocol and has been there for more than 25 years. It was used to authenticate remote dial-in users (like me in this example) and hence the name.
Even though we don't use dial-in technology that much today, the RADIUS protocol is still used in the same way today. The only thing that has changed is that instead of PPP we are using IEEE 802.1X to get the credentials from the client.
RADIUS is a very simple client-server protocol and has only 4 basic messages.
1. Access_Request - This message always goes from the client to the server, requesting to start an authentication process. This message is also used to convey any additional parameters to the server from the client. This message is also used during the EAP negotiations.
2. Access_Challenge - This message always goes from the server to the client, when the server needs any additional information from the client, such as requesting a digital certificate etc. This message is also used during the EAP negotiations.
3. Access_Accept - This message conveys that the authentication request was successful and always goes from the server to the client.
4. Access_Reject - This message conveys that the authentication request was not successful and always goes from the server to the client.
Summary
In summary,
IEEE 802.1X specifies that the authentication is needed for the switch to "authorize" (open) the port and helps in getting the credentials from the supplicant.
EAP decides how the supplicant and the authentication server should authenticate. The authenticator (switch) is only interested in the outcome of the authentication, not in how exactly the supplicant authenticates to the authentication server. There is no need to enable EAP on the authenticator. It is enabled only on the supplicant and the authentication server, with at least one common EAP method.
RADIUS is the protocol that is used between the authenticator (switch) and the authentication server such as Cisco ISE or Microsoft RADIUS server.
Always Remember;
1. The supplicant and the authentication server should be configured/enabled with at least one common EAP method.
2. The authenticators are not configured or enabled with any EAP method because they are not interested in what EAP method was used in authentication, but only interested in the outcome of the authentication process.
3. Your laptop or the PC is not the RADIUS client. Your authenticator (switch/WLC) is the RADIUS client. Your PC/laptop does not run RADIUS. They only run the IEEE 802.1X supplicant.
4. If your laptop/PC is enabled for IEEE 802.1X supplicant, it can communicate with the switch even if the switch port is in an "unauthorized" state. Remember, an unauthorized port can send and receive Layer 2 EAPOL frames.
5. IEEE 802.1X/EAP/RADIUS works almost in a similar fashion on wireless networks, with some minor changes. I will explain this in a separate blog.
I hope you enjoyed reading this and hopefully got some basic understanding. Please feel free to share your thoughts and comments. Also if you find any mistakes or room for improving this blog, please let me know.
Have a Great Day!!!
No comments:
Post a Comment
Please feel free to leave your comments here: