57 th IETF CAPWAP Security Issues David Molnar

57 th IETF CAPWAP Security Issues David Molnar Security Architect July 18, 2003

57 th IETF CAPWAP Security Issues David Molnar Security Architect July 18, 2003

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 3

What Are We Protecting? SM RC DT Wireless clients To network Access Point(AP) § Radio Control (RC) Access Router(AR) – Radio configuration, statistics, discovery § Session Management (SM) – 802. 11 management and 802. 1 x authentication frames § Data Tunneling (DT) – User data § Choice - What do we protect at which level? – Who protects DT? 4

Choice: MAC Termination § Terminate 802. 11 MAC at AR or AP? – Issues with Qo. S (802. 11 e), L 2 fragmentation § Terminate at AP § Terminate at AR § Split Termination – Example: LWAPP drops encryption at AP, packetization at AR 5

Constraints § § § Wireless between Station and AP AP-AR link may be L 2, 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 6

Secure Associations, not just Links Bob Alice Charlie § 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 7

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 8

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 9

Scenario 1 : Shared Password “PASSWORD” § Simplest § Cryptographic issues – Should not use password directly as key – Use “key expansion, ” e. g. PKCS #5 standard or IEEE 1363 Key Derivation Function § Could use “zero-knowledge password protocols” – Prevent “offline guessing”; mitigate poor choice of user password – e. g. SRP (RFC 2945), SPEKE, PDM, many others – Patent issues are murky, see forthcoming IPR WG § Does not scale on its own (combine with RADIUS ? ) 10

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/~fms 27/duckling. html § Issue – how exactly is imprinting done? – What if adversary imprints AP first? 11

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? 12

Scenario 4: Guilty Until Proven Innocent Yes/No Let AP on network? § 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? 13

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. ieee 802. org/11/Documents/Document. Holder/2 -477. zip 14

Future Directions § Clarify requirements § Evaluate transport layer requirements – Address AP RNG issue, L 2/L 3 § 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 15

Questions? Download presentation at http: //www. legra. com/info_center. htm 16