Wireless Security Research with focus on PEAP/TTLS Design

Wireless Security Research with focus on PEAP/TTLS Design and Implementation Based on Nirmala Bulusu’s Master Thesis Nirmala 1

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 2

Introduction WLAN, RADIUS, EAP, TLS, TTLS and PEAP Nirmala 3

Why Wireless Networking Advantages: No "plug ins" Increased Productivity Easier network expansion Flexibility and Wireless Network Wired Ethernet Network Lowers the cost of ownership Use unlicensed band Wireless Network Access Point Vulnerabilities Unauthorized user access Eavesdropping (network can be tapped using sniffing tools) Nirmala 4

War Driving A directional antenna fashioned from a Pringles can is used to search for unsecured access points. Nirmala 5

Parking Lot Attack Nirmala Doonesbury 6

Secure Tunnels The Extensible Authentication Protocol (EAP) uses encryption to create a “tunnel” for data confidentiality. Nirmala 7

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. P A P MD5 TLS C H A P E A P TTLS EAP PEAP MS-CHAPv2 EAP 802.1X Nirmala PPP 802.11 8

EAP- Tunneled Transport Layer 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 9

How PEAP Works PEAP – 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 10

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 11

The New Proposed Protocols EAP-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, MSCHAP, MS-CHAPv2 and EAP Research Goal : Design, Implement and perform a comparative analysis of the two protocols. Nirmala 12

What is PEAP ? 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) Nirmala 13

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. The three elements in IEEE 802.1x Supplicant System Host NIC Ethernet 802.1, Wireless PC card, etc. Authentication Server System Authenticator System EAPOL Services offered by the Authenticator system Controlled Port Authenticator PAE (Port Access Entity) EAP Messages Encapsulated Port Unauthorized Authorize/Unauthorize Uncontrolled Port MAC Enable Nirmala Authentication Server [AAA] Any EAP Mostly Radius The th ree d ifferent elements in IEEE 802.1x 14

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) Access Point ( AP) / encapsulates EAP messages in RADIUS packets Network Access Client/ End- User Supplicant Ethernet EAPoL RADI US Server Server/ NAS Authenticator EAP EAP- Payload Authentication Server CRC EAPoL Packet RADI US Packet Nirmala IP UDP RADI US EAP EAP- Payload 15

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 16

Message Exchanges Between RADIUS Client and Server RADIUS Client Network Access Server (NAS) RADIUS Server Access Request (NAS-ID, NAS-port, username, password) Access - Challenge For PEAP, Password is not sent in this frame (“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) Nirmala 17

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 18

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 No user-password kind of exchanges Signs Certification Authority Server rootCA Client Certificate Client/ End- User Supplicant Signs Server Certificate Access Point ( AP) / Network Access Server/ NAS Authenticator RADI US Server Authentication Server TLS Handshake Phase Nirmala Certificate exchange 19

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 20

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. PKI certificates Client PPP/ EAPoL Access Point RADI US TTLS AAA Server USER Database RADI US AAA /H Server Secure password authentication tunnel Secure data tunnel Nirmala TTLS Architectural Model 21

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 usercredentials, 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 22

Phase 1- Establish TLS Tunnel (User-name) /Start AP only passthrough device from this point Exchange Series of TLS messages User Validates server certificate Nirmala RADIUS server sends Certificate chain to Client 23

Phase 2- Authenticate Client Challenge String Response to challenge string & user password EAPSuccess message Session key, encrypted WEP key Nirmala 24

PEAP Protocol Implementation Details Nirmala 25

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 26

Free RADIUS Code Directory Structure radiusd doc raddb src share libltdl include main modules include test rlm mschap rlm unix rlm eap rlm ldap rlm sql eap.c The new developed Software rlm eap leap rlm eap.c rlm md5 rlm eap peap rlm eap peap.c Nirmala types eap.h peap.c rlm eap tls rlm eap peap.h rlm eap.h rlm eap ttls Makefile 27

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 shutdown to release the allocated resources. Nirmala 28

Example - radiusd.conf modules { eap { default eap type peap tls{ } peap { default eap type mschapv2 } } } # eap sets the authorize type as EAP authorize { eap } # eap authentication takes place. authenticate { eap } Nirmala 29

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 30

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 31

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 32

EAP –TLV Packet Formats E A P –TLV P acket 0 7 8 Code Type R e s u lt T L V P a c k e t F o r m a t 15 16 I d e n t i fi e r 31 L e n g th 1 2 M R D a ta . C ode : 1 - R e q u e s t 2 -R e s p o n s e Id e n tifie r : U s e d to m a tc h re s p o n s e to re q u e s t Type: 3 3 (E A P - T L V ) L e n g t h : T h e L e n g th fie ld in d ic a te s th e le n g th o f th e E A P p a c k e t in c lu d in g t h e C o d e , Id e n tifie r , L e n g th , T y p e , a n d T L S d a t a D a ta : T h e D a t a fie ld is o f v a r ia b le le n g th , a n d c o n ta in s E A P - T L V T L V s Nirmala 0 15 16 TLV Type 31 L e n g th S ta tu s M T L S /R : 1 - M a n d a to ry T L V 0 -R e s e rv e d L V T y p e : 3 - ( S u c c e s s /F a ilu r e ) e n g th : 2 ta tu s : C o n ta in s v a lu e 1 - S u c c e s s 2 - F a ilu r e 33

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 34

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 35

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 36

Performance Analysis of PEAP and TTLS Nirmala 37

TEST BED at UCCS ENG LAB RADIUS Client Nirmala 38

Client/Server Machine Configurations Machine Spec IP Address OS Software wiper.uccs.edu 1.8 Ghz, 1 GB RAM RADIUS Server and DHCP server 128.192.61.132 RedHat 9.0 Running Linux 2.2.20-19.9 kernel FreeRadius Modified CVS snapshot radiusd09.03.03.tar.gz willow.uccs.edu Access 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 Client Using Cisco Aironet 350 PC Card Dynamic IP address 128.192.61.144 to 128.98.61.152 RedHat 6.2 running Linux 2.2.20-19.9 kernel Open1x Xsupplicant Version 9.0 Hobbit – 1 Ghz Dell Optiplex, 512 MB Wireless Client Using Cisco Aironet 350 PCI Card Dynamic IP address 128.192.61.144 to 128.98.61.152 Windows XP-SP1 And RedHat 9.0 Running Linux 2.2.20.9 kernel Open1x Xsupplicant for Linux and built in Service Pack for XP Nirmala 39

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 40

PEAP vs TTLS on Toshiba machine T im e in m s e c PEAP vs TTLS [Toshiba - 366.604mhz] 1500 1400 1300 1200 1100 1000 900 800 700 600 500 TTLS PEAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Average Nirmala Variance PEAP TTLS 1046 949 8142 12060 41

PEAP vs TTLS on Hobbit machine TTLS vs PEAP [hobbit - 996.785mhz] T im e in m s e c 1300 1200 1100 1000 TTLS PEAP 900 800 700 600 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No of Times PEAP TTLS Nirmala Average 983 911 Variance 10 356 42

PEAP vs TTLS Simultaneous Access of Clients T im e in m se c TTLS vs PEAP [Running Requests Simultaenoulsy From Toshiba and Hobbit] 1500 1400 1300 1200 1100 1000 900 800 700 600 500 TTLS PEAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No of Times Average Nirmala Variance PEAP TTLS 1006 947 23707 12387 43

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 44

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 45

PEAP vs TTLS Distance Range 30ft PEAP-TTLS Performance Comparison For Distance Range 30 ft 5000 4500 T im e in m s e c 4000 3500 3000 PEAP TTLS 2500 2000 1500 1000 500 1 10 19 28 37 46 55 64 73 82 91 100 No. of Runs Nirmala 46

PEAP vs TTLS Distance Range 25ft PEAP-TTLS Performance Comparison For Distance Range 25 ft [Behind Closed Doors and Walls] 3500 Time in msec 3000 2500 PEAP TTLS 2000 1500 1000 500 1 10 19 28 37 46 55 64 73 82 91 100 No. of Runs Nirmala 47

PEAP vs TTLS Distance Range 45ft PEAP-TTLS Performance Comparison For Distance Range 45 ft 4500 4000 T im e in m s ec 3500 3000 PEAP TTLS 2500 2000 1500 1000 500 1 10 19 28 37 46 55 64 73 82 91 100 No. of Runs Nirmala 48

PEAP vs TTLS Distance Range 55ft PEAP-TTLS Performance Comparison For Distance Range 55 ft 5000 4500 Time in msec 4000 3500 3000 PEAP TTLS 2500 2000 1500 1000 500 1 10 19 28 37 46 55 64 73 82 91 100 No. of Runs Nirmala 49

PEAP vs TTLS Distance Range 65ft PEAP-TTLS Performance Comparison For Distance Range 65 ft [behind Closed Doors and Walls] 4500 4000 Time in msec 3500 3000 PEAP 2500 TTLS 2000 1500 1000 500 1 10 19 28 37 46 55 64 73 82 91 100 No. of Runs Nirmala 50

PEAP vs TTLS Average Performance PEAP-TTLS Average Performances over varying Distances 1500 Average-Time/ msec 1400 1300 1200 PEAP TTLS 1100 1000 900 800 DIST1 DIST2 DIST3 DIST4 DIST5 Distance Range Nirmala 51

PEAP vs TTLS Variance Data Variance Data for PEAP and TTLS over Varying Distances 250000 V ariance 200000 150000 PEAP TTLS 100000 50000 0 Dist1 Dist2 Dist3 Dist4 Dist5 Distance Nirmala 52

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 53

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 54

PEAP vs TTLS Network Uptime 5.0 sec T im e in s e c PEAP-TTLS Resilience Test with Network Uptime 5.0 sec and Downtime 3 sec 65 60 55 50 45 40 35 30 25 20 15 10 5 0 TTLS PEAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Nirmala PEAP TTLS Average 12 6 Variance 266 84 55

PEAP vs TTLS Network Uptime 4.5 sec PEAP-TTLS Resilience Test with Network Uptime 4.5sec and Downtime 3sec T im e in s e c 25 20 15 TTLS PEAP 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Nirmala PEAP TTLS Average 9 8 Variance 105 95 56

PEAP vs TTLS Network Uptime 4.2 sec PEAP-TTLS Resilience Test with Network Uptime 4.2sec and Downtime is 3sec T im e in s e c 30 25 20 TTLS PEAP 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Nirmala PEAP TTLS Average 12 12 Variance 106 118 57

PEAP vs TTLS Network Uptime 4.0 sec PEAP-TTLS Resilience Test with Network Uptime 4.0sec and Downtime 3sec T im e in s e c 30 25 20 TTLS PEAP 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Nirmala PEAP TTLS Average 18 16 Variance 50 91 58

PEAP vs TTLS Network Uptime 3.9 sec T im e in s e c PEAP-TTLS Resilience Test with Network Uptime 3.9sec and Downtime 3.0sec 60 55 50 45 40 35 30 25 20 15 10 5 0 TTLS PEAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 No. of Runs Nirmala PEAP TTLS Average 25 26 Variance 437 390 59

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 60

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 61

Stress Test - PEAP PEAP STRESS TEST T im e in m s e c 6000 Average1011 5000 4000 3000 PEAP 2000 1000 0 1 200 399 598 797 996 1195 1394 No. of Runs Nirmala 62

Stress Test - TTLS TTLS STRESS TEST T im e in m s e c 7000 Average1099 6000 5000 4000 TTLS 3000 2000 1000 0 1 200 399 598 797 996 1195 1394 No. of Runs Nirmala 63

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 64

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 65

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 66

Conclusion & Future Work Nirmala 67

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 68

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. Nirmala 69