TGi Accomplishments to Date

1. A Proposal to IEEE 802.11i: Optional MAC-LevelAuthentication and Encryption Key ManagementCarlos RiosLinCom Wireless Carlos Rios, LinCom Wireless

2. TGi Accomplishments to Date • Good solution (ESN) proposed for Enterprise WLANs: • Mutual AP and STA Authentication • Per Link, Per Session Keys • Key Generation, Distribution, Expiration, Regeneration • Replay Protection • Message Authentication • Strong Encryption (AES) • Not Quite So Strong Encryption (WEP2) for legacy support • Authentication and Key Management are provided by Upper Layer entities • 802.1x Port • Kerberos, Radius Authentication Servers Carlos Rios, LinCom Wireless

3. TGi Unfinished Business • Per Document 00/245r1, Security framework must scale to: • Simple Environments (Home, SoHo, etc) • Public Environments (Hotels, Public Services) • Ad Hoc WLANs It’s unclear AT BEST that ESN can comply • There has been talk about embedding Authentication Servers into home and small business APs • Still don’t address peer to peer networks • Add significant costs to devices primarily marketed at consumers This is a “Let Them Eat Cake” Solution Carlos Rios, LinCom Wireless

4. What does this mean? • The 802.11i solution on the table either calls for sophisticated infrastructure equipment to supplement APs and NICs… • Not too many homes will buy such equipment • Not too many Hotels and Starbucks will buy such equipment • “Ad Hoc Networkers” have no hope Their security solution would remain the discredited 802.11-99 WEP • Or, it requires that sophisticated upper layer mechanisms be incorporated into low cost products • This, in general, will NOT happen • More cost-effective (proprietary) security solutions will be developed instead • Such equipment will be non-standard and non-interoperable And we’ll get blamed for it Carlos Rios, LinCom Wireless

5. An Approach: DHAKM • “Diffie-Hellman Authentication and Key Management” • MAC-level Mutual STA and AP (or peer STA) Authentication • MAC-level Key generation, distribution, expiration and regeneration • Per Link, Per Session Encryption Keys • Combines with AES to get Strong Security • AES adds Strong Encryption, Replay Protection and Message Authentication • Readily supports Home, Public and Ad Hoc WLANs • Enterprise can (should) still be served with ESN • Combines with “WEP2+” to get Not Quite So Strong Security • WEP2+ is WEP2 plus keyed IV (Replay Protection), MIC (Message Authentication) • WEP2 RC4 provides Not Quite So Strong Encryption • Legacy Equipment upgrades can be supported via firmware download • Can be immediate, interim solution for Home, Public and Ad Hoc WLANs • Enterprise can (should) still be served with ESN Carlos Rios, LinCom Wireless

6. The General Idea • All STAs have unique, factory assigned “Secret Keys” (SKs) • “Partial Keys” (PKs) are derived from the SKs using one-way functions • PKs are publicly exchanged to create a “Common Key” (CK) secret to both STAs • Authentication Signatures and Per Link, Per Session Keys are derived from the CK • “Signed Diffie-Hellman” exchanges occur between STAs • One time “DHAKM Registration” of STA and AP/Peer STA • Provides a “chaperoned formal introduction” • The devices negotiate parameters to be used in future sessions • “DHAKM Key Generation” occurs upon initiation of every subsequent session • The devices use previously negotiated parameters to mutually authenticate • The devices use previously negotiated parameters to generate the session key • “DHAKM Key Regeneration” occurs at periodic intervals within a given session • The devices suspend data exchange • They again mutually authenticate and generate a new session key • The devices resume data exchange using the new encryption key Carlos Rios, LinCom Wireless

7. DHAKM Registration • Occurs upon first instantiation of STA and AP/PSTA communications • New STA gets added to an infrastructure network, has to register with all APs • Pull a new NIC for the home WLAN out of the box • First meeting between two or more Ad Hoc STAs • DHAKM Registration is a “monitored and protected” exchange • Opportunity for an attacker to make mischief by “impersonating” STA or AP • One or more “Operators” (i.e., “the computer guy”, Ad-Hoc users) need be involved • Initiate the Registration process (enable the “formal introduction”) • Provide Authorization that the devices are to be networked (“chaperone the introduction”) • Detect and foil any impersonation attacks (“deter any hanky-panky”) • A “Registration Enabling Event” (REE) external to the WLAN is involved • Menu selection or Key Sequence depression on computer hosts • Simultaneous enclosure pushbutton sequence on non-GUI devices • “Docking Procedure” for non UI devices • Registration then proceeds and terminates automatically • Devices are placed in “DHAKM Registration mode”, provide feedback to Operator(s) • Devices calculate PKs from their respective SKs • (New) Authentication frames exchange PKs to create the CK • Authentication frames include“Common Key Signatures” (CKSs) to deter MIM attacks • Seeds for future CKSs are incremented at both STAs to deter “signature replay” attacks • Devices automatically exit Registration, provide positive feedback to Operator(s) Carlos Rios, LinCom Wireless

8. DHAKM Registration Carlos Rios, LinCom Wireless

9. DHAKM Key Generation • Mutual Authentication, Key generation upon start of session • Infrastructure STA powers on or roams into range of a new AP • Ad Hoc STA powers on or emerges from Registration • Uses parameters negotiated at Registration, or updated during the previous session • Key material for Common Key is recalled, NOT exchanged • Key material to divine Signature Functions is recalled, NOT exchanged • Mutual Authentication, Session Key Generation requires knowledge of both • Public exchange of new Authentication Frames • Supplicant STA senses Beacon, issues Authentication Request to other STA • Both STAs independently recover parameters associated with other’s MAC Address • STAs Mutually Authenticate by exchanging, comparing Common Key Signatures • STAs generate new session key based on the CK, update seeds for next session Carlos Rios, LinCom Wireless

10. DHAKM Key Generation Carlos Rios, LinCom Wireless

11. DHAKM Key Regeneration • Mutual Authentication and Key Regeneration upon current key expiration • Infrastructure STA determines current encryption key’s end of life has been reached • Ad Hoc STA determines current encryption key’s end of life has been reached • Data exchange is temporarily suspended • Nearly identical process as DHAKM Key Generation • Supplicant STAc senses Beacon, issues DHAKM Authenticate Request to AP/PSTAa • Both STAs independently recover parameters associated with other’s MAC Address • STAs Mutually Authenticate by exchanging, comparing Common Key Signatures • STAs generate new session key based on the CK, update seeds for next session key regeneration Carlos Rios, LinCom Wireless

12. DHAKM Key Regeneration Carlos Rios, LinCom Wireless

13. Summary • DHAKM is a MAC-level Authentication and Key Management scheme • Requires no Upper Layer entities to provide any functionality • DHAKM provides • Mutual Authentication • Per Link, per Session Encryption Key generation, expiration and regeneration • DHAKM can be combined with AES encryption to provide a comprehensive Strong Security solution for non-enterprise WLANs • DHAKM can be combined with an improved WEP2 to provide comprehensive Not Quite So Strong Security for legacy WLANs • DHAKM could be the basis for an IEEE 802.11i Enhanced Security solution for Home, Public Access and Ad Hoc WLANs Carlos Rios, LinCom Wireless