Hostapd 802.1X authentication

1. Overview

When EAP is invoked by an 802.1X enabled NAS (Network Access Server) device such as an 802.11 a/b/g Wireless Access Point, modern EAP methods can provide a secure authentication mechanism and negotiate a secure PMK (Pair-wise Master Key) between the client and NAS. The PMK can then be used for the wireless encryption session which uses TKIP or AES encryption.

2. 802.1X basic components

• Supplicant -- A software client running on wireless client/station
  
• Authenticator --- Access point. In som case, access point can also act as authentication server as well.
  
• Authentication server-- a authentication database, usually a radius server, or microsoft IAS

EAP(extensible authentication protocol) is support on freeradius

• EAP-MD5 (Message Digest) Challenge is an EAP authentication type that provides base-level EAP support. EAP-MD-5 is typically not recommended for wireless LAN implementations because it may allow the user's password to be derived. It provides for only one way authentication - there is no mutual authentication of wireless client and the network. And very importantly it does not provide a means to derive dynamic, per session wired equivalent privacy (WEP) keys.
  
• EAP-TLS (Transport Layer Security) provides for certificate-based and mutual authentication of the client and the network. It relies on client-side and server-side certificates to perform authentication and can be used to dynamically generate user-based and session-based WEP keys to secure subsequent communications between the WLAN client and the access point. One drawback of EAP-TLS is that certificates must be managed on both the client and server side. For a large WLAN installation, this could be a very cumbersome task.
  
• EAP-TTLS (Tunneled Transport Layer Security) was developed by Funk Software and Certicom, as an extension of EAP-TLS. This security method provides for certificate-based, mutual authentication of the client and network through an encrypted channel (or "tunnel"), as well as a means to derive dynamic, per-user, per-session WEP keys. Unlike EAP-TLS, EAP-TTLS requires only server-side certificates.
  
• EAP-FAST (Flexible Authentication via Secure Tunneling) was developed by Cisco. Instead of using a certificate, mutual authentication is achieved by means of a PAC (Protected Access Credential) which can be managed dynamically by the authentication server. The PAC can be provisioned (distributed one time) to the client either manually or automatically. Manual provisioning is delivery to the client via disk or a secured network distribution method. Automatic provisioning is an in-band, over the air, distribution.
  
• LEAP (Lightweight Extensible Authentication Protocol), is an EAP authentication type used primarily in Cisco Aironet WLANs. It encrypts data transmissions using dynamically generated WEP keys, and supports mutual authentication. Heretofore proprietary, Cisco has licensed LEAP to a variety of other manufacturers through their Cisco Compatible Extensions program.
  
• PEAP (Protected Extensible Authentication Protocol) provides a method to transport securely authentication data, including legacy password-based protocols, via 802.11 wireless networks. PEAP accomplishes this by using tunneling between PEAP clients and an authentication server. Like the competing standard Tunneled Transport Layer Security (TTLS), PEAP authenticates wireless LAN clients using only server-side certificates, thus simplifying the implementation and administration of a secure wireless LAN. Microsoft, Cisco and RSA Security developed PEAP.

A review of the above discussions and table will usually provide the following conclusions:

• MD5 is not typically used as it only does a one-way authentication, and perhaps even more importantly does not support automatic distribution and rotation of WEP keys so does nothing to relieve the administrative burden of manual WEP key maintenance.
• TLS, while very secure, requires client certificates to be installed on each wireless workstation. Maintenance of a PKI infrastructure requires additional administrative expertise and time in addition to that of maintaining the WLAN itself.
• TTLS addresses the certificate issue by tunneling TLS, and thus eliminating the need for a certificate on the client side. Making this an often preferred option. TTLS is primarily promoted by Funk and there is a charge for supplicant and authentication server software.
• LEAP has the longest history, and while previously Cisco proprietary (works with Cisco wireless adapters only), Cisco has licensed LEAP to a variety of other manufacturers through their Cisco Compatible Extensions program. A strong password policy should be enforced when LEAP is used for authentication.
• EAP-FAST is now available for enterprises that cannot enforce a strong password policy and do not want to deploy certificates for authentication.
• The more recent PEAP works similar to EAP-TTLS in that it does not require a certificate on the client side. PEAP is backed by Cisco and Microsoft and is available at no additional cost from Microsoft. If desired to transition from LEAP to PEAP, Cisco's ACS authentication server will run both.
• PEAPv0/EAP-MSCHAPv2
• PEAPv1/EAP-GTC

Note:Note: The PEAP standard was created by Microsoft, Cisco, and RSA after EAP-TTLS had already come on the market. Even with its late start, Microsoft’s and Cisco’s size allowed them to quickly overtake EAP-TTLS in the market. Microsoft and Cisco parted ways when Microsoft only supported the PEAPv0 standard while Cisco supported both PEAPv0 and PEAPv1. PEAPv0 and PEAPv1 both refer to the outer authentication method and is the mechanism that creates the secure TLS tunnel to protect subsequent authentication transactions while EAP-MSCHAPv2, EAP-GTC, and EAP-SIM refer to the inner authentication method which facilitates user or device authentication. From Cisco’s perspective, PEAPv0 supports inner EAP methods EAP-MSCHAPv2 and EAP-SIM while PEAPv1 supports inner EAP methods EAP-GTC and EAP-SIM. Since Microsoft only supports PEAPv0 and doesn’t support PEAPv1, Microsoft simply calls PEAPv0 PEAP without the v0 or v1 designator. Another difference between Microsoft and Cisco is that Microsoft only supports PEAPv0/EAP-MSCHAPv2 mode but not PEAPv0/EAP-SIM mode. However, Microsoft supports another form of PEAPv0 (which Microsoft calls PEAP-EAP-TLS) that Cisco and other third-party server and client software don’t support. PEAP-EAP-TLS does require a client-side digital certificate located on the client’s hard drive or a more secure smartcard. PEAP-EAP-TLS is very similar in operation to the original EAP-TLS but provides slightly more protection due to the fact that portions of the client certificate that are unencrypted in EAP-TLS are encrypted in PEAP-EAP-TLS. Since few third-party clients and servers support PEAP-EAP-TLS, users should probably avoid it unless they only intend to use Microsoft desktop clients and servers. Ultimately, PEAPv0/EAP-MSCHAPv2 is the only form of PEAP that most people will ever know. PEAP is so successful in the market place that even Funk Software, the inventor and backer of EAP-TTLS, had no choice but to support PEAP in their server and client software for wireless networks.