A Comparative Analysis of

Extensible Authentication Protocols

Genebeck HAHN*, Taekyoung KWON**, Jooseok SONG*
* Dept. of Computer Science, College of Engineering, Yonsei University,
134 Shinchon-Dong, Sodaemoon-Gu Seoul 120-749, Korea.
{gbhahn, jssong}@emerald.yonsei.ac.kr
** Dept. of Software Engineering, Sejong University,
98 Gunja-Dong, Gwangjin-Gu, Seoul 143-747, Korea.
tkwon@sejong.ac.kr
Tel : +82-2-365-7966, Fax : +82-2-365-2579

Abstract
From the security aspects, EAP is extensible since a group of authentication mechanisms can be
applied to provide the port-based access control. IEEE 802.1X is a standard for port-based access
control and contains the port access control mechanisms for IEEE 802.11 wireless LANs. The
WLANs are typically regarded as an essential technology for high speed wireless internet, next
generation wired/wireless integrated networks and smart homes. Since the WLAN standard
emerged in 1999, lots of research have been done to resolve the security flaws of WLAN. IEEE
802.1X is one of such proposals and published by IEEE 802.1X WG. Fundamentally, IEEE 802.1X
is based on the authentication mechanisms called EAP methods. This paper compares several
currently proposed EAP methods for IEEE 802.1X. First, we present the shared key based EAP
methods and explain a few of non shared key based EAP methods. Among the non shared key
based EAP methods, we mainly focus on the certificate based methods. Then, we illustrate the
comparative analyses for the shared key based methods with regard to security and compare a
few certificate based methods by regarding several factors. Besides, we present the summarized
features of widely used EAP methods. Most critically, we propose the possible usages of IEEE
802.1X authentication methods in the current integrated communication networks and compare
the respective application scenarios. As an appendix, we FIRST exemplify the message flows of
several EAP methods tunneled in PEAP that is considered as an emerging standard for wireless
LAN authentication method. Then, we summarize the detailed features of several EAP methods.
Index Terms : EAP, IEEE 802.1X Authentication, shared/non shared key based EAP methods,
integrated communication networks

I. Introduction
1.1. Extensible Authentication Protocol
The Extensible Authentication Protocol(EAP) is an authentication framework providing several

authentication methods and runs over the data link layers such as Point-to-Point Protocol(PPP)
or IEEE 802 without requiring IP. The most critical feature of EAP architecture is its flexibility.
This indicates that EAP can be used to select the specific authentication mechanism. Instead of
requiring an authenticator to be updated to support new authentication methods, EAP allows
the use of backend authentication server. The backend authentication server may implement a
few of EAP methods and in this case, the authenticator acts as a pass-through for EAP methods
[1].
The EAP exchange is performed as follows.
[1] An authenticator transmits a Request to authenticate a peer. The Request has a Type field to
show what is being requested. Typically, an authenticator sends an initial Identity Request;
however, an initial Identity Request may not be required, and be bypassed.
[2] The peer sends a Response packet in reply to the valid Request. As with the Request packet,
the Response packet contains a Type field corresponding to the Type field of the Request.
[3] The authenticator sends an additional Request packet, and the peer replies with a Response.
The series of Requests and Responses continues as long as the packets are required. Also, the
authenticator MUST NOT send a Success or a Failure packet while retransmitting or when it
fails to get a response from the peer.
[4] This conversation continues until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests). In this case, the authenticator MUST send an EAP
Failure. Alternatively, the authentication conversation can continue until the authenticator
determines that successful authentication has occurred. In this case, the authenticator MUST
send an EAP Success.
Figure 1 briefly describes the flow of 802.1X authentication occurred in wireless LAN hotspots
system.

N e tw o r k
S e r v ic e

A u th e n tic a tio n
S erver

A c c e ss
P o in t
A u th o riz e d
P o rt

U n a u th o riz e d
P o rt
PAE

P h y s ic a l P o r t

PAE
M o b ile
T e r m in a l

Figure 1. 802.1X Authentication Procedure in Wireless LAN Hotspot System

The advantages of EAP are summarized as follows.

 The EAP can support multiple authentication mechanisms without having to pre-negotiate a
particular one.
The Network Access Server(NAS) devices do not need to understand each method and MAY
act as a pass-through agent for backend authentication server. The authenticators support for
pass-through is optional.
Separation of an authenticator from a backend authentication server simplifies the credential
management and policy decision making.
On the other hand, EAP has the following disadvantages.
For use in PPP, the EAP requires the addition of new authentication type to PPP LCP and thus
PPP implementations will have to be modified to use it. It also strays from the previous PPP
authentication model of negotiating the specific authentication mechanisms during LCP.
The authenticator is separated from the backend authentication server, which complicates the
security analysis and, if needed, key distribution.

1.2. Contribution
Generally, the WLAN has two important security concerns. One is the weak authentication for
network users and the other is the weak encryption for actual data traffic. The former allows the
unauthorized users to access the network resources and the latter allows the attackers to recover
the transmissions. In our view, the robust authentication is critical to prevent the unauthorized
users from obtaining the network access. To resolve the problems of weak authentication, a few
of authentication protocols have been proposed for use with wireless LANs. IEEE 802.1X is the
widely known standard for wireless LAN authentication and it is based on the IETFs EAP. In
detail, IEEE 802.1X illustrates how to perform the EAP directly over the link layer protocol. The
EAP is a transport protocol that can be used by a variety of authentication types known as EAP
methods. IEEE 802.1X can support a number of authentication methods and each of them has its
own merits and flaws. In this sense, it is important to decide the type of authentication used for
IEEE 802.11 WLANs.
In this paper, we review and compare the currently proposed IEEE 802.1X EAP methods. Our
work covers the summarized descriptions for the shared key based and non shared key based
EAP methods. With regard to security, our work carefully evaluates the shared key based EAP
methods and offers the comparative analyses for those methods. Also, our work presents a brief
illustration for some non shared key based methods and compares the certificate based methods
with several factors. Most importantly, we illustrate the practical application scenarios for the
usages of IEEE 802.1X EAP methods in the integrated communications networks and examine
the suitability of respective scenarios. Finally, our work provides a number of examples for the
message flows of several EAP methods tunneled in PEAP. Then, we summarize the additional
features of shared key based and non shared key based EAP methods.
This paper is organized as follows : Section II summarizes and analyzes a few of EAP methods.
Specifically, Section II presents the comprehensive review of shared key based and non shared
key based methods. Besides, Section II evaluates the secrecy of shared key based EAP methods
and illustrates a variety of features of non-shared key based methods. Section III proposes the
actual application scenarios of several authentication methods in the integrated communication
networks and shows the adequacy of using those EAP methods. Section IV concludes this paper.

Finally, Appendix introduces some EAP methods tunneled in PEAP and illustrates the flow of
signaling messages of those methods. In addition, the detailed features of shared key based and
non-shared key based methods are presented.

II. Extensible Authentication Protocol Methods

This section is composed of three subsections. First, Section 2.1 describes the shared key based
EAP methods using either long term secret key or password. We first explain some shared key
based methods with secret key and then present the methods with password. The former, i.e.,
the EAP methods using long term secret key are EAP-Cisco Wireless, EAP-SIM, EAP-AKA, EAP
-Archie, EAP-PSK, EAP-HTTP Digest, EAP-SKE and EAP-SSC. The latter, i.e. the methods using
password are EAP -MD5(Tunneled), SRP-SHA1, EAP-MSCHAP-V2, EAP-SPEKE, EAP-FAST,
EAP-IKEv2 and EAP-LDAP. However, EAP-MD5, EAP-IKEv2 and EAP-LDAP can use both the
secret key and password simultaneously. On the other hand, Section 2.2 covers the non-shared
skey based EAP methods. We first illustrate a number of general non shared key based methods.
The methods include EAP-TLS, EAP-MAKE, EAP-OTP, SecureID EAP, SentriNET, EAP-GPRS.
Then, we show the non-shared key based methods with tunneling. These are EAP-TTLS, PEAP.
Finally, Section 2.3 investigates the shared key based EAP methods with regard to security and
compares the respective features of TLS-based EAP methods. This section is concluded with the
summarization for the variety of features of the most widely used methods. Additional security
features of both shared key and non-shared key based EAP methods are illustrated in Appendix
A.4 and A.5 respectively.

2.1. Shared Key based EAP Methods

2.1.1. EAP-Cisco Wireless
EAP-Cisco Wireless is known as LEAP, i.e., Lightweight EAP and it is built on the MS-CHAP.
LEAP is Cisco proprietary EAP-Type and is designed to overcome the wireless authentication
concerns through the use of dynamic WEP keys or mutual authentication. LEAP inherits a few
of cryptographic weakness from the MS-CHAP and is vulnerable to the dictionary/brute-force
offline attacks. Similar to EAP-MD5, LEAP has some security flaws and thus it cannot be fitted
for use in WLAN [2][26].

2.1.2. EAP-SIM
SIM means Subscriber Identity Module and EAP-SIM is based on the symmetric cryptography
that uses the GSM authentication infrastructure. Specifically, EAP-SIM utilizes the GSM SIM to
provide the authentication and session key generation. It enhances the GSM authentication and
key agreement in such a way that a number of authentication triplets are combined to generate
the authentication responses and session keys of greater strength. Also, EAP-SIM provides the
network authentication, user anonymity support, and fast re-authentication procedure. It offers
an optional support to protect the privacy of subscriber identity [2][7].

2.1.3. EAP-AKA
AKA indicates Authentication and Key Agreement and EAP-AKA depends on the symmetric
key cryptography that uses the UMTS authentication infrastructure. Similar to EAP-SIM, EAPAKA utilizes the UMTS (Universal Mobile Telecommunications System) AKA mechanisms to
provide the authentication and session key distribution. It is not the generic shared key based
EAP method in its design principle and it provides the optional identity privacy support, fast re
-authentication procedure. EAP-AKA is far more evolved than EAP-SIM [2][17].

2.1.4. EAP-Archie
EAP-Archie is based on the symmetric cryptography using the pre-shared keys and it concerns
EAP-PSK very closely. The critical differences between EAP-Archie and EAP-PSK are presented
as follows [2][12].
A few of cryptographic changes, i.e., the use of OMAC in EAP-PSK instead of CBC-MAC, the
use of key derivation scheme, the use of EAX to set up the protected channel and the removal
of AEK key wrap algorithm from EAP-PSK
Several design changes, i.e., the use of TLV format in EAP-PSK instead of message types
Fundamentally, EAP-Archie offers the session establishment and user identity protection [12].

2.1.5. EAP-PSK
PSK means Pre-Shared Key and EAP-PSK relies on the symmetric key cryptography. In case the
authentication is completed successfully, a protected channel is established for both parties to
communicate over. The key features of EAP-PSK are [2][8]:
Simplicity : It must be easy to implement and deploy without any pre-existing infrastructure
Wide applicability : It must be possible to use this method for authentication via any network.
Security : It must be conservative in its cryptographic design and satisfy the security proofs.
Extensibility : It must be possible to append the required extensions to this method whenever
needed.
EAP-PSK regards itself as the successor of EAP-Archie and can substitute MD5-challenge [2][8].

2.1.6. Other Shared Key based Methods using Long Term Secret Key
Besides the aforementioned methods, a few of other shared key based EAP methods with long
term secret key are proposed. At first, EAP-HTTP Digest allows HTTP Digest authentication to
be offloaded from a gateway to an AAA server. This indicates that it may be applied to use with
HTTP servers as well as other protocols which use HTTP as a transport and also require HTTP
digest authentication [2]. Also, EAP-SKE (Shared Key Exchange) is based on the symmetric key
cryptography. It is a method for mutual authentication and generation of per session, per node
EAP master secret session keys. The main concern of EAP-SKE is the network efficiency in the
roaming situations [2][11]. Finally, SSC indicates Secured Smart Channel and EAP-SSC sets up

an EAP secured channel between a smart card and an Authentication Server as well according
to the asymmetric key exchange model as the symmetric key exchange model [2][3].

2.1.7. EAP-MD5
EAP-MD5 is the least secure version of EAP method since it uses the user names and passwords
for authentication. It provides no mutual authentication and no key derivation. Thus, EAP-MD5
is highly vulnerable to the active brute-force attack and dictionary attack. This means that EAPMD5 has a number of security flaws and it cannot be fitted for use in WLAN [2]. On the other
hand, EAP-MD5-Tunneled is a protocol which is proposed to be used as an inner authentication
protocol in the tunneling EAP such as EAP-TTLS or PEAP. Specifically, it allows the passwordchallenge authentication to be performed inside a tunnel. This can be converted into CHAP or
EAP-MD5-Challenge authentication outside the tunnel for forwarding through the RADIUS or
other AAA protocol to a legacy backend authenticator. Thus, it cryptographically corresponds
to the standard CHAP and EAP-MD5-Challenge protocol. Fundamentally, EAP-MD5-Tunneled
does not focus on the provision of a generic shared key EAP method. Instead, it aims the issues
implied by the tunneling EAP methods. EAP-MD5-Tunneled has the same cryptographic flaws
as EAP-MD5 [2][23].

2.1.8. SRP-SHA1
SRP is Secure Remote Password and SRP-SHA1 is based on the symmetric and asymmetric key
cryptography to provide strong password only authenticated key exchange. This is similar to
EAP-SPEKE. In detail, SRP-SHA1 provides strong, password-based authentication which relies
on the cryptographic hashing. SRP-SHA1 is a method which uses the evolved cryptography to
efficiently deal with passwords. It is resistant to the dictionary attacks. Also, it is resistant to the
eavesdropping and active attacks. On the other hand, SRP-SHA1 creates a session key which is
resistant to the man-in-the-middle attacks. In this sense, it can be regarded as a substitute for
EAP-MD5 [2][5].

2.1.9. EAP-MSCHAP-V2
MSCHAP is Microsoft Challenge-Handshake Authentication Protocol and EAP-MSCHAP-V2 is
based on the symmetric key cryptography that uses the MS-CHAPv2 authentication protocol.
EAP-MSCHAP-V2 provides the mutual authentication and has the benefits of password aging,
changing process. From the security aspect, a few of cryptanalysis have been presented on MSCHAP-V1 and V2. However, MS-CHAP-V2 has overcome most of the security flaws found in
MS-CHAP-V1. A noticeable thing is that the use of weak passwords makes EAP-MSCHPA-V2
vulnerable to the dictionary based attacks. Generating the cryptographically random challenges
may increase the overall security of EAP-MSCHAP-V2 [2][10].

2.1.10. EAP-SPEKE
SPEKE indicates Simple Password Exponential Key Exchange and EAP-SPEKE depends on the
symmetric and asymmetric key cryptography to provide a strong password only authenticated

key exchange. In detail, EAP-SPEKE is based on the Diffie-Hellman key exchange that supports
strong authentication by using small passwords. In EAP-SPEKE, devices exchange the random
looking messages and these can not be used by attackers to guess what the password might be.
There is no need for long-lived public/private keys or any sensitive data other than a password
since EAP-SPEKE is based on the public key computations. By using Zero Knowledge Password
Proof (ZKPP) authentication method, EAP-SPEKE protects the user information and passwords
during authentication dialog. Thus, in EAP-SPEKE, even a small or poorly chosen password can
be protected well from a variety of attacks. From the security aspect, EAP -SPEKE is better than
EAP-PSK when a password is used. This mainly stems from the fact that it utilizes the evolved
modern cryptography techniques specially designed to sophisticatedly deal with the ordinary
small passwords. EAP-SPEKE is fast, easy, and not expensive to be deployed in wireless LANs.
In this sense, EAP-SPEKE can be considered as a substitute for EAP-MD5 [2][9][26].

2.1.11. EAP-FAST
FAST is Flexible Authentication via Secure Tunneling and EAP-FAST relies on the symmetric
and asymmetric key cryptography that uses the TLS mechanisms. EAP-FAST enables the secure
communication between client and server by using the pre-shared secret which is used to setup
the mutually authenticated and protected tunnel. Similar to PEAP, EAP-FAST enhances the TLS
by initiating a tunnel setup with symmetric cryptography. Within the secure tunnel, a few EAP
encapsulated authentication methods can facilitate the provision of credentials, authentication
or authorization policies from the server to the client [2][4].

2.1.12. EAP-IKEv2
IKEv2 is Internet Key Exchanges v2 and EAP-IKEv2 depends on the symmetric and asymmetric
cryptography of IKEv2. EAP-IKEv2 uses the payload of IKEv2 and offers the security benefits of
IKEv2 authentication and key agreement. EAP-IKEv2 provides mutual authentication and this
relies on either the symmetric methods using pre-shared keys or the asymmetric methods using
public/private key pairs and certificates. In EAP-IKEv2, it is possible to use the different types
of authentication mechanisms for different directions. Besides, EAP-IKEv2 provides the secure
fragmentation mechanism where integrity protection is performed for each fragment of IKEv2
message [2][25].

2.1.13. EAP-LDAP
EAP-LDAP uses EAP-MD5 and hash algorithm for challenge-based authentication. In detail, it
stores the hash of a users password in the identity store and this can act as the key to EAP-MD5.
In this sense, EAP-LDAP inherits the security flaws from EAP-MD5 and cannot be regarded as
a substitute of EAP-MD5. Specifically, EAP-LDAP provides one-way authentication and MD5
key generation. Also, it provides a means to support other EAP methods when an EAP server
has no knowledge of or access to users cleartext passwords. To provide the integrity protection,
mutual authentication and address most of the security vulnerabilities, it is recommended that
EAP-LDAP should be used with a tunneled authentication method [2][14].

2.2. Non-Shared Key based EAP methods

2.2.1. EAP-TLS
EAP-TLS depends on the asymmetric cryptography using TLS handshake. In detail, it uses the
X.509 certificates for authentication. This means that EAP-TLS requires both the Supplicant and
the Authenticator to exchange their own certificates. As a result, it provides the explicit mutual
authentication and is resilient to man-in-the-middle attacks. After the authentication is finished
successfully, a secure TLS link is established and the link can help to reliably communicate an
unique session key from the Authentication Server to the Authenticator. In EAP-TLS, the X.509
certificates are required on the Supplicant and this imposes significant management overheads.
Depending on the implementation, the certificate may be protected on the client as a passphrase,
PIN, or stored on a smart card. A noticeable drawback of EAP-TLS is that the identity exchange
proceeds in the clear prior to the exchange of certificates. As a result, a passive attack can easily
obtain the user names [2][26][27].

2.2.2. EAP-MAKE
MAKE means Mutual Authentication with Key Exchange and EAP-MAKE is initiated by EAPKEA that depends on the asymmetric cryptography. EAP-MAKE focuses on the simplicity and
scalability. In EAP-MAKE, authentication is provided with the mechanism that is derived from
the Diffie-Hellman scheme. Besides, it can derive and check a common secret key to ensure the
privacy [2][21].

2.2.3. Other Non Shared Key based Methods with Public Key
There are several other non shared key based EAP methods using public key. First, OTP means
one-time password and EAP-OTP defines the OTP and Generic Token Card EAP methods. Both
provide one-way authentication but not provide key generation. The OTP and Generic Token
Card EAP methods are suitable for use on the networks where the physical security is basically
assumed. This means that these methods should not be used through wireless networks or over
the internet in case the EAP conversation is not protected. The protection can be provided using
IPsec or TLS. From the security aspect, EAP-OTP is vulnerable to a few of attacks such as traffic
insertion, snooping and session hijacking [2][16].
On the other hand, RSA Security SecurID EAP and SecurID EAP are OTP methods that depend
on the RSA SecurID authentication token. Specifically, SecurID is either a hardware token card
product or software emulation which is proposed by RSA Security. The SecurID is used for enduser authentication and thus the SecurID mechanism can be used to provide the authentication
over EAP [2][22].
SentriNET is a biometric middleware product adding biometrics to the existing user accounts in
their native location. It is designed to extend the biometrics logon available to the local users to
remote access via NAS or VPN. Fundamentally, it offers a user name to the server that checks
which biometrics have been enrolled and returns information on the suitable hardware types to
the client. The client then captures a live biometric on the corresponding device and returns it to
the server for matching [2].

2.2.4. EAP-TTLS
TTLS is a Tunneled TLS Authentication Protocol and EAP-TTLS is based on the asymmetric key
cryptography using TLS mechanism. EAP-TTLS is proposed to extend EAP-TLS and it is a twophase authentication protocol that establishes the security in phase one and then performs the
authentication in phase two. In phase one, the Authentication Server is first authenticated to the
Supplicant with X.509 certificate. A secure channel is setup by using the TLS and the Supplicant
is authenticated to the Authentication Server through the secure channel in phase two. During
the Supplicant authentication, several legacy PPP authentication protocols such as PAP, CHAP,
MS-CHAP and MS-CHAPv2 can be used. These protocols are protected against eavesdropping,
man-in-the-middle and a few other cryptographic attacks. Besides, EAP-TTLS can support all
methods defined by EAP. In this sense, EAP-TTLS extends the authentication negotiation using
the secure connection setup by TLS handshake. In EAP-TTLS, the TLS handshake may be oneway or mutual. This indicates that only the server is authenticated to the client and the secure
connection established by the handshake is used to authenticate the client to the server. This can
be done with the existing authentication infrastructure such as RADIUS. Compared with EAPTLS, EAP-TTLS has the advantage that it only requires a certificate on the Authentication Server.
This stems from the fact that the certificate on the Supplicant is not ideal for user authentication
for a few of reasons. EAP-TTLS can forward the Supplicant requests to a legacy RADIUS server.
Besides, it supports the identity hiding in which the Authenticator can know of the anonymous
username used to setup the TLS channel at the first phase but it cannot know of the individual
user authenticated during the second phase [2][13][26][27].

2.2.5. EAP-PEAP
PEAP indicates Protected Extensible Authentication Protocol and it depends on the asymmetric
key cryptography by using TLS mechanism. It provides an encrypted and authenticated tunnel
that encapsulates EAP mechanisms. Similar to EAP-TTLS, PEAP is a two-phase authentication.
In phase one, the Authentication Server is authenticated to the Supplicant using X.509 certificate.
A certificate is only required at the Authentication Server. As shown before, a secure channel is
setup using the TLS handshake and thus any other EAP-methods can be utilized to authenticate
the Supplicant to the Authentication Server through secure channel. This is the second phase.
PEAP also supports the identity hiding where the Authenticator can only know the anonymous
username used to establish the TLS channel at the first phase but it cannot know the individual
user authenticated during the second phase. From the security perspective, PEAP uses the TLS
to protect against the rogue authenticators and a group of attacks to compromise the inner EAP
method exchange. PEAP also provides the chaining of several EAP mechanisms, cryptographic
bindings between authentication which is performed by inner EAP mechanisms and the tunnel,
exchanges of arbitrary parameters (TLVs), optimized session resumption [2][18][26][27].

2.3. Comparisons for the Secrecy of EAP Methods

2.3.1. Security Provisions of Shared Key based EAP methods
Although the shared key based EAP methods are convenient, they have several vulnerabilities.

For example, these methods are vulnerable to offline dictionary attacks, where an attacker can
select the guesses from his dictionary of possible passwords. Table 1 summarizes the secrecy
of several shared key-based EAP methods.

Ciphersuite
Negotiation
Mutual
Authentication
Integrity
Protection
Replay
Protection
Confidentiality
Key
Derivation
Dictionary
Attack
Fast Reconnect
Cryptographic
Binding
Session
Independence
Fragmentation
Channel
Binding

EAPSIM
No

EAPAKA
No

EAPFAST

EAPArchie

EAPIKEv2
Yes

EAPLDAP
No

EAPPSK
No

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes
Yes

Yes
Yes

Yes
Yes

Yes

Yes
Yes

No
No

No
Yes

N/A

N/A

Yes

Yes

N/A

Yes

Yes

Yes
N/A

Yes
N/A

Yes

Yes
N/A

No

No
No

Yes

Yes

Yes

Yes

No
No

No
No

Yes
Yes

No
No

Table 1. Security Provisions of Shared Key-based EAP Methods

2.3.2. Features of TLS Based EAP Methods

Table 2 illustrates the detailed features of TLS-based EAP methods [27].

EAP-TLS
Software
Client
Implementations
Supported Client
Platforms
Authentication Server
Implementations by

Cisco, Funk,
Meetinghouse,
Microsoft, Open1X
Linux, Mac OS,
Windows 95/95/ME
/NT/2000/XP
Cisco, Funk, HP,
FreeRADIUS,
Meetinghouse,

EAP-TTLS

PEAP

Funk, Meetinghouse

Microsoft

Linux, Mac OS,

Windows 95/95/ME
/NT/2000/XP
Funk, Meetinghouse

Windows XP

Cisco

Authentication
Methods
Protocol Operations
Basic Protocol
Structure

Fast Session
Reconnect
WEP Integration

Microsoft
Client Certificates

Establish TLS session

and validate
certificates on both
client and server

No

Any

Any EAP Method

Two phase:
(1) Establish TLS
between client
and TTLS server
(2) Exchange attribute
-value pairs
Between client
and server
Yes

Two parts:
(1) Establish TLS
between client
and PEAP server
(2) Run EAP
exchange over
TLS Tunnel
Yes

Server can supply WEP key with external protocol (e.q., RADIUS
extension)
PKI and Certificate Processing
Server Certificate
Required
Required
Required
Client Certificate
Required
Optional
Optional
Cert Verification
Through certificate chain or OCSP TLs extension
Effect of Private Key
Re-issue all server
Re-issue certificate for servers (and client if
Compromise
and client certificates
using client certificates in first TLS exchange)
Client and User Authentication
Authentication
Mutual: Uses digital
Mutual: Certificate
Mutual: Certificate
Direction
certificates both ways for server authentica- for server, and
tion and tunneled
protected EAP
methods for client
methods for client
Protection of User
No
Yes, Protected by TLS Yes, Protected by TLS
Identity Exchange
Table 2. Features of TLS-based EAP Methods

2.3.3. Overall Summary and Comparisons for the widely used EAP Methods
The choice of EAP type depends on the security level and the management overhead required
in the corresponding organization. Table 3 explains the features of widely used EAP methods in
detail. EAP-MD5 only performs one-way authentication. Furthermore, it does not provide the
automatic distribution and refresh of WEP key. This increases the management overhead for
manual WEP key maintenance. EAP-TLS provides the robust security. However, it must install
the certificate for each mobile and the maintenance of PKI infrastructure is the time consuming
task. EAP-TTLS tunnels the TLS and avoids the requirement for installing client side certificate.
Currently, it is one of the most widely used EAP methods. The recently developed EAP method,
i.e., PEAP, is similar to the EAP-TTLS in that it does not require the client side certificate.

802.1X EAP
Features

EAP-MD5

EAP-TLS

EAP-TTLS

PEAP

LEAP

Client Side
Certificate
Server Side
Certificate
WEP Key
Management
Rouge AP
Detection
Authentication
Server
Authentication
Client
Authentication

Installment
Complexity
Dynamic Key Delivery
Wireless Security

Not
Required
Not
Required

Required
Required

Not
Required
Not
Required

Not
Required
Required

Not
Required
Not
Required

No

Yes

Yes

Yes

Yes

No

No

No

No

Yes

One Way

Mutual
Public Key
(Certificate)
Public Key
(Certificate
or Smart
Card)

Mutual
Public Key
(Certificate)
CHAP,
PAP, MSCHAP-V2,
EAP

Mutual
Public Key
(Certificate)

Mutual
Password
Hash

Any EAP
or Public
Key

Password
Hash

Low

High

Middle

Middle

Middle

No

Yes
Most
Secure

Yes
Highly
Secure

Yes
Highly
Secure

Yes
Highly
Secure

No
Password
Hash

Not secure

Table 3. Features of widely recommended EAP methods

III. Proposed Application Scenarios of EAP Methods

3.1. Descriptions for Integrated Communication Networks
The integrated communication networks being introduced in this section can be considered as a
technique to enhance the usage of computing devices by making them available throughout the
physical environment. In principle, the integrated communication networks must provide the
adaptively customized and personalized services to the roaming users via seamless connectivity
between mobile terminals and heterogeneous networks. The primary objective of the integrated
communication networks is to setup an efficient infrastructure where roaming users can obtain
anytime, anywhere services. We expect that the integrated networks must contain the following
features.
- Anytime, anywhere network connectivity through Ethernet based on IP technology
- Seamless user/terminal mobility and access between heterogeneous networks
- Mobile broadband services based on the wireless LANs and cellular networks
The integrated communication networks comprising the wireless LANs and cellular networks
must provide the mobile users the ubiquitous connectivity with laptop computers, notebooks,
PDAs and cellular phones. Currently, several wireless LANs have been implemented as stand
alone entities with proprietary security solutions. This means that the security provisions and
authentication methods may not be compatible with each other. In addition to the IEEE 802.1X
based authentication methods for wireless LANs, the security techniques for cellular networks

must be considered to provide the security services for roaming users between wireless LANs
and cellular networks. In our perspective, the security methods for integrated communication
networks must contain the followings:
- 802.1x based authentication with AAA for Wireless LANs
- Security provisions using UIM, SIM in cellular networks
- 3G-wireless LAN interworking for authentication, accounting
By using the IEEE 802.1X security framework with AAA, we present a number of authentication
scenarios for roaming users in the integrated communication networks. Our approach accepts
different authentication credentials/methods. Figure 2 illustrates a brief view of the integrated
communication networks. This figure presents the connectivity between Home Network and a
few other public LANs/cellular mobile networks.

AAA
Server

WLAN Gateway,
HA, FA

Cellular Mobile Networks

(CDMA, CDMA2000)

AAA
Server
HLR

PDGN(HA)
Public WLAN
(Enterprise,
Public Hotspot)

Access
Point

Access
Point

PDSN (FA)
MSC

Access
Point

Home Gateway

Internet
(Mobile IPv6 based
Backbone Network)

Home Network

BS

MSC

BS

BS

Cellular Mobile Networks

(GSM, UMTS)

AAA
Server

GGSN (HA)

PDA, Notebook

BS

BS

HLR
SGSN (FA)

Home Server
BSC

BSC

Cellular Phone
PC, Printer,
Scanner
Phone

TV, Audio,
Video

BS

BS

BS

BS

BS

Figure 2. Wireless Anytime, Anywhere Networks

As shown in Figure 2, our integrated communication networks model comprises the following
components.

Public Wireless LAN

Access Systems
- IPv6/4 Router
- Access Point :
(IEEE 802.11b/a/g)
- Mobile Node : Notebook,
PDA, Laptop Computer
- AAA Server

Cellular Mobile Networks

(GSM, UMTS)
- GGSN, SGSN, HLR, BSC
- Base Station

Cellular Mobile Networks

(CDMA, CDMA2000)
- PDGN, PDSN, HLR, MSC
- Base Station

- Mobile Node : Cellular

Phone
- AAA Server

- Mobile Node : Cellular

Phone
- AAA Server

Table 4. System Specifications for Integrated Communication Networks

We assume that the mobile terminals in our model have dual mode operations which support
both 3G and Wireless LAN. We can see that the examples of mobile terminals can be notebooks,
PDAs or laptop computers. On the other hand, the cellular phones can access to the ubiquitous
services through the cellular mobile networks. We also assume that the cellular networks and
public wireless LANs are operated by respective service providers. This means that each type of
network keeps its own authentication server providing AAA services. As shown in our model,
the public wireless LAN authentication system is an authentication server and assumes an IEEE
802.1X, EAP based authentication. The access point is based on the IEEE 802.11b/a/g and also
depends on an IEEE 802.1X authentication. The credential types used by the mobile users may
be either the username/password pair or the certificate (e.q., X.509).

3.2. Application Scenarios of EAP Methods

Following figure 3 describes the proposed EAP application scenarios through either the public
WLAN or the cellular mobile networks.

AAA
Server

WLAN Gateway,
HA, FA

Shared Key based or PEAP

Authentication Methods

Cellular Mobile Networks

(CDMA, CDMA2000)

AAA
Server
HLR

PDGN(HA)
Public WLAN
(Enterprise,
Public Hotspot)

Access
Point

Access
Point

PDSN (FA)
MSC

Access
Point

Internet
(Mobile IPv6 based
Backbone Network)

Home Gateway

BS

MSC

BS

BS

Cellular Mobile Networks

(GSM, UMTS)
AAA
Server

EAP-SIM or EAP-AKA
Authentication Methods
Home Network

GGSN (HA)

PDA, Notebook

BS

BS

HLR
SGSN (FA)

Home Server
BSC

BSC

Cellular Phone
PC, Printer,
Scanner
Phone

TV, Audio,
Video

BS

BS

BS

BS

BS

Figure 3. EAP Application Scenario

As a first scenario, we show the case where a mobile user currently resides in the public WLAN
with his mobile terminal and tries to communicate with the device within his home. In this case,
the authentication can be performed with several shared key based EAP methods described in
Section II. Specifically, the mobile terminals access to the authentication server through access
point to perform the authentication process by using the shared key based EAP methods. If the
mobile terminals are determined as legal, they can access to the home network through wireless
LAN gateway. Ultimately, they can communicate with the devices within his home network via

home gateway. Figure 4 and 5 describe the overhead of authentication signaling flows required
by some shared key based authentication methods. A few descriptions for the signaling flows of
respective EAP methods are presented in Appendix A.6.
The signaling overhead can be defined as
Signaling Overhead =

Packet Size of Signaling Flows between Network Entities

As we can see, the signaling overhead represents the sum of packet size for all signaling flows
which are exchanged between the network entities for each method. Since some EAP methods
process the variable length packets, the signaling overhead shown in Figure 4 and 5 may vary
depending on the authentication conditions.

Overhead of Authentication Signaling Flow s

4000
3500

M T - AP

3000
2500
Signaling
2000
Overhead
1500

AP AAA_Home
Total

1000
500
0
1

EAP M ethods

Figure 4. Signaling Overhead of Shared Key Based Methods within Home Network

Overhead of Authentication Signaling Flow s

6000
M T - AP

5000
4000
Signaing
3000
Overhead
2000

AP AAA_V is ited
AAA_V is ited
- AAA_Home
Total

1000
0
1

EAP M ethods

Figure 5. Signaling Overhead of Shared Key Based Methods within Visited Network

The EAP methods shown in Figure 4 and 5 specify the followings.

1 EAP-MD5
3 - EAP-MSCHAP-V2
5 - EAP- Archie

2 - EAP-SRP-SHA1
4 - EAP- SPEKE
6 - EAP- IKEv2

7 EAP- LDAP
Table 5. Authentication Methods used in EAP Application Scenario 1

As described in Figure 4 and 5, among the shared key based methods considered here, EAPMD5, EAP-SPEKE, EAP-MSCHAPv2, EAP-LDAP and EAP-SRP-SHA1 make low overhead for
user authentication and consume a little network bandwidth. However, EAP-IKEv2 and EAPArchie generate significant signaling overhead compared to the other methods. In more detail,
EAP-Archie requires 3344 (octets) in a case where a user resides in his home network and 4868
(octets) in a case where a user resides in the visited network. EAP-IKEv2 requires 1224 (octets)
and 1828 (octets) respectively for both cases. On the other hand, EAP-SRP-SHA1, EAP-SPEKE,
EAP-MSCHAP-V2 and EAP-LDAP require nearly the same signaling load. In detail, EAP-SRPSHA1 consumes 380 (octets) and 256 (octets) for both cases. Besides, EAP-SPEKE, EAP-LDAP
and EAP-MSCHAP-V2 consume 364 and 250 (octets) respectively. EAP-MD5 requires the least
signaling overhead for user authentication. Specifically, it consumes 244 (octets) and 170 (octets)
respectively for both cases. Typically, the shared key based methods are easy to implement and
lightweight in size, computational complexity. Thus, the methods can be simply deployed and
used without any pre-existing infrastructure. This makes the shared key based authentication
methods available for use with public wireless LAN access. From the security aspect, the shared
key based methods are, however, vulnerable to some security attacks such as session hijacking,
dictionary attacks, man-in-the-middle attacks. As the shared key based EAP methods evolve, a
few security-enhanced methods are proposed. Among the shared-key based methods currently
proposed, EAP-FAST, EAP-SRP-SHA1, EAP-SPEKE and EAP-IKEv2 are robust enough to resist
against several security attacks.
Contrary to the shared key based authentication mechanisms, the TLS based EAP methods, i.e.,
EAP-TTLS and EAP-PEAP provide a secure authentication process by replacing the passwords
or shared secrets with client and server-side certificates. Therefore, the TLS based methods may
be recommended in the case where strong security is required and the PKI is already installed.
Since the TLS based methods setup the TLS channel prior to the secondary authentication, these
methods are far expensive compared with the shared key based methods. In our approach, we
focus on EAP-PEAP rather than EAP-TTLS. This stems from the fact that by using EAP-PEAP,
the session key derivation/distribution can be implemented for various credential types such as
certificates, usernames/passwords and SIM cards. As explained before, the use of EAP-PEAP
with other authentication methods ensures strong level security independent of which method
is selected as a secondary authentication method in EAP-PEAP. This indicates that EAP-PEAP
provides the strong keying material, mutual authentication, data origin authentication, dynamic
key distribution and session encryption for mobile terminals, access points and authentication
servers. Finally, EAP-PEAP provides the interoperability and roaming supports considering the
3GPP security requirements. The signaling overhead of several EAP methods with PEAP are
much higher than that of corresponding methods. As stated before, this stems from the fact that
the PEAP based methods requires the setup of TLS channel. Put it concretely, there is a critical
gap between the original methods and the corresponding methods tunneled in PEAP. The gap
becomes the signaling overhead which is required to establish the TLS channel.
As a second scenario, we present the case where a mobile user currently resides in the cellular
networks and tries to communicate with the devices within his home. Here, the authentication
can be performed by using either EAP-SIM or EAP-AKA. To perform the authentication process,

the mobile terminals first access to the authentication server via BSC. If the mobile terminals are
considered as legal, they can access the home network through GGSN(HA) and ultimately, they
can communicate to the devices within the home network via home gateway. EAP-SIM allows a
SIM-card based authentication across WLAN and GPRS/EGPRS wireless networks. Similarly,
EAP-AKA uses the USIM-card for authentication in 3G-WCDAM networks. These mechanisms
depend on cellular service providers infrastructure. Thus, we can see that EAP-SIM and EAPAKA provide the interoperability between the wireless LAN enterprises/public hot spots and
cellular mobile networks. Figure 6 and 7 describe the overhead of signaling flows required by
EAP-SIM and EAP-AKA respectively. As shown in the figures, the overhead for authentication
signaling of EAP-SIM is a little bit larger than that of EAP-AKA. From the security aspect, the
EAP-AKA is, however, more robust than EAP-SIM. Similar to the aforementioned shared key
based EAP methods, the EAP-SIM and EAP-AKA do not generate high signaling overhead for
each user authentication and consume a little network bandwidth.

Overhead of Authentication Signaling Flow s

350
300
250

EAPSIM

Signaling 200
Overhead 150

EAPAKA

100
50
0
M T - AP

AP - AAA_Home

Total

Figure 6. Signaling Overhead of Messages for EAP-SIM, EAP-AKA within Home Network

Overhead of Authenticaiton Signaling Flow s

500
450
400
350
300
Signaling
250
Overhead
200
150
100
50
0

EAPSIM
EAPAKA

M T - AP

AP AAA_V is ited

AAA_V is ited AAA_Home

Total

Figure 7. Signaling Overhead of EAP-SIM, EAP-AKA within Visited Network

VI. Conclusion and future work

Wireless LAN is one of the most essential wireless technologies since it allows robust and highspeed wireless access to several locations. The wireless LAN currently operates with laptops,

PDAs and will soon incorporate cellular phones. To support the growing demand for wireless
LAN technology, a framework to make wireless LAN robust and secure must be defined. As a
method, the implementation of authentication method is important to secure the wireless LAN
deployment. We review a few currently proposed 802.1X EAP methods for IEEE 802.11 wireless
LAN. The 802.1X is an authentication standard using the port-based network access control. It is
emerged to provide authentication and dynamic key distribution by using RADIUS and is used
between mobile terminals and Access Points, while RADIUS is used between Access Points and
authentication servers. We classify the EAP methods into two categories, i.e., shared-key based
methods and non-shared key based methods. We carefully illustrate and compare a group of
authentication methods contained in the respectively categories. We also explain several EAPPEAP based methods to show the authentication mechanisms using certificate and tunneling.
Wireless LAN is regarded as a technique to enable the ubiquitous access and seamless mobility
via a wide range of locations. This indicates that wireless LAN can provide a seamless roaming
across private and public Wireless LANs as well as across wireless LANs and other wired and
wireless networks. We describe a model for integrated communication networks including the
public wireless LANs, cellular mobile networks and home networks. We then propose a usage
model of several 802.1X authentication methods. Our approach aims at providing architectural
scenarios to enable the protected and seamless connectivity in the integrated communication
networks of any size, topology. In detail, we show All-IP based ubiquitous security provisions
with the use of X.509 public key certificates, several legacy and symmetric key based methods.
.
Currently, public wireless LAN services are in their developing phase. Thus, we expect a rapid
evolution of public wireless LAN requirements to support advanced services. Although some
mobile service providers offer the cellular and WLAN services, the security provisions between
them are incompatible due to the architectural limitations in access infrastructures. As cellular
networks integrate IP-based services or vice versa, the mobile users roam seamlessly from their
enterprise network, to public networks/other cellular mobile networks and back to their home
networks. This realizes the seamless roaming which allows the users to remain connected and
securely keep remote applications active while moving anywhere.

Reference
[1] B.Aboba, L.Blunk, J.Vollbrecht, J.Carlson, H.Levkowetz, Extensible Authentication Protocol
(EAP), IETF Network Working Group, RFC 3748.
[2] Florent Bersani, EAP shared key methods: a tentative synthesis of those proposed so far,
IETF Internet Draft, Oct. 2004.
[3] P. Urien, M. Dandjinou, EAP-SSC Secured Smartcard Channel, IETF Internet Draft, drafturien-eap-ssc-01.txt
[4] N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou, EAP Flexible Authentication via Secure
Tunneling (EAP-FAST), IETF Internet Draft, draft-cam-winget-eap-fast-00.txt
[5] J. Carlson, B. Aboba, H. Haverinen, EAP SRP-SHA1 Authentication Protocol, IETF Internet
Draft, draft-ietf-pppext-eap-srp-03.txt
[6] William A. Nace, Peter Yee, James E. Zmuda, PPP EAP KEA Public Key Authentication Protocol, IETF Internet Draft, draft-ietf-pppext-eapkea-01.txt
[7] H. Haverinen, J. Salowey, Extensible Authentication Protocol Method for GSM Subscriber
Identity Modules (EAP-SIM), IETF Internet Draft, draft-haverinen-pppext-eap-sim-13.txt
[8] F. Beresani, The EAP-PSK Protocol: a Pre-Shared Key EAP Method, IETF Internet Draft,

draft-bersani-eap-psk-03.txt
[9] Interlink Networks, EAP Methods for 802.11 Wireless LAN Security
[10] D. Potter, J. Zamick, PPP EAP MS-CHAP-V2 Authentication Protocol, IETF Internet Draft,
draft-dpotter-pppext-eap-mschap-01.txt
[11] L. Salgarelli, EAP SKE authentication and key exchange protocol, IETF Internet Draft, draft-salgarelli-pppext-eap-ske-03.txt
[12] Jesse Walker, Russ Housley, The EAP Archie Protocol, IETF Internet Draft, draft-jwalkereap-archie-01.txt
[13] Paul Punk, Simon Blake-Wilson, EAP Tunneled TLS Authentication Protocol, IETF Internet Draft, draft-ietf-pppext-eap-ttls-04.txt
[14] H. Mancini, EAP-LDAP Protocol, IETF Internet Draft, draft-mancini-pppext-eap-ldap-00.
txt
[15] Bernard Aboba, EAP GSS Authentication Protocol, IETF Internet Draft, draft-aboba-pppext-eapgss-12.txt
[16] L. Blunk, J. Vollbrecht, Bernard Aboba, The One Time Password and Generic Token Card
Authentication Protocols, IETF Internet Draft, draft-ietf-eap-otp-00.txt
[17] J. Arkko, H. Haverinen, Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (EAP-AKA), IETF Internet Draft, draft-arkko-pppext-eap-aka-12.txt
[18] Ashwin Palekar, Dan Simon, Joe Salowey, Hao Zhou, Glen Zorn, S. Josefsson, Protected
EAP Protocol (PEAP) Version 2, IETF Internet Draft, draft-josefsson-pppext-eap-tls-eap-08.txt
[20] A. Salkintzis, The EAP GPRS Protocol, IETF Internet Draft, draft-salki-pppext-eap-gprs02.txt
[21] R. Berrendonner, H. Chabanne, MAKE : Mutual Authentication with Key Exchange, IETF
Internet Draft, draft-berrendo-chabanna-pppext-eapmake-01.txt
[22] S. Josefsson, The EAP SecurID(r) Mechanism, IETF Internet Draft, draft-josefsson-eap-securid
[23] Paul Funk, The EAP MD5-Tunneled Authentication Protocol, IETF Internet Draft, draftfunk-eap-md5-tunneled-01.txt
[25] H. Tschofenig, D. Kroeselberg, Y. ohba, EAP IKEv2 Method, IETF Internet Draft, draft-tschofenig-eap-ikev2-03.txt
[26] International Engineering Consortium, EAP Methods for 802.11 Wireless LAN Security,
http://www.iec.org
[27] OReilly Network, A Technical Comparison of TTLS and PEAP, http://www.oreillynet.c
om

Appendix. Tunneled EAP Methods in PEAP

As we stated above, the IEEE 802.1X provides authentication through port-based access control
and several authentication schemes are proposed. Among the EAP methods, the EAP-MD5 and
EAP-TLS are recommended for use with wireless LANs. Besides, EAP-AKA and EAP-SIM are
required to provide a seamless interconnection between wired broadband cellular network and
wireless LAN. Lots of legacy shared key based EAP methods are vulnerable to several security
attacks and thus are recommended to use with PEAP or TTLS. This means that legacy methods
can be protected by encapsulating such methods by using PEAP or TTLS. Currently, the PEAP
is emerging as the authentication standard for IEEE 802.11 Wireless LAN and will be the most
widely used protocol in the future. PEAP version 2 contains a fix for man-in-the-middle attacks
which are possible when the same credentials are used both inside and outside of PEAP. In this
section, we show a few of shared key based EAP methods tunneled in PEAP. First, we illustrate

the examples for PEAP with password based EAP methods. And then, PEAP with a number of
secret key based EAP methods are described. We also show the detailed features of shared and
non shared key based EAP methods.

A.1. PEAP with Password based EAP Methods

Figure 8 through Figure 13 shows the handshake of PEAP with password based EAP methods.
As described in the figures, the authentication procedures of PEAP are occurred in two parts.
The first is for the establishment of TLS channel and the second part is for the authentication for
network access.

A.1.1. PEAP with EAP-MD5

< TLS Channel Setup >
1. EAP-Request/Identity (Access Point -> Mobile Terminal)
2. EAP-Response/Identity (Mobile Terminal -> Access Point)
3. EAP-Response/Identity (Access Point -> Authentication Server)
4. EAP-Request/Start PEAP (Authentication Server -> Access Point)
5. A series of TLS exchanges (Authentication Server -> Mobile Terminal)
< EAP-MD5 Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-MD5 (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-MD5 (Mobile Terminal -> Authentication Server)
10. EAP-Success (Authentication Server -> Mobile Terminal)

1
2

3
4
5
Authentication
Server
(RADIUS)

6
7
8
9
10

Access
Point

Mobile
Terminal

Figure 8. Authentication Procedures of PEAP with EAP-MD5

A.1.2. PEAP with EAP-MS-CHAP-V2

< EAP-MS-CHAP-V2 Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-MS-CHAP-V2 Challenge (Authentication Server -> Mobile Terminal)

9. EAP-Response/EAP-MS-CHAP-V2 Response (Mobile Terminal -> Authentication Server)

10. EAP-Request/EAP-MS-CHAP-V2 Success (Authentication Server -> Mobile Terminal)
11. EAP-Response/EAP-MS-CHAP-V2 Ack (Mobile Terminal -> Authentication Server)
12. EAP-Success (Authentication Server -> Mobile Terminal)

3
4
5
Authentication
Server
(RADIUS)

6
7
8
9
10
11
12

1
2

Access
Point

Mobile
Terminal

Figure 9. PEAP with EAP-MS-CHAP-V2

A.1.3. PEAP with EAP-SRP-SHA1

< EAP-SRP-SHA1 Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-SRP-SHA1 (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-SRP-SHA1 (Mobile Terminal -> Authentication Server)
10. EAP-Request/EAP-SRP-SHA1 (Authentication Server -> Mobile Terminal)
11. EAP-Response/EAP-SRP-SHA1 (Mobile Terminal -> Authentication Server)
12. EAP-Request/EAP-SRP-SHA1 (Authentication Server -> Mobile Terminal)
13. EAP-Response/EAP-SRP-SHA1 (Mobile Terminal -> Authentication Server)
14. EAP-Success (Authentication Server -> Mobile Terminal)

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10
11
12
13

Access
Point

14

Figure 10. PEAP with EAP-SRP-SHA1

Mobile
Terminal

A.1.4. PEAP with EAP-SPEKE

< EAP-SPEKE Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-SPEKE (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-SPEKE (Mobile Terminal -> Authentication Server)
10. EAP-Request/EAP-SPEKE-Success (Authentication Server -> Mobile Terminal)
11. EAP-Response/EAP-SPEKE-Success (Mobile Terminal -> Authentication Server)
12. EAP-Success (Authentication Server -> Mobile Terminal)

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10
11
12

Access
Point

Mobile
Terminal

Figure 11. PEAP with EAP-SPEKE

A.1.5. PEAP with EAP-IKEv2

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10
11
12

Access
Point

Figure 12. PEAP with EAP-IKEv2

< EAP-IKEv2 Authentication >

6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)

Mobile
Terminal

8. EAP-Request/EAP-IKEv2 (Authentication Server -> Mobile Terminal)

9. EAP-Response/EAP-IKEv2 (Mobile Terminal -> Authentication Server)
10. EAP-Request/EAP-IKEv2-Cert (Authentication Server -> Mobile Terminal)
11. AP-Response/EAP-IKEv2-Cert (Mobile Terminal -> Authentication Server)
12. EAP-Success (Authentication Server -> Mobile Terminal)

A.1.6. PEAP with EAP-LDAP

< EAP-LDAP Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-LDAP-Challenge (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-LDAP-Response (Mobile Terminal -> Authentication Server)
10. EAP-Request/EAP-LDAP-Success (Authentication Server -> Mobile Terminal)
11. EAP-Response/EAP-LDAP-Ack (Mobile Terminal -> Authentication Server)
12. EAP-Success (Authentication Server -> Mobile Terminal)

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10
11
12

Access
Point

Mobile
Terminal

Figure 13. PEAP with EAP-LDAP

A.2. PEAP with Secret Key based EAP Methods

Figure 14 through Figure 16 shows the handshake of PEAP with secret key based EAP methods.

A.2.1. PEAP with EAP-SIM

< EAP-SIM Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-SIM (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-SIM (Mobile Terminal -> Authentication Server)
10. EAP-Request/EAP-SIM-Challenge (Authentication Server -> Mobile Terminal)
11. EAP-Response/EAP-SIM-Challenge (Mobile Terminal -> Authentication Server)
12. EAP-Success (Authentication Server -> Mobile Terminal)

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10
11
12

Access
Point

Mobile
Terminal

Figure 14. PEAP with EAP-SIM

A.2.2. PEAP with EAP-AKA

< AKA Authentication >
6. EAP-Request/Identity (Authentication Server -> Mobile Terminal)
7. EAP-Response/Identity (Mobile Terminal -> Authentication Server)
8. EAP-Request/EAP-AKA-Challenge (Authentication Server -> Mobile Terminal)
9. EAP-Response/EAP-AKA-Challenge (Mobile Terminal -> Authentication Server)
10. EAP-Success (Authentication Server -> Mobile Terminal)

Authentication
Server
(RADIUS)

4
5

6
7
8
9
10

Access
Point

Figure 15. PEAP with EAP-AKA

A.2.3. PEAP with EAP-Archie

< Archie Authentication >
EAP-Request/Identity (Authentication Server -> Mobile Terminal)
EAP-Response/Identity (Mobile Terminal -> Authentication Server)
EAP-Request/EAP-Archie (Authentication Server -> Mobile Terminal)
EAP-Response/EAP-Archie (Mobile Terminal -> Authentication Server)

Mobile
Terminal

Authentication
Server
(RADIUS)

4
5

6
7
8
9

Access
Point

Mobile
Terminal

Figure 16. PEAP with EAP-Archie

A.3. Additional features of shared key based EAP methods

EAP Types
EAP-SIM

EAP-AKA

EAP-Archie

EAP-PSK

EAP-SPEKE

EAP-FAST

Security Features
Limits the traffics towards the AuC, preventing the attackers from flooding the
AuC and from extending the DoS attack from EAP-SIM to the other users of
AuC
Cannot prevent attacks over GSM or GPRS radio networks.
Does not protect EAP method negotiation
Provides protected result indications
Avoid man-in-the-middle-attacks and session hijackings
Limits the traffics towards the AuC, preventing the attackers from flooding the
AuC and from extending the DoS attack from EAP-AKA to the other users of
AuC
Not vulnerable to the brute-force attacks
Does not protect EAP method negotiation
Provides the protected result indications
Avoids man-in-the-middle-attacks and session hijacking
Provides conservative use of cryptography
Immune to man-in-the-middle attacks
Provides session formation
Provides limited denial-of-service protection
Support protected result indications
Not vulnerable to denial of service attacks
Does not provide identity protection, protected ciphersuite negotiation
Provides strong protection against offline-dictionary attack
Prevents man-in-the-middle-attacks
Strong, unlimited length of key can be negotiated
Client and server are authenticated simultaneously
Provides mutual authentication and integrity protection
Immune to passive dictionary attacks
Immune to man-in-the-middle attacks
Flexible to support for most password authentication methods.
Does not protect NAK packets for method negotiation
Provides per packet confidentiality
Strong mutually derived master session keys
Fast re-authentications through session resumption
Provides user identity protection and validation

EAP-IKEv2

EAP-LDAP

Protects against forged clear text EAP packets

Minimization of per user authentication state requirement
Fragmentation support
Crypto-binding to allow a sequence of EAP methods
Provides password-based authentication
Immune to man-in-the-middle attacks
Supports ciphersuite negotiation
Supports protected result indication
Can not provide identity protection
Provides credential reuse
Can not provide acknowledged result indications
Vulnerable to man-in-the-middle-attacks
Table 6. Additional Features of Shared Key based Methods

A.4. Additional features of non-shared key based EAP methods

EAP Types
EAP-OTP

SecurID
EAP

EAP-TTLS

EAP-PEAP

Security Features
Does not provide identity protection, authentication
No keys are derived
Can not be used to provide a keying material
Do not provide a protected ciphersuite negotiation
Provides protection for passive eavesdropping attacks
Does not provide session privacy, session integrity
Does not provide server authentication or protection from active attacks
Vulnerable to man-in-the-middle-attacks
Does not provide protection for session hijacking, replay attacks
Extends authentication negotiation by using the secure connection setup by
TLS handshake
Provides protection against eavesdropping
Provides protection against man-in-the-middle-attack and other cryptographic
attacks
Provides the peer identity privacy by using the TLS
Provides server authenticated, encrypted and integrity protected channel
Provides protection against man-in-the-middle attacks
Table 7. Additional Features of Non-Shared Key based Methods