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

2 Agenda 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.1x link level authentication Performance Measurement

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

4 Challenges and Our Solutions 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 pre- shared secret between user and network L2/Web Compound Authentication

5 The Single Sign-on concept 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 Coffee shop (provider A) Street (provider B) Office (provider C) ID Provider Confederation Initial Sign-on Single sign-on

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

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

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

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

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

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

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

13 Authentication Adaptation User Interface

14 Layer 2 Roaming User Interface

15 Delay Profile Evaluation Proxy-based (RADIUS) Redirect-based (Liberty) LocalRoamingLocalRoaming Web Authentication Policy Engine Link Layer (802.1x) Authentication Total (Units: sec)

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

backup

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

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

20 L2/Web Authentication Comparison Web-based802.1x/WPA/11i SupportMost public WLAN providers Corporate Networks (only on 802 LAN/MANs) Pre-shared Secret Not necessary (use credit-card authorization) Necessary EncryptionNonePer-station RC4, AES(802.11i) AuthenticationSSL-protected Password EAP-TLS (certificate- based) Access ControlIP/MAC addressCryptographic AccountingFine-grainedOnly at boot time

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

22 Race Attack Scenario Legitimate Client APRADIUS/Web L2 Auth K1 Malicious Client (MAC Spoofer) L2 Auth K2 Firewall (L2 Session key verify NG) Bind (MAC, MD5(K1) Bind (MAC, MD5(K2)) Theft of service can be prevented by authentication binding L2 DoS attack is still possible L2 Auth Web Auth+ MD5(K1) (Why L2 session key digest embedding is necessary)

23 Compound Authentication Testbed Access Point Client RADIUS/Web Server (1) 802.1x TLS guest authentication External Network (2) Establish L2 Session Key (3) Web Auth (with L2 session key digest) (4)Firewall Control Xsupplicant 0.6 libwww-perl Cisco AIR-350 FreeRADIUS Apache Attacker (rejected)