1 / 15

Vienna, february 18th, 2010

EAP-FAST. Paul Dekkers, SURFnet Tomasz Wolniewicz, PIONIER. Vienna, february 18th, 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

kiril
Download Presentation

Vienna, february 18th, 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 provisioningPhase 1: PAC is used to establish TLS tunnelPhase 2: credentials exchanged inside tunnel, in type/lengt/value (TLV) packets, MSCHAP-v2

  3. How to get a PAC • “Phase 0”, manual • Automatic PAC provisioningWhen 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?)

  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 ACSwith Mac OS X client, eapol_test, Cisco client • See presentation from Maja for FreeRADIUS experience • We learned more about optimizing EAP in general

  5. EAP type selection (1) • Order of EAP-type in config (of Radiator) matterseg. 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

  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.

  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-typesFor EAP-TTLS, with and without DHFile: * Actually, there is more (Open)SSL specific stuff you need

  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

  9. EAP, UDP packets by type 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 With the maximum fragment size on the server set to 1000 Now other EAP-mechanisms fill up fragment-size too

  11. After optimization 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 regardWe 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

  13. Paul.Dekkers@surfnet.nl

  14. Spare sheet 1 EAP tunables • EAPTLS_MaxFragmentSizeSetting 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-signedGlobalsign instead of homebrew gives 2-4 extra packets, ~1500 bytes • DHfileadding 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.

More Related