57th IETFCAPWAP Security Issues

David Molnar

Security Architect

July 18, 2003

57th IETFCAPWAP Security Issues

David Molnar

Security Architect

July 18, 2003

3

What I’m Going To Talk About

Identify choices and goals for discussion

Make assumptions explicit

Scenarios for provisioning associations– Not last word

“Heavyweight” protocols on “lightweight” APs ?

Guiding principle: be paranoid– Weigh costs vs. benefits

– Realize adversaries tend to do it if it can be done

4

What Are We Protecting?

Radio Control (RC)– Radio configuration, statistics, discovery

Session Management (SM)– 802.11 management and 802.1x authentication frames

Data Tunneling (DT)– User data

Choice - What do we protect at which level?– Who protects DT?

Access Point(AP)Access Router(AR)

Wireless clients

SMSM

RCRC

DTDT

Tonetwork

5

Choice: MAC Termination

Terminate 802.11 MAC at AR or AP?– Issues with QoS (802.11e), L2 fragmentation

Terminate at AP

Terminate at AR

Split Termination– Example: LWAPP drops encryption at AP, packetization at

AR

6

Constraints

Wireless between Station and AP AP-AR link may be L2, routed, or even wireless MAC addresses spoofable APs lightweight (more later) Existing hardware crypto support in AP, AR Must not break 802.11

Attacks

“Rogue” APs and “Rogue” ARs

De-association and De-authentication of users

Eavesdropping on user data

Taking over AP or AR

Denial of Service

7

Secure Associations, not just Links

Alice, Bob, and Charlie all have certificates, can negotiate shared secret

BUT– How does Alice know she should be with Bob and not Charlie? (Rogue AR)

– How does Bob know Alice should be with him? (Rogue AP)

Goal: Shared secret PLUS assurance of the “right” association.

Related issues: Discovery, Handoff

Alice

Bob

Charlie

8

After Secure Association: Secure Transport Now need to use shared secret Some attacks possible on session:

– Eavesdropping– Changing packets – Truncation– Reordering– Replay– Redirection– Reflection

Secure transport should prevent ALL such attacks Choice: Adapt existing secure transport or build our own?

– Extensive peer review critical for finding security flaws– Special requirements for AP-AR affect decision

9

Some Transport Pros&Cons

IPSec– Pros: widespread, scrutinized, works w/any IP transport– Cons: Heavyweight, NAT/firewall issues, assumes IP

TLS– Pros: widespread, scrutinized– Cons: Assumes certs, reliable transport

Can work around to use shared secret (Gutmann ID) CMS (PKCS #7)

– Pros: Indifferent to transport layer– Cons: No replay/reorder prevention, no session control

Custom– Pro: Can meet requirements exactly– Con: Time-consuming, error-prone

10

Scenario 1 : Shared Password

Simplest Cryptographic issues

– Should not use password directly as key– Use “key expansion,” e.g. PKCS #5 standard or IEEE1363 Key

Derivation Function

Could use “zero-knowledge password protocols”– Prevent “offline guessing”; mitigate poor choice of user password– e.g. SRP (RFC 2945), SPEKE, EKE, PDM, many others– Patent issues are murky, see forthcoming IPR WG

Does not scale on its own (combine with RADIUS ?)

“PASSWORD” “PASSWORD”

11

Scenario 2 : Imprinting

AP manually “imprints” on AR, exchanges shared secret Associates only with imprinted AR (or delegate of AR) AP keeps shared secret until imprint cleared

– Can clearing be forced remotely? Reference: “The Resurrecting Duckling”

– http://www-lce.eng.cam.ac.uk/~fms27/duckling/duckling.html

Issue – how exactly is imprinting done?– What if adversary imprints AP first?

12

Scenario 3: Management Layer meets PKI

Every AP and AR has certificate for unique name Every AP and AR recognizes administrator’s public key Administrator signs statement “AP Alice belongs with AR Bob”

– List discussion – use x.509 alt name– Distributes to BOTH Alice and Bob

who’s the CA? How is management layer configured for AR and AP?

13

Scenario 4: Guilty Until Proven Innocent

AP negotiates shared secret with AR, “preliminary association” AR verifies association with management layer

– No packets from AP to network until verification Similar to EAP model

Association bound to shared secret– Maybe no certificate in AP at all

What information does management layer have for approval?– MAC address not credible – Device certs?

Let AP on network?

Yes/No

14

Wait, Aren’t APs Lightweight?

Public-key crypto expensive, slow Symmetric-key crypto less expensive (and hardware

support) APs do not have physical random number generators

– Good randomness critical Conclusions

– Use public-key rarely, establish long term symmetric key– Design protocols for no AP random number generation – OR design secure PRNG seed protocol for AP

Where does seed come from? – Factory-implanted seed– Shipped from AR (secured how? replays?)– 802.11 informational document on seed generation

http://www.ieee802.org/11/Documents/DocumentHolder/2-477.zip

15

Future Directions

Clarify requirements

Evaluate transport layer requirements– Address AP RNG issue, L2/L3

Pick secure transport

Evaluate provisioning scenarios; develop new ones

Track relevant concurrent work– DNSSEC, Authenticated DHCP, enroll, TLS/UDP, etc…

Suggestion Solve secure transport, secure association separately

– For transport, assume shared secret exists

– Protocol extensions for methods to derive shared secret

16

Questions?

Download presentation at

http://www.legra.com/info_center.htm