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
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.
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.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].
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
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
Windows XP
Cisco
Authentication
Methods
Protocol Operations
Basic Protocol
Structure
Fast Session
Reconnect
WEP Integration
Microsoft
Client Certificates
No
Any
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
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
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
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
As shown in Figure 2, our integrated communication networks model comprises the following
components.
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).
AAA
Server
WLAN Gateway,
HA, FA
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
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
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 =
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.
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
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
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.
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
EAPSIM
EAPAKA
M T - AP
AP AAA_V is ited
Total
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
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.
1
2
3
4
5
Authentication
Server
(RADIUS)
6
7
8
9
10
Access
Point
Mobile
Terminal
3
4
5
Authentication
Server
(RADIUS)
6
7
8
9
10
11
12
1
2
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
11
12
13
Access
Point
14
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
11
12
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
11
12
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
11
12
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
11
12
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
10
Access
Point
Mobile
Terminal
Authentication
Server
(RADIUS)
4
5
6
7
8
9
Access
Point
Mobile
Terminal
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
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