Extensible Authentication Protocol and 802.

1X

Extensible Authentication Protocol and 802.1X are protocols, now becoming widely available in
standard products, that allow a user to be authenticated to the network infrastructure before
obtaining a connection. They provide very effective access control to wireless and other networks.

The Extensible Authentication Protocol (EAP)

EAP is a very simple protocol. The party demanding authentication is called the authenticator. The party
being authenticated is called the peer. An EAP exchange consists mainly of requests issued by the
authenticator and responses returned by the peer. Each request and response contains an EAP type field (a
synonym is EAP method) which indicates the type of data being carried. Finally, success and failure
packets are used by the authenticator to indicate the authentication result to the peer.

The EAP specification defines three basic authentication types: MD5-Challenge, OTP, and GTC. Three
further types are defined. Identity is used to determine the user name claimed by the peer. Nak is used by
the peer to indicate that a type proposed by the authenticator is unacceptable (for example, unsupported by
the peer). Notification, which is rarely used, returns a message that must be displayed to the user.

A final aspect of EAP is pass-through authentication. With pass-through authentication the authenticator
issues the first Request to the peer but, instead of processing the Response returned by the peer, it forwards
it to an EAP server for processing. This server then assumes the role of the authenticator. The advantage of
pass-through authentication is that authentication for an entire network can be performed by a single
central EAP server. The RADIUS protocol is used to transport the EAP packets between the authenticator
to an EAP server (which is generally a RADIUS server). Another advantage is that the authenticator does
not need to “support” the type negotiated by the peer and the EAP server; it is totally transparent.

802.1X Port-based network access control

802.1X defines the transport of EAP over LAN. In 802.1X, the peer is a host wishing to connect to a LAN
and the authenticator is a LAN bridge (such as a switch or access point) that the host physically connects
to. The RADIUS protocol is used to implement pass-through authentication from the bridge to an EAP
server. In 802.1X terminology, the EAP peer is the called the supplicant. An example 802.1X exchange is
shown below. The peer refuses OTP authentication, but agrees to MD5-Challenge and is authenticated.

Peer (or supplicant) Authenticator RADIUS

(ie. switch or access point) Authentication
server
server
(1) Request: Identity
(2) Response: Identity (7) Request user password
(3) Request: OTP Challenge
(4) Response: Nak
(5) Request: MD5 Challenge
(8) User password
(6) Response: MD5 challenge response
(9) Success

EAP over (W)LAN EAP over RADIUS

Any of the previously mentioned types are suitable for use on a switched network where the EAP
exchange takes place 'over the wire' between the supplicant and the authenticator. However, an 802.11
wireless network does not provide this physical protection; hence, an EAP transaction is unprotected and
can be easily sniffed. The MD5-Challenge and GTC types are therefore vulnerable to credential theft. OTP
prevents credential reuse, but like the others does not provide the keying material that is required to start
the 802.11 encryption ciphers. None of these types are therefore considered suitable for authenticating
users to 802.11 wireless networks. A number of other types have been developed to address these
problems. Of these, only three have been widely implemented: TLS, TTLS, and PEAP.
The TLS type implements authentication based on the TLS protocol. This requires that individual users
have their own certificate installed on the supplicant and a server certificate is installed on the EAP server.
Thus, TLS can only be used by organisations with a Certificate Authority (CA) that issues user
certificates, and consequently it is not widely deployed. The PEAP and TTLS types also use TLS, but
avoid the need for user certificates by operating in two phases. In the first phase the server identifies itself
to the client using a server certificate, which the client authenticates using the CA's root certificate. A TLS
context is generated that protects the second phase, which authenticates the supplicant to the server using a
“tunneled”, or inner-method, authentication protocol. While the PEAP and TTLS tunneling approaches are
similar, PEAP can only tunnel other types whereas TTLS can tunnel almost any authentication protocol.

Things to think about when deploying 802.1X

802.1X is the preferred access control technology for the UKERNA eduroam service, which uses
RADIUS proxy servers to refer visitor authentication to the visitor's Home organisation. You may want to
consult the service's documentation for detailed recommendations; the following is a brief summary.

Determine how your passwords are stored in your user database(s), and which operating systems you need
to support. These factors will largely determine which type(s) you deploy. Windows' supplicant only
supports the MSCHAPv2 type within PEAP, requiring that the EAP server is able to authenticate
MSCHAPv2 credentials. If this is not the case, TTLS should be considered. Windows' supplicant also
integrates poorly with Windows domain authentication. While this is not typically required for casual
network access, it can make it unsuitable for authenticating conventional desktop terminals; Longhorn will
rectify this shortcoming. If the Windows' supplicant is deemed unsuitable, a third-party supplicant will be
necessary. The table below provides a comparison of the supplicants available in August 2005.

Operating systems EAP types 802.11 ciphers Other

Supplicants W95 W98 WME W2K WXP Linux OSX PPC TLS PEAP TTLS WEP WPA WPA2 Availability Ease of use

Native Windows 1 2 3 4
Bundled


5

Native MacOS 6 7
Bundled




HP ProCurve Client 8 9
Commercial




Funk Odyssey Commercial




Meetinghouse Aegis Commercial




SecureW2 1 10
Free




wpa_supplicant 11 11 11
Free


12

Xsupplicant Free




Wire1X Free


13

Notes: 1. Requires SP3. 2. EAP-MSCHAPv2 inner-method only. 3. Requires WPA driver from adapter vendor. 4. Requires SP2 or SP1 and WPA driver from adapter vendor.
5. Caches credentials permanently in registry. 6. Requires MacOS 10.3. 7. Requires Airport Extreme. 8. Requires Redhat 9+. 9. Requires MacOS 10.2. 10. WXP only. 11. WEP and
WPA only. 12. Advanced 802.1X and 802.11 features; basic, but improving, GUI. 13. No known production use.

Ensure that your RADIUS server supports EAP, the chosen type(s), and authentication against your user
database(s). A variety of products are known to be used by JANET sites including Microsoft's IAS, Open
Solution's Radiator, Funk's Steelbelted RADIUS and the open-source FreeRADIUS.

Only deploy authenticators that support pass-through authentication - most do. If you want to segregate
users onto different networks, use authenticators that support dynamic VLAN allocation using RADIUS
and, in the case of access points, multiple SSIDs. If at all possible, avoid using WEP wireless encryption;
WPA encryption is now supported by most access points, supplicants, operating systems and adapters.

Consider how you will acquire a certificate for the RADIUS server. If you acquire certificates from a
vendor, as opposed to a self-signed certificate, ensure that you configure the supplicants to perform name-
based constraints on the certificate's server name attribute. This prevents a rogue EAP server from
masquerading as the authorised EAP server by acquiring a certificate from the same vendor.