El paralelo de la lectura

The idea behind PEAP is to allow additional EAP methods to be run atop (or chained after) an EAP-TLS handshake. That is, other EAP methods or protocols can be “wrapped” within TLS, providing them with the security benefits of TLS. Another way of looking at PEAP is to consider it as consisting of an inner EAP being run within TLS, which is in turn run within an outer EAP.

One key motivation behind this approach is to allow users to submit their credential (which may contain their identity) after the TLS session has been estab- lished, and therefore have their credential passed to the server under the protection (encryption) of the TLS session.

Another motivation for PEAP is to allow the server to request various forms of credentials from the client. In other words, in PEAP multiple authentication methods (e.g., GTC and OTP) can be run under the protection of the previously established TLS session. These can be run sequentially or in parallel. For deploy- ment cases where a client certificate is required, PEAP allows client certificates to be delivered after the TLS session has been established, instead of during the TLS session setup.

Some of the security benefits provided by PEAP are as follows:

• Identity protection: The initial EAP identity request and EAP identity re-

attacker. PEAP supports identity protection by establishing a TLS channel first, before the client’s identity is passed to the server.

An additional benefit of this approach is the protection of EAP authen- tication methods (e.g., password-based) that might be subject to an offline dictionary attack.

• Negotiation and termination protection: The negotiation (e.g., ciphersuites) that occurs with EAP (within TLS) is protected from possible downgrade attacks where the attacker replays certain packets to the client/server to force them to use a weaker ciphersuite.

An additional benefit from using an established TLS channel is the protection of the success/failure indications of the EAP conversation, which may otherwise be open to spoofing (e.g., EAP failure message) by an attacker, which may then in turn lead to to a denial of service.

• Header protection: The TLS channel provides protection against the (inner) EAP header being modified in transit (i.e., type-data field within PEAPv2, which includes the EAP header of the EAP method within PEAPv2). • Multiple authentication methods: Since a full (inner) EAP is run within an

established TLS session, other EAP methods for authentication can also be thus executed between the client and server. PEAPv2 provides a standard way to chain or sequence different EAP methods for authentication, each possibly supporting different forms of credentials. PEAPv2 allows for both serial

authentication (one EAP method after another), or parallel authentication

where an EAP method is initiated after another has failed.

Note that this possibility is attractive to networks where a “machine” credential is used in addition to a “human” credential. For example, for the TLS session establishment (in the outer EAP) a machine certificate could be mandated on the client. If the TLS session establishment succeeds, a human certificate could then be used for the (inner) EAP authentication method (e.g., EAP-TLS).

Other benefits, such as fragmentation/reassembly and fast reconnect, are discussed further in [5].

4.3.2 EAP Methods over TLS: EAP-TLV

A key feature of PEAPv2 is its ability to provide multiple authentication methods over an established TLS channel or session. More specifically, PEAP allows EAP methods for authentication to be run (unmodified) over the TLS channel, either in sequential fashion or in parallel.

In order to provide this ability, PEAP introduces a new EAP method called

type-length-value (TLV). The purpose of the EAP-TLV method is to carry payloads

consisting of other authentication-specific EAP methods. Thus, when we mentioned that EAP runs atop a TLS channel (which runs over EAP, or EAP-over-TLS-over- EAP), what really occurs is that the EAP-TLV method runs inside the top-most (inner most) EAP. In turn, that TLV method carries other EAP methods between the client and server. Figure 4.3 shows a simplified arrangement of layers within PEAP. Note that the bottom-most EAP layer in Figure 4.3 is the outer EAP, whereas the top EAP is the inner EAP.

Client (EAP Peer) RADIUS (EAP Server) Access Point (Pass-Through Authenticator) EAP 802.11 802.3 (Ethernet) IP RADIUS EAP 802.3 (Ethernet) TLS (PEAP) EAP IP RADIUS EAP EAP-TLV EAP authentication methods

EAP TLS (PEAP)

802.11 EAP EAP-TLV EAP authentication methods

Figure 4.3 Overview of PEAP layers.

The EAP-TLV method is a really only a payload with standard TLV objects, and TLV objects could be used to carry any arbitrary parameters between the client (EAP peer) and the EAP server. The work in [5] defines a number of TLV packets for carrying out a conversation between a client and server. Although a discussion on all of the TLVs are beyond the scope of the current work, some of the TLVs that are relevant for the discussion on the PEAPv2 exchange (Section 4.3.3) are as follows:

• The NAK TLV: The NAK TLV is used by a client to indicate to the server that it does not support a given TLV proposed by the server.

• The crypto-binding TLV: The client and server use the crypto-binding TLV to prove to each other that they respectively participated in the same sequence of authentications. This includes starting from the TLS session establishment, all the way to the (inner) EAP authentication methods (which generated keys). The same format is used for Binding Request (B1) and Binding Response

(B2), with the subtype field indicating them respectively. In phase 2 of PEAP (after the TLS channel is established), the crypto-binding TLV is used to perform cryptographic binding after each successful EAP method (except EAP-TLV) in a sequence of EAP methods.

Other TLVs include the EAP-TLV request packet, the EAP-TLV response packet, the Result TLV packet, the connection binding TLV packet, the EAP payload TLV packet and the vendor specific TLV packet. The reader is directed to [5] for further details on each.