Network Security: WLAN Mobility Tuomas Aura CS-E4300 Network security Aalto University, Autumn 2017
Outline Link-layer mobility in WLAN Password-based authentication for WLAN Eduroam case study 2
LINK-LAYER MOBILITY IN WLAN
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
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 802.11f in 2003, never standardized
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 802.11i, included in WPA2 6
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
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
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
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
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
802.11r fast BSS transition! Amendment 802.11r adds mechanisms for fast handover With PSK or cached MSK, piggyback the 4-way handshake on 802.11 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 802.11e) done in parallel with the 4-way handshake 12
*********** Passphrase 802.1X authentication 802.11r 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
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 802.11r specifies the key hierarchy and communication between STA and AP; the protocol between APs and the R0KH is not standardized 14
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 802.11r both support roaming and hierarchical authentication AAAA is an IETF standard and runs on TCP or SCTP 802.11r 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
PASSWORD AUTHENTICATION FOR WLAN 16
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
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 (e.g. @aalto.fi ) for identity protection Similar protocols: LEAP by Cisco (insecure and no longer used) and EAP-TTLS by Funk Software/Juniper 18
EDUROAM CASE STUDY 19
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 email 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
+-------+. +---+---+ / \ +----------------/ \---------------------+ +--+---+ +--+--+ +----+---+.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]
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
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
Security protocol design and standardization: case EAP-NOOB Tuomas Aura, Aalto University
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
EAP-NOOB user experience example aalto.fi aalto.fi aalto.fi AAA/cloud account login Aura, Sethi: draft-aura-eap-noob 26
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
Scenario: cloud-connected IoT appliance Remote AAA (in cloud) IoT appliances Local AAA Wireless AP Trust Scan Aura, Sethi: draft-aura-eap-noob 28
Scenario: cloud-connected IoT appliance Remote AAA (in cloud) IoT appliances Local AAA Wireless AP Trust Scan Web page / API RADIUS routing @eap-noob.net EAP in-band OOB Output / Input User-assisted OOB channel Aura, Sethi: draft-aura-eap-noob 29
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
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
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
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
Summary: EAP-NOOB Research on security protocol design Nimble out-of-band authentication for EAP: bootstrapping security for smart appliances Spec: https://datatracker.ietf.org/doc/draft-aura-eapnoob/ Code: https://github.com/tuomaura/eap-noob