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.
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; see 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
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.
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. |
)
Figure
7-15 PEAP Choreography
|
Steps 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. |
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.
|
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. |
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.