The Extensible Authentication Protocol (EAP) framework, described in [37,3,] and other drafts, provides a standard mechanism for support of additional authentication methods within PPP, IEEE 802 wired networks, IEEE 802.11 (with IEEE 802.1X) or other access technology.
The Protected Extensible Authentication Protocol (Version 2), Protocol PEAP (20), provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP (Extensible Authentication Protocol) authentication mechanisms. [94]
Protocol PEAP should provide Fresh Key Agreement, 3P-Authorization, and ID Protection (Eavesdropper) (G1-3,6,7,10,12,13).
The PEAP conversation occurs between the EAP peer and EAP server, passing through a Network Access Server, NAS. The NAS is not involved in the PEAP conversation, which is confidentially protected, and therefore the NAS does not have knowledge of the TLS master secret derived between the peer and the EAP server. In order to provide keying material for link-layer purposes, the NAS obtains the master session key, which is derived from a one-way function of the TLS master secret as well as keying material provided by EAP methods. This enables the NAS and EAP peer to subsequently derive transient session keys suitable for encrypting, authenticating and integrity protecting session data. However, the NAS cannot decrypt the PEAPv2 conversation or spoof session resumption, since this requires knowledge of the TLS master secret.
The protocol is quite complex and includes 2 different parts, each one with several phases and variants: The first part is as follows: The initial identity exchange is used primarily to route the EAP conversation to the EAP server. Then a TLS session is established. TLS itself has several variants, depending in particular on the type of credentials used. If required for privacy reasons, the TLS session may be re-negotiated after the first server authentication. Then a version negotiation procedure enables PEAP implementations to be backward compatible with previous versions of the protocol. It should guarantee that the EAP peer and server will agree to the latest version supported by both parties. There is also a variant for resuming a previously established session. The second part of the PEAPv2 conversation typically consists of a complete EAP conversation occurring within the TLS session negotiated in Part 1. Besides being a standard Key Exchange Problem, TLS also offers identity protection against eavesdroppers.
Protocol EAP-SIM (21), the EAP SIM Authentication of [82], is an authentication and session key distribution method based on the GSM Subscriber Identity Module SIM mechanism, a challenge/response authentication and key agreement procedure based on a symmetric 128-bit pre-shared secret. EAP SIM also makes use of a peer challenge, not part of GSM, to provide mutual authentication. EAP-SIM specifies optional support for version negotiation and for protecting the privacy of the subscriber identity using the same concept as GSM, which uses pseudonyms/temporary identifiers. This protocol is also quite complex and includes Version Negotiation, Identity Management, Re-Authentication, EAP Notifications, Error Case Handling, and Key Generation, all including several phases and variants.
Protocol EAP-SIM should provide Fresh Key Agreement and 3P-Authorization (G1-3,6,7,10,12).
Protocol EAP-AKA (22), the EAP AKA Authentication, proposed in [15], is a mechanism for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys and typically runs in a UMTS Subscriber Identity Module, a smart card like device. EAP AKA includes optional identity privacy support, an optional re-authentication procedure, EAP Notifications, Error Case Handling, Key Generation, and the protocol exists in different variants.
Each of the 2 protocols offers us a wide range of security problems: Identity Protection, Mutual Authentication, Key Derivation, Brute-Force and Dictionary Attacks, Integrity Protection, Replay Protection and Confidentiality, Negotiation Attacks.
Protocol EAP-AKA should provide Fresh Key Agreement, 3P-Authorization, and ID Protection (Eavesdropper and Peer) (G1-3,6,7,10,12-14).
Protocol EAP-Archie (23), the EAP Archie Protocol, defined in [201], performs mutual authentication, and fresh session key derivation. EAP-Archie is based on a static long-lived 512-bit secret, the Archie Key, shared between the two main entities in the protocol, the EAP Peer and the EAP Server. The Archie Key consists of two 128-bit sub-keys and a 256-bit sub-key, respectively called the key-confirmation key (KCK), the key-encryption key (KEK), and the key-derivation key (KDK). The protocol uses the KCK to mutually authenticate the EAP Peer and the EAP Server, the KEK to distribute secret nonces used for session key derivation, and the KDK to derive a session key between the EAP Peer and the EAP Server.
Protocol EAP-Archie should provide Fresh Key Agreement, 3P-Authorization, and DoS Resilience (G1-3,6,7,10,12,15).
Newly discovered Man-in-the-middle attacks in the context of tunneled authentication protocols (see [157] and [18]) are applicable to IKEv2 if legacy authentication with EAP is used ([95,38]). To counter this threat Protocol EAP-IKEv2 (24) was designed ([191]), providing a session key inside the AUTH payload.
EAP-IKEv2 consists of three parts plus an optional DoS protection exchange.
Protocol EAP-IKEv2 should provide Fresh Key Agreement, 3P-Authorization, and DoS Resilience (G1-3,6,7,10,12,15).
Protocol EAP-TTLS (25), the EAP Tunneled TLS Authentication Protocol, is defined in [71] (see also [5]).
Protocol EAP-TTLS should provide Fresh Key Agreement and 3P-Authorization (G1-3,6,7,10,12).