Upload
erik-george-fitzgerald
View
215
Download
1
Tags:
Embed Size (px)
Citation preview
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
2
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?)
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 ACSwith Mac OS X client, eapol_test, Cisco client
- See presentation from Maja for FreeRADIUS experience
- We learned more about optimizing EAP in general4
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=43EAP: Received EAP-Request id=4 method=43EAP: Received EAP-Request id=5 method=43EAP: Received EAP-Request id=6 method=43EAP: Received EAP-Request id=7 method=435
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 EAP consecutive EAP
bytes 2561 2751
packets 14 16
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 need7
with DHfile without DHfile
bytes 6189 5213
packets 20 18
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, requested8
PAC provis. Tunneled auth Pkts
Radiator MSCHAPv2 MSCHAPv2, GTC opt 14
Cisco ACS MSCHAPv2 GTC 10
Local FAST avg. Remote FAST avg.
Radiator 27 – 41 ms 228 ms
Cisco ACS 23 ms 163 ms
EAP, UDP packets by type
9
FAST FAST-PAC TTLS PEAP TLS
# of packets
16 22 16 26 22
tot packet-length
2701 4185 4728 6165 7054
average packetsize
168 190 295 237 321
max packetsize
277 566 566 566 1472
With the maximum fragment size on the server set to 512Packet-size from clients not restricted by server-settings, filling up MTU
EAP, UDP packets by type
10
FAST FAST-PAC TTLS PEAP TLS
# of packets
16 20 (-2) 12 (-4) 22 (-4) 16 (-6)
tot packet-length
2695 3975 4362 5799 6505
average packetsize
168 198 364 293 407
max packetsize
272 670 1082 1082 1472
average time
454 ms 594 ms 866 ms 777 ms
With the maximum fragment size on the server set to 1000Now other EAP-mechanisms fill up fragment-size too
After optimization
11
FAST* FAST-PAC TTLS PEAP TLS
# of packets
14 / 10 18 / 18 10 18 12
tot packet-length
2479 / 2136
3785 / 4193
3391 4649 5420
average packetsize
184 / 213 210 / 233 339 258 451
max packetsize
178 / 406 670 / 699 1460 1460 1472 frag1549
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
Reduced packet-size is an improvement considering RADIUS/UDP reliability
* 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 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 caching12
Spare sheet 1 EAP tunables
14
- 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)
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