Secure Authentication System for Public WLAN Roaming Yasuhiko

Secure Authentication System for Public WLAN Roaming Yasuhiko Matsunaga Ana Sanz Merino Manish Shah Takashi Suzuki Randy Katz

Agenda n n Single sign-on to confederated wireless networks with authentication adaptation Privacy information protection using policy engine Improve security of web-based WLAN authentication by binding 802. 1 x link level authentication Performance Measurement 2

Loose Trust Relationship in Current Public Wireless LAN Roaming WLAN Service Provider Strong Trust Weak Trust n n (ISPs, Card Companies) ID Provider WLAN Strong No Trust Service Trust Provider User Each WLAN system is isolated, deploys different authentication schemes Users have to maintain different ID and credentials 3

Challenges and Our Solutions n n Confederate service providers under different trust levels and with different authentication schemes to offer wider coverage Alleviate user burden of maintaining different identities and credentials per WLAN provider SSO Roaming with Authentication Adaptation Select proper authentication method and protect privacy of user information per WLAN provider Policy Engine Client Avoid theft of wireless service without assuming preshared secret between user and network L 2/Web Compound Authentication 4

The Single Sign-on concept Single sign-on ID Provider Initial Sign-on n n Office (provider C) Street (provider B) Coffee shop (provider A) Confederation Single username and password Users authenticate only the first time Inter-system handover with minimal user intervention Each network may deploy its own authentication scheme 5

Single Sign-on Technology n Currently two technologies clearly accepted by industry: ¨ ¨ n n RADIUS: Proxy-based authentication scheme Liberty Alliance: Redirect-based authentication scheme We adopted both of them for our implementation Need authentication adaptation framework 6

Authentication Adaptation Flow User Terminal (3)Select authentication method according to user’s preferences (1) Request authentication (2) Announce: - provider id - authentication methods - charging options - required user information (4) Submit: - selected authn. method - selected charging option - user information WLAN Service Provider (5) Authenticate the user 7

Client-side Policy Engine n Control automatic submission of user authentication information according to communication context ¨Context includes trust level of provider, cost, etc. n Authentication/Authorization flow adaptation ¨Switch between Proxy-based (Radius) and Redirect-based (Liberty-style) single sign on 8

Policy Engine Architecture End User Policy Check Engine Policy Repository Context Client Applet Auth Info. Repository Policy Enforcement Point Web Browser AAA Server Capability Policy EAP/ 802. 1 X WLAN provider 9

Security Threats of Web-based Authentication and Access Control n Lack of cryptographic bindings causes several security vulnerabilities No Data Encryption ->Eavesdropping Rogue AP >Do. S Web Server Gate-control (IP/MAC) No Message Integrity Check ->Message Alteration IP/MAC spoofing-> Theft of Service External Network 10

L 2/Web Compound Authentication RADIUS/Web Server Client (1) 802. 1 x TLS guest authentication (2) Establish L 2 Session Key Access Point (3) Web Auth (with L 2 session key digest) (4)Firewall Control External Network • Prevent theft of service, eavesdropping, message alteration 11 • Don’t work for L 2 Do. S attack – out of scope

WLAN Single Sign on Testbed Identity Provider Web Radius Server RADIUS Service Provider #1 Radius Web Portal Fire wall HTTPS Client MC External Network SOAP HTTPS Service Provider #2 Radius Web Fire wall Radius RADIUS Web 802. 1 x Client 12

Authentication Adaptation User Interface 13

Layer 2 Roaming User Interface 14

Delay Profile Evaluation (Units: sec) Redirect-based (Liberty) Proxy-based (RADIUS) Local Web Authentication Roaming Local Roaming 0. 184 0. 188 0. 175 1. 467 Policy Engine 0. 318 Link Layer (802. 1 x) Authentication 0. 124 Total 0. 626 0. 630 0. 617 1. 909 15

Conclusions 1. 2. 3. 4. 5. Secure public WLAN roaming made possible by accommodating multiple authentication scheme and ID providers with an adaptation framework Policy Engine reflects user authentication scheme preference and protects privacy of user information Compound L 2/Web authentication ensures cryptographically-protected access Confirmed with prototype, measured performance shows reasonable delay for practical use Exploits industry-standard authentication architectures: Radius, Liberty alliance 16

backup

Public Wireless LAN Service Model n The network is ‘open’ to users without pre-shared secret User Category AAA Servers (1)Monthly/Prepaid Subscribers (2)One-time Users (3)Non. Subscribers WLAN Infrastructure Services Premium Contents & External Network Access (Subscriber Pays) Free & Advertisement Contents (Hotspot Owner Pays) 18

802. 1 x/11 i/WPA L 2 Network Authentication and Access Control n Conventional ‘Closed-style’ authentication: Only hosts with pre-shared key can access the network, Mainly for Corporate WLAN (1) Mutual TLS authentication with pre-shared key (2) Establish L 2 session key dynamically (3) Only successfullydecrypted packets are forwarded External Network 19

L 2/Web Authentication Comparison Web-based 802. 1 x/WPA/11 i Support Most public WLAN Corporate Networks providers (only on 802 LAN/MANs) Pre-shared Secret Not necessary (use Necessary credit-card authorization) None Per-station RC 4, AES(802. 11 i) Encryption Authentication SSL-protected Password Access Control IP/MAC address Accounting Fine-grained EAP-TLS (certificatebased) Cryptographic Only at boot time 20

Our Approach n n Compound L 2/Web authentication to ensure users to have cryptographically-protected wireless LAN access Use 802. 1 x ‘guest’ authentication mode, embed L 2 session key digest in web authentication ¨ At layer 2, do not assume pre-shared secret ¨ Digest embedding is necessary for avoiding race attack n After Web authentication, user gets full access ¨ Otherwise, users have limited access to free contents n L 2 Do. S protection is out of scope 21

Race Attack Scenario (Why L 2 session key digest embedding is necessary) Malicious Client (MAC Spoofer) Legitimate Client L 2 Auth AP RADIUS/Web Firewall Bind (MAC, MD 5(K 1) L 2 Auth K 1 Web Auth+ MD 5(K 1) L 2 Auth K 2 Bind (MAC, MD 5(K 2)) (L 2 Session key verify NG) • Theft of service can be prevented by authentication binding 22 • L 2 Do. S attack is still possible

Compound Authentication Testbed RADIUS/Web Server (1) 802. 1 x TLS guest authentication (2) Establish L 2 Session Key Client Access Point Cisco AIR-350 Xsupplicant 0. 6 libwww-perl 5. 6. 9 (3) Web Auth (with L 2 session key digest) (rejected) Attacker Free. RADIUS 0. 8. 1 Apache 2. 0. 40 (4)Firewall Control External Network 23