EAP
The Extensible Authentication Protocol (EAP) is an extension to PPP that allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection. With PPP authentication protocols such as MS-CHAP and SPAP, a specific authentication mechanism is chosen during the link establishment phase. Then, during the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order.
With EAP, the specific authentication mechanism is not chosen during the link establishment phase. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. Once the connection authentication phase is reached, the PPP peers must first negotiate the use of a specific EAP authentication scheme known as an EAP type. Once the EAP type is agreed upon, EAP allows for an open-ended conversation between the remote access client and the remote access server that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation is dependent upon the EAP type.
For example, when EAP is used with security token cards, the remote access server could separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the user passes through another level of authentication. When all questions have been answered satisfactorily, the user is authenticated and permitted access to the network.
The use of EAP is negotiated during LCP negotiation by specifying the authentication protocol LCP option (type 3) and the authentication protocol 0xC2-27. Once LCP negotiation is complete, EAP messages use the PPP Protocol ID of 0xC2-27. Windows 2000 includes support for the EAP-MD5 and EAP-TLS EAP types.
Architecturally, EAP is designed to allow authentication plug-in modules at both the client and server ends of a connection. By installing an EAP type library file on both the remote access client and the remote access server, a new EAP type can be supported. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the highest flexibility in authentication uniqueness and variations.
EAP-MD5
EAP-MD5 is the CHAP authentication mechanism used within the EAP framework. Rather than negotiating to perform MD5 authentication during the link establishment phase, the authenticator and peer negotiate to do EAP during the connection authentication phase.
Once the connection authentication phase is reached, the following process verifies the client:
The authenticator sends an EAP-Request message requesting the identity of the client.
The client sends its user ID to the authenticator as an EAP-Response message.
The authenticator sends an EAP-Request message containing the MD5 challenge string.
The client sends the MD5 hash of its user ID and password to the authenticator as an EAP-Response message.
If the response is proper, the authenticator sends a Success message to the client.
EAP-MD5 is a required EAP type and can be used to test EAP interoperability. Like, CHAP, EAP-MD5 requires that local or domain passwords be stored in a reversibly encrypted form. For more information, see Windows 2000 Server Help.
EAP-TLS
The Transport Layer Security (TLS) protocol, based on the Secure Sockets Layer, allows applications to communicate securely. TLS provides authentication (user and data), data integrity, and data confidentiality services. To achieve these services, TLS specifies a framework that allows the following:
Client and two-way authentication using symmetric or asymmetric encryption.
Negotiation of the specific encryption algorithm (the cipher-suite).
Secured exchange of encryption keys to be used for encrypting messages.
Message integrity and user authentication using a message authentication code.
For more information about the details of TLS, see RFC 2246. For more information about EAP-TLS, see RFC 2716.
EAP-TLS is the use of TLS during the establishment of a PPP connection. With EAP-TLS, mutual authentication between the PPP client and the authenticator is done through the exchange and verification of certificates. The client attempting the connection sends a user certificate, and the authenticator sends a machine certificate.
EAP-TLS is only supported on Windows 2000 Server remote access server computers that are a member of a Windows 2000 mixed or native domain. Stand-alone Windows 2000 remote access servers do not support EAP-TLS.
EAP-RADIUS
EAP-RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server. The remote access server becomes a pass-through device passing EAP messages between the remote access client and the RADIUS server. All processing of EAP messages occurs at the remote access client and the RADIUS server.
EAP-RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server.
In a typical use of EAP-RADIUS, the remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client.