802.1X

Introduction

• EAP-MD5 - see later
• EAP-TLS - see later
• EAP-OTP - see later

• Supplicant � sits on a client device such as a laptop or PDA, the Supplicant is software that handles authentication from the client's point of view, it is also known as the Port Access Entity (PAE)
• Authenticator � edge network device such as an access switch, router or Wi-Fi access point. The Authenticator encapsulates the EAP frames within RADIUS.
• Authentication server � a RADIUS server with EAP capability

EAPOL Frame Format

• 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

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

• 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
  
  

  Extensible Authentication Protocol (EAP) and 802.1X

  
  
  The 802.1X standard is used to control port access, and there is a RADIUS extension for Extensible Authentication Protocol (EAP) which is a server plug-in used to give clients access to the RADIUS server. These allow interoperability between manufacturers when it comes to security. For each user device within the network, a username and password is stored in the RADIUS server, these are called the client Credentials. The user uses EAP over LAN (or Wi-Fi), and EAP over RADIUS with the RADIUS server and authenticates. The user and the RADIUS server such as Cisco ACS, FreeRADIUS or Steel Belted RADIUS (Juniper Networks), then negotiate a single-session, single-user encryption key. In a Wi-Fi environment this key is stored on the AP and this allows continuation of the session.
  
  

  Operation of 802.1X

  
  
  See below for the steps used to authenticate a client using 802.1X over a LAN, the colour orange represents that EAP is encapsulated within 802.1X whereas green represents EAP encapsulated within RADIUS. The EAP method can vary, however throughout the whole process the Authenticator is performing the relevant encapsulations:
  
  
  
  Below are the steps used to authenticate a client using 802.1X over Wi-Fi:
  
  
  
  So in general, the login credentials are sent by the supplicant to the Authenticator (e.g. access switch or Wi-Fi access point) which allows the user open authentication access only for 802.1X traffic. No other traffic is permitted. It is as if there are two virtual ports, one that allows 802.1X traffic only, and the other that is blocked for all other traffic until authentication is successful. The authenticator forwards the credentials (depending on the EAP method) on to the RADIUS server in RADIUS format which checks them against its database. In this manner the supplicant also checks the validity of the server too, thereby providing mutual authentication.
  
  
  
  

  Types of Extensible Authentication Protocol (EAP)

  
  
  There are a number of EAP methods, common ones are listed below and described in some detail:
  
  

  EAP-Transport Layer Security (EAP-TLS)

  
  
  TLS is Cryptographic-based and is devised as an alternative to SSL and can tie in to the NT/2000 and LDAP databases with a single login. TLS is an IETF open standard defined in RFC 2716. It is required that clients and servers have separate private certificates issued by a CA as part of a PKI. Refer to Encryption for information on PKI and CA servers. As well as the private certificates which are never shared with anyone except the CA, there is a public key which is shared. The CA has to be trusted by both parties (server and client). You can tie the Microsoft credentials for a user to the certificate of that user. This then permits a single log in to be implemented.
  
  
  You can set up both user and machine authentication. In this instance, multiple EAP transactions take place.
  
  
  TLS operates as follows:
  
  
  1. Either the supplicant sends a EAP Over LAN (EAPOL) start message or the authenticator sends an identity request message.
  2. The supplicant sends the Network Access Identifier (NAI) (not necessarily the username) to the authenticator along with the EAP type being used
  3. The NAI is encapsulated in a RADIUS access request message and sent on to the RADIUS server.
  4. An encrypted tunnel is required so the server sends its CA-issued certificate to the supplicant
  5. If the client trusts the certificate it uses it to encrypt the authentication messages
  6. The supplicant sends its user or/both machine certificate to the server
  7. The server authenticates the client and it sends encrypted data to the authenticator which now unblocks the port for the client.
  8. The client now receives the data to enable it to derive the session key.
  
  

  Protected EAP (PEAP)

  
  
  Tunnel-based Protected EAP (PEAP) is IETF draft so is standards-based and there are two versions. PEAP is limited to Windows NT/2000/XP/CE clients and its strength is that it protects the authentication mechanism by way of a certificate on the server side that is used to encrypt the exchange between the server and the client.
  
  
  • PEAP-MSCHAPv2 (Microsoft PEAP) can interact with NT/2000 and Active Directory (AD), also known as PEAP version 0. This can be used when there are multi-vendor devices on the network.
  • PEAP - Generic Token Card (PEAP-GTC) can interact with LDAP, One Time Password (OTP) and NDS authentication servers. Also known as PEAP version 1 it was developed by RSA and Cisco. PEAP v1 is not supported by Microsoft, only by Cisco Compatible Extensions (CCX).
  
  
  With a Generic token Card you have a OTP when you click, the password is generated on both the client and the token server, they are synchronized and never have to be typed in or sent across a non-secure link. Typically this password lasts for a couple of minutes (this time is configurable). The interface typically asks you to pick out certain characters of this password. OTP systems are developed by Secure computing SafeWord and RSA Security SecureID.
  
  
  PEAP operates as follows:
  
  
  1. Either the supplicant sends a EAP Over LAN (EAPOL) start message or the authenticator sends an identity request message.
  2. The supplicant sends the Network Access Identifier (NAI) (not necessarily the username) to the authenticator along with the EAP type being used
  3. The NAI is encapsulated in a RADIUS access request message and sent on to the RADIUS server.
  4. An encrypted tunnel is required so the server sends its TLS certificate to the supplicant
  5. If the client trusts the certificate it uses it to encrypt the authentication messages, the server is authenticated to the client
  6. The supplicant sends its TLS encrypted credentials (username and password) to the server, the client does not need a CA certificate
  7. The server authenticates the client and it sends encrypted data to the authenticator which now unblocks the port for the client.
  8. The client now receives the data to enable it to derive the session encryption key.
  
  

  Lightweight EAP (LEAP)

  
  
  Released late in 2000, LEAP was developed by Cisco to use Windows NT/2000 login format for the NT or Active Directory databases (user ID and password). LEAP is Challenge-Response-based. LEAP is also supported on the MAC and Linux and is implemented on many vendor Network Interface Cards so it has wide support. Supplicant support includes Cisco Secure Client (formerly Meetinghouse Aegis) and Funk Odyssey by Juniper Networks. LEAP supports fast roaming between APs i.e. the authentication takes less than 150ms.
  
  
  LEAP operates as follows:
  
  
  1. Either the supplicant sends a EAP Over LAN (EAPOL) start message or the authenticator sends an identity request message.
  2. The supplicant sends the username to the authenticator
  3. The username is encapsulated in a RADIUS access request message and sent on to the RADIUS server.
  4. The RADIUS server sends a clear text challenge to the supplicant via the authenticator
  5. The supplicant responds with the challenge but now the message is encrypted
  6. The RADIUS server sends a success or failure message back to the supplicant via the authenticator
  7. The supplicant sends a challenge to the RADIUS server via the authenticator
  8. The RADIUS server responds and also sends a dynamic key that is placed in the authenticator. This key is specific to the supplicant.
  9. The broadcast key is encrypted with the client encryption key and the decision is made to use 40-bit or 128-bit WEP keys. The broadcast key is sent to the client as a session key.
  
  
  The main issue is that the initial challenge is sent by the RADIUS server in clear text. Because the response is encrypted a dictionary attack could be performed using a tool such as ASLEEP. It is advisable to use 11 or more characters with alphanumeric and uppercase letters in order to mitigate against such an attack.
  
  

  EAP Flexible Authentication via Secure Tunnelling (EAP-FAST)

  
  
  EAP-FAST is Tunnel-based and was developed by Cisco in 2003 and is now defined in RFC 4851 so it is standards-based, although only supported on Windows operating systems. The need was to find a way around sending an initial clear text challenge. This is achieved by placing a Protected Access Credentials (PAC) on the client device. This PAC is used to authenticate the server and acts like a certificate. In addition, EAP-FAST can integrate with LDAP authentication, also permits Windows-initiated password changes using MSCHAPv2 as well as Cisco local authentication. EAP-FAST supports Fast Secure Roaming.
  
  
  1. The supplicant sends a start message to the authenticator
  2. The authenticator requests the identity i.e. the username and password
  3. The supplicant sends through its identity and this is forwarded on to the RADIUS server.
  
  
  Next there are three phases:
  
  
  Phase Zero (optional):
  1. An anonymous Diffe-Hellman key exchange (A-ID) occurs using EAP-MSCHAPv2, this results in the creation of a tunnel.
  2. On success, the RADIUS server provides the supplicant a PAC based on a master key. The key has a lifetime, so the PAC must be renewed regularly.
  
  
  The PAC could be manually placed on the client instead!
  
  
  Phase One:
  1. The supplicant sends the PAC to the server and a TLS tunnel is established based on this PAC, provided that it was based on an unexpired master key.
  
  
  Phase Two:
  1. Within the TLS tunnel the server authenticates the client credentials with EAP-Generic Token Card (EAP-GTC)
  2. The user is logged in the Passed Authentication Log
  3. When the client�s PAC is renewed then an additional entry appears in the Passed Authentication Log
  
  

  Other EAPs

  
  
  Other EAP types include the following:
  • EAP-MD5 - This is described within RFC 3748. EAP-MD5 is Challenge-Response-based. Points to make about EAP-MD5 is that the MD5 hash function is vulnerable to dictionary attacks, it doesn't support dynamic key generation and there is no mutual authentication so EAP-MD5 is vulnerable to 'man-in-the-middle' attacks.
  • EAP-OTP - The OTP mechanism is used extensively in VPN and PPP scenarios but not in the wireless world. EAP One Time Password is similar to EAP-MD5, except it uses the One-Time Password (OTP) as the response. The request contains a displayable message. The OTP method is defined in RFC 2289
  • EAP Pre-shared Key (EAP-PSK) - this is described in RFC 4764. EAP-PSK supports session key generation and mutual authentication so it is ideal for non-secure environments such as Wi-Fi when access to a CA is not practical.
  • EAP-Tunneled Transport Layer Security (EAP-TTLS) - this is Tunnel-based and is an enhancement to EAP-TLS where only the server needs to be authenticated to the client using a PKI CA-based certificate. Once the server is authenticated to the client, then the client can be authenticated to the server over a secure encrypted tunnel. Any EAP method may be used within this tunnel so you are able to implement EAP within EAP. EAP-TTLS is currently in draft form.
  • EAP-IKEv2 - this is based on the draft IKEv2 and may use asymmetric key pairs, symmetric key pairs and passwords.
  • EAP-SIM - this is EAP for Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM) and is defined in RFC 4186
  • EAP-AKA - EAP for UMTS Authentication and Key Agreement is used for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Universal Subscriber Identity Module (USIM). EAP-AKA is defined in RFC 4187

  References

  
  
  IEEE 802.1X-2020 standard.
  RFC 2284 describes PPP Extensible Authentication Protocol.
  RFC 2289 describes EAP-OTP
  RFC 2716 describes EAP-TLS
  RFC 2865 describes RADIUS
  RFC 2866 describes RADIUS Accounting
  RFC 3748 describes Extensible Authentication Protocol for IEEE 802.
  RFC 4186 describes EAP-SIM
  RFC 4187 describes EAP-AKA
  RFC 4851 describes EAP-FAST
  
  
  Home

  

  Disclaimer