Vienna, february 18th, 2010

EAP-FASTPaul Dekkers, SURFnetTomasz Wolniewicz, PIONIER

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 EAPbytes 2561 2751packets 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 DHfilebytes 6189 5213packets 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 PktsRadiator MSCHAPv2 MSCHAPv2, GTC opt 14Cisco ACS MSCHAPv2 GTC 10

Local FAST avg. Remote FAST avg.Radiator 27 – 41 ms 228 msCisco 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 mstime / 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

13

Paul.Dekkers@surfnet.nl

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