wireless security potpourri

23/4/22 1

Wireless Security Potpourri

William A. ArbaughDepartment of Computer

ScienceUniversity of Maryland

waa @ cs.umd.eduhttp://www.cs.umd.edu/~waa

12/15/02

2

For LTS Review Purposes Only - Do Not Redistribute

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

12/15/02

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

12/15/02

4


Outline cont. Standards Activity

TGf Proactive caching Network wide DoS found

Tgi Proactive key distribution Numerous DoS attacks

IETF EAP AAA SEND

12/15/02

5


One View of the Future

CDMA1x

WLAN

Ad hoc extension

12/15/02

6


Properties Required Transparency Security Ubiquity Performance

12/15/02

7


Characterize the Problem

Roamingdelay = Layer1delay + Layer2delay + Layer3delay

We want the total roaming delay to be less than 50ms.

12/15/02

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

12/15/02

9


Prism2 (Zoomair)Handoff Latency - ZoomAir (prism2) on CiscoAP

(umd) Breakup

0

50

100

150

200

250

300

1 3 5 7 9 11 13 15

Handoff Number

Late

ncy

(ms) Reassociation Delay

Authentication DelayDecision DelayProbe Delay

Data from Arunesh Mishra and Min-ho Shin

12/15/02

10


Cisco Aironet 340Handoff Latency - Cisco client and Cisco AP (umd)

- Breakup

0

100

200

300

400

500

1 3 5 7 9 11 13 15 17 19

Handoff Number

Late

ncy



12/15/02

11


LucentHandoff Latency - Lucent on Cisco AP (umd) -

Breakup

0

20

40

60

80

100

120

1 3 5 7 9 11 13 15 17 19

Handoff Number

Late

ncy



12/15/02

12


The Handoff Procedure Probe 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

12/15/02

13


The Handoff Procedure – Probe Phase

Empirical Results: High latencies Large variation

Average Values of Handoff LatenciesVariation in Handoff Latencies

12/15/02

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.

12/15/02

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 M

essages

Reassociation Response

12/15/02

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

1

A

B

C

E

D

AB

E

D

C

12/15/02

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

12/15/02

18


Proactive Caching Algorithm

Key Idea : Propagate security contexts

to potential ‘next’ APs to eliminate IAPP latency during reassociation

1. STA associates to AP A2. 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

STA’

s pa

th o

f m

otio

n

STA

STA

Security Context

1

2

3 B

12/15/02

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

12/15/02

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


Reassociation Response Cont

ext i

n Ca

che

Propagate context


Reassociation Response Cont

ext i

n Ca

che

Context storedin cache

12/15/02

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

12/15/02

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

12/15/02

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

Mobility

Cac

he H

it R

atio

12/15/02

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.

12/15/02

25


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

trusted.

12/15/02

26


Only Two Ways Exponentiation support for

assymmetric cryptographic operations at AP, or

Trusted Third Party, i.e. Roaming Server

12/15/02

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

12/15/02

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

12/15/02

29


Key Locations

RADIUS (AAA)

MKPMK

AP1 AP2PMKPTK

MKPMKPTK

12/15/02

30


Roaming Example Given the following infrastructure with associated neighbor

graph with STA about to associate to AP A.

A

B

C

E

D

AB

E

D

C

12/15/02

31


Pre Association

RADIUS (AAA)

A B C D E

12/15/02

32


Post Authentication and 4-handshake

RADIUS (AAA)

A B C D E

MKPMKPTK

PMKPTK

MKPMK

12/15/02

33


Pre-authentication

RADIUS (AAA)

A B C D E

MKPMKPTK

PMKPTK

MKPMK

Full 802.1XAuthentication

ViaNext AP

12/15/02

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

12/15/02

35


Proactive Key Distribution

RADIUS (AAA)

A B C D E

MKPMKPTK

PMKPTK

MKPMK

Roam Server

MK,PMK

12/15/02

36

For LTS Review Purposes Only - Do Not RedistributeProactive Key Distribution

Post Authentication

A B C D E

MKPMKA

PTK

PMKA

PTK

RADIUS (AAA)

Roam ServerMKPMKA

PMKB=TLS-PRF(MK, PMKA, APB-MAC-Addr, STA-MAC-Addr)

PMKE=TLS-PRF(MK, PMKA, APE-MAC-Addr, STA-MAC-Addr)

PMKB

PMKBPMKE

PMKE

12/15/02

37


STA Roam to AP B

A B C D E

PMKB=TLS-PRF(MK, PMKA, APB-MAC-ADDR, STA-MAC-ADDR)

PTK via standard 4-way handshake

PMKA

PTK

RADIUS (AAA)

Roam ServerMKPMKA

PMKB PMKE

PMKBPMKE

Old and newAP’s inform

RS RS buildsNeighbor Graph

12/15/02

38


STA Roam to AP B

A B C D E

RADIUS (AAA)

Roam ServerMKPMKA’

PMKB

PMKC

PMKD

PMKE’

PMKB

PTKPMKE’

MKPMKB

PTK

PMKDPMKCPMKA’

12/15/02

39


Proactive Key Distribution Protocol

1. STA associates to AP1.2. STA performs 802.1X EAP-TLS authentication with (AP1, AS).3. AS and STA derive the PMK = TLS-PRF(MasterKey, "client

EAP Encryption" | clientHello.random | serverHello.random).4. AS sends PMK to AP1.5. AP1 and STA derive PTK via any method, e.g. 4-way

handshake6. AP1 and STA derive GTK in usual way7. AS constructs PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-

Addr, STA-MAC-Addr)8. AS sends PMK2 to AP29. Steps 7 and 8 performed for each AP in Neighbor(AP1)

12/15/02

40


Protocol cont.1. STA roams to AP22. STA derives PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-

Addr, STA-MAC-Addr)3. AP2 and STA derive PTK via key agreement, e.g. 4-way

handshake4. AP2 and STA derive GTK in usual way5. STA can resume data traffic6. AP1 and AP2 inform AS of the roam7. AS constructs PMK3 = TLS-PRF(MasterKey, PMK2, AP3-MAC-

Addr, STA-MAC-Addr)8. AS sends PMK3 to AP39. Steps 7 and 8 done for each AP in Neighbor(AP2)

12/15/02

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

12/15/02

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

12/15/02

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

12/15/02

44


DRNAT

DRNAT

DRNAT

Net 1

IP A

Host A

Host B

IP B

IP 1 Net 2

IP 2

IP 3

Can be placedIn

edge router

12/15/02

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

12/15/02

46


Inter-LAN Roaming Proactive key distribution handles

security well. Proactive caching handles other AP

context well.

12/15/02

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.

12/15/02

48


Ad Hoc Network Security

We’re focusing on: Availability

The major function of routing

A non-trivial aspect of ad hoc network security

12/15/02

49


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

12/15/02

50


Problems with SUCV

S T

Malicious node Virtual node

Virtual network

Create public-private key pair

Assign corresponding SUCV address

12/15/02

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

12/15/02

52


Overall Flow Graph of Route Discovery

DestinationSource

R1

R2

R3

R’1

R’2

Decision nodeData packet

PRP Route Request

PRP Route ReplyRed nodes will make route selection according to the risk value of routes

12/15/02

53

For LTS Review Purposes Only - Do Not RedistributeSimulations from Initial Experiment (without

SUCV)

Average Delay

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

Routing Overhead Delivery Ratio

12/15/02

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!

12/15/02

55


Quantification of Risk

route. theof theas viewedbe could /1)1(1

1))(1(

1)(

d.compromisenot is route ch they with whiprobabilit thebe Let . route theofcost theis where

d.compromise is if ,; dcompromisenot is if ,

)(Let

confidenceppc

pcprAErRisk

rprc

rrc

rA

12/15/02

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:

ii

iie

ii

ie cp

cpp

cpp

c2

,

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.

route theon nodes totalof #nodes trustedof #

confidence

12/15/02

57


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

12/15/02

58


Deciding Trusted Nodes

S A B C T

[ ] [ T(A, S)] [ T(A, S),T(B, A)]

[ T(A, S),T(B, A)]

[ T(A, S) ,T(B, A),T(T, B),T(T, C)]

[ T(A, S) ,T(B, A),T(T, B),T(T, C)]

[ T(A, S) ,T(B, A),T(T, B) ,T(T, C) ,T(C, T)]

[ T(A, S),T(B, A) ,T(T, B) ,T(T, C) ,T(C, T) ,T(B, T)]

[ T(A, S) ,T(B, A) ,T(T, B) ,T(T, C) ,T(C, T) ,T(B, T) ,T(A, B) ]

[T(A, S),T(B, A),T(T, B),T(T, C),

T(C, T),T(B, T),T(A, B),T(S, A)]

Preestabl i shedtrust rel ati onshi ps

12/15/02

59


Route Selection Algorithm

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

Destination

Route Risk

… … …T ST1:

{S,A,B,T}T ST2:

{S,M,N*,T}T ST3:

{S,L,C,T}… … …

Route cache in source S:

12/15/02

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

12/15/02

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.

12/15/02

62


Questions ?

12/15/02

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.

wireless security potpourri

Documents