Wireless Security Potpourri William A. Arbaugh Department of Computer Science University of Maryland waa @ cs.umd.edu http://www.cs.umd.edu/~waa 2018/9/17

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

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

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

One View of the Future CDMA1x Ad hoc extension WLAN

Properties Required Transparency Security Ubiquity Performance

Characterize the Problem Roamingdelay = Layer1delay + Layer2delay + Layer3delay We want the total roaming delay to be less than 50ms.

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

Prism2 (Zoomair) Data from Arunesh Mishra and Min-ho Shin

Cisco Aironet 340

Lucent

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

The Handoff Procedure – Probe Phase Empirical Results: High latencies Large variation Variation in Handoff Latencies Average Values of Handoff Latencies

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.

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

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

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

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

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

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

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 : 1.119 ms Reassociation with IAPP : 16.392 ms IAPP with Proactive-caching : 1.319 ms

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 : 1.583 ms Reassociation with IAPP : 12.67 ms IAPP with Proactive-caching : 1.982 ms

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

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.

TGi Trust Assumptions AAA Server is trusted AP to which STA is associated is trusted.

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

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

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

Key Locations MK PMK RADIUS (AAA) PMK PTK AP1 AP2 MK PMK PTK

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

Pre Association RADIUS (AAA) A B C D E

Post Authentication and 4-handshake MK PMK RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

Pre-authentication Full 802.1X Authentication Via Next AP MK PMK RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

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

Proactive Key Distribution MK,PMK MK PMK Roam Server RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

Proactive Key Distribution Post Authentication MK 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

Proactive Key Distribution STA Roam to AP B MK 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

Proactive Key Distribution STA Roam to AP B MK PMKA’ PMKB PMKC PMKD PMKE’ Roam Server RADIUS (AAA) PMKB PTK A PMKA’ B C PMKC D PMKD E PMKE’ MK PMKB PTK

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)

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)

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

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

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

DRNAT Host A Can be placed In edge router IP A IP 1 Net 2 IP 3 Host B IP B

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

Inter-LAN Roaming Proactive key distribution handles security well. Proactive caching handles other AP context well.

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.

Ad Hoc Network Security We’re focusing on: Availability The major function of routing A non-trivial aspect of ad hoc network security

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)]

Problems with SUCV Malicious node Virtual node S T Virtual network Assign corresponding SUCV address Malicious node Virtual node Create public-private key pair

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

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

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

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!

Quantification of Risk

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.

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).

Deciding Trusted Nodes

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

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

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.

Questions ?

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.