Transcript Defense

Implementation and Performance
Analysis of the
Protected Extensible
Authentication Protocol (PEAP)
Nirmala Bulusu
Nirmala 12/18/03
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 12/18/03
2
Introduction
WLAN, RADIUS, EAP, TLS,
TTLS and PEAP
Nirmala 12/18/03
3
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 12/18/03
4
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.
Authenticator System
Supplicant
System
Host NIC
Ethernet 802.1,
Wireless PC card,
etc.
Authentication
Server System
EAPOL
Services offered by
the Authenticator
system
Controlled
Port
Authenticator
PAE
(Port Access Entity)
Port Unauthorized
Authorize/Unauthorize
Uncontrolled
Port
MAC Enable
Nirmala 12/18/03
EAP Messages
Encapsulated
Authentication
Server [AAA]
Any EAP
Mostly Radius
The three different
elements in IEEE
802.1x
5
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
Access Point (AP)/
Network Access
Server/NAS
Client/End-User
Supplicant
Ethernet
EAPoL
RADIUS Server
Authenticator
EAP
EAP-Payload
Authentication
Server
CRC
EAPoL Packet
RADIUS Packet
Nirmala 12/18/03
IP
UDP
RADIUS
EAP
EAP-Payload
6
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 12/18/03
7
Message Exchanges Between
RADIUS Client and Server
RADIUS Client
Network
Access Server
(NAS)
RADIUS
Server
Access Request
(NAS-ID, NAS-port, username, password)
For PEAP, Password is
not sent in this frame
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)
Nirmala 12/18/03
8
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 12/18/03
9
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
RADIUS Server
Authentication
Server
TLS Handshake Phase
Nirmala 12/18/03
Certificate exchange
10
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 12/18/03
11
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
RADIUS
TTLS
AAA
Server
USER
Database
RADIUS
AAA /H
Server
Secure password authentication tunnel
Secure data tunnel
Nirmala 12/18/03
TTLS Architectural Model
12
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-TimePassword, 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 12/18/03
13
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 12/18/03
RADIUS server
sends Certificate
chain to Client
14
Phase 2- Authenticate Client
Challenge
String
Response to
challenge string &
user password
EAPSuccess
message
Session key, encrypted WEP key
Nirmala 12/18/03
15
PEAP Protocol
Implementation Details
Nirmala 12/18/03
16
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 12/18/03
17
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
types
eap.c
The new
developed
Software
rlm_eap_leap
eap.h
rlm_md5 rlm_eap_peap
rlm_eap_peap.c
Nirmala 12/18/03
rlm_eap.c
peap.c
rlm_eap_tls
rlm_eap_peap.h
rlm_eap.h
rlm_eap_ttls
Makefile
18
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 12/18/03
19
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 12/18/03
20
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 12/18/03
21
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 12/18/03
22
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 12/18/03
23
EAP –TLV Packet Formats
EAP–TLV Packet
0
78
Code
Data:
1516
Identifier
Type
Code :
Identifier:
Type:
Length:
Result TLV Packet Format
31
Length
0
1 2
M R
Data….
1 - Request 2-Response
Used to match response to request
33 (EAP - TLV)
The Length field indicates the length of
the EAP packet including the Code,
Identifier, Length, Type, and TLS data
The Data field is of variable length, and
contains EAP-TLV TLVs
Nirmala 12/18/03
1516
TLVType
31
Length
Status
M/R :
TLV Type :
Length :
Status :
1 - Mandatory TLV 0-Reserved
3 - (Success/Failure)
2
Contains value
1 - Success 2 - Failure
24
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 12/18/03
25
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 12/18/03
26
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 12/18/03
27
Performance Analysis of
PEAP and TTLS
Nirmala 12/18/03
28
TEST BED at UCCS ENGG LAB
RADIUS
Client
Nirmala 12/18/03
29
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 12/18/03
30
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 12/18/03
31
PEAP vs TTLS
on Toshiba machine
Time in msec
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 12/18/03
Variance
PEAP
TTLS
1046
949
8142
12060
32
PEAP vs TTLS
on Hobbit machine
TTLS vs PEAP
[hobbit - 996.785mhz]
1300
Time in msec
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
Nirmala 12/18/03
PEAP
TTLS
Average
983
911
Variance
10
356
33
PEAP vs TTLS
Simultaneous Access of Clients
Time in msec
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 12/18/03
Variance
PEAP
TTLS
1006
947
23707
12387
34
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 12/18/03
35
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 12/18/03
36
PEAP vs TTLS
Distance Range ~ 30ft
PEAP-TTLS Performance Comparison For
Distance Range ~30 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 12/18/03
37
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
2000
TTLS
1500
1000
500
1
10
19
28
37
46
55
64
73
82
91
100
No. of Runs
Nirmala 12/18/03
38
PEAP vs TTLS
Distance Range ~ 45ft
PEAP-TTLS Performance Comparison For
Distance Range ~45 ft
4500
4000
Time in msec
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 12/18/03
39
PEAP vs TTLS
Distance Range ~ 55ft
PEAP-TTLS Performance Comparison For
Distance Range ~55 ft
5000
4500
Time in msec
4000
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 12/18/03
40
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 12/18/03
41
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 12/18/03
42
PEAP vs TTLS
Variance Data
Variance Data for PEAP and TTLS over Varying Distances
250000
Variance
200000
150000
PEAP
TTLS
100000
50000
0
Dist1
Dist2
Dist3
Dist4
Dist5
Distance
Nirmala 12/18/03
43
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 12/18/03
44
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 12/18/03
45
PEAP vs TTLS
Network Uptime 5.0 sec
Time in sec
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 12/18/03
PEAP
TTLS
Average
12
6
Variance
266
84
46
PEAP vs TTLS
Network Uptime 4.5 sec
PEAP-TTLS Resilience Test with Network
Uptime 4.5sec and Downtime 3sec
25
Time in sec
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 12/18/03
PEAP
TTLS
Average
9
8
Variance
105
95
47
PEAP vs TTLS
Network Uptime 4.2 sec
PEAP-TTLS Resilience Test with Network
Uptime 4.2sec and Downtime is 3sec
30
Time in sec
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 12/18/03
PEAP
TTLS
Average
12
12
Variance
106
118
48
PEAP vs TTLS
Network Uptime 4.0 sec
PEAP-TTLS Resilience Test with Network
Uptime 4.0sec and Downtime 3sec
30
Time in sec
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 12/18/03
PEAP
TTLS
Average
18
16
Variance
50
91
49
PEAP vs TTLS
Network Uptime 3.9 sec
Time in sec
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 12/18/03
PEAP
TTLS
Average
25
26
Variance
437
390
50
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 12/18/03
51
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 12/18/03
52
Stress Test - PEAP
PEAP STRESS TEST
6000
Average 1011
Time in msec
5000
4000
3000
PEAP
2000
1000
0
1
200
399
598
797
996
1195
1394
No. of Runs
Nirmala 12/18/03
53
Stress Test - TTLS
TTLS STRESS TEST
7000
Average 1099
Time in msec
6000
5000
4000
TTLS
3000
2000
1000
0
1
200
399
598
797
996
1195
1394
No. of Runs
Nirmala 12/18/03
54
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 12/18/03
55
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 12/18/03
56
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 12/18/03
57
Conclusion
&
Future Work
Nirmala 12/18/03
58
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 12/18/03
59
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 12/18/03
60