Share via

1.3 Overview

  • Article

Network administrators often require authentication and authorization of users or devices attaching to their networks. For example, a network administrator can require that only known users be allowed to connect. Likewise, the operator of a virtual private network (VPN) can require that remote network access only be granted to known and authorized users.

EAP enables extensible authentication for network access. EAP methods operate within the EAP framework to provide support for a variety of authentication techniques. For example, an administrator who requires certificate-based authentication can deploy the EAP Transport Layer Security (TLS) method, as specified in [RFC5216]. If password-based authentication is required, the EAP Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MSCHAPv2 [MS-CHAP]) method might be used.

Strong credentials, such as digital certificates, offer many security benefits. However, in many environments, deploying such credentials to every client can be expensive and hard to manage due to the infrastructure they require. This, for example, is often the case for corporate wireless network deployments. As a result, there is a need for an EAP method that can provide the security benefits of authentication with strong credentials, without incurring the cost of an infrastructure required by a client public key infrastructure (PKI) deployment.

PEAP version 0 is an EAP method designed to meet this need. It does so by having the client establish a TLS session with a server by using the server's certificate. Then, the client is authenticated using its credential of choice within that TLS session.

The flow of a successful PEAP authentication is as follows:

  1. The Authenticator (network access server (NAS)) sends an optional Identity Request packet to the EAP peer as described in [RFC3748] section 2. The EAP peer then responds to the Authenticator with an Identity Response packet and the Authenticator forwards the same to the EAP server.

  2. The EAP server and EAP peer negotiate the EAP method to use. PEAP and version 0 are selected. The same server and peer now play the roles of PEAP server and PEAP peer as they exchange PEAP data with the EAP packets.

  3. PEAP enters phase 1. The purpose of phase 1 is to authenticate the PEAP server and to establish a TLS session.

    1. The PEAP peer and the PEAP server exchange TLS messages by placing the TLS records into the payload of the PEAP messages.

    2. These PEAP messages are exchanged until the TLS session is successfully established between the PEAP peer and the PEAP server. This completes phase 1.

  4. PEAP then enters phase 2, where the PEAP peer and the PEAP server continue to exchange PEAP messages, with TLS records placed in the payload. The purpose of phase 2 is to allow the PEAP server to authenticate the PEAP peer inside the TLS session established in phase 1.

    1. A new EAP negotiation is initiated by the PEAP server to authenticate the PEAP peer. This new "inner method" EAP negotiation is carried inside the TLS records being exchanged between the PEAP peer and PEAP server.

    2. The PEAP server and the PEAP peer negotiate and agree on an inner method.

    3. The PEAP peer and the PEAP server exchange inner method messages until the PEAP peer is successfully authenticated. This completes phase 2.

  5. PEAP completes when phase 2 is completed.

The security provided by the TLS session established in phase 1 protects the PEAP peer authentication in phase 2 so that passwords or other dictionary-attackable tokens can be used confidentially.

PEAP is typically deployed in an environment such as the one depicted in the following figure. The EAP peer mutually authenticates with an EAP server using PEAP through a network access server (NAS) (that is, a wireless access point or VPN gateway). The actual PEAP messages are carried from the EAP peer to the NAS over lower-layer protocols such as the Point-to-Point Protocol (PPP) or [IEEE802.1X], and from the NAS to the EAP server over a lower-layer protocol such as the Remote Authentication Dial-In User Service (RADIUS) [RFC2865].

Typical PEAP deployment environment

Figure 1: Typical PEAP deployment environment

To understand PEAP, it is necessary to understand both EAP and TLS. An overview of EAP is specified in [RFC3748] section 2, while an overview of TLS is specified in [RFC2246] section 1. For more information on security requirements for EAP methods that are used with wireless local area networks (WLANs), see [RFC4017].