PEAP, as the name suggests, provides a way to do EAP negotiation safe from prying eyes. The original motivation was to make password-based client security safe from offline dictionary attack. To achieve this, the EAP session is completely hidden from attackers. It was hard to decide whether PEAP should be in Chapter 8 in the discussion of access control or here, in the coverage of upper-layer authentication. PEAP is a sort of welding together of EAP and TLS in an attempt to maintain the flexibility of EAP while overcoming its lack of inherent security protection.
First, let's consider the security weaknesses of EAP. EAP is like a good sandwich: meaty center surrounded by two slices of thin bread (apologies to vegetarians). The meaty center is the authentication exchange between the client and the server. If a method like TLS is used, the security credentials of this part are good. The thin slices of bread are the parts of EAP that are common to all methods the EAP-Identity phase and the EAP-Success or EAP-Fail messages at the end. This is where the security weaknesses occur:
A solution to both these problems is to perform the EAP negotiation in a private encrypted "tunnel." If we have an existing secure connection between the client and the server, then we can do the EAP negotiation quite safely and the client's identity will not be revealed. All the flexibility of EAP will still be available; you can negotiate any of the upper-layer authentication methods available. This is the basic idea behind PEAP: The entire EAP negotiation is protected.
The obvious question is how to establish such a secure communication channel, given that the purpose of EAP is to set up a secure communication channel! To answer the question, we need to go back to one of the basic principles of security and consider the difference between privacy and authenticity. Privacy means that no unwanted party can understand the protected communications. Authenticity means that the two (or more) parties can mutually prove their identity.
It is quite possible to have privacy without authenticity and sometimes this is useful. Digressing for a slightly seedy analogy here, consider sexy chit-chat lines. People call a premium toll phone number and talk to a complete stranger with a sexy voice about any subject they care to choose (although probably not sports related). The illusion is that the woman or man who answers the phone is in some sort of private intimate setting. However, in practice these are regular call center operations with people sitting at rows of desks, each with a phone. This is a case in which the caller wants privacy, but doesn't care about (or get) authenticity.
The object of EAP is authenticity: Extensible Authentication Protocol. The object of PEAP is to do this authentication in private. To meet both objectives, we first establish privacy without authenticity; and then we perform the authentication using the private connection. In other words, we use a two-phase approach:
TLS is the chosen method to establish privacy in phase 1; but once the private channel is established, any EAP-supported method could be negotiated. It does not have to be TLS.
Notice that the first phase of PEAP does involve some level of authentication; the server is always required to prove its identity. It can do this by using a certificate, as described for regular TLS. It lets the client know that the server is legitimate and not some rogue server trying to attract unwary clients. This is especially important for wireless LAN because it is relatively easy for people to set up rogue access points and falsely advertise that they belong to a valid network. We review the two phases of EAP separately.
From the outside, phase 1 looks like a normal EAP negotiation. If you study how TLS over EAP works (earlier in this chapter), then you understand how the first phase of PEAP works. The difference comes at the end of the phase when, instead of sending an EAP-Success, the negotiation moves into phase 2 and starts an entirely new EAP session encrypted using the newly negotiated keys.
At the start of both phase 1 and phase 2, the server sends an EAP-Request/Identity message. The client must reply with an identity response. However, the client is explicitly allowed to send an anonymous identity in the first EAP round. In normal EAP, the identity is often used to determine which upper-layer authentication method will be used. The same is true for PEAP so the identity sent in the first phase may enable the server to determine that PEAP will be used. However, it could be some arbitrary name like "firstname.lastname@example.org". The client's real identity is sent during phase 2. Sometimes the authenticator uses the name to specify which backend server will be consulted for authentication decisions. This might be the case for an access point in a reception area serving a variety of companies. In such a case, a sort of half-anonymous name can be used such as "anonymous@MyCo.com". The company name is real, but the user name is not given until later, when the secure connection to the company's server is established.
During the TLS negotiation, the server might request a client certificate. Providing such a certificate will compromise the identity of the client. In PEAP the client has the right to refuse to provide a certificate and the server should still proceed to phase 2. If the client provides a certificate and wants to use TLS anyway, there is hardly any point in going to phase 2 because mutual authentication will be achieved in phase 1.
Phase 2 is a conventional EAP negotiation allowing any upper-layer protocol that the authentication server supports. The only difference is that all the EAP messages are sent using the encrypted session established in phase 1. It is quite safe to send the real identity of the client. The authenticator is not allowed to compare the identity given in the second phase to that given in the first phase. It is understood that the first phase identity may be meaningless.
PEAP allows an attacker to get through phase 1 unchallenged. Because there is no authentication, any attacker can do the TLS negotiation and establish a secure connection to the authentication server. Therefore at the start of phase 2, the client must be treated as completely untrusted even though it is working in a secure link. Obviously, if the client cannot authenticate itself successfully in the second phase, it should be unceremoniously disconnected.
Status of PEAP
At the time of writing, PEAP is still in draft form. However, it is essentially complete and may proceed to RFC status. An attack (described in Chapter 15) that eliminates the benefits provided by PEAP was recently identified, and it is unclear yet how that attack will affect the status of PEAP within the IETF. By the time you read this, there may or may not be an RFC number assigned.