Wireless Security Potpourri

1
Wireless Security Potpourri

• William A. Arbaugh
• Department of Computer Science
• University of Maryland
• waa _at_ cs.umd.edu
• http//www.cs.umd.edu/waa

2
Students

• Aram Khalili (LTS Funded)
• Nick Petroni (LTS Funded)
• Chuk Seng (LTS Funded)
• Arunesh Mishra
• Min-ho Shin (LTS Funded)
• Zhongchao Yu
• Yuan Yuan

3
Outline of Talk

• Technology
• Empirical Analysis of 802.11 hand-offs
• Neighbor graphs
• Proactive caching
• Proactive key distribution for LANs and
  Interworking
• Double Reverse NAT (DrNAT)
• Ad-hoc networking
• Probablistic based routing
• Secure service discovery
• Contextual based security associations

4
Outline cont.

• Standards Activity
• TGf
• Proactive caching
• Network wide DoS found
• Tgi
• Proactive key distribution
• Numerous DoS attacks
• IETF
• EAP
• AAA
• SEND

5
One View of the Future
CDMA1x
Ad hoc extension
WLAN
6
Properties Required

• Transparency
• Security
• Ubiquity
• Performance

7
Characterize the Problem

• Roamingdelay Layer1delay Layer2delay
  Layer3delay
• We want the total roaming delay to be less than
  50ms.

8
Layer 2 (Inter-LAN)

• Layer2delay Probe Decision Association
  Authentication
• Probe delay of scanning for next AP
• Decision - delay of initiating roam
• Associaiton IEEE 802.11b association delay
• Authentication IEEE 802.11 authentication delay

9
Prism2 (Zoomair)
Data from Arunesh Mishra and Min-ho Shin
10
Cisco Aironet 340
11
Lucent
12
The Handoff Procedure

• Probe Phase
• STA scans for APs
• Reassociation Phase
• STA attempts to associate to preferred AP

13
The Handoff Procedure Probe Phase

• Empirical Results
• High latencies
• Large variation

Variation in Handoff Latencies
14
Why is this important?

• Hand-off times MUST be efficient to support
  synchronous connnections, e.g. VoIP
• ITU guidance on TOTAL hand-off latency is that it
  should be less than 50 ms. Cellular networks try
  to keep it less than 35 ms.

15
The Handoff Proceduure- Reassociation Phase - IAPP

• Four IAPP Messages
• IAPP Latency gt 4 RTT
• Move Request and Move Response messages over TCP

16
Neighbor Definition and Graph

• Two APs i and j are neighbors iff
• There exists a path of motion between i and j
  such that it is possible for a mobile STA to
  perform a reassociation
• Captures the potential next AP relationship
• Distributed data-structure i.e. each AP or RS can
  maintain a list of neighbors

A
B
A
E
C
E
C
B
D
D
1
17
AP Neighborhood Graph Automated Learning

• Construction
• Manual configuration for each AP/RS or,
• AP can learn
• If STA c sends Reassociate Request to AP i, with
  old-ap AP j
• Create new neighbors (i,j) (i.e. an entry in AP
  i, for j and vice versa)
• Learning costs only one high latency handoff
  per edge in the graph
• Enables mobility of APs, can be extended to
  wireless networks with an ad-hoc backbone
  infrastructure
• Dynamic, i.e. stale entries time out
• Easily extended to a server

18
Proactive Caching Algorithm

• Key Idea
• Propagate security contexts to potential next
  APs to eliminate IAPP latency during
  reassociation
• 1. STA associates to AP A
• 2. AP A sends security context to AP B
  proactively (new IAPP message)
• 3. STA moves to AP B does fast reassociation
  since B has security context in cache

A
19
Proactive Caching The Algorithm

• When STA c associates/reassociates to AP i
• If context(c) in cache
• Send Reassociate Response to client
• Send Move-Notify to Old-AP
• If context(c) not in cache, perform normal IAPP
  operation
• Send security context to all Neighbours(i)
• Cache Replacement Least Recently Used
• Cache size vendor dependent

20
IAPP Messages with Proactive Caching

1. STA reassociates to AP A
2. AP A has security context in cache
3. AP A propagates context to AP B (all neighbors of
   A)
4. STA reassociates to AP B which again has security
   context in cache

STA
AP A
AP B
Context in Cache
Reassociation Request
Reassociation Response
Propagate context
Context stored in cache
Reassociation Request
Context in Cache
Reassociation Response
21
Proactive Caching Latency Improvements

• Measurements based on Soekris/OpenBSD platform
  using Prism2 HostAP driver.
• AP shared secrets preloaded on APs, i.e. no
  RADIUS or security block messages included.
• Basic Reassociation 1.119 ms
• Reassociation with IAPP 16.392 ms
• IAPP with Proactive-caching 1.319 ms

22
Proactive Caching Latency Improvements

• Measurements based on Pentium 4 laptop (IBM
  Thinkpad T23) using Prism2 HostAP driver.
• AP shared secrets preloaded on APs, i.e. no
  RADIUS or security block messages included.
• Basic Reassociation 1.583 ms
• Reassociation with IAPP 12.67 ms
• IAPP with Proactive-caching 1.982 ms

23
Proactive Caching Expected Performance

• Handoff latencies play a role in performance when
  mobility is high
• With LRU cache, higher the mobility, higher the
  cache-hit ratio (on average), implies larger
  number of fast-handoffs

Cache Hit Ratio
Mobility
24
TGi Fast Roaming Goals

• Handoff to next AP SHOULD NOT require a complete
  802.1x re-authentication.
• Compromise of one AP MUST NOT compromise past or
  future key material, i.e. back traffic protection
  and perfect forward secrecy.

25
TGi Trust Assumptions

• AAA Server is trusted
• AP to which STA is associated is trusted.

26
Only Two Ways

• Exponentiation support for assymmetric
  cryptographic operations at AP, or
• Trusted Third Party, i.e. Roaming Server

27
Proactive Key Distribution (TGi)

• Extend Neighbor Graphs and Proactive Caching to a
  Roaming Server
• Eliminates problems with sharing key material
  amongst multiple APs
• Easily extended to support WAN roaming
• Possibly extendable to support Interworking

28
TGi Pairwise Key Hierarchy
29
Key Locations
MK PMK
RADIUS (AAA)
PMK PTK
AP1
AP2
MK PMK PTK
30
Roaming Example

• Given the following infrastructure with
  associated neighbor graph with STA about to
  associate to AP A.

31
Pre Association
RADIUS (AAA)
A
B
C
D
E
32
Post Authentication and 4-handshake
MK PMK
RADIUS (AAA)
PMK PTK
A
B
C
D
E
MK PMK PTK
33
Pre-authentication
Full 802.1X Authentication Via Next AP
MK PMK
RADIUS (AAA)
PMK PTK
A
B
C
D
E
MK PMK PTK
34
Problems with Pre-Auth

• Expensive in terms of computational power for
  client, and time (Full EAP-TLS can take seconds
  depending on load at RADIUS Server).
• Requires well designed and overlapping coverage
  areas
• Edge cases

35
Proactive Key Distribution
MK,PMK
MK PMK
RADIUS (AAA)
Roam Server
PMK PTK
A
B
C
D
E
MK PMK PTK
36
Proactive Key DistributionPost Authentication
Roam Server
MK PMKA
PMKBTLS-PRF(MK, PMKA, APB-MAC-Addr,
STA-MAC-Addr) PMKETLS-PRF(MK, PMKA,
APE-MAC-Addr, STA-MAC-Addr)
RADIUS (AAA)
PMKE
PMKB
PMKA PTK
PMKB
A
B
C
D
E
PMKE
MK PMKA PTK
37
Proactive Key DistributionSTA Roam to AP B
Roam Server
MK PMKA
PMKB
Old and new APs inform RS
PMKE
RADIUS (AAA)
RS builds Neighbor Graph
PMKA PTK
PMKB
A
B
C
D
E
PMKE
PMKBTLS-PRF(MK, PMKA, APB-MAC-ADDR,
STA-MAC-ADDR) PTK via standard 4-way handshake
38
Proactive Key DistributionSTA Roam to AP B
Roam Server
MK PMKA PMKB PMKC PMKD PMKE
RADIUS (AAA)
PMKB PTK
A
B
C
D
E
PMKE
PMKD
PMKC
PMKA
MK PMKB PTK
39
Proactive Key Distribution Protocol

• STA associates to AP1.
• STA performs 802.1X EAP-TLS authentication with
  (AP1, AS).
• AS and STA derive the PMK TLS-PRF(MasterKey,
  "client EAP Encryption" clientHello.random
  serverHello.random).
• AS sends PMK to AP1.
• AP1 and STA derive PTK via any method, e.g. 4-way
  handshake
• AP1 and STA derive GTK in usual way
• AS constructs PMK2 TLS-PRF(MasterKey, PMK1,
  AP2-MAC-Addr, STA-MAC-Addr)
• AS sends PMK2 to AP2
• Steps 7 and 8 performed for each AP in
  Neighbor(AP1)

40
Protocol cont.

• STA roams to AP2
• STA derives PMK2 TLS-PRF(MasterKey, PMK1,
  AP2-MAC-Addr, STA-MAC-Addr)
• AP2 and STA derive PTK via key agreement, e.g.
  4-way handshake
• AP2 and STA derive GTK in usual way
• STA can resume data traffic
• AP1 and AP2 inform AS of the roam
• AS constructs PMK3 TLS-PRF(MasterKey, PMK2,
  AP3-MAC-Addr, STA-MAC-Addr)
• AS sends PMK3 to AP3
• Steps 7 and 8 done for each AP in Neighbor(AP2)

41
Why a Roaming Server?

• Not actually required (could use current AAA
  server) but
• May load RADIUS/DIAMETER host too much
• Requires retention of state which RADIUS tries to
  avoid

42
Inter-LAN and Intra-WAN Roaming

• IP address change too costly (Layer 3 delay)
• Current solutions (Mobile IP and IPv6) suffer
  from deployment problems.
• Mobile IP suffers from additional delays due to
  home agent

43
Our Approach

• Use double reverse network address translation
  (DRNAT) to eliminate IP address change.
• If a second device is used, use smart look ahead

44
DRNAT
Host A
Can be placed In edge router
IP A
DRNAT
IP 1
Net 2
IP 3
Host B
IP 2
DRNAT
Net 1
IP B
45
Advantages of DRNAT

• Can be realized in software or hardware
• Requires no infrastructure changes
• Can be placed in the infrastructure to support
  non-mobile hosts

46
Inter-LAN Roaming

• Proactive key distribution handles security well.
• Proactive caching handles other AP context well.

47
Intra-LAN and WAN Roaming

• The approach will be to define a Roaming station
  to Roaming station message protocol for AAA.
• DRNAT remains useable as a client only approach
  which requires no standards activity.

48
Ad Hoc Network Security

• Were focusing on
• Availability
• The major function of routing
• A non-trivial aspect of ad hoc network security

49
SUCV

• SUCV Address
• Due to the cryptography difficulty, its hard to
  impersonate a given SUCV address node, by using
  another private-public key pair.
• Dilemma the malicious node is able create
  arbitrary virtual nodes, with new SUCV addresses.

Routing prefix (64 bits)
SUCV ID (64 bit)
SUCV ID Hash1 Hash2(imprint), Hash2(Public
Key)
50
Problems with SUCV
S
T
Virtual network
Assign corresponding SUCV address
Malicious node
Virtual node
Create public-private key pair
51
Probabilistic Routing Protocol (PRP) Motivation

• Traditional Ad Hoc Routing Protocols
• Deterministically based on the value of some well
  known metrics (e.g hops, cost)
• Metrics can be easily affected by attackers
• Enhancement of availability
• Introduce a new metric (risk) over which
  attackers have less control
• Select routing randomly (to some degree) to
  guarantee minimum amount of throughput
• Based on DSR

52
Overall Flow Graph of Route Discovery
R1
R1
Destination
R2
R2
R3
Red nodes will make route selection according to
the risk value of routes
53
Simulations from Initial Experiment (without SUCV)
Average Delay
Delivery Ratio
Routing Overhead

• Average delay is increased, since the routes are
  no longer always the shortest
• PRP does not suffer a large performance penalty
  with respect to both packet overhead and packet
  delivery ratio

54
Assumptions

• SUCV property holds (G.Montenegro et al.,
  G.OShea et al., Bobba et al.)
• Secure binding between an IP address and a public
  key for each node (still subject to attacks in
  which nodes create multiple virtual Ids - to be
  addressed in future work)
• Some nodes share a trust relation, but not all
• A non-trusted node may be or may not be a
  malicious node but has some possibility to be a
  malicious node
• Trust is bidirectional and transitive
• Not the case in theory, but usually the case in
  practice!

55
Quantification of Risk
56
Estimation of confidence
Confidence could be computed as
For routes replied from the route cache of an
intermediate node A, equivalent cost and
confidence from A to T is given by
in which the sum is done for all the routes from
A to T. This formula is given in accordance with
the probabilistic algorithm described later.
57
Trust Assertion

• An assertion T(A,B) is defined as
• T(A,B)(A, A trusts B, public key of A, nonce)
  , which is signed by A using the private key
• T(A,B) contains a statement asserting a node B as
  trusted
• T(A,B) could not be forged (by properties of
  SUCV).

58
Deciding Trusted Nodes
59
Route Selection Algorithm
Destination Route Risk

T ST1S,A,B,T
T ST2S,M,N,T
T ST3S,L,C,T

Route cache in source S

• Source randomly selects a route
• With the probability of the selected route as
  1/risk
• For routes replied from the destination ST1
  ST3
• Route selection is made only by source
• For routes replied from the intermediate node
  ST2
• Intermediate node will make another random route
  selection with the same strategy as the source

60
Future Work

• Simulations under new assumptions (e.g. SUCV
  property etc.)
• Modeling the behavior of malicious nodes to
  complement the simulation
• Exploring further the random route selection
  algorithm to make optimal tradeoff between
  security and performance
• Studying countermeasures against multiple ID
  attacks imposed on SUCV

61
IEEE Standards Activity

• Proactive caching proposed to TGf.
• Received well, but standard is in early stages of
  approval.
• Full written proposal will be submitted during
  re-circulation ballot (ends Dec 16).
• Proactive key distribution will be proposed to
  TGi in January 03.
• Intel, Cisco, and Microsoft currently support the
  proposal.

62
Questions

• ?

63
IETF Standards Activity

• A new keying draft will be submitted to AAA
  (March 03).
• A new key wrap will be proposed to replace RFC
  2548 (March 03).
• A roaming server to roaming server protocol will
  be proposed (March 03).
• Member of the SEND design team.
• EAP WG security advisor.
• Students formalizing EAP state machine.