Network Security: WLAN Mobility. Tuomas Aura CS-E4300 Network security Aalto University, Autumn 2017

Transcription

1 Network Security: WLAN Mobility Tuomas Aura CS-E4300 Network security Aalto University, Autumn 2017

2 Outline Link-layer mobility in WLAN Password-based authentication for WLAN Eduroam case study 2

3 LINK-LAYER MOBILITY IN WLAN

4 Wireless LAN roaming latency! Moving between APs is slow: May require full association and WPA2- Enterprise authentication Many roundtrips to a remote authentication server Many messages between STA and AP, and the channel acquisition time for each message can be long on a busy WLAN Packets buffered in the old AP are dropped Lost packets trigger TCP retransmission How to speed up the handover? 4

5 Reassociation and IAPP When STA moves between APs, it sends Reassociation Request Association Request that includes the old AP address New AP could contact the old AP over the wire network to delete the old association there Old AP could forward to the new AP any packets that are buffered or still arrive there Communication between the new and old AP has not been standardized Inter-access point protocol (IAPP) Protocol for communication between APs over the wire network Draft specification f in 2003, never standardized

6 PMK caching! Speeding up reauthentication to the same AP: AP and STA may cache previous pair-wise master keys (PMK) and reuse them if the same client returns to the same AP only the 4-way handshake is needed after (re)association to refresh the PTK Mechanism: STA may send a list of key identifiers (PMKID) in (re)association request; AP may select one of them in Message 1 of the 4-way handshake Standardized in i, included in WPA2 6

7 WLAN switch and opportunistic PMK caching Proprietary protocol WLAN switch EAP over RADIUS Authentication server PMK PTK1 PTK2 Thin AP1 1. Associate first time STA PMK 2. Associate with cached PMK Thin AP2 7

8 WLAN switch! Speeding up reauthentication to a different AP: Authenticator moved from APs to a switch Switch caches PMKID and PMK and computes new PTKs for all APs connected to it Opportunistic PMK caching: client STA sends PMKIDs for cached PMKs to all APs in the ESS, even if the PMK was created at a different AP Communication between switch and AP has not been standardized; proprietary solutions from equipment manufacturers (Recall that ESS basically means the APs with the same SSID.) 8

9 802.1X preauthentication Distribution system, usually a switched Ethernet Intranet EAP over RADIUS Authentication server EAP over LAN 3. Preauhentication over the LAN with the other APs Current AP 1. Association & open port at AP STA 2. Scan for potential new APs 4. Associate with cached PMK Potential next AP 9

10 802.1X preauthentication! Speeding up reauthentication to a different AP: Client STA scans for potential new APs and authenticates to them before deassociation from the old AP AP advertises the preauthentication capability in its beacon STA communicates with the new AP over the wire LAN, through the old AP STA uses the BSSID (= MAC address) of the new AP as the destination address of the frames it sends to the new AP new AP must be on the same IP segment AP caches the PMK, just as if the STA had associated with it previously Finally, STA reauthenticates to the new AP and uses the cached PMK 10

11 Local handoff problem Handoff between local APs Internet or a large network Remote authentication server Even local handoffs require connection to the AS, which may be far away 11

12 802.11r fast BSS transition! Amendment r adds mechanisms for fast handover With PSK or cached MSK, piggyback the 4-way handshake on authentication and association messages only 2 roundtrips between STA and AP Mobility domain = group of APs close to each other + local server that helps in local handoffs AP advertises its capability for fast BSS transition, and a mobility domain identifier Key hierarchy within the mobility domain: local server (R0KH) holds first-level key (PMK-R0), which is used to derive secondlevel keys (PMK-R1) for APs (R1KH) in the same domain avoid contacting a remote authentication server in local mobility In practice: R0KH = WLAN switch, R1KH = AP Also, pre-reservation of resources for QoS (see e) done in parallel with the 4-way handshake 12

13 *********** Passphrase 802.1X authentication r key hierarchy! Pre-Shared Key PSK = PBKDF2(Passphrase) Pairwise Master Key, first level PMK-R0 = R0-Key-Data = KDF(PSK/MSK, "FT-R0", SSID, MDID, R0KH-ID, MAC STA ) Pairwise Temporal Key PTK = PTK = KDF(PMK-R1, "FT-PTK", N STA, N AP, BSSID, MAC STA ) Key Confirmation Key KCK split Key Encryption Key KEK (for encrypting the group i.e. broadcast key) Master Session Key MSK Pairwise Master Key, second level PMK-R1 = PMK-R1 = KDF(PMK-R0, FT-R1 BSSID, MAC STA ) Temporal Key TK (key material for session keys) PMK-R0 = key shared by STA and the mobility domain (WLAN switch); derived from MSK (or PSK) PMK-R1 = key shared by STA and AP; derived locally from PMK-R0 AP only knows PMK- R1, STA knows PMK-R0 and can compute PMK-R1 for each new AP 13

14 802.11r mobility domains R1KH AP Mobility domain R1KH AP WLAN switch R0KH R1KH AP R1KH AP Mobility domain R1KH AP R0KH WLAN switch Internet or a large network Remote authentication server Handoff within a mobility domain is supported by the local R0KH EAP with AS only when moving between mobility domains r specifies the key hierarchy and communication between STA and AP; the protocol between APs and the R0KH is not standardized 14

15 AAAA Authentication, authorization and accounting architecture (AAAA) Architecture and protocols for managing network access Standard protocols: DIAMETER (newer), RADIUS (old, still widely used) Roaming support (but no fast local mobility): Visited AAA server (AAAF) acts as a proxy for home AAA (AAAH) AAA brokers can be used to create roaming federations Many hierarchical mobility schemes proposed but not standardized AAAA and r both support roaming and hierarchical authentication AAAA is an IETF standard and runs on TCP or SCTP r is standardized by Wi-Fi equipment vendors and IEEE AAAF (RADIUS server of foreign network) AAA broker (proxy RADIUS server) AAAH (RADIUS server of user s home domain) Internet AP=NAS 15

16 PASSWORD AUTHENTICATION FOR WLAN 16

17 Captive portal! Web-based authentication for network access; also called universal access method (UAM) Used in hotels and wireless hotspots for credit-card payment or password authentication New users are directed to an authentication web page ( captive portal ) when they open a web browser Redirection usually based on spoofed HTTP redirection; sometimes DNS spoofing or IP-layer interception Authenticated users MAC addresses are added to a whitelist to allow Internet access

18 PEAP! Protected EAP (PEAP) is an EAP method defined by Microsoft General idea: authenticate the server with TLS, then the client inside the encrypted tunnel Round 1: EAP-TLS with server-only authentication Instead of EAP-Success, start encryption and move to round 2 Round 2: any EAP authentication method with mutual authentication In practice, the authentication in round 2 is MSCHAPv2: called EAP-PEAP-MSCHAPv2, PEAPv0, or usually just PEAP What does PEAP achieve: Password authentication takes place inside an encrypted tunnel prevents offline password cracking from MSCHAPv2 messages EAP-Response-Identity sent twice, both in inner and outer EAP layer: outer layer may reveal only the domain ) for identity protection Similar protocols: LEAP by Cisco (insecure and no longer used) and EAP-TTLS by Funk Software/Juniper 18

19 EDUROAM CASE STUDY 19

20 Eduroam WLAN roaming between academic institutions Roaming enabled by federation between RADIUS servers WPA2 with AES encryption Aalto RADIUS server is radius.org.aalto.fi Aalto user s NAI looks like the address, e.g. tuomas.aura@aalto.fi Aalto users are authenticated with EAP-PEAP Microsoft s proprietary EAP method with TLS for the server authentication and password for the client 20

21 / \ / \ edu....nl....ac.uk / \ \ / \ \ / \ \ utk.edu utah.edu case.edu hva.nl surfnet.nl soton.ac.uk user: paul@surfnet.nl surfnet.nl Authentication server Eduroam RADIUS hierarchy Initially RADIUS messages passed through the root server Now RADIUS peering between countries Dynamic IdP discovery with DNS PKI for authorization Routing based on the realm part of NAI Figure 2: eduroam RADIUS Hierarchy [RFC 7593]

22 Eduroam Eduroam is a federation for wireless roaming between educational institutions User is registered at the home university, which has a RADIUS server (AAAH) National educational and research network (NREN), e.g. Funet, operates a national roaming broker National brokers are connected to a regional broker for international roaming EAP authentication: user s home institution determines the EAP authentication method Aalto uses PEAP Users identified by NAI: username@realm NAI for Aalto users: firstname.lastname@aalto.fi (earlier also username@aalto.fi, seems to be no longer in use) In PEAP, the outer NAI only needs to have only correct realm, but Aalto seems to require the username to be correct as well (should test if this is still the case) 22

23 Network authentication?! IN EAP-TLS and PEAP, the client authenticates the RADIUS server based on a certificate To verify the certificate, the client needs to know: trusted CAs name of the RADIUS server On many clients, any commercial CA and any name in the certificate is accepted anyone with any commercial certificate can set up a fake AP and pretend to be the RADIUS server MitM attacker can sniff the unprotected MSCHAPv2 and crack the password (or DES key) Have you configured he network authentication for Eduroam correctly on your clients? 23

24 Security protocol design and standardization: case EAP-NOOB Tuomas Aura, Aalto University

25 EAP-NOOB Team: Tuomas Aura, Mohit Sethi, Shiva TP at al. Cooperation with Ericsson Research Nimble out-out-of-band authentication for EAP Internet-Draft draft-aura-eap-noob EAP method for secure bootstrapping of cloudconnected smart appliances Register device to cloud + get Wi-Fi access One user-assisted out-of-band message Long path from research publication to a real protocol specification 25

26 EAP-NOOB user experience example aalto.fi aalto.fi aalto.fi AAA/cloud account login Aura, Sethi: draft-aura-eap-noob 26

27 Fundamental protocol design Security protocol design ECDH + OOB authentication Communication channels Fit into the AAA architecture and EAP protocol Authentication vs. first registration No pre-established device id (NAI) or credentials AAA server does not know that the device exists Device ownership Linking to one cloud service and one user account Lifecycle from bootstrapping to ownership handover and reuse

28 Scenario: cloud-connected IoT appliance Remote AAA (in cloud) IoT appliances Local AAA Wireless AP Trust Scan Aura, Sethi: draft-aura-eap-noob 28

29 Scenario: cloud-connected IoT appliance Remote AAA (in cloud) IoT appliances Local AAA Wireless AP Trust Scan Web page / API RADIUS EAP in-band OOB Output / Input User-assisted OOB channel Aura, Sethi: draft-aura-eap-noob 29

30 EAP-NOOB in the background 1. EAP-NOOB initial exchange: ECDH in-band aalto.fi aalto.fi 2. OOB message: secret + hash aalto.fi 3. EAP-NOOB completion: authentication and key confirmation in-band AAA/cloud account login Aura, Sethi: draft-aura-eap-noob 30

31

32 Design challenges 1 Identifier allocation Initial authentication without pre-allocated name Device selection without secure name Identifier squatting Fail-stop vs. deadlock freeness Protocol state machine, formal model (Promela) Generality vs. immediate usefulness OOB directions Implementation as fully-fledged EAP method Roaming support

33 Design challenges 2 Avoid rerun of user-assisted authentication From ephemeral state to persistent association Timeouts Must have values, but how many seconds? Error reporting and handling Failure recovery Avoid permanent failure from DoS Back-off behavior vs DoS

34 Design challenges 3 Rekeying without user interaction Use master key from persistent association Algorithm update with master-key update Must update persistent association Spec complexity Mismatches with existing EAP software architecture User experience evaluation Standards group process issues and politics

35 Summary: EAP-NOOB Research on security protocol design Nimble out-of-band authentication for EAP: bootstrapping security for smart appliances Spec: Code: