IETF RFC 2284 describes Extensible Authentication Protocol (EAP) as a framework designed to add new authentication types to the Point-to-Point Protocol (PPP). With many authentication decisions being made by RADIUS servers, EAP support was added to the RADIUS protocol and is detailed in IETF RFC 2869. Although originally designed for PPP, EAP can also be used to authenticate identities over IEEE 802 networks. Details of EAP use with IEEE 802 networks is specified in IEEE 802.1X standard. One popular use of EAP is with IEEE 802.11 wireless networks.
In EAP three virtual entities are involved with the autentication process: the peer, the authenticator, and the authentication server. The peer is entity that requires authentication to gain access to a network. In IEEE 802.1X the peer is called the supplicant. Often the peer is refered to as the EAP client. The authenticator is the entity requiring the peer to authenticate before accessing a network. The authenticator can be a Network Access Server (NAS) or Access Point (AP). The final entity is the authentication server. The authentication server authenticates the peer and provides authentication information to the authenticator. The authentication server is also called the EAP server. The authenticator and the authentication server could be the same entity but often an authenticator will send authentication decisions to an external server supporting EAP. One protocol used to relay EAP messages between the authenticator and authentication server is RADIUS. A RADIUS server can either act as an authentication server or it can proxy EAP messages to another server providing EAP support. Although there is no requirement for RADIUS to be used between the authenticator and authentication server, 8950 AAA is a RADIUS server and we will only consider RADIUS as the message protocol between the authenticator and authentication server.
EAP uses four different message codes between the peer and authentication server: EAP-Request, EAP-Response, EAP-Success, and EAP-Failure. The peer notifies the autenticator that is supports EAP by sending an empty EAP message. The autenticator in return send a request to the peer for its identity. The peer responds with its identity and the autenticator forwards the EAP message to the authentication server. The authentication server determines which EAP authentication mechanism to use with the peer. The authenticator then sends one or more requests for authentication information specific to the authentication mechanism chosen. The autenticator forwards the requests to the peer. The peer answers each request with a reponse. The autenticator receives the responses from the peer and forwards them to the authentication server. The authentication server terminates the EAP conversation by sending the peer either an EAP-Success or EAP-Failure message. The autenticator is notified of success or failure by receiving a RADIUS Access-Accept or Access-Reject message which contains a either an EAP-Success or EAP-Failure attribute.
In RADIUS, EAP messages are sent from the authenticator to the RADIUS server using the EAP-Message attribute. Since EAP does not use the Password attribute when making authentication decisions, EAP requires the presence of a Message-Authenticator attribute to insure that the packet has not ben tampered with. Often the first EAP message seen by a RADIUS server is during authentication is an EAP-Response of type Identity sent to authenticator. EAP does not require that identity be determined through EAP messages but it often is. In cases where identity is not determined by EAP, the RADIUS server will receive an empty EAP message from the NAS and will use other RADIUS attributes in the Access-Request packet to determine which EAP authentication type to use.
8950 AAA supports both the EAP-Message and Message-Authenticator attributes. When a EAP-Message is received the packet is checked for the required Message-Authenticator. If the Message-Authenticator attribute is missing or contains an invalid value the Access-Request packet is silently discarded. If the Message-Authenticator is valid the EAP-Message is parsed and various components of the EAP-Message are placed in the packet variable group to assist in policy flow decisions. These component variables are:
EAP authentication schemes are implemented in plug-ins. In 8950 AAA , seven EAP authentication types are supported.
8950 AAA uses the AuthEapMd5 plug-in to provide support for EAP authentication type 4 (MD5-Challenge). The AuthEapMd5 plug-in sends a RADIUS Access-Challenge packet to the authenticator with a EAP-Message containing a challenge value. The authenticator extracts the message and sends it to the authenticatee. The authenticatee then creates a response using the challenge and its password. The response is sent to the authenticator and the autheticator sends the response in an RADIUS Access-Request packet. The AuthEapMd5 plug-in creates a similar response using the password retrieved by 8950 AAA for the authenticatee. If the two responses are equal the plug-in returns success and an EAP-Success message will be sent to the authenticator. If the two responses are not equal then the plug-in returns failure and an EAP-Failure message will be sent to the authenticator. This plug-in does not generate session keys for use in securing network traffic.
8950 AAA uses the AuthEapTls plug-in to provide support for EAP authentication type 13 (EAP-TLS). EAP-TLS uses X.509 certificates to authenticate using public and private keys as specified in the handshake phase of the Transport Level Security (TLS) protocol. Using this plug-in requires 8950 AAA to have a list of all trusted signers of client certificates and all clients need to trust the certificate sent by the 8950 AAA server. EAP-TLS requires a complicated conversation with certificates being sent in large request and response messages. Once both ends of the conversation have validated each others certificates, the AuthEapTls plug-in will generate session keys that can be used to encrypt communications between the dial-in client and authenticator.
8950 AAA uses the AuthEapLeap plug-in to provide support for EAP authentication type 17 (Cisco Wireless). This Cisco proprietary authentication scheme is popular with Cisco Aironet wireless equipment. The scheme provides mutual authentication by first having the authentication server challenge the peer and then having the peer challenge the authentication server. In both cases, a MS-CHAP (MD4) digest of the client's password and a challenge is used. Optionally the AuthEapLeap plug-in can authenticate the user against an NT domain controller. If the authentication sucedes a session key is returned to the authenticator for use in securing network traffic for the client. One unique requirement of the AuthEapLeap plug-in is the use of the Continue plug-in to allow 8950 AAA to save information from the peer authentication to use in the server authentication.
8950 AAA uses the AuthEapTtls plug-in to provide support for EAP authentication type 21 (Tunneled TLS). Although still an IETF draft, Tunneled TLS peers are available from Funk Software and Meetinghouse. In TTLS the authentiaction server is authenticated by the peer through the use of a X.509 certificate. Optionally the autentication server can request a certifiacte from the peer but often this not done to simplify deploying the TTLS software. Instead after a secure TLS tunnel is established between the peer and authentication server, the peer sends credentials through the tunnel that are verified by the authentication server. In 8950 AAA this verification occurs in a special tunnel policy flow which uses other plug-ins to process the tunneled attributes. If the tunnel policy successfully authenticates the peer, an indication of success is sent to the peer and authenticator. Session key data is also securely returned to the authenticator for use in securing network traffic for the peer.
8950 AAA uses the AuthEapPeap plug-in to provide support for EAP authentication type 25 (Protected EAP). Although still an IETF draft, PEAP peers are available from Microsoft and Cisco. In PEAP the authentiaction server is authenticated by the peer through the use of a X.509 certificate. Optionally the autentication server can request a certifiacte from the peer but often this not done to simplify deploying the PEAP software. Instead after a secure TLS tunnel is established between the peer and authentication server, the peer sends EAP messages through the tunnel that are verified by the authentication server. In 8950 AAA this verification occurs in a special tunnel policy flow which uses other EAP plug-ins to process the tunneled EAP messages. If the tunnel policy successfully authenticates the peer, an indication of success is sent to the peer and authenticator. Session key data is also securely returned to the authenticator for use in securing network traffic for the peer.
8950 AAA uses the AuthEapMsCapV2 plug-in to provide support for EAP authentication type 26 (MS-CHAPV2). Although still an IETF draft, EAP MS-CHAPV2 is used by Microsoft as an EAP type inside of a PEAP tunnel. In EAP MS-CHAPV2, the peer and authentication perform a mutual authentication using the Microsoft CHAP version 2 protocol. Optionally, the plug-in can use an Microsoft NT domain controller to perform the authentication. If the authentication succedes, a session key is created and sent to the authenticator for use in securing network traffic for the peer.
8950 AAA uses the AuthEApGtc plug-in to provide support for EAP authentication type 6 (Generic Token Card). EAP Generic Token Card is used by Cisco PEAP software to tunnel password data used for token cards and plaintext authentication. The AuthEapGtc plug-in specifies a tunnel policy flow used to process password data sent in the EAP messages and allows the tunnel policy flow to issue challenges for additional password data. This plug-in does not generate session keys for use in securing network traffic.