EAPFAST Paul Dekkers SURFnet Tomasz Wolniewicz PIONIER Vienna

EAP-FAST Paul Dekkers, SURFnet Tomasz Wolniewicz, PIONIER Vienna, february 18 th, 2010

EAP-FAST - Successor by Cisco for LEAP (and Cisco PEAP? ) while still trying to stay “L”, lightweight - PEAP is perceived difficult because of certificates to authenticate server to client - EAP-FAST uses Protected Access Credential (PAC), per user file - Phase 0: manual PAC provisioning Phase 1: PAC is used to establish TLS tunnel Phase 2: credentials exchanged inside tunnel, in type/lengt/value (TLV) packets, MSCHAP-v 2 2

How to get a PAC - “Phase 0”, manual - Automatic PAC provisioning When done with server certificates; safe way of providing PAC (Mi. M risks still apply). - We used automatic PAC provisioning in TLS tunnel (which requires server certificates) - First auth attempt fails, but provides PAC So… is it easier? More secure? Faster? (Does it offer faster roaming then for instance PMK caching? ) 3

What we’ve done - Test how EAP-FAST works - Speed tests (generic EAP) from PIONIER to SURFnet, includes 8 hops adding latency - Packet count and size - Testing against Radiator and Cisco ACS with Mac OS X client, eapol_test, Cisco client - See presentation from Maja for Free. RADIUS experience 4 - We learned more about optimizing EAP in general

EAP type selection (1) - Order of EAP-type in config (of Radiator) matters eg. EAPType PEAP, TTLS, FAST - Server requests first configured mechanism to client, after that (second attempt) the client preference is tried 5 . /eapol_test … | grep "Received EAP-Request” EAP: Received EAP-Request id=0 method=1 (Identity) EAP: Received EAP-Request id=1 method=21 (TTLS) EAP: Received EAP-Request id=2 method=43 (FAST) EAP: Received EAP-Request id=3 method=43 EAP: Received EAP-Request id=4 method=43 EAP: Received EAP-Request id=5 method=43 EAP: Received EAP-Request id=6 method=43 EAP: Received EAP-Request id=7 method=43

EAP type selection (2) - Some servers do not allow to configure order - It saves at most 2 packets preferred EAP consecutive EAP bytes 2561 2751 packets 14 16 (numbers with EAP-fast as type) So it’s smarter to configure your preferred mechanism as first option in the config, when possible. 6

Influence of Diffie. Hellman keys - For EAP-FAST you need a EAPTLS_DHFile *, for other EAP-mechanisms this is optional - It does influence other EAP-types For EAP-TTLS, with and without DHFile: 7 with DHfile without DHfile bytes 6189 5213 packets 20 18 * Actually, there is more (Open)SSL specific stuff you need

Differences in FAST implementations - Hard to do speed comparisons; - Amount of logging, OS, certificates matters - Differences local vs. remote Local FAST avg. Remote FAST avg. Radiator 27 – 41 ms 228 ms Cisco ACS 23 ms 163 ms - Differences in minimal amount of packets - Differences in tunneled auth, more pkts & bytes! Radiator PAC provis. Tunneled auth Pkts MSCHAPv 2, GTC opt 14 GTC 10 Cisco ACS MSCHAPv 2 - Radiator does not (yet) cache PACs, requested 8

EAP, UDP packets by type FAST-PAC TTLS PEAP TLS 16 22 16 26 22 tot packet- 2701 length 4185 4728 6165 7054 average packetsize 168 190 295 237 321 max packetsize 277 566 566 1472 # of packets With the maximum fragment size on the server set to 512 Packet-size from clients not restricted by server-settings, filling up MTU 9

EAP, UDP packets by type FAST-PAC TTLS PEAP TLS 16 20 (-2) 12 (-4) 22 (-4) 16 (-6) tot packet- 2695 length 3975 4362 5799 6505 average packetsize 168 198 364 293 407 max packetsize 272 670 1082 1472 average time 454 ms 594 ms 866 ms 777 ms # of packets 10 With the maximum fragment size on the server set to 1000 Now other EAP-mechanisms fill up fragment-size too

After optimization FAST* FAST-PAC TTLS PEAP TLS 14 / 10 18 / 18 10 18 12 tot packet- 2479 / length 2136 3785 / 4193 3391 4649 5420 average packetsize 184 / 213 210 / 233 339 258 451 max packetsize 178 / 406 670 / 699 1460 1472 frag 1549 average time (ms) 228 / 163 300 ms 518 ms 369 ms local avg. 27 / 23 ms 264 / 375 41 ms 53 ms 46 ms time / pkt. 16 ms 30 ms 29 ms 31 ms # of packets Reduced packet-size is an improvement considering RADIUS/UDP reliability 11 * Radiator / Cisco ACS

Conclusions - Packet-loss, -reordering and retransmissions are annoying (and sometimes killing) - EAP mechanisms that send less and smaller packets have less risks - EAP-FAST does a nice job in that regard We do need (more, free) clients - Risks are higher at remote locations - Rad. Sec solves many of these problems too, does not introduce much delay 12 - 802. 11 r, PMK caching

Paul. Dekkers@surfnet. nl 13

Spare sheet 1 EAP tunables - EAPTLS_Max. Fragment. Size Setting of eg. 512 versus no (max UDP) can mean difference of 12 vs. 20 packets, ~800 bytes - CA and certificate sizes, public CA or selfsigned Globalsign instead of homebrew gives 2 -4 extra packets, ~1500 bytes - DHfile adding one adds bytes (~800) and packets (2) 14

Spare sheet 2 PACs consist of… - PAC-Key: A 256 -bit key used by the client to establish the TLS tunnel. This key maps as the TLS pre-master-secret. The PAC-Key is randomly generated by the AS to produce a strong entropy 32 -octet key. - PAC-Opaque: A variable length field that is sent to the server during the TLS tunnel establishment. The PAC-Opaque can only be interpreted by the server to recover the required information for the server to validate the peer’s identity and authentication. For example, the PAC-Opaque may include the PAC-Key and the PAC’s peer identity. The PAC-Opaque format and contents are specific to the issuing PAC server. - PAC-Info: A variable length field used to provide at minimum, the authority identity or PAC issuer. Other useful but not mandatory information, such as the PAC-Key lifetime, may also be conveyed by the AS to the peer during PAC provisioning or refreshment. 15