PEAP

In many ways, PEAP is actually EAP over TLS for the wireless domain. In this section, you will see how PEAP adds capabilities needed in the wireless domain, such as chaining EAP mechanisms and exchange of arbitrary parameters, cryptographic binding between EAP mechanism and the tunnel, session optimization, and generic reauthentication.

From a draft perspective, all the EAP drafts are generic and do not fully address the wireless domain. In addition, RFC 3579 is superseding RFC 2284. The PEAP draft aims at providing secure EAP authentication for 802.11 based on the new EAP drafts.

Note

One of the major security vulnerabilities from the EAP perspective is that some of the outer/initial exchanges, such as identity and results, are sent in the clear. This can result in denial-of-service (DoS) vulnerability; for example, an intruder can flood EAP failure messages. Inner exchanges such as EAP-MD5, EAP-SIM, and EAP-MSCHAPV2 also are not fully and uniformly protected. In many cases, the credential exchanges are open to attacks, such as dictionary attacks on a password.

The opportunity for vulnerability is complicated by the "compound binding problem" with PEAP and like protocols, in which two otherwise-secure protocols are combined without cryptographic handoff and might become less secure in combination than separate. On the other hand, password-based EAP protocols are simpler to manage.

PEAP aims at leveraging EAL-TLS, securing the open exchanges, and facilitating any of the EAP mechanisms over the secure channel, thus maintaining the simplicity (as far as possible) with the required level of security. For example, PEAP requires only server-side certificates, uses TLS for the secure tunnel, and extends the EAP-TLS beyond the finished message exchange to add client authentication and key exchange. The client authentication can be any of the EAP methods and thus can achieve security and the use of existing authentication paradigms. Of course, PEAP has some drawbacks. It is a little chatty (because of more message exchanges) and does require a certificate infrastructure for the servers. Also, TLS is normally implemented over a reliable transport-TCP, so implementing TLS over EAP requires small reliability and retransmit mechanisms.

The PEAP protocol has two phases. The first phase is to establish a secure tunnel using the EAP-TLS with server authentication. The second phase implements the client authentication based on EAP methods, exchange of arbitrary information, and other PEAP-specific capabilities through the secure transport established during phase 1. It will be instructive to see how PEAP manages to stay within EAP-TLS (for the most part), still adding capabilities. This is important to achieve a simpler supporting infrastructure.

PEAP Frame Format

Figure 7-11 shows the PEAP request and response format.

Figure 7-11. PEAP Frame Format

The PEAP frame format is almost the same as the EAP-TLS format, the difference being the version bits in the flags field and the type (25 for PEAP versus 13 for EAP-TLS; Table 7-2).

PEAP Arbitrary Parameter Exchange

The type-length-value (TLV) mechanism is used to exchange arbitrary name-value pairs. Because this exchange happens in the second phase of the PEAP exchange, the frame formats are EAP formats with type 33 (see Table 7-2) but different from the TLS domain.

Figure 7-12 shows the frame format for the TLV mechanism. The RFC has defined approximately eight TLV types. Figure 7-13 shows the vendor-specific TLV. As you can see, this makes PEAP totally extensible but specific to a vendor.

Figure 7-12. PEAP TLV Frame Format

Figure 7-13. PEAP TLV Frame Format?Vendor-Specific TLV

Another interesting mechanism is the EAP Payload TLV shown in Figure 7-14, which encapsulates the EAP frame in a PEAP-TLV frame. This is powerful because it can tunnel EAP methods over the secure transport. The following subsection shows how this is being used in the PEAP phase 2 choreography.

Figure 7-14. PEAP TLV Frame Format?EAP Payload TLV

Note

Not all PEAP implementations are required to understand all the TLV types. The mandatory flag indicates this disposition. The mandatory TLV types are the EAP Payload TLV, Intermediate Result TLV, vendor-specific TLV (syntactical?that is, it should understand that it is a vendor-specific TLV; semantic understanding depends on the vendor implementation), Result TLV, and NAK TLV. The NAK TLV is used to indicate if an entity cannot understand the syntax of a TLV.

Another feature in the specs is the optimization of TLV message exchange; the spec allows multiple TLVs to be sent in one message?the only caveat being that multiple TLVs in one message are not allowed for the EAP Payload TLV.

PEAP Choreography

The PEAP choreography is similar (in fact, the same in most of the cases) to EAP-TLS. The main difference is that PEAP does not require client authentication, and the message exchange extends beyond where EAP-TLS stops.

Figure 7-15 shows the PEAP exchange.

Figure 7-15. PEAP Choreography

As you can see, the PEAP conversation is between the EAP server and the EAP peer, and the authenticator acts as a pass-through for most of the conversation. The advantage of this scheme is that newer EAP schemes can be developed and implemented without changing the authenticator and NAS?only the peer(supplicant/client) and the EAP server need to be updated. This results in easier and simpler upgrade to the supporting infrastructure.

Step 1.	Similar to EAP-TLS, the EAP server requires a certificate; the client/peer certificate is optional.
Step 2.	The client/peer must establish a connection to the authenticator?in this case, a wireless connection. An important requirement is the secure channel between the authenticator and the EAP server. This is vital because the specification does not indicate how this is established, but it requires one.
Step 3.	The identity request-response is the basic EAP sequence, which is sent in the clear. In PEAP, this is used for administrative purposes, such as which server to select, and possibly for other initial context setup. The identity, which is sent in the clear, should not be used for any other purposes. Any identity exchange should happen in phase 2 after the secure tunnel is established?for example, tunneling the identity request-response using the EAP-TLV mechanism (Step 7). The identity response is sent to the EAP server, which in turn starts the process with the EAP-TLS start message.
Step 4, 5, and 6.	These steps are typical EAP-TLS exchanges. Usually the client certificate is not exchanged. The successful completion of the EAP-TLS ends phase 1, and phase 2 leverages the secure tunnel created by phase 1.
Step 7.	This is the beginning of phase 2. The EAP-TLV mechanism can be used to tunnel the normal EAP identity exchange.
Step 8.	In this step, the EAP server authenticates the client using any of the EAP mechanisms: EAP-MD5, EAP-CHAP, EAP-SIM, and so on. The exchange is fully protected by the TLS tunnel, and the EAP-TLV choreography allows a graceful mechanism to affect the EAP mechanisms. This is the heart of the PEAP method?the server with a certificate, the establishment of the tunnel by TLS, and the use of the EAP methods available in the organization's infrastructure.
Step 9.	This is the final stage of crypto binding and so on between the client and the EAP server.
Step 10.	In this step, the client and the server derive the required keys.
Step 11.	This is where the authenticator receives the keys and the result of the authentication process.
Step 12.	Now the client and AP can exchange information using the keys that are derived from the PEAP mechanism.

Key Derivation, Exchange, and Management

The description in this section really skipped over the more intimate details about key derivation, exchange, and management. You should read the PEAP RFC for the details; there are key derivation algorithms, key management sequences, and theory. The Compound Session Key (CSK) is actually a concatenation of the Master Session Key (MSK), which is 64 bytes, and the Extended Master Session Key (EMSK), which is 64 bytes.

The MSK and EMSK are defined in RFC 3269 (also known as RFC 2284bis) as follows:

Master Session Key? Key derived between the peer and the EAP server and exported to the authenticator.
Extended Master Session Key? Additional keying material derived between the peer and the EAP server and exported to the authenticator. It is reserved for future use and not defined in the current RFC. In addition, the PEAP key mechanisms are designed for future extensibility; the exchange sequences (and choreographies) and formats can be used for handling any key material; binding inner, outer, and other intermediate methods; and verifying the security between the layers that are required for future algorithms.

There are a lot more details and capabilities, such as reauthentication using the session resumption feature of TLS, fast roaming, fragmentation and assembly, key rotation and rekeying, and so on, in PEAP. In short, PEAP is a powerful mechanism that is in its initial stages of implementation.