Pdf 00000

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 (ie. switch or access point)

RADIUS server

(1) Request: Identity

(2) Response: Identity

(3) Request: OTP Challenge

Authentication server (7) Request user password

(4) Response: Nak (5) Request: MD5 Challenge

(6) Response: MD5 challenge response

(8) User password

(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 Supplicants

W95

W98

WME

Native Windows

W2K

WXP

EAP types

Linux

OSX

1

PPC

TLS

PEAP 2

Native MacOS

TTLS

802.11 ciphers WEP

WPA 3

6

HP ProCurve Client

8

WPA2

Availability

4

Bundled

7

Bundled Commercial

9

Funk Odyssey

Commercial

Meetinghouse Aegis

Commercial

SecureW2 wpa_supplicant

Other

1

11

11

11

10

Free Free

Xsupplicant

Free

Wire1X

Free

Ease of use


























5

12

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