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

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

3. 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. 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 SM RC DT To network

5. 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. 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. 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. 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. 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. 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”

11. 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.htmlhttp://www-lce.eng.cam.ac.uk/~fms27/duckling/duckling.html  Issue – how exactly is imprinting done? –What if adversary imprints AP first?

12. 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. 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. 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. 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. 16 Questions? Download presentation at http://www.legra.com/info_center.htm