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 and !A#$AE& has not

currently been compromised.

!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 indows

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 certificate. The more secure the network" the greater the comple*ity and the higher the cost of implementation. Active 0irectory. Additionally a Certificate Authority is often re2uired or a third party

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 pretty much useless. !A was an interim measure until 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 E! was proven !A# ',-#...i( was

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

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& <ased on Transport 5ayer &ecurity8which is based on the !ublic %ey Infrastructure '!%I( EA!$)0= <ased on )0= hash EA!$!&% <ased on pre$shared keys '!&%( EA!$TT5& <ased on Tunnelled Transport 5ayer &ecurity 'TT5&(8most widely used EA!$I%E# <ased on Internet %ey E*change !rotocol version # 'I%Ev#(8it uses asymmetric/symmetric key pairs and passwords

!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 <ased on 1niversal )obile Telecommunications &ystem '1)T&( &ubscriber Identity )odule '1&I)( Authentication and %ey Agreement 'A%A( EA!$>&& <ased on >eneric &ecurity &ervice '>&&(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&" )eetinghouse" )icrosoft"

Funk" Interlink" Cisco" )eetinghouse" Interlink"

Funk" Cisco" FreeRA0I1&" Funk" Interlink" )eetinghouse" Radiator Cisco" Funk"

Funk" Interlink" Radiator

)eetinghouse" )icrosoft" Radiator Funk" )eetinghouse" )icrosoft indows 4!/#---/#--? 4" 5inu*" in?#

Supplicant Client Support Em edded !S Support Platforms supported T"ird-Party Supplicants User Aut"enticatio n Data ase and Server

Radiator Cisco" Funk" Alfa$Ariss" )eetinghouse" )icrosoft" +pen.4 indows 4!/#---/#--? )ac+& y <&0" in?# +T!" 6ovell indows 0omains" 50A!" 60&" 6T 4" )ac+& 5inu*" <&0" in?# Funk" )eetinghouse" +pen.4 n/a

)eetinghouse

n/a

in?#

indows 0omains" Active 0irectory

6T

indows 0omains" Active 0irectory

6T

Active 0irectory Re#uires Server Certificates Re#uires Client Certificates Sin$le Si$n- @es !n Usin$ %indo&s Lo$in Pass&ord Expiration and C"an$e %or's &it" 6o (ast Secure @es @es Roamin$ %or's &it" @es %PA %PA) 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 indows operating system" but standard. There is no native support for 5EA! in any and 6o $ @es 6o @es with EA!$ FA&T @es @es @es @es 6o 6o @es @es 6o

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!.

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 #--A 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 *(lexi le 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 RFCA,=.. !AC provisioning is still officially ork$in$progress" even though there are many implementations. !AC provisioning typically only needs to be done once for a RA0I1& server" client pair. In !hase ." the client and the AAA server uses

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" reCect 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 A,=. sec D.A.A 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.

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 server can 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

there are so many flavors of !EA!. <ehind EA!$T5&" !EA!v-/EA!$)&C3A!v# is the second most widely supported EA! standard in the world. There are client and server implementations of it in )icrosoft" Cisco" Apple" 5inu*" and open source. !EA!v-/EA!$)&C3A!v# is natively supported in )ac +& 4 .-.? and above" indows #--- &!A" indows 4!" indows &erver #--? and above" and indows CE A.#.

The support for inner EA! methods in !EA!v- varies by vendor7 while Cisco9s implementation of !EA!v- supports inner EA! methods EA!$)&C3A!v# and EA!$ &I)" )icrosoft only supports the !EA!v-/EA!$)&C3A!v# mode but not the !EA!v-/EA!$&I) mode. )icrosoft also only supports !EA!v- and doesnEt support !EA!v." so they simply call !EA!v- !EA! without the v- or v. designator. )icrosoft supports another form of !EA!v- which they call !EA!$EA!$T5&" one that Cisco and other third$party server and client software donEt support. !EA!$EA!$T5& does re2uire a client$side digital certificate located on the clientEs hard drive or a more secure smartcard.

!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 shared secret is 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 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. !A later recommended using

Currently" the two most used EA! implementations are EA!$TT5& and !EA!v-. <oth are e*tensively supported by most commonly used operating systems ')icrosoft" )ac +&" and 5inu*( as well as by most network vendors. As mentioned earlier" EA! is a standard that provides a framework for network access clients and authentication servers. EA! does not specify the authentication mechanism itself but the way it is negotiated by the communicating parties. Conse2uently" EA! has no security issues in itself. In contrast" each EA! implementation stipulates some specific valid authentication methods. Conse2uently different EA! implementations may e*hibit specific security vulnerabilities. <elow is a summary of the most common security issues associated to the different EA! implementations. Dictionary Attac's

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" CiscoEs 5EA! relies on a shared secret" the userEs 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 FGH. 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 userEs 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.

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 the vulnerabilities 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 short listing the available implementations. 5A6 is far from simple" however if Assuming that the available we look at the client capabilities first to establish what the client can support and implementations meet our security needs we can then investigate the comple*ity and changes re2uired to implement our security architecture.

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.