130 likes | 211 Views
A Proposal to IEEE 802.11i: Optional MAC-Level Authentication and Master Encryption Key Management Carlos Rios RiosTek. TGi Accomplishments to Date. Good solution (ESN) proposed for next generation WLANs: Support for Per Link/Per Session and Shared encryption keys Strong Encryption (AES-OCB)
E N D
A Proposal to IEEE 802.11i: Optional MAC-LevelAuthentication and Master Encryption Key ManagementCarlos RiosRiosTek
TGi Accomplishments to Date • Good solution (ESN) proposed for next generation WLANs: • Support for Per Link/Per Session and Shared encryption keys • Strong Encryption (AES-OCB) • Message Authentication • Replay Protection • “WEP Fix” solution taking shape for legacy equipment • Rapid Refresh of Per Link/Per Session and Shared Keys • Strengthened RC4 Encryption (Temporal Key Hash and Rapid Refresh) • Message Authentication • Replay Protection • However, enhanced Authentication is an upper layer function • 802.1x and EAPOL, and (usually external) Authentication Servers • And Master Encryption Key Management tracks ULAP • Master Per Link/Per Session Encryption Keys for unicast transmissions • Master Shared Key for multicast/broadcast transmissions
About Authentication and Key Management… • Per the 802.11 Enhanced Security Requirements Document 00/245r1, the Enhanced Security framework must scale to: • Simple Environments (Home, SoHo, etc) • IBSS, or Ad Hoc WLANs 802.1x and EAPOL are not reeeally designed for these • There has been talk about OEMs embedding Authentication Servers, etc into the AP • Still doesn’t address Ad Hoc networks • Adds complexity and cost to devices marketed at consumers Complex, expensive, not timely and likely proprietary solutions
A simpler, less expensive, nearer term, readily standardizable approach : DHAKM • “Diffie-Hellman Authentication and Key Management” • MAC-level Mutual STA and AP (or Ad Hoc peer STA) Authentication • MAC-level Master(Per Link/Per Session and Shared) Encryption Key generation • MAC- Level Master Per Link/Per Session Encryption Key refresh • Combines with ESN for strong long term security • AES-OCB adds Strong Encryption, Replay Protection and Message Authentication • Provides excellent support for Home, Public and Ad Hoc WLANs • Defers to Enterprise-centric 802.1x and EAP • Combines with WEP Fix for strong legacy, near term security • WEP Fix incorporates stronger RC4, Replay Protection and Message Authentication • Legacy Equipment upgrades are supported via firmware download • Can be immediate, interim solution for Home, Public and Ad Hoc WLANs • Defers to any deployed 802.1x and EAP- based enterprise configurations
The General Idea • All STAs feature unique, secret, factory assigned Key Material • Diffie Hellman Modulus, a 1024 bit prime number • Diffie Hellman Base, a special 256 bit number • Diffie Hellman Private Key, a 256 bit random number • STA Shared Key, a 256 bit random number • Each STA independently derives a Public Key from its Key Material • 1024 bit one way function of the STA’s DH Modulus, Base and Private Key • STAs exchange Public Keys to create a “Common Key” secret to both • Simple, public (yet secure) two message Diffie-Hellman handshake • 1024 bit one way function of complementary Private and Public Keys • Authentication Signatures (MICs) are calculated from the Common Key and incorporated into the handshake messages • Master Per Link/Per Session keys are also derived from the Key Material • 256 bit function of DH Modulus and Base, newly generated random Private Key • Master Shared Keys are derived using a different approach • IBSS initiator STA’s, or AP’s STA Shared Key is designated as “Alpha” Shared Key • Countdown-Based Rekeying of securely distributed Alpha Shared Keyproduces the sequence of Master Shared Keys
In More Detail • First of all, a one time “DHAKM Authorization” of STA and AP/Peer STA • Provides a “chaperoned formal introduction” • The devices exchange key material to be used in future sessions • Performed by all STA pairs in an IBSS upon very first communication • Performed by home AP and each home STA upon first power on • “DHAKM Sequence” occurs upon start of every session, and upon roaming • For an ESN the DHAKM Sequence initiates: • Mutual STA and AP/Peer STA Authentication • AES-OCB key derivation • Message-Based Rekey handshake to generate/update unicast Master Session keys • Also selects and distributes Master Shared Key for multicast/broadcast transmissions • For the WEP Fix the DHAKM Sequence initiates: • Mutual AP (or Ad Hoc peer STA) and STA Authentication • Base and Temporal Key generation • Message Based Rekey handshake to generate/update unicast Master Session keys • Also selects and distributes Master Shared Key for multicast/broadcast transmissions
DHAKM Authorization • Occurs upon first instantiation of STA and AP/PSTA communications • New STA gets added to infrastructure network, has to register with all APsNote: Unwieldy for networks with large numbers of APs (Hint: Use 802.1x) • First meeting between two or more Ad Hoc STAs • DHAKM Authorization is a “monitored and protected” exchange • Opportunity for an attacker to make mischief by “impersonating” STA or AP • If attacker were in range and ready to pounce the precise instant of this one time event • One or more “Operators” (i.e., IT manager, Ad-Hoc STA users) need be involved • Initiate the Authorization process (enable the “formal introduction”) • Monitor the Authorization (“chaperone the introduction”) • Detect and foil any impersonation attacks (“deter any hanky-panky”) • An “Authorization Enabling Event” (AEE) 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 • Authorization and Master Shared Key generation then proceeds automatically • Devices are placed in “DHAKM Authorization Mode”, provide feedback to Operator(s) • Three message handshake exchanges key material, confirms Authorization • Devices calculate their Public Keys and the Common Key from the key material • Message frames include MICs to foil forgeries, impersonations • Devices automatically exit Authorization, provide positive feedback to Operator(s)
DHAKM Sequence • Mutual Authentication upon start of a session, or upon roaming • Infrastructure STA powers on or moves into range of a new AP • Ad Hoc STA powers on or emerges from Authorization • Common Key derived during Authorization is used as “authenticating mutual secret” • Common Key also provides basis for Message Authentication MIC • New key material is used for updating Master Keys • “Freshness” Nonce • Individual STA Nonces • Individual, randomly generated STA DH Private Keys and associated Public Keys • New Master Per Link/Per Session Key is generated from the complementary STA Private and Public Keys • BSS Master Shared Key (derived via Countdown Rekeying from AP’s original STA Shared Key) is encrypted using hash of Master Session Key and sent to STA • Streamlined process for Mutual Authentication and Key Generation • Supplicant STA senses Beacon, requests DHAKM Authentication from AP/PSTA • Both STAs independently recover key material associated with other’s MAC Address • STAs Mutually Authenticate by exchanging, checking MICs based on Common Key • Same two message handshake • Exchanges key material for generating new Per Link/ Per Session Master Key • Transmits current Master Shared Key from AP/PSTA to supplicant STA
DHAKM and 802.1x • DHAKM provides a self-contained, fully specified, readily implementable MAC level Mutual Authentication and Master Key Refresh mechanism particularly well suited for: • Legacy WLANs that don’t support 802.1x • 802.1x enabled WLANs wanting superior IBSS support • 802.1x enabled home WLANs not provided with Authentication Servers • DHAKM best complements (not replaces) 802.1x • 802.1x supports IBSS via reduction to one way Shared Key Authentication • DHAKM provides per link Mutual IBSS STA Authentication, for all links • 802.1x supports home WLANs if EAP-xxx is incorporated into the AP • DHAKM uses a two message MAC-level exchange instead • 802.1x best supports Enterprise WLANs • Where EAP-TLS capable Authentication Servers exist and abound • 802.1x and DHAKM can happily coexist • Got an Authentication Server? Use 802.1x • Don’t got an Authentication Server? Use DHAKM
DHAKM in 802.11i, the Arguments • Pros • Technically sound approach to Authentication and Master Key Management • Readily, immediately implementable, even in legacy equipment • Consistent with 802.11-99 MAC architecture • Forward compatible with and complementary to 802.1x and ESN • Immediately compatible with the proposed WEP Fix • Completely under the control of 802.11i • Best solution for IBSS and Home WLANs • Cons • Does not fit into the domain of 802.1x • Is philosophically orthogonal to the concept of Upper Layer Authentication DHAKM is simple, inexpensive, readily implementable and compatible with everything else in 802.11i
DHAKM, the Motion • Would like to place a motion before the 802.11i Task Group: “Move that the DHAKM algorithm be incorporated into the 802.11i draft standard text as an optional MAC-level Mutual Authentication and Key Management construct”