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

2. 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-v2 2

3. How to get a PAC -“Phase 0”, manual -Automatic PAC provisioning When done with server certificates; safe way of providing PAC (MiM 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

4. 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 FreeRADIUS experience -We learned more about optimizing EAP in general 4

5. EAP type selection (1) -Order of EAP-type in config (of Radiator) matters eg. EAPType PEAP, TTLS, TLS, FAST -Server requests first configured mechanism to client, after that (second attempt) the client preference is tried./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 5

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

7. 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: * Actually, there is more (Open)SSL specific stuff you need 7 with DHfilewithout DHfile bytes61895213 packets2018

8. Differences in FAST implementations -Hard to do speed comparisons; -Amount of logging, OS, certificates matters -Differences local vs. remote -Differences in minimal amount of packets -Differences in tunneled auth, more pkts & bytes! -Radiator does not (yet) cache PACs, requested 8 PAC provis.Tunneled authPkts RadiatorMSCHAPv2MSCHAPv2, GTC opt14 Cisco ACSMSCHAPv2GTC10 Local FAST avg.Remote FAST avg. Radiator27 – 41 ms228 ms Cisco ACS23 ms163 ms

9. EAP, UDP packets by type 9 FASTFAST-PACTTLSPEAPTLS # of packets 1622162622 tot packet- length 27014185472861657054 average packetsize 168190295237321 max packetsize 277566 1472 With the maximum fragment size on the server set to 512 Packet-size from clients not restricted by server-settings, filling up MTU

10. EAP, UDP packets by type 10 FASTFAST-PACTTLSPEAPTLS # of packets 1620 (-2)12 (-4)22 (-4)16 (-6) tot packet- length 26953975436257996505 average packetsize 168198364293407 max packetsize 2726701082 1472 average time 454 ms594 ms866 ms777 ms With the maximum fragment size on the server set to 1000 Now other EAP-mechanisms fill up fragment-size too

11. After optimization 11 FAST*FAST-PACTTLSPEAPTLS # of packets 14 / 1018 / 18101812 tot packet- length 2479 / 2136 3785 / 4193 339146495420 average packetsize 184 / 213210 / 233339258451 max packetsize 178 / 406670 / 6991460 1472 frag 1549 average time (ms) 228 / 163300 ms518 ms369 ms local avg.27 / 23 ms264 / 37541 ms53 ms46 ms time / pkt.16 ms30 ms29 ms31 ms Reduced packet-size is an improvement considering RADIUS/UDP reliability * Radiator / Cisco ACS

12. 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 -RadSec solves many of these problems too, does not introduce much delay -802.11r, PMK caching 12

13. 13 Paul.Dekkers@surfnet.nl

14. Spare sheet 1 EAP tunables 14 -EAPTLS_MaxFragmentSize 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 self- signed Globalsign instead of homebrew gives 2-4 extra packets, ~1500 bytes -DHfile adding one adds bytes (~800) and packets (2)

15. 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