1. Wireless Security Potpourri
William A. Arbaugh
Department of Computer Science
University of Maryland
cs.umd.edu
2018/9/17

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 Tgi IETF 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 b association delay
Authentication – IEEE 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 Reassociation Phase
STA scans for APs
Reassociation Phase
STA attempts to associate to preferred AP
STA
Probe requests
Probe responses
APs
New AP
PROBE PHASE
REASSOCIATION PHASE
Other APs
IAPP
Reassociatiion request
Reassociatiion response

13. The Handoff Procedure – Probe Phase
Empirical Results:
High latencies
Large variation
Variation in Handoff Latencies
Average Values of 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 > 4 * RTT
Move Request and Move Response messages over TCP
STA
New AP
Old AP
Reassociation Request
Move Notify
Send Security Block
Ack Security Block
Move Response
IAPP Messages
Reassociation Response

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
STA’s path of motion
STA
Security Context 1 2 3 B 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
STA reassociates to AP A
AP A has security context in cache
AP A propagates context to AP B (all neighbors of A)
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 AP’s, i.e. no RADIUS or security block messages included.
Basic Reassociation : ms
Reassociation with IAPP : ms
IAPP with Proactive-caching : ms

22. Proactive Caching – Latency Improvements
Measurements based on Pentium 4 laptop (IBM Thinkpad T23) using Prism2 HostAP driver.
AP shared secrets preloaded on AP’s, i.e. no RADIUS or security block messages included.
Basic Reassociation : ms
Reassociation with IAPP : ms
IAPP with Proactive-caching : 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
Master Key (MK)
Pairwise Master Key (PMK) = TLS-PRF(MasterKey, “client EAP encryption” | clientHello.random | serverHello.random)
Pairwise Transient Key (PTK) = EAPoL-PRF(PMK, AP Nonce | STA Nonce | AP MAC Addr | STA MAC Addr)
Key Confirmation Key (KCK) – PTK bits 0–127
Key Encryption Key (KEK) – PTK bits 128–255
Temporal Key – PTK bits 256–n – can have cipher suite specific structure

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. A B E D C A B C E D

31. Pre Association
RADIUS (AAA) A B C D E

32. Post Authentication and 4-handshakeMK
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
Roam Server
RADIUS (AAA)
PMK
PTK A B C D E MK
PMK
PTK

36. Proactive Key Distribution Post AuthenticationMK
PMKA
Roam Server
PMKB=TLS-PRF(MK, PMKA, APB-MAC-Addr,
STA-MAC-Addr)
PMKE=TLS-PRF(MK, PMKA, APE-MAC-Addr,
RADIUS (AAA)
PMKE
PMKB
PMKA
PTK
PMKB A B C D E
PMKE MK
PMKA
PTK

37. Proactive Key Distribution STA Roam to AP BMK
PMKA
Roam Server
PMKB
Old and new
AP’s inform RS
PMKE
RADIUS (AAA)
RS builds
Neighbor Graph
PMKA
PTK
PMKB A B C D E
PMKE
PMKB=TLS-PRF(MK, PMKA, APB-MAC-ADDR,
STA-MAC-ADDR)
PTK via standard 4-way handshake

38. Proactive Key Distribution STA Roam to AP BMK
PMKA’
PMKB
PMKC
PMKD
PMKE’
Roam Server
RADIUS (AAA)
PMKB
PTK A
PMKA’ B C
PMKC D
PMKD E
PMKE’ 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 IP 1 Net 2 IP 3 Host B
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
We’re focusing on:
Availability
The major function of routing
A non-trivial aspect of ad hoc network security

49. SUCV ID = Hash1 [ Hash2(imprint), Hash2(Public Key)]
SUCV Address
Due to the cryptography difficulty, it’s 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 Malicious node Virtual node 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
Source R1
R’1
Destination R2
R’2 R3
Decision node
Data packet
PRP Route Request
PRP Route Reply
Red nodes will make route selection according to the risk value of routes

53. Simulations from Initial Experiment (without SUCV)
Average Delay
Routing Overhead
Delivery Ratio
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.O’Shea 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
ST1:{S,A,B,T}
ST2:{S,M,N*,T}
ST3:{S,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.