explanation and recommendations for eap implementations

8/13/2019 Explanation and Recommendations for EAP Implementations

1/13

Explanation and recommendations for EAP Implementations

Introduction

Firstly any wireless security implementation is governed by several factors. These

include but are not limited to

Cost

Ease of implementation

Administrative overhead

Client capabilities

Infrastructure capabilities

Risk

Inherently more secure systems cost more to implement. If we deploy simple

encryption using E!" !A or !A# we have taken some steps to securing our

network in that some effort must go into gathering information to circumvent the

security measures we have implemented on our network.

Currently both E! and !A$T%I! are easily compromised" !A#$AE& has not

currently been compromised. !A and !A# also use authentication for user

authentication. At its most basic level this is !&% '!re &hared %ey( and is known as

!ersonal )ode. !ersonal )ode should not be used for enterprise wireless security.

As implementations become more comple* the cost increases both in terms of

hardware and effort.

+bviously to deploy Enterprise mode !A solutions using ,-#.*/EA! there is

additional hardware primarily a RA0I1& server to interface to either act as an

authentication server or as an interface to an authentication server such as indows

Active 0irectory. Additionally a Certificate Authority is often re2uired or a third party

certificate.

The more secure the network" the greater the comple*ity and the higher the cost of

implementation.


2/13

3owever" the cost of implementation must be analysed alongside the ease of

ongoing administration and risk should the network be compromised. The greater the

risk" the greater the need for security" the greater the cost" etc.

)any wireless deployments will be largely dependent upon the client capabilities.

&everal years ago it was simply encryption and pretty limited until E! was proven

pretty much useless. !A was an interim measure until !A# ',-#.i( was

available. Then there is ,-#.*/EA!.

EAP

,-#.*/EA! is a framework for authenticating and controlling user traffic to a

protected network" as well as dynamically varying encryption keys. ,-#.4 ties a

protocol called EA! 'E*tensible Authentication !rotocol( to both the wired and

wireless 5A6 media and supports multiple authentication methods" such as token

cards" %erberos" one$time passwords" certificates" and public key authentication.

,-#.4 re2uires three entities7

The supplicant$8Resides on the wireless 5A6 client

The authenticator$8Resides on the access point

The authentication server8Resides on the RA0I1& server

The supplicant becomes active on the medium and associates to the access point.

The authenticator detects the client association and enables the supplicant9s port. It

forces the port into an unauthori:ed state so that only ,-#.4 traffic is forwarded. All

other traffic is blocked. The client may send an EA! &tart message" although client

initiation is not re2uired

The authenticator replies with an EA! Re2uest Identity message back to the

supplicant to obtain the client9s identity. The supplicant9s EA! Response packet

containing the client9s identity is forwarded to the authentication server.

The authentication server is configured to authenticate clients with a specific

authentication algorithm. Currently" ,-#.4 for ,-#. 5A6s does not stipulate a

specific algorithm to use. 3owever" this paper focuses on Cisco 5EA! authentication

and assumes that Cisco 5EA! credential verification occurs.

The end result is a RA0I1&$ACCE!T or RA0I1&$RE;ECT packet from the RA0I1&

server to the access point. 1pon receiving the RA0I1& ACCE!T packet" the


3/13

authenticator transitions the client9s port to an authori:ed state" and traffic may be

forwarded.

,-#.4 and EA! )essage Flow

,-#.4 provides the means for a wireless 5A6 client to communicate with an

authentication server to validate the client credentials. ,-#.4 is e*tensible and

allows a variety of authentication algorithms to operate over it.

EAP Types

There are many flavours of EA! some shown below" this illustrates how popular EA!

has become as a security solution.

5ightweight EA! '5EA!( Cisco proprietary8it is a modified version of )&$

C3A!

EA!$T5&


4/13

!EA!v-/EA!)&C3A!v# &imilar in design to EA!$TT5&8however" it only

re2uires a server side !%I certificate8second most used

!EA!v/EA!$>TC Cisco variant8based on >eneric Token Card '>TC(

authentication

EA!$FA&T Cisco proprietary replacement for 5EA!8based on Fle*ible

Authentication via &ecure Tunnelling 'FA&T(

EA!$&I) For >lobal &ystem for )obile Communications '>&)(8based on

&ubscriber Identity )odule '&I)(" a variant of !EA! for >&)

EA!$A%A &&(8it uses %erberos

Popular EAP Types

A summary of the most popular ,-#/* EA! solutions are shown below.

EAP-TLS EAP-TTLS PEAP LEAP

RADIUS

Server

Support

Cisco"

FreeRA0I1&"

Funk" Interlink"

)eetinghouse"

)icrosoft"

Radiator

Funk" Interlink"

)eetinghouse"

Radiator

Cisco" Funk"

Interlink"

)eetinghouse"

)icrosoft"

Radiator

Cisco"

FreeRA0I1&"

Funk" Interlink"

)eetinghouse"

Radiator

Supplicant

Client

Support

Cisco" Funk"

)eetinghouse"

)icrosoft"

+pen4

Alfa$Ariss"

Funk"

)eetinghouse"

+pen4

Funk"

)eetinghouse"

)icrosoft

Cisco" Funk"

)eetinghouse

Emedded!S Support

indows4!/#---/#--?

n/a indows4!/#---/#--?

n/a

Platforms

supported y

T"ird-Party

Supplicants

)ac+& 4"


5/13

Active

0irectory

Re#uires

Server

Certificates

@es

@es 6o

Re#uires

Client

Certificates

@es

6o 6o

Sin$le Si$n-

!n Usin$

%indo&s

Lo$in

@es @es @es

Pass&ordExpiration

and C"an$e

$ @es 6o

@es with EA!$

FA&T

%or's &it"

(ast Secure

Roamin$

6o 6o @es

%or's &it"

%PA and

%PA)

@es @es @es

LEAP '5ightweight E*tensible Authentication !rotocol( is a proprietary EA! method

developed by Cisco prior to the IEEE ratification of the ,-#.i security standard.

Cisco distributed the protocol through the CC4 'Cisco Certified E*tensions( as part of

getting ,-#.4 and dynamic E! adoption into the industry in the absence of a

standard. There is no native support for 5EA! in any indows operating system" but

it is widely supported by third party client software most commonly included with

5A6 'wireless 5A6( devices. 0ue to the wide adoption of 5EA! in the networking

industry" many other 5A6 vendors claim support for 5EA!.


6/13

5EA! uses a modified version of )&$C3A!" an authentication protocol in which user

credentials are not strongly protected and are thus easily compromised. Along these

lines" an e*ploit tool called A&5EA! was released in early #-- by ;oshua right.

Cisco recommends that customers that absolutely must use 5EA! do so only with

sufficiently comple* passwords" though comple* passwords are difficult to administer

and enforce. Cisco9s current general recommendation is to use newer and stronger

EA! protocols such as EA!$FA&T" !EA!" or EA!$T5&.

EAP-(AST *(lexile Aut"entication via Secure Tunnelin$+is a protocol proposal

by Cisco as a replacement for 5EA!. The protocol was designed to address the

weaknesses of 5EA! while preserving the BlightweightB implementation. 1se of

server certificates is optional in EA!$FA&T. EA!$FA&T uses a !rotected Access

Credential '!AC( to establish a T5& tunnel in which client credentials are verified.

EA!$FA&T has three phases. !hase - is an optional phase in which the !AC can be

provisioned manually or dynamically" but is outside the scope of EA!$FA&T as

defined in RFC,=. !AC provisioning is still officially ork$in$progress" even though

there are many implementations. !AC provisioning typically only needs to be doneonce for a RA0I1& server" client pair. In !hase " the client and the AAA server uses


7/13

the !AC to establish T5& tunnel. In !hase #" the client credentials are e*changed

inside the encrypted tunnel.

hen automatic !AC provisioning is enabled" EA!$FA&T has a slight vulnerability

that an attacker can intercept the !AC and subse2uently use that to compromise

user credentials. This vulnerability is mitigated by manual !AC provisioning or by

using server certificates for the !AC provisioning phase.

There is also a vulnerability where a hacker9s A! can use the same &&I0" reect the

users !AC and supply a new one. )ost supplicants can be set to prompt the user to

accept it" and if he does" then he will send his credentials using the inner method to

the hacker" who will then get either a clearte*t password 'EA!$FA&T w/ >TC( or a

vulnerable to dictionary attack )&C3A!v# hash.

It is worth noting that the !AC file is issued on a per$user basis. This is a re2uirement

in RFC ,= sec D.. so if a new user logs on the network from a device" he needs

a new !AC file provisioned first. This is one reason why it is difficult not to run EA!$

FA&T in insecure anonymous provisioning mode. The alternative is to use device

passwords instead" but then it is not the user that is validated on the network.

EAP-TLS is the original standard wireless 5A6 EA! authentication protocol.

Although it is rarely deployed" it is still considered one of the most secure EA!

standards available and is universally supported by all manufacturers of wireless

5A6 hardware and software including )icrosoft. The re2uirement for a client$side

certificate" however unpopular it may be" is what gives EA!$T5& its authentication

strength and illustrates the classic ease of administration/overhead over security

trade$off.


8/13

The security of the T5& protocol is strong" provided the user understands potential

warnings about false credentials. It uses !%I to secure communication to the

RA0I1& authentication server. &o even though EA!$T5& provides e*cellent security"

the overhead of client$side certificates may be its Achilles9 heel.

EAP-TTLS is an EA! protocol that e*tends T5&. It was co$developed by Funk

&oftware and Certicom. It is widely supported across platforms" although there is no

native +& support for this EA! protocol in )icrosoft indows.

After the server is securely authenticated to the client via its CA certificate" the servercan then use the established secure tunnel to authenticate the client. It can use an

e*isting authentication protocol and infrastructure" incorporating legacy password

mechanisms and authentication databases" while the secure tunnel provides

protection from eavesdropping and man$in$the$middle attack. 6ote that the user9s

name is never transmitted in unencrypted clearte*t" thus improving privacy.

PEAP or more correctly PEAPv,EAP-.SC/APv). henever the word !EA! is

used" it almost always refers to this form of !EA! since most people have no idea


9/13

there are so many flavors of !EA!.


10/13

!EA!$EA!$T5& is very similar in operation to the original EA!$T5& but provides

slightly more protection due to the fact that portions of the client certificate that are

unencrypted in EA!$T5& are encrypted in !EA!$EA!$T5&. &ince few third$party

clients and servers support !EA!$EA!$T5&" users should probably avoid it unless

they only intend to use )icrosoft desktop clients and servers.

EAP Security Ris's

In wireless 5A6s" i$Fi !rotected Access '!A( originally recommended EA!$!&%

mainly because small office applications were not re2uired to support IEEE ,-#.*

authentication. EA!$!&% is based on pre$shared keys where a sharedsecretis used

between the two parties using some secure channel. EA!$!&% is a very lightweight

protocol only re2uiring four messages to complete the authentication stage.

Regardless of EA!$!&% simplicity and economy !A later recommended using

EA!$T5& and EA!$TT5& for increased security.

IEEE ,-#.i '!A#( re2uires enterprise$level security. Therefore" in addition to

EA!$T5&/TT5&" !A# devices also support !EA!v-" !EA!v and other EA! types.

Currently" the two most used EA! implementations are EA!$TT5& and !EA!v-.


11/13

A dictionary attack is a techni2ue for defeating a code or authentication mechanism

by trying each word from a dictionary" a list of common words" and encoding it the

same way the original passphrase was encoded.

0ictionary attacks differ from brute$force attack on the fact that only the most likely

words are tried.

&everal EA! implementations are vulnerable to dictionary attacks. For instance"

Ciscos 5EA! relies on a shared secret" the users logon password. Implementations

lacking strong password policies can easily be compromised with dictionary attacks.

As a conse2uence of this vulnerability Cisco developed EA!$FA&T to provide better

protection against dictionary attacks. 3owever" EA!$FA&T is vulnerable to )it)

attacks as e*plained below.

EA!$>&& is another e*ample of an EA! implementation vulnerable to dictionary

attacks. >&& relies on the %erberos protocol" which is itself vulnerable to dictionary

attacks GH.

Plaintext Attac's

EA! implementations that rely on clear$te*t authentication using RA0I1& 'even

within a protected tunnel( are vulnerable to known$plainte*t attacks. In a known$

plainte*t attack" the attacker uses samples of both the plainte*t and its encrypted

version to reveal further secret information such as the secret encryption key.

EA!$I%E# and EA!$TT5& are e*amples of EA! implementations that may use

password$based authentication '!A!( and therefore are vulnerable to this type of

attack. In !A!$based authentication" passwords are transmitted unencrypted.

.an-in-t"e-middle Attac's *.it.+

Tunnelling protocols such as T5& and TT5& offer a server$authenticated tunnel that

secures both the authentication method and the users identity. +riginal

implementations of EA! that are based on these protocols may also be vulnerable to

man$in$the$middle ')it)( attacks.

In a )it) attack" a rogue client assumes the identities of both the client and the

server in order to intercept packets from one device and send modified packets to the

other device.


12/13

The main reasons for these vulnerabilities are

1sing legacy client authentication protocols that run inside the authenticated

tunnel.

Clients cannot or do not properly authenticate the server" even when the

authentication protocol is used within a supposedly server$authenticated

tunnel.

In a nutshell" the problem arises when the client re$use a legacy authentication

mechanism 'for instance" plain EA!( vulnerable to )it) within the secured tunnel.

Also" if the client does not support mutual authentication or some form of session key

agreement" then the backend server cannot be sure that the identity of the client

using the legacy authentication protocol and the identity of the client endpoint are the

same.

The same )it) vulnerability has also been found on the first !EA!v- implementation

for )icrosoft indows 4! &!. The problem was later corrected for &!#.

Another EA! implementation vulnerable to )it) attacks is EA!$FA&T" the protocol

Cisco developed as replacement for 5EA!. EA!$FA&T was designed to address thevulnerabilities of 5EA! while keeping its simplicity and economy. 3owever" the

automatic private key provisioning mechanisms reuse legacy authentication methods

that make the authentication model vulnerable to the same )it) attacks all other

tunnelled implementations are e*posed to.

Fortunately" several solutions to the problem of )it) attacks have been suggested

since the original research on this issue was first published in #--?.

Summary

It is clear that choosing a solution to secure the 5A6 is far from simple" however if

we look at the client capabilities first to establish what the client can support and

short listing the available implementations. Assuming that the available

implementations meet our security needs we can then investigate the comple*ity and

changes re2uired to implement our security architecture.


13/13

If there is no native implementation that meets our security re2uirements then we

need to consider third party supplicants installed on the devices or changing the

devices" this obviously adds another level of comple*ity in both the deployment and

administrative overhead. Fortunately most enterprise class wireless solutions support

a variety of security implemetations.

e also need to look at technical needs" for instance implementing fast secure

roaming is not supported on many implementations which is desirable for voice" as

people can walk around between access points while on a call" but less of an issue

for laptop users who are generally static when using their device.

e also need to consider our current infrastructure" is it ready for a wireless network"

what changes will be re2uired to implement the 5A6" also can you leverage some

of the security principles to other parts of the network such as wired ,-#.*

ireless networks have come a long way in a few short years and are now being

adopted by all industry sectors. Additional measures may be considered as part of

the 5A6 security implementation such as wireless I0&/I!& dependent upon the

risk analysis of your individual security re2uirements.

Also there may be additional re2uirements for reporting" management or regulatory

re2uirements such as &arbanes +*ley etc that may need to be taken into account

and weighed against risk versus cost versus administrative overhead.

explanation and recommendations for eap implementations

Documents