Post on 05-Jan-2016
description
Nirmala 1
Wireless Security Researchwith focus on PEAP/TTLS Design
and Implementation
Based on Nirmala Bulusu’s Master Thesis
Nirmala 2
Outline of the Talk
Introduction• WLAN, RADIUS, EAP, TLS,TTLS, PEAP
Design and Implementation of PEAP Module for Free RADIUS
Performance Comparison of PEAP and TTLS
Conclusion and Future Work
Nirmala 4
Why Wireless NetworkingAdvantages:
No "plug ins"
Increased Productivity
Easier network expansion
Flexibility and
Lowers the cost of ownership
Use unlicensed band
Vulnerabilities• Unauthorized user access• Eavesdropping
(network can be tapped using sniffing tools)
Wired Ethernet Network
Access Point
Wireless Network
Wireless Network
Nirmala 5
War Driving
A directional antenna fashioned from a Pringles can is used to search for unsecured access points.
Nirmala 7
Secure Tunnels
The Extensible Authentication Protocol (EAP) uses encryption to create a “tunnel” for data confidentiality.
Nirmala 8
IEEE 802.1x - Architecture IEEE 802.1x is a port-based network access control solution to
authenticate every network user accessing the LAN services. It defines an encapsulation technique that allows for the transmission
of EAP packets between the Supplicant and Authenticator in the LAN environment.
802.1X
MD5 TLS TTLS
802.11PPP
PEAP MS-CHAPv2
CHAP
PAP
EAP
EAP
EAP
Nirmala 9
EAP- Tunneled Transport Layer EAP- Tunneled Transport Layer Security (EAP- TTLS)Security (EAP- TTLS)
• TTLS is a two-stage protocol - establish security in stage one, exchange authentication in stage two.
• The user’s identity and password-based credentials are tunneled during authentication
• Provides: mutual authentication, key generation , client identity privacy and data cipher suite negotiation
Nirmala 10
How PEAP WorksPEAP – Phase 1: Establish TLS Tunnel
• Client/Supplicant associates with AP - EAPOL
• Authentication Server is authenticated to the Supplicant using PKI certificate.
• Supplicant sends machine credentials to authenticator over the established TLS channel
• Authenticator checks Client’s validity and if valid, generates the WEP key
• Authenticator delivers key to supplicant and transitions controlled port status to permit supplicant access to LAN
Nirmala 11
How PEAP Works PEAP – Phase 2: Authenticate Client
• Client is requested user identity
• Supplicant responds by sending user credentials to authenticator
• Authenticator checks validity by looking up the user database
• If user id valid, authenticator extends controlled port status to permit supplicant full access to LAN
• User is logged on to the domain and the network is open
Nirmala 12
The New Proposed ProtocolsEAP-TTLS and PEAP
PEAP – developed by Microsoft, Cisco.
Windows XP is currently the only operating system that supports PEAP.
Only EAP - generic token card
TTLS - developed by Funk and Certicom,
Linux, Mac OS X, Windows 95/98/ME, and Windows NT/2000/XP.
Can use any Authentication Method - CHAP, PAP, MS-CHAP, MS-CHAPv2 and EAP
Research Goal : Design, Implement and perform a comparative analysis of the two protocols.
Nirmala 13
IETF Draft-standard proposed by RSA, Microsoft, Cisco • draft-josefsson-pppext-eap-tls-eap-02.txt.
PEAP is an 802.1x Authentication protocol typically designed for enhancing access control in wireless LANs (WLANs)
It is built on top of two well known protocols• Extensible Authentication Protocol (EAP)• Transport Layer Security (TLS)
What is PEAP ?
Nirmala 14
IEEE 802.1x – How it Works 802.1x is a port-based network access control method to
authenticate and authorize users accessing Local Area Network (LAN) services.
(Port Access Entity)
EAP MessagesEncapsulated
EAPOL
Supplicant System
Authenticator System
Host NIC Ethernet 802.1,
Wireless PC card, etc.
Services offered by the Authenticator
system
Authenticator PAE
Authorize/Unauthorize
Port Unauthorized Controlled
Port
Uncontrolled Port
MAC Enable
Authentication Server System
Authentication Server [AAA]
Any EAP Mostly Radius
The th ree d ifferent elements in IEEE
802.1x
The three elements in IEEE 802.1x
Nirmala 15
802.1x Communication protocols
Protocols to transmit data between Supplicant and the Access Point:– EAP-over-LAN (EAPoL) encapsulated EAP messages in
Ethernet frames– EAP over RADIUS (Remote Access Dial-in User Service)
encapsulates EAP messages in RADIUS packets
RADI US Server
Authenticator Authentication Server
Supplicant
Client/ End-User
Access Point (AP)/ Network Access
Server/ NAS
Ethernet EAPoL EAP EAP-Payload CRC
IP UDP RADIUS EAP-Payload EAP
EAPoL Packet
RADIUS Packet
Nirmala 16
Remote Access Dial-in User Service (RADIUS)
RADIUS is a Client/server protocol and software that supports authentication, authorization, and accounting (AAA) for dial-up, virtual private network, and wireless network access.
Three major components of RADIUS• End User (Supplicant)• RADIUS Client (Access Point, Authenticator or Terminal Server)• RADIUS server (Authentication server).
All RADIUS messages are sent as User Datagram Protocol (UDP) messages on port 1812.
Nirmala 17
Message Exchanges Between RADIUS Client and Server
For PEAP, Password is not sent in this frame
Access Request
RADIUS Server
(NAS-ID, NAS-port, username, password)
Access - Challenge
(“Challenge, enter your password at the prompt” message displayed to the client)
Access Request (New)
(new NAS-ID, NAS-port, username, encrypted password)
Access-Accept or Access-Reject
(Send success or Send another Access Challenge)
RADIUS Client Network
Access Server (NAS)
Nirmala 18
802.1X Authentication Types EAP-TLS (EAP-Transport Layer Security)
• Mutual authentication via PKI based client & server certificates• Supported in XP and soon other Windows versions• Imposes substantial administrative burden to generate, distribute and
manage user certificates.
EAP-TTLS (EAP-Tunneled Transport Layer Security)• User authentication via user ID and password• Supported by Funk Software’s Odyssey• Supports both EAP and non-EAP kind of Authentication methods.
PEAP (Protected EAP)• User authentication via user ID and password• Supported by Cisco Aironet client adapters and Microsoft XP SP1• Supports only EAP authentication methods.
Nirmala 19
EAP–Transport Layer Security EAP-TLS (RFC2716) defines a mechanism for exchange of
messages with both client and server validating each other via certificates providing mutual authentication
Certificate management required for secure operation
Client Certificate Server Certificate
TLS Handshake Phase
Signs
Authenticator Authentication Server
Supplicant
Client/ End-User
Access Point (AP)/ Network Access
Server/ NAS RADI US Server
rootCA
Certification Authority Server
Signs
Certificate exchange
No user-password kind of exchanges
Nirmala 20
Need for PEAP/TTLS
Wireless AP broadcasts all traffic hence can easily collect data if within the broadcast range • PEAP/TTLS answers this by transmitting user-sensitive data in an
encrypted channel - the established TLS tunnel
Weak Wireless Encryption • Using PEAP/TTLS the data within the tunnel cannot be decrypted
without the TLS master secret and the key is not shared with the Access point. Rogue/compromised access points cannot decrypt messages.
MAC address based access control does not work [NetStumbler]• Use TLS-based authentication mechanisms to tunnel user credentials.
EAP-TLS administrative overhead• With PEAP/TTLS only server side PKI infrastructure based digital
certificates are used to authenticate EAP servers. No need to install and maintain Client side certificates.
Nirmala 21
EAP-Tunneled Transport Layer Security (EAP-TTLS)
Is a two-phase protocol - establish security in stage one, exchange authentication in phase two.
The user’s identity and password-based credentials are tunneled during authentication The AAA server can proxy the user authentication to AAA/H (e.g., LDAP, Active
Directory) server.
TTLS Architectural Model
Client Access Point
TTLS AAA
Server
AAA /H Server
PPP/EAPoL RADIUS RADIUS
Secure password authentication tunnel
Secure data tunnel
PKI certificates
USER Database
Nirmala 22
Protected EAP (PEAP)
Two Phase Protocol: Establish TLS connection, start a second EAP authentication process inside encrypted tunnel.
Client is authenticated in the second phase using any EAP authentication mechanism (Generic Token Card, One-Time-Password, MS-CHAPv2)• MS-CHAPv2 : Microsoft Challenge-Handshake Authentication Protocol
PEAP addresses the weaknesses of EAP by protecting user-credentials, standardizes key exchanges, supports fragmentation, fast reconnects and seamless transition.• Fast reconnection: Do quick re-authentication by passing only session
keys. The session can be resumed without having to perform PEAP Phase 1 or 2.
• Seamless transition: uses the connection re-establishment mechanism provided by the TLS handshake protocol.
Nirmala 23
Phase 1- Establish TLS Tunnel
(User-name)
/Start
Exchange Series of TLS messages
User Validates server certificate
RADIUS server sends Certificate chain to Client
AP only pass-through device from this point
Nirmala 24
Phase 2- Authenticate Client
Challenge String
Response to challenge string & user password
EAP- Success message
Session key, encrypted WEP key
Nirmala 26
FreeRADIUS Server Code Organization
Handles requests through a module interface Radius Load Module [RLM]
Module has four components that act on RADIUS requests at different stages of processing the request
• Authorization: Process of obtaining information about the user from external source & determining the type of authentication protocol to be used.
• Authentication: Process of validating a User’s Identity. • Pre-Accounting:Decides whether to proxy the request • Accounting :This records the request in the RADIUS log
A module declares which components it supports by putting function pointers in its "module_t rlm_* ” structure.
Nirmala 27
Free RADIUS Code Directory
Structure
rlm_mschap
radiusd
doc share libltdl raddb src
modules include main include test
rlm_eap rlm_unix rlm_ldap rlm_sql
types eap.c eap.h rlm_eap.c rlm_eap.h
rlm_eap_tls rlm_eap_leap rlm_md5 rlm_eap_peap rlm_eap_ttls
rlm_eap_peap.h peap.c rlm_eap_peap.c Makefile
The new developed Software
Nirmala 28
Module Behavior Add module inside the modules{} block of the
radiusd.conf file. module_name defined in the block is used to load the module.
Each configured module calls its own init() method.
The instantiate() method is called next. It is given a handle to the configuration block holding the parameters.
Finally a detach() method is called when server is shut- down to release the allocated resources.
Nirmala 29
modules {eap {
default_eap_type = peaptls{} …peap { default_eap_type = mschapv2 }…
} …}…# eap sets the authorize type as EAPauthorize { …
eap}# eap authentication takes place.authenticate { …
eap} …
Example - radiusd.conf
Nirmala 30
The rlm_eap_peap module Deals with the standard attach, detach, and authenticate
interfaces. The rlm_eap_peap module does not have an initiate()
interface. • PEAP is a protocol on top of TLS, so before initiating PEAP we
have to initialize the TLS session.
/* rlm_eap_peap.c - Contains interfaces called from the main module EAP */ EAP_TYPE rlm_eap_peap = {
"eap_peap", /* module_name */eappeap_attach, /* attach */NULL, /* No peap initialization interface*/NULL, /* No need for authorization interface*/eappeap_authenticate, /* authentication */eappeap_detach /* detach */
};
Nirmala 31
PEAP Phase 1- Implementation
Handler is sent to the eaptls_process function which processes the EAP request & returns the status code.
If the status code returned is a Success then the PEAP module proceeds to decode the tunneled attributes
If the status code returned is a Fail then the PEAP module interprets it as a failure in establishing the TLS session and returns back to the eaptls_process method for ending the session.
Nirmala 32
The EAP-TLV Method
EAP-TLV is a payload with standard Type-Length-Value (TLV) objects. • Used to carry arbitrary parameters between the EAP peer and
the EAP server.
The PEAP tunnel success/failure packet contains a Result TLV. • The Result TLV packet is used to indicate success or failure of
the PEAP tunnel.
They are sent in the TLS channel - Phase 2. • Packets are protected from being spoofed by an attacker.
Nirmala 33
EAP –TLV Packet Formats
C o d e : 1 - R e q u e s t 2 - R e s p o n s eI d e n t i f i e r : U s e d t o m a t c h r e s p o n s e t o r e q u e s tT y p e : 3 3 ( E A P - T L V )L e n g t h : T h e L e n g t h f i e l d i n d i c a t e s t h e l e n g t h o f
t h e E A P p a c k e t i n c l u d i n g t h e C o d e , I d e n t i f i e r , L e n g t h , T y p e , a n d T L S d a t a
D a t a : T h e D a t a f i e l d i s o f v a r i a b l e l e n g t h , a n d c o n t a i n s E A P - T L V T L V s
3 1 C o d e I d e n t i fi e r
0 7 8 1 5 1 6
T y p e
L e n g t h
D a t a … .
E A P – T L V P a c k e t
3 1 M T L V T y p e
0 1 2
1 5 1 6 L e n g t h R
S t a t u s
M / R : 1 - M a n d a t o r y T L V 0 - R e s e r v e dT L V T y p e : 3 - ( S u c c e s s / F a i l u r e )L e n g t h : 2S t a t u s : C o n t a i n s v a l u e
1 - S u c c e s s 2 - F a i l u r e
R e s u l t T L V P a c k e t F o r m a t
Nirmala 34
Implementation – EAP-TLV User credentials, the state of the message exchange
and the Status i.e the Result TLV has to be passed through the encrypted channel. • A data structure to store these parameters is defined• Two functions for explicitly framing the result TLV
packets have been implemented
/* eap_peap.h - PEAP header file*/#define TLV_SUCCESS 1#define TLV_FAILURE 2#define PW_EAP_TLV 33 typedef struct peap_tunnel_t {
VALUE_PAIR *username;VALUE_PAIR *state;int status; /* Checks for Result TLV status */
} peap_tunnel_t;static int eappeap_success(EAP_HANDLER *handler, tls_session_t *tls_session)static int eappeap_failure(EAP_HANDLER *handler, tls_session_t *tls_session)
Nirmala 35
PEAP Phase 2- Implementation Starts with the eappeap_authenticate () interface
receiving the EAP_TLSOK status code from the eaptls_process function
The function proceeds to read and decrypt the tunneled data from the SSL session using the in built SSL functions .
Next it allocates a new request data structure and adds the tunneled attributes to the request.
It then calls the rad_authenticate () function with the new request packet as the parameter to handle the tunneled EAP-Type MS-CHAPv2.
Nirmala 36
PEAP Phase 2- Implementation
Next it reads the Response Packet received from the rad_authenticate function.
IF the status field = TLV_SUCCESS, then Phase two of the protocol has been successful and the server can proceed to generate the MPPE (Microsoft Point–to-Point Encryption) keys according to the RFC 2716 [EAP-TLS].
Any response messages in the VALUEPAIR format need to be converted to the tunneled data format.
Nirmala 39
Client/Server Machine Configurations
Machine Spec IP Address OS Software
wiper.uccs.edu1.8 Ghz, 1 GB RAMRADIUS Server and
DHCP server
128.192.61.132 RedHat 9.0Running Linux
2.2.20-19.9 kernel
FreeRadiusModified
CVS snapshot radiusd-
09.03.03.tar.gz
willow.uccs.eduAccess Point
Cisco Aironet 1200
128.192.61.130 RedHat 9.0 Running Linux
2.2.20-19.9 kernel
Cisco 1200 series
Software
Toshiba – 366 Mhz, 512 MB
Wireless ClientUsing Cisco Aironet
350 PC Card
Dynamic IP address
128.192.61.144to
128.98.61.152
RedHat 6.2 running Linux 2.2.20-19.9
kernel
Open1x XsupplicantVersion 9.0
Hobbit – 1 Ghz Dell Optiplex, 512 MBWireless Client
Using Cisco Aironet 350 PCI Card
Dynamic IP address
128.192.61.144to
128.98.61.152
Windows XP-SP1And RedHat 9.0 Running Linux 2.2.20.9 kernel
Open1x Xsupplicant for
Linux and built in Service Pack for
XP
Nirmala 40
Performance Impact of Clients’ Processor Speed on PEAP & TTLS Purpose:
Investigate the impact of Client’s processor speed on the time taken to process the Client requests and to see the capacity of the server to handle multiple requests coming from the Clients.
Number of Tests Performed:
Three Tests performed - Toshiba machine – 366Mhz, Hobbit machine – 996 Mhz and with two clients having simultaneous access to the server.
Nirmala 41
PEAP vs TTLS on Toshiba machine
PEAP vs TTLS[Toshiba - 366.604mhz]
500600700800900
100011001200130014001500
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e in
ms
ec
TTLS
PEAP
PEAP TTLS
Average 1046 949
Variance 8142 12060
Nirmala 42
PEAP vs TTLS on Hobbit machine
TTLS vs PEAP [hobbit - 996.785mhz]
600
700
800
900
1000
1100
1200
1300
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No of Times
Tim
e in
msec
TTLS
PEAP
PEAP TTLS
Average 983 911
Variance 10 356
Nirmala 43
PEAP vs TTLS Simultaneous Access of Clients
TTLS vs PEAP [Running Requests Simultaenoulsy From Toshiba
and Hobbit]
500600700800900
100011001200130014001500
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No of Times
Tim
e in
ms
ec
TTLS
PEAP
PEAP TTLS
Average 1006 947
Variance 23707 12387
Nirmala 44
Result Analysis
TTLS out performing PEAP on an average by 8% At lower processor speeds - TTLS was outperforming
PEAP by 10% At higher processor speeds – the performance
difference is around 7% When running simultaneously with two clients it shows
a performance difference of only 6% TTLS and PEAP both show low data variance.
• PEAP had almost negligible variance with a higher processor speed Client.
Processor speeds influencing PEAP relatively more as compared to TTLS
Nirmala 45
Sensitivity study of PEAP & TTLS with Client stationed at varying
distances Purpose:
To study the impact on the performance of the two protocols by introducing packet loss or signal degradation with increasing distances between wireless Client and AP.
Number of Tests Performed: Five Tests performed at distance ranges of approximately 25, 30, 45, 55 and 65 feet. Some tests were done behind walls and closed doors to see the impact of line of sight.
Nirmala 46
PEAP-TTLS Performance Comparison For Distance Range ~30 ft
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
1 10 19 28 37 46 55 64 73 82 91 100
No. of Runs
Tim
e in
ms
ec
PEAP
TTLS
PEAP vs TTLS Distance Range ~ 30ft
Nirmala 47
PEAP-TTLS Performance Comparison For Distance Range ~25 ft [Behind Closed Doors and Walls]
500
1000
1500
2000
2500
3000
3500
1 10 19 28 37 46 55 64 73 82 91 100
No. of Runs
Tim
e in
ms
ec
PEAP
TTLS
PEAP vs TTLS Distance Range ~ 25ft
Nirmala 48
PEAP-TTLS Performance Comparison For Distance Range ~45 ft
500
1000
1500
2000
2500
3000
3500
4000
4500
1 10 19 28 37 46 55 64 73 82 91 100
No. of Runs
Tim
e in
ms
ec
PEAP
TTLS
PEAP vs TTLS Distance Range ~ 45ft
Nirmala 49
PEAP-TTLS Performance Comparison For Distance Range ~55 ft
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
1 10 19 28 37 46 55 64 73 82 91 100
No. of Runs
Tim
e in
ms
ec
PEAP
TTLS
PEAP vs TTLS Distance Range ~ 55ft
Nirmala 50
PEAP-TTLS Performance Comparison For Distance Range ~65 ft [behind Closed Doors and Walls]
500
1000
1500
2000
2500
3000
3500
4000
4500
1 10 19 28 37 46 55 64 73 82 91 100
No. of Runs
Tim
e in
ms
ec
PEAP
TTLS
PEAP vs TTLS Distance Range ~ 65ft
Nirmala 51
PEAP-TTLS Average Performances over varying Distances
800
900
1000
1100
1200
1300
1400
1500
DIST1 DIST2 DIST3 DIST4 DIST5
Distance Range
Ave
rag
e-T
ime/
mse
c
PEAP
TTLS
PEAP vs TTLS Average Performance
Nirmala 52
Variance Data for PEAP and TTLS over Varying Distances
0
50000
100000
150000
200000
250000
Dist1 Dist2 Dist3 Dist4 Dist5
Distance
Vari
an
ce
PEAP
TTLS
PEAP vs TTLS Variance Data
Nirmala 53
Result Analysis
As Client goes farther away from the access point the performance of both the protocols degrades.
At a lower distance range there is negligible performance difference between PEAP and TTLS – TTLS performing 1% better.
With increasing distance range average performance difference increases - TTLS performs 20 % better at ~65 feet range.
Data collected highly variant for PEAP as compared to TTLS at closer distances but at the farthest point of ~65 feet TTLS data showed higher variance than PEAP.
Nirmala 54
PEAP & TTLS Resilience Tests
Purpose: To study the tolerance capacity of the protocols towards network transient behavior.
Number of Tests Performed: Five Tests performed. The network interface at the RADIUS server end is brought up and down over different time periods by running a Perl script.
Note: A constant downtime of 3 sec has been used in all tests. • At first this was chosen randomly. But later by changing
downtime it seemed to be making less difference to the performance as compared to changing network uptime.
Nirmala 55
PEAP-TTLS Resilience Test with Network Uptime 5.0 sec and Downtime 3 sec
05
101520253035404550556065
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e i
n s
ec
TTLS
PEAP
PEAP vs TTLS Network Uptime 5.0 sec
PEAP TTLS
Average 12 6
Variance 266 84
Nirmala 56
PEAP-TTLS Resilience Test with Network Uptime 4.5sec and Downtime 3sec
0
5
10
15
20
25
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e i
n s
ec
TTLS
PEAP
PEAP vs TTLS Network Uptime 4.5 sec
PEAP TTLS
Average 9 8
Variance 105 95
Nirmala 57
PEAP-TTLS Resilience Test with Network Uptime 4.2sec and Downtime is 3sec
0
5
10
15
20
25
30
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e i
n s
ec
TTLS
PEAP
PEAP vs TTLS Network Uptime 4.2 sec
PEAP TTLS
Average 12 12
Variance 106 118
Nirmala 58
PEAP-TTLS Resilience Test with Network Uptime 4.0sec and Downtime 3sec
0
5
10
15
20
25
30
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e i
n s
ec
TTLS
PEAP
PEAP vs TTLS Network Uptime 4.0 sec
PEAP TTLS
Average 18 16
Variance 50 91
Nirmala 59
PEAP-TTLS Resilience Test with Network Uptime 3.9sec and Downtime 3.0sec
05
1015202530354045505560
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e i
n s
ec
TTLS
PEAP
PEAP vs TTLS Network Uptime 3.9 sec
PEAP TTLS
Average 25 26
Variance 437 390
Nirmala 60
Result Analysis
Client performance degrades as the network interface uptime gets shorter.
At 3.8 sec uptime both PEAP and TTLS protocols failed to recover.
The average performance of TTLS as compared to PEAP is negligible
Where difference was large the variance difference between the two also has been relatively big.
Nirmala 61
PEAP & TTLS Stress Tests
Purpose: To study the performance of the two protocols when run for a longer period of time.
Number of Tests Performed: Two Tests performed – One for Each Protocol. Each test was run for over 15 hours
Nirmala 62
PEAP STRESS TEST
0
1000
2000
3000
4000
5000
6000
1 200 399 598 797 996 1195 1394
No. of Runs
Tim
e i
n m
se
c
PEAP
Stress Test - PEAP
Average1011
Nirmala 63
TTLS STRESS TEST
0
1000
2000
3000
4000
5000
6000
7000
1 200 399 598 797 996 1195 1394
No. of Runs
Tim
e i
n m
se
c
TTLS
Stress Test - TTLS
Average1099
Nirmala 64
Result Analysis
Both protocols passed the stress tests. Both authenticated the Client all times.
The peaks can be attributed to the fact that in some of
the cases the Client got authenticated in the second or third trial of authentication
The peaks reached by TTLS are much more frequent and higher as compared to PEAP - Over a longer time period TTLS shows more variance than PEAP
Nirmala 65
MAC Address Spoofing Test
Purpose: Investigate if by spoofing the MAC address an attacker can gain access to a wireless network that relies on tunneled encryption like PEAP/TTLS for authenticating wireless Clients.
Number of Tests Performed: One test was performed with a Linux Client authenticating using PEAP. Attacker had Windows XP running AiroPeek software for sniffing MAC addresses.
I would like to thank Donovan Thorpe of Computer Services UCCS for his help in performing this test.
Nirmala 66
Result Analysis
The attacker could associate with the Access Point as it had a valid MAC address while eavesdropping the network. Thus passed the first line of defense – MAC address filtering.
The attacker was prompted for the user credentials. This stage could not be by-passed and the attacker could not access the network as the user credentials were in encrypted format and thus could not be sniffed.
Nirmala 68
Conclusion Developed a Radius Server on Linux that supports both
PEAP and TTLS.
PEAP is relatively more influenced by Client’s processor speeds, distance range and network transient nature as compared to TTLS.
Although the higher performance shown by TTLS over PEAP is negligible, it is worth noting that TTLS was outperforming PEAP on an average by 10% in all the tests.
The enhanced Radius Server can serve both Windows and Linux clients.
Nirmala 69
Future Work
Study how to apply the PEAP/TTLS protocols in Mobile Ad-Hoc Networks.
Study the implications of providing Virtual Private Network (VPN) features in addition to encryption of PEAP/TTLS within the wireless Access Point devices.
Develop ways to protect user's identity that is passed in clear between the access point, the RADIUS server, and any other database-backend server by implementing firewalls or other such viable security techniques.