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