IEEE 802.1X (dot1x) Port Based Authentication

In a large network environment consisting of large number of computers spanned over multiple buildings (For example, a university campus) it is difficult to monitor all the network end points. A network attacker can attach his laptop loaded with all different hacking tools to an enabled network port located at a corner of a building and start attacking the network.

IEEE 802.1X (dot1x) Port-Based Authentication can be used to prevent unauthorised devices from gaining access to the network. IEEE 802.1X (dot1x) Port-Based Authentication can allow network access for a device attached to a network port if the authentication process succeeded and prevent access to that port if the authentication process failed. IEEE 802.1X (dot1x) standards can provide authentication and authorization services at network port level. Main components of IEEE 802.1X (dot1x) Port-Based Authentication are listed below.

The protocol used for communication between Supplicant and Authenticator is EAPoL. The protocol used for communication between Authenticator and Authentication Server is RADIUS.
EAPoL is a Layer 2 protocol.

Supplicant, Authenticator and Authentication Server

1) Supplicant: Supplicant is a network device which collects authentication credentials from end user and forwards those credentials for authentication process. Example: A software application running on a laptop attached to a network port or an Operating system related process running on that laptop.

2) Authenticator: Authenticator is a network access device which collects the authentication credentials from the Supplicant and relay those credentials to the Authentication Server for verification. (Switch or wireless AP).

3) Authentication Server: Authentication Server is a network server that validates the credentials sent by the supplicant based on the information stored in its database and determines whether to allow network access or prevent network access to the Supplicant. Authentication Server can be any RADIUS Server.

IEEE 802.1X (dot1x) Authentication Protocols - EAPoL (Extensible Authentication Protocol over LAN) and RADIUS The protocol used for communication between Supplicant and Authenticator is EAPoL. The protocol used for communication between Authenticator and Authentication Server is RADIUS. 1) Extensible Authentication Protocol (EAP): In an wired Ethernet network, IEEE 802.1X (dot1x) uses the Extensible Authentication Protocol over LAN (EAPoL) to exchange messages during the authentication process. EAPoL (Extensible Authentication Protocol over LAN) is used to transport EAP packets between Supplicant and an Authenticator over Local Area Network (LAN). There are different Extensible Authentication Protocol (EAP) Authentication Methods are available. Extensible Authentication Protocol (EAP) Authentication Methods are used in the Extensible Authentication Protocol (EAP) Authentication process. Common EAP Authentication methods used in IEEE 802.1X (dot1x) are EAP-TLS (EAP-Transport Layer Security) and PEAP-MSCHAPv2 (Protected EAP-Microsoft Challenge Handshake Authentication Protocol version) 2) RADIUS (Remote Authentication Dial-in User Service): The protocol used for communication between Authenticator and Authentication Server is RADIUS. RADIUS (Remote Authentication Dial-in User Service) is all-vendor supported AAA protocol. RADIUS was first developed by Livingston Enterprises Inc in 1991, which later merged with Alcatel Lucent. RADIUS later became an Internet Engineering Task Force (IETF) standard. Some RADIUS server implementations use UDP port 1812 for RADIUS authentication and UDP port 1813 for RADIUS accounting. Some other implementations use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting. ################################################################################## How IEEE 802.1X (dot1x) Port Based Authentication works: For deatails explanation with packet captures go through the below link: http://www.omnisecu.com/tcpip/how-ieee-802.1x-port-based-authentication-works.php http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.h ################################################################################## Understanding 802.1X The 802.1X is a specification that defines EAP (Extensible Authentication Protocol) over LAN. This is also known as EAPOL. EAP is an authentication framework with supports multiple authentication methods. It is defined in RFC 3748. EAP defines three terminologies: Supplicant: A device (usually workstation) that requests access to the LAN and switch services. The workstation running the IEEE802.1X-compliant client software is called the Supplicant. Authenticator: A device (a switch or a wireless access point) that controls the physical access to the network based on the authentication status of the Supplicant. The Authenticator requests the identity from the Supplicant, verifies that information with the Authentication Server and relays the response to the Supplicant. The Authenticator includes the RADIUS Client. The EAP messages are encapsulated and decapsulated by the Authenticator while interacting with the Authentication Server. Authentication Server: A device that performs the actual authentication of the Supplicant. The Authentication Server validates the identity of the Supplicant and notifies the Authenticator whether the Supplicant is allowed to use the LAN and switch services. The type of EAP method used will be decided between the Supplicant and the Authentication Server. Some of these methods are- LEAP, EAP-TLS, EAP-MD5, EAP-FAST, EAP-GTC, PEAP, etc. EAP over LAN (EAPOL):EAPoL is a Layer 2 protocol. EAPOL is a method to transport EAP packets between Supplicant and an Authenticator directly over LAN MAC service (both wired and wireless). There are 5 types of EAPOL message and not all EAPOL frames carry EAP messages; they are used for administrative tasks: EAPOL-Start: When the Supplicant first connects to the LAN, it does not know the MAC address of the Authenticator (if any). By sending the EAPOL-Start message to a multicast group, the Supplicant can find out if there is any Authenticator present. EAPOL-Key: Using this message type, the Authenticator sends encryption (and other) keys to the Supplicant once it has decided to admit it to the network.  EAPOL-Packet: This EAPOL frame is used to send actual EAP messages. It is simply a container to send EAP message across LAN. EAPOL-Logoff: This message indicates that the Supplicant wishes to be disconnected from the network.  EAPOL-Encapsulated-ASF-Alert: This is provided for use by Alert Standard Forum (ASF) to allow alerts to be forwarded through a port that is in Unauthorized state. All EAPOL frames have Ether Type of 0x888E. Authentication Process and Message Exchange: During bootup, if the Supplicant does not receive EAP-Request/Identity message from the Authenticator, the Supplicant initiates authentication by sending the EAPOL-Start frame, which prompts the router to request the Supplicant's identity. If the Authenticator port connected to the Supplicant is not configured with dot1x port-control auto command, the Authenticator will not allow any EAPOL frames to pass through it and the port will remain in Unauthorized state. The Supplicant and the Authenticator begin the conversation by negotiating the use of EAP. Once EAP is negotiated, the Authenticator sends an EAP-Request/Identity message to the Supplicant. The Supplicant supplies the EAP-Response/Identity message indicating to the Authenticator that it should proceed with authentication. The Authenticator acts as a pass-through and encapsulates the EAP-Response within an EAP-message attribute sent to the Authentication Server (RADIUS Server) within a RADIUS Access-Request message. On receiving an Access-Request message, the RADIUS server responds with an Access-Challenge message containing EAP-Message attribute. If the RADIUS server does not support EAP, it sends an Access-Reject message. The Authenticator receives the Access-Challenge message, decapsulates the packet and passes onto the Supplicant as an EAP-Request/Auth message. The Supplicant responds back with an EAP-Response/Auth message to the Authenticator. The Authenticator encapsulates it with an Access-Request packet containing EAP-Message attributes and passes onto the RADIUS Server. The RADIUS Server decapsulates the packet and obtains the EAP-Message attribute. It responds back with an Access-Accept packet. The Authenticator decapsulates and forwards the EAP-Success message to the Supplicant.  The authentication process at this stage is completed and the port state changes to Authorized. The port state changes to Unauthorized when the link state on the port changes from UP to DOWN, or, the Authenticator receives an EAPOL-Logoff message.

EAPOL Frame Format

The EAPOL frame sits within an Ethernet frame after the LLC field and has the following structure:

• Code - this has 8 bits, it identifies the type of EAP packet and can have the following EAP code numbers:
• 1 - Request
• 2 - Response
• 3 - Success
• 4 - Failure
• Identifier - this has 8 bits and matches Responses with Requests, it can have the following values:
• 0 - EAP Packet, Both the supplicant and the authenticator send this packet, It is used during authentication and contains MD5 or TLS information required to complete the authentication process
• 1 - EAPOL Start, Send by supplicant when it starts authentication process
• 2 - EAPOL Logoff, Send by supplicant when it wants to terminate the 802.1x session
• 3 - EAPOL Key, Send by switch to the supplicant and contains a key used during TLS authentication
• Length - The Length field is 16 bits and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields.

RADIUS Packet Format

Remote Authentication Dial In User Service (RADIUS) is defined in RFC2865 (which obsoletes RFC2138) and RADIUS Accounting is defined in RFC2866 (which obsoletes RFC2139).

RADIUS concerns itself with AAA management of network access and is the transport for EAP between the Authenticator and the Authentication server. In addition, RADIUS is also used to carry policy instructions back to the Authenticator in the form of AV pairs.

• Authentication - A client sends a access request to the network at link layer. This request contains user credentials or a user certificate. The authenticator packages this in RADIUS format as an Access Request message and forwards it on to a RADIUS server. The RADIUS server checks its user database for a match and then consequently decides whether or not to authenticate the user. The messages used are either Access Reject, Access Challenge (ask more information) or Access Accept.
• Authorisation - The RADIUS server stipulates the terms of access for the user i.e. what the user is permitted to do on the network.
• Accounting - If user access statistics and information are required then RADIUS accounting is enabled by the Authenticator issuing an Accounting Start Request to the RADIUS server. Subsequent Interim Accounting Records may also be sent to indicate information such as the duration of the user session. Accounting is halted when an Accounting Stop Record is sent to the server.

The RADIUS protocol uses UDP ports 1812 for Authorisation and 1813 for Accounting as standard. Originally these ports were 1645 for Authorisation and 1646 for Accounting and are still used today, therefore RADIUS servers look out for both sets of ports.

The RADIUS Datagram has the following structure:

• Code - indicates the type of RADIUS packet
• 1 - Access-Request
• 2 - Access-Accept
• 3 - Access-Reject
• 4 - Accounting-Request
• 5 - Accounting-Response
• 11 - Access-Challenge
• 12 - Status-Server (experimental)
• 13 - Status-Client (experimental)
• 255 - Reserved
• Identifier - matches request with response
• Length - indicates the length of the whole packet which may vary between 20 and 4096 bytes
• Authenticator - contains the information that the client and server use to authenticate each other
• Attributes - this field contains specific authentication, authorisation, information, plus configuration details for RADIUS packets
• Type - this is the type of attribute and take one of the following numbers (192 to 255 are reserved):
• 1 - User-Name
• 2 - User-Password
• 3 - CHAP-Password
• 4 - NAS-IP-Address
• 5 - NAS-Port
• 6 - Service-Type
• 7 - Framed-Protocol
• 8 - Framed-IP-Address
• 9 - Framed-IP-Netmask
• 10 - Framed-Routing
• 11 - Filter-ID
• 12 - Framed-MTU
• 13 - Framed-Compression
• 19 - Reply-Message
• 24 - State
• 25 - Class
• 26 - Vendor-Specific
• 27 - Session-Timeout
• 28 - Idle-Timeout
• 29 - Termination-Action
• 32 - NAS-Identifier
• 61 - NAS-Port-Type
• 62 - Port-Limit
• Length - the length of the attribute
• Value - the size of this field varies and contains specific information on the attribute. The structure of a Vendor Specific Attribute (VSA) is as follows:
• Type - this is set as 0x1A
• Length - length of the VSA in bytes
• Vendor-ID - constructed as 0x00SSSSSS where the 'S' numbers represent the Structure and Identification of Management Information (SMI) Network Management Private Enterprise Code of the vendor
• String - this contains a 1 byte Vendor Type field, a 1 byte Vendor Length field and a variable Attribute-Specific field contains the data for the specific vendor attribute.

The list of RADIUS attributes is by no means exhaustive, more information can be found from RFC 2865 and RFC 2866

For Further reading please see the below links also:

1. http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius
2. http://www.ciscopress.com/articles/article.asp?p=369223&seqNum=2
3. http://www.ietf.org/rfc/rfc3579.txt
4. http://etutorials.org/Networking/802.11+security.+wi-fi+protected+access+and+802.11i/Part+II+The+Design+of+Wi-Fi+Security/Chapter+8.+Access+Control+IEEE+802.1X+EAP+and+RADIUS/EAPOL/
5. http://packetlife.net/blog/2008/aug/6/simple-wired-8021x-lab/

For A Quick Overview Go through the Below Vedio: