802.1X and AKE Comparison

1. 802.1X and AKE Comparison Nancy Cam-Winget, Atheros Russ Housley, RSA Laboratories Tim Moore, Microsoft Jesse Walker, Intel Cam-Winget,Housley,Moore,Walker

2. 802.1X Requirements/Decisions • Security session Management • 802.1X owns the security session, decides when to authenticate, re-authenticate abd deauthenticate • Encryption is offloaded to 802.11 MAC but encryption decision is made during 802.1X authentication by the authentication server – whether it gives the master key to the authenticator • Liveliness of station/AP via 802.1X authentication or re-associate signature • Race Conditions • Synchronization done by always having a free KeyID • Requires 2 KeyIDs for key mapping keys • Rekey at twice the key lifetime • Roaming and key hand-off • Reuse 802.1X EAPOL-Key message • Key messages must be in clear to allow roaming • Implies that 802.1X must be unencrypted • Fast handoff via IAPP supported • Fast handoff enabled by signature in re-association (562) • WEP “rapid rekeying” • Reuse EAPOL-Key from 802.1X • Authenticator “owns” network so stations must obey key messages • EAPOL-Key is acknowledged from receiver because it is a data message • Authenticator is not told if station cannot obey the message Cam-Winget,Housley,Moore,Walker

3. AKE Requirements/Decisions • Security session Management • MAC owns the security session, decides when to end session • Encryption performed in 802.11 MAC and encryption enforced by security association setup completion • Master Key is provided from external source (802.1X, Manual, Whatever…) • No security assumptions of Master Key • Different approaches for key-mapping keys and default keys • Pre-shared key authentication proves liveness • Use management channel message handshakes to • Synchronize transition from old key to new key • simplify interface with ULA • defeats race condition at 802.1X level • Roaming and key hand-off • Master Key is transferred by extranal source (TGf, Whatever…) • Liveness confirmed by security association establishment • WEP “rapid rekeying” • Arbitrary rekey interval, but default keys must be done on published schedule Cam-Winget,Housley,Moore,Walker

4. Similarities • Secure session is required • State machine is the same • 2 keys are needed for key roll-over • Authenticated exchange used for key roll-over • Roaming facilitated • Implementation complexity roughly the same for the whole system • Implementation will probably in driver or above • Likely to be OS specific Cam-Winget,Housley,Moore,Walker

5. 802.1X Uses in-band messages MAC layer must bypass encryption for 802.1X traffic identified by ethertype Secure session resides in 802.1X Authenticator decides when to rekey: MAC to Application Layer interface needed (MIB?) Informational not normative No enforcement of what to do when replay counter is exhausted IBSS complexity KeyMap keys are managed by individual peers Default keys are managed by beacon transmitter Rekey transition has no confirm Old key stays live until next new key Rekey is message based for both keymap and default keys Liveness algo uses MD5 AKE Uses out-of-band messages Secure session resides in MAC MAC decides when to rekey IBSS always managed by beacon transmitter Rekey transition uses confirm Frees key storage for other purpose Rekey is message based for keymap keys and countdown for default keys Liveness algo uses AES Differences Cam-Winget,Housley,Moore,Walker