The Cable Guy
EAPHost in Windows
Prerelease information in this column about Windows Server 2008 is subject to change.
When an access client connects to a protected network, it must use a negotiated authentication method to verify itself to an authentication server. For example, the access client and authentication server may agree to use a specific password authentication protocol, such as Microsoft Challenge Handshake Authentication
Protocol version 2 (MS-CHAP v2). However, when an access client and authentication server use built-in and hardcoded authentication methods, it is difficult to add new protocols.
The Extensible Authentication Protocol (EAP) is an architectural framework that provides extensibility for authentication methods for commonly used protected network access technologies, such as IEEE 802.1X-based wireless networks and Point-to-Point Protocol (PPP) connections such as dial-up and VPN. EAP is not an authentication method like MS-CHAP v2, but rather a framework on the access client and authentication server that allows networking vendors to develop and easily install new authentication methods known as EAP methods. For more background information on EAP, see the Microsoft EAP Web page at microsoft.com/eap
Although EAP has been supported in Microsoft® Windows® since Windows 2000, the architecture of EAP in Windows XP and Windows Server® 2003 has extensibility limitations for EAP methods and supplicants, which are software components that can use EAP over a specific type of link layer. The EAPHost architecture in Windows Vista™ and Windows Server 2008 addresses these limitations, making it much easier for third-party network vendors to extend Windows for new supplicants and for EAP methods.
EAP Support in Windows Server 2003 and Windows XP
Windows Server 2003 and Windows XP use EAP for wireless or wired connections that authenticate with 802.1X and for PPP-based connections such as dial-up or VPN-based remote access or site-to-site connections. Specifically, these operating systems contain an implementation of EAP that adheres to RFC 2284, and include IEEE 802.1X and PPP supplicants. Figure 1 shows the EAP and supplicant architecture for Windows XP and Windows Server 2003. It should be noted, however, that the EAP implementation in Windows XP Service Pack 2 (SP2) and Windows Server 2003 SP1 does not support RFC 3748 (the current Internet standard for EAP) and other EAP RFCs.
Figure 1 EAP and supplicant architecture for Windows XP and Windows Server 2003
An EAP API provides the means for extending authentication in Windows XP and Windows Server 2003. Although third-party vendors can develop and install new EAP methods, the built-in PPP and 802.1X supplicants cannot use all the installed EAP methods. For example, a vendor might create a new fingerprint scanning EAP authentication method, but that method might not be available for wireless connections.
Because of the limitations of the built-in supplicants, some third-party software and hardware vendors develop their own supplicants, which typically replace and disable built-in supplicants and the entire EAP architecture. This alternative presents a few issues, however. First, replacing the built-in supplicants and EAP architecture incurs developmental costs and causes delays. In addition, if an enterprise customer does not develop its own supplicants, it can incur per-seat costs to license and install a third-party product.
Features of EAPHost
EAPHost provides the following new features:
Support for additional EAP methods.
EAPHost will support the installation and use of all the EAP methods listed on the EAP Registry at www.iana.org/assignments/eap-numbers
, and other popular authentication methods such as Lightweight EAP (LEAP), developed and provided by Cisco Systems, Inc.
Network discovery. EAPHost supports network discovery as defined in RFC 4284.
RFC 3748 compliance. EAPHost conforms to the EAP State Machine and addresses a number of security vulnerabilities that have been specified in RFC 3748. Previously, supplicants had to implement their own state machines. Additionally, EAPHost supports capabilities such as Expanded EAP Types (including vendor-specific EAP methods).
EAP method coexistence. EAPHost allows multiple implementations of the same EAP method to coexist simultaneously. For example, you can install and select the Microsoft version of Protected EAP (PEAP) and the Cisco Systems, Inc. version of PEAP.
Modular supplicant architecture. EAPHost supports a modular supplicant architecture in which new supplicants can be easily added without having to replace the entire EAP implementation as you did in the previous version.
For EAP method vendors, EAPHost supports EAP methods already developed for Windows XP and Windows Server 2003 and an easier method of developing new EAP methods for Windows Vista and Windows Server 2008. EAPHost also allows better classification of EAP types so that the built-in IEEE 802.1X supplicant can use them.
For supplicant vendors, EAPHost provides support for additional supplicants for new link layers. Because EAPHost is integrated with Network Access Protection (NAP), new supplicants do not have to be NAP-aware. In order to participate in NAP, new supplicants just need to register a connection identifier and a callback function that informs the supplicant to reauthenticate. For more information about NAP, see John Morello’s Security Watch column in this issue of TechNet Magazine
, as well as the NAP Web page at microsoft.com/nap
. For information about how to develop EAP methods or supplicants for EAPHost, see Extensible Authentication Protocol Host at msdn2.microsoft.com/aa364249.aspx
EAPHost and EAP Infrastructure Architecture
EAPHost architecture consists of the EAP infrastructure architecture for EAPHost, the EAPHost architecture on the EAP peer (the authenticating client), and the EAPHost architecture on the authentication server. Figure 2 shows the components of the EAP infrastructure architecture for EAPHost on computers running Windows Vista or Windows Server 2008. On these operating systems, the EAP peer has a layer of supplicants (such as the built-in supplicant for 802.1X), the new EAPHost architecture for EAP peers (facilitating communication and management of supplicants and EAP methods), and a layer of EAP methods to perform authentication.
Figure 2 EAP infrastructure architecture for EAPHost (Click the image for a larger view)
The authentication server for Windows Server 2008 has the Network Policy Server (NPS), the new EAPHost architecture for authentication servers, and a layer of EAP methods. Previously known as the Internet Authentication Service (IAS) in Windows Server 2003, NPS is a Remote Authentication Dial-In User Service (RADIUS) server and proxy and a policy server for NAP.
The supplicant on the EAP peer uses a link-layer technology such as PPP or 802.1X to send and receive EAP messages on the link between the EAP peer and the pass-through authenticator (a network access server such as a wireless access point or a remote access server). The pass-through authenticator and NPS on the authentication server use RADIUS to send and receive EAP messages on the IP-based network between the pass-through authenticator and the NPS.
After the EAP peer and the authentication server negotiate the use of a specific EAP method, the logical communication consists of EAP messages sent between the negotiated EAP method on the EAP peer and the authentication server.
Figure 3 shows the EAPHost architecture on the EAP peer running Windows Vista or Windows Server 2008. This architecture consists of supplicants, EAPHost components, EAP method management components, and NAP components.
Figure 3 EAPHost architecture on the EAP peer (Click the image for a larger view)
Windows Vista and Windows Server 2008 include an 802.1X supplicant for 802.1X-based wireless and wired connections. A PPP supplicant for dial-up or VPN-based remote access or site-to-site connections is being investigated for a future update to these two operating systems. Additional supplicants developed by third parties can also be added. The EAPHost API allows the supplicants to use EAP for connections. For more information, see the article at msdn2.microsoft.com/aa364249.aspx
EAPHost components include the EAP Client State Machine/Protocol Validator, which maintains the EAP peer state machine (see RFC 3748) and validates EAP messages. Also included is the EAP Method Manager, which manages the various EAP methods whether they are EAPHost-compatible or not, and helps to make EAP methods available to applications and services. And finally there’s the EAP Library Manager, which facilitates with the loading and unloading of EAP method libraries.
EAP method components include:
Built-in EAP methods. They include PEAP, EAP-Transport Layer Security (TLS), and EAP-MS-CHAP-V2.
Two host APIs. These host non-EAPHost-compatible EAP methods (Legacy EAP API) and third-party EAPHost-compatible EAP methods (EAPHost Method API).
Legacy Translator Method. This translates between the non-EAPHost-compatible EAP methods written to the Legacy EAP API and the EAPHost Method API.
EAP Method Proxy Manager . This hosts third-party EAP methods, whether or not they are compatible with the EAPHost.
The EAP Method API is the new API for EAPHost-compatible EAP methods. EAP methods export the APIs defined in EAP Method API. EAPHost loads the EAP methods and calls into the exported API functions.
The NAP components include the following items:
EAP NAP EC Messenger . This component facilitates communication of NAP-related data, such as statements of health and events, between the EAPHost NAP Enforcement Client (EC) and other components of EAPHost.
EAPHost NAP EC . This interacts with other NAP components to provide health validation and enforcement of limited access when an 802.1X-authenticated connection does not comply with NAP system health requirements.
NAP Agent. This maintains the current health state of the client and facilitates communication between the installed NAP ECs and the layer of System Heath Agents (SHAs). Each SHA is defined for one or more system health requirements.
As Figure 3 shows, third-party vendors can develop new supplicants and new EAPHost-compatible EAP methods. You can also use existing EAP methods developed for Windows Server 2003 or Windows XP.
Figure 4 shows the EAPHost architecture on the authentication server running Windows Server 2008 and NPS. This architecture is the same as that for the EAP peer for supporting EAP methods. Instead of supplicants, the authentication server has NPS, which uses the EAPHost API to use and configure EAP methods. Within the EAP components, the EAP Server State Machine/Protocol Validator does the job of maintaining the EAP authentication server state machine and validating incoming EAP messages.
Figure 4 EAPHost architecture on the authentication server (Click the image for a larger view)
EAPHost on the authentication server allows third-party software vendors to develop and install new EAPHost-compatible EAP methods and supports EAP methods that have already been developed for Windows XP and Windows Server 2003.
For both the EAP peer and the authentication server, EAPHost also provides an EAPHost UI Proxy API (not shown in Figures 3 and 4), which EAPHost-compatible methods can use to display dialog boxes that require user interaction. The EAPHost UI Proxy API allows third-party vendors to add their own dialog boxes for a more seamless user experience.
EAPHost in Windows Server 2008 and Windows Vista updates the EAP implementation in Windows for the latest Internet standards and provides a new modular architecture to extend Windows with EAP authentication methods and supplicants. Networking vendors can extend the existing user experience in Windows without replacing the entire Windows EAP implementation by developing new supplicants written to the EAPHost API and new authentication methods written to the EAPHost Method API. EAPHost also supports existing EAP methods developed for Windows Server 2003 and Windows XP.
Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly TechNet Cable Guy column.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited