802 11 i Overview Jesse Walker Intel Corporation

802. 11 i Overview Jesse Walker Intel Corporation jesse. walker@intel. com 1

Presentation Objectives ® Outline security problems in 802. 11 -1999 ® Communicate what IEEE 802. 11 i is and how it works 2

Agenda What’s Wrong with WEP? ® Architecture ® Data Transfer ® Key Management ® Authentication ® Security Capabilities Discovery ® Other Features ® 3

What’s wrong with WEP? What is it? ® IEEE Std 802. 11 -1999 defines Wireless Equivalent Privacy (WEP) ¯ Protocol intended to effect “privacy”… ¯ …because anyone with a radio receiver can eavesdrop! ® WEP’s Goals: ¯ Create the “privacy achieved by a wired network” ¯ Not a well-defined, testable goal ® WEP vulnerabilities discovered; WEP broken! ¯ Walker (Oct 2000), Borisov et. al. (Jan 2001), Fluhrer-Mantin-Shamir (Aug 2001) 4

What’s wrong with WEP? How does WEP “work”? 0 xaa 0 x 00 0 x 80 0 x 00 802. 11 Hdr Append ICV = CRC 32(Data) 802. 11 Hdr Select and insert IV Per-packet Key = IV || RC 4 Base Key RC 4 Encrypt Data || ICV 802. 11 Hdr IV Data Check ICV = CRC 32(Data) Data ICV Remove IV from packet Per-packet Key = IV || RC 4 Base Key RC 4 Decrypt Data || ICV Data ICV 24 bits 5

What’s wrong with WEP? Review of the cipher RC 4 Pseudo-random number generator “key stream” byte b Plaintext data byte p Ciphertext data byte c=p b Decryption works the same way: p = c b Thought experiment: what happens when p 1 and p 2 are encrypted under the same “key stream” byte b? c 1 = p 1 b Then: c 2 = p 2 b c 1 c 2 = (p 1 b) (p 2 b) = p 1 p 2 6

What’s wrong with WEP? Collision attacks 802. 11 Hdr IV 24 luxurious bits Data ICV Encrypted with per-packet key = IV || RC 4 • WEP expands each RC 4 key into 224 per-packet keys data can be recovered if IV is ever repeated with same key RC 4 key must be changed at least every 224 packets or data is exposed through IV collisions! Some implemented IV selection strategies: • Random: Collision probability Pn two packets will share same IV after n packets is P 2 = 1/224 for n = 2 and Pn = Pn– 1+(n– 1)(1–Pn– 1)/ 224 for n > 2. q 50% chance of a collision exists already after only 4823 packets!!! • Increment from 0: Collision probability = 100% after two devices transmit 7

What’s wrong with WEP? Weak key attacks exposes 1 st 8 bytes of keystream 8 bytes known plaintext… 802. 11 Hdr IV 0 xaa 0 x 00 0 x 80 0 x 00 0 xc 0 0 x 15 0 x 7 e 0 xa 5 0 x 3 f 0 x 22 0 xea 0 xa 1 Data ICV Per-packet key = IV || base key: 1 st 3 bytes of per-packet key exposed • Class of RC 4 weak keys exists where patterns in the 1 st 3 bytes of key causes corresponding patterns in 1 st few bytes of the generated RC 4 key stream. • For each packet, use IV and exposed key stream to identify potential weak keys • Iterate over potential weak keys from a sequence of packets until the RC 4 base key is found 8

What’s wrong with WEP? Replay attacks Good guy STA Authorized WEP communications Eavesdrop and record Good guy AP Play back selections Bad guy (STA or AP) 9

What’s wrong with WEP? Forgery attacks 802. 11 Hdr Recv-Addr, Src-Addr, Dest-Addr Data IV 0… 1 ICV … 0 New ICV • Sample Attack 1: q Recv-Addr, Src-Addr, Dest-Addr are all unprotected q On packets from a STA to the AP, corrupt the Dest-Addr q The AP will decrypt data and send it to the forged destination • Sample Attack 2: q create a blank message with same number of data bytes q Flip some bits and compute the ICV q XOR resulting bit-flipped message + ICV into captured message 10

What’s wrong with WEP? Ill-defined goals = attacker success • Aims must be translated into measurable technical objectives • Doesn’t solve the right problems to achieve goals • Securing a WLAN is like securing a submarine: closing only a few of the hatches doesn’t help • If you’re not a professional, don’t indulge in crypto design Weak Keys IV Collisions Message Forgery Replay S. S. WEP 11

Architecture Architectural Components Goals ® EAP/802. 1 X/RADIUS ® Operational Phases ® ¯Discovery, Authentication, Key Management, Data transfer 12

Architecture Goals Replace WEP by protocol that properly uses encryption ® Add data authenticity and integrity ® ¯ Decrypted data doesn’t mean anything if you don’t know who sent it Add proper authentication ® Manufacture “fresh” keys ® ¯ Can’t efficiently defeat replay without fresh keys ¯ Encryption harder to get right without fresh keys ® Tie data link keys to the authentication ¯ Must prove each packet received is authorized 13

Architecture Authentication and Key Management Architecture Wireles s Station Access Point Out of scope of 802. 11 i standard Authenticatio n Server EAP-TLS EAP 802. 1 X (EAPo. L) RADIUS 802. 11 UDP/IP 14

Architecture 802. 11 Operational Phases Station Authenticatio n Server Access Point Security capabilities discovery 802. 1 X authentication 802. 1 X key management RADIUS-based key distribution Data protection 15

Architecture Purpose of each phase (1) ® Discovery ¯ ¯ ® Determine promising parties with whom to communicate AP advertises network security capabilities to STAs 802. 1 X authentication Centralize network admission policy decisions at the AS STA determines whether it does indeed want to communicate ¯ Mutually authenticate STA and AS ¯ Generate Master Key as a side effect of authentication ¯ Use master key to generate session keys = authorization token ¯ ¯ 16

Architecture Purpose of each phase (2) ® RADIUS-based key distribution ¯ AS moves (not copies) session key (PMK) to STA’s AP ® 802. 1 X key management ¯ Bind PMK to STA and AP ¯ Confirm both AP and STA possess PMK ¯ Generate fresh operational key (PTK) ¯ Prove each peer is live ¯ Synchronize PTK use 17

Data Transfer Overview ® 802. 11 i defines 2 protocols to protect data transfer ¯TKIP – for legacy devices only ¯CCMP – better security for new ® devices Two protocols instead of one due to politics 18

Data Transfer Requirements ® ® ® ® Never send or receive unprotected packets Message origin authenticity — prevent forgeries Sequence packets — detect replays Avoid rekeying — 48 bit packet sequence number Eliminate per-packet key – don’t misuse encryption Protect source and destination addresses Use one strong cryptographic primitive for both confidentiality and integrity Interoperate with proposed quality of service (Qo. S) enhancements (IEEE 802. 11 TGe) 19

Data Transfer Filtering STA AP Association Request Association Response Begin filtering non 802. 1 X data MPDUs EAP type specific mutual authentication 4 -Way Handshake Group Key Handshake Allow data MPDUs protected by pairwise, group keys 20

Data Transfer Replay Mechanisms ® 48 -bit IV used for replay detection ¯ First four bits of IV indicate Qo. S traffic class ¯ Remaining 44 bits used as counter ¯ Decryption/integrity check fail if traffic class bits are altered ¯ Sender uses single counter space, but receiver needs one for each traffic class ® AES with CCM or OCB authenticated encryption ¯ CCM is mandatory, and OCB is optional ¯ Header authentication ¯ Payload authentication and confidentiality 21

Data Transfer TKIP Summary ® TKIP: Temporal Key Integrity Protocol ® Designed as a wrapper around WEP ¯Can be implemented in software ¯Reuses existing WEP hardware ¯Runs WEP as a sub-component ® Meets criteria for a good standard: everyone unhappy with it 22

Data Transfer TKIP design challenges ® Mask WEP’s weaknesses… Prevent data forgery ¯ Prevent replay attacks ¯ Prevent encryption misuse ¯ Prevent key reuse ¯ ® … On existing AP hardware 33 or 25 MHz ARM 7 or i 486 already running at 90% CPU utilization before TKIP ¯ Utilize existing WEP off-load hardware ¯ Software/firmware upgrade only ¯ Don’t unduly degrade performance ¯ 23

Data Transfer TKIP MPDU Format 24

Data Transfer TKIP Keys ® TKIP Keys ¯ 1 128 bit encryption key ® AP and STA use the same key ® TKIP’s per-packet key construction makes this kosher ¯ 2 64 -bit data integrity keys ® AP, STA use different keys for transmit 25

Data Transfer TKIP Design (1) -- Michael Protect against forgeries • Must be cheap: CPU budget 5 instructions/byte • Unfortunately is weak: a 229 message attack exists • Computed over MSDUs, while WEP is over MPDUs • Uses two 64 -bit keys, one in each link direction • Requires countermeasures: rekey on active attack, rate limit rekeying DA SA Payload 8 byte MIC Michael Authentication Key 26

Data Transfer TKIP Countermeasures ® Check MIC CRC, ICV, and IV before verifying ¯Minimizes chances of false positives ¯If MIC failure, almost certain active attack underway ® If an active attack is detected: ¯Stop using keys ¯Rate limit key generation to 1 per minute 27

Data Transfer TKIP Design (3) Protect against replay • reset packet sequence # to 0 on rekey • increment sequence # by 1 on each packet • drop any packet received out of sequence Hdr Wireles s Station Packet n Hdr Packet n + 1 Hdr Packet n Access Point 28

Data Transfer TKIP Design (4) Stop WEP’s encryption abuse • Build a better per-packet encryption key… • … by preventing weak-key attacks and decorrelating WEP IV and per-packet key • must be efficient on existing hardware Intermediate key Base key Transmit Address: 00 A 0 -C 9 -BA-4 D-5 F Packet Sequence # Phase 1 Mixer 4 msb Phase 2 Mixer Per-packet key 2 lsb 29

Data Transfer CCMP Mandatory to implement: the long-term solution ® Based on AES in CCM mode ® ¯ CCM = Counter Mode Encryption with CBC-MAC Data Origin Authenticity ¯ AES overhead requires new AP hardware ¯ AES overhead may require new STA hardware for hand-held devices, but not PCs An all new protocol with few concessions to WEP ® Protects MPDUs = fragments of 802. 2 frames ® 30

Data Transfer Counter Mode with CBC-MAC ® Authenticated Encryption combining Counter (CTR) mode and CBC-MAC, using a single key ¯ Assumes 128 bit block cipher – IEEE 802. 11 i uses AES ® Designed for IEEE 802. 11 i ¯ By D. Whiting, N. Ferguson, and R. Housley ¯ Intended only for packet environment ¯ No attempt to accommodate streams 31

Data Transfer CCM Mode Overview Encrypted Header Payload MIC Authenticated Use CBC-MAC to compute a MIC on the plaintext header, length of the plaintext header, and the payload ® Use CTR mode to encrypt the payload ® ¯ Counter ® values 1, 2, 3, … Use CTR mode to encrypt the MIC ¯ Counter value 0 32

Data Transfer. . . E E padding B 0 B 1 . . . Bk 0 padding Bk+1 Header . . . Br 0 MIC Payload S 1 A 1 . . . Sm Sm E . . . Am E S 0 m S A 0 E 33

Data Transfer CCM Properties ® CTR + CBC-MAC (CCM) based on a block cipher ® CCM provides authenticity and privacy A CBC-MAC of the plaintext is appended to the plaintext to form an encoded plaintext ¯ The encoded plaintext is encrypted in CTR mode ¯ ® CCM is packet oriented ® CCM can leave any number of initial blocks of the plaintext unencrypted ® CCM has a security level as good as other proposed combined modes of operation, including OCB ¯ In particular, CCM is provably secure 34

Data Transfer CCM Usage by CCMP ® Needs one fresh 128 -bit key ¯ Same 128 -bit Temporal key used by both AP and STA ¯ CBC-MAC IV, CTR constructions make this kosher Key configured by 802. 1 X ® CCMP uses CCM to ® ¯ Encrypt packet data payload ¯ Protect packet selected header fields from modification 35

Data Transfer CCMP MPDU Format 36

Data Transfer Long-term Solution Summary ® Builds on the lessons learned from IEEE 802. 10 and IPsec packet protocol designs ¯Relies on proper use of strong cryptographic primitives Strong security against all known attacks ® Requires new hardware ® 37

Data Transfer Summary Cipher Key Size Key Life Packet Key Integrity Data Header Replay Key Mgmt. WEP RC 4 40 or 104 bits CCMP AES 128 bits 24 -bit IV, wrap Concat. TKIP RC 4 128 bits encryption, 64 bit auth 48 -bit IV Mixing Fnc CRC-32 None Michael Use IV EAP-based CCM Use IV EAP-based 48 -bit IV Not Needed 38

Key Management 802. 1 X Key Management 802. 11 i data protocols fail without “fresh” keys Want to use 802. 1 X framework Original 802. 1 X key management hopelessly broken, so redesigned by 802. 11 i ® New model: ® ® ® Derive a Pairwise Master Key (PMK) AP and STA use PMK to derive Pairwise Transient Key (PTK) ¯ Use PTK to protect the link ¯ ¯ ® Limitations: ¯ No explicit binding to earlier association, authentication ® ¯ Relies on temporality, PMK freshness for security Keys are only as good as back-end allows 39

Key Management Pairwise Key Hierarchy Master Key (MK) Pairwise Master Key (PMK) = TLS-PRF(Master. Key, “client EAP encryption” | client. Hello. random | server. Hello. random) Pairwise Transient Key (PTK) = EAPo. L-PRF(PMK, AP Nonce | STA Nonce | AP MAC Addr | STA MAC Addr) Analog of the WEP key Key Confirmation Key (KCK) – PTK bits 0– 127 Key Encryption Key (KEK) – PTK bits 128– 255 Temporal Key – PTK bits 256–n – can have cipher suite specific structure 40

Key Management Overview STA AP AS Step 1: Use RADIUS to push PMK from AS to AP Step 2: Use PMK and 4 -Way Handshake to derive, bind, and verify PTK Step 3: Use Group Key Handshake to send GTK from AP to STA 41

Key Management Step 1: Push PMK to AP ® RADIUS: not worth talking about… 42

Key Management EAPo. L Key Message Descriptor Type – 1 octet Key Information – 2 octets Key Length – 2 octets Replay Counter – 8 octets Nonce – 32 octets IV – 16 octets RSC – 8 octets Key ID – 8 octets MIC – 16 octets Data Length – 2 octets Data – n octets 43

Key Management Step 2: 4 -Way Handshake AP STA PMK Pick Random ANonce EAPo. L-Key(Reply Required, Unicast, ANonce) Pick Random SNonce, Derive PTK = EAPo. L-PRF(PMK, ANonce | SNonce | AP MAC Addr | STA MAC Addr) EAPo. L-Key(Unicast, SNonce, MIC, STA RSN IE) Derive PTK EAPo. L-Key(Reply Required, Install PTK, Unicast, ANonce, MIC, AP RSN IE) EAPo. L-Key(Unicast, MIC) Install TK 44

Key Management STA Step 3: Group Key Handshake PTK AP PTK Pick Random GNonce, Pick Random GTK Encrypt GTK with KEK EAPo. L-Key(All Keys Installed, ACK, Group Rx, Key Id, Group , RSC, GNonce, MIC, GTK) Decrypt GTK EAPo. L-Key(Group, MIC) unblocked data traffic 45

Key Management One Last Detail EAPo. L-PRF(K, A, B, Len) R “” for i 0 to (Len+159)/160 do R R | HMAC-SHA 1(K, A | B | i) return Truncate-to-len(R, Len) Example for CCMP: PTK EAPo. L-PRF(PMK, “Pairwise key expansion”, AP-Addr | STA-Addr | ANonce | SNonce, 384) Why HMAC-SHA 1? ® Because we couldn’t think of anything better ® Because that’s what IKE and Son-of-IKE use 46

Key Management Summary ® 4 -Way Handshake ¯ Establishes a fresh pairwise key bound to STA and AP for this session ¯ Proves liveness of peers ¯ Demonstrates there is no man-in-the-middle between PTK holders if there was no man-in-themiddle holding the PMK ¯ Synchronizes pairwise key use ® Group Key Handshake provisions group key to all STAs 47

Authentication Requirements Want key tied back to authorization decision ® Establish a session between AS and STA ® Establish a mutually authenticated session key shared by AS and STA ® Session key is fresh ¯ Mutually authenticated bound only to AS and STA ¯ ® Defend against eavesdropping, man-in-the-middle attacks, forgeries, replay, dictionary attacks against either party ¯ ® Cannot expose non-public portions of credentials Identity protection not a goal ¯ Can’t hide the MAC address 48

Authentication Components Wireles s Station Authenticatio n Server Access Point EAP-TLS EAP 802. 1 X (EAPo. L) RADIUS 802. 11 UDP/IP 49

Authentication STA Authentication Overview AP STA 802. 1 X blocks port for data traffic AS AP 802. 1 X blocks port for data traffic 802. 1 X/EAP-Request Identity 802. 1 X/EAP-Response Identity (EAP type specific) RADIUS Access Request/Identity EAP type specific mutual authentication Derive Pairwise Master Key (PMK) RADIUS Accept (with PMK) 802. 1 X/EAP-SUCCESS 802. 1 X RADIUS 50

Authentication Digging Deeper: EAP (1) ® EAP = Extensible Authentication Protocol Defined in RFC 2284 ¯ Being revised due to implementation experience and poor specification (rfc 2284 bis) ¯ Developed for PPP, but 802. 1 X extends EAP to 802 LANs ® Design goal: allow “easy” addition of new authentication methods ® AP need not know about new authentication method ¯ Affords great flexibility ¯ ® EAP is a transport optimized for authentication, not an authentication method itself ¯ Relies on “concrete” methods plugged into it for authentication 51

Authentication Digging Deeper: EAP (2) ® Eases manageability by centralizing Authentication decisions ¯ Authorization decisions ¯ ® Well matched economically to 802. 11: Minimizes AP cost by moving expensive authentication to AS ¯ AP unaware of the authentication protocol ¯ ® EAP supports “chained” authentications naturally First do mutual authentication of devices, then user authentication, etc… ¯ … so well suited to multi-factor authentication ¯ 52

Authentication Digging Deeper: EAP (3) ® AS initiates all transactions Request/Response protocol ¯ STA can’t recover from AS or AP problems ¯ This affords AS with limited Do. S attack protection ¯ ® AS tells the STA the authentication protocol to use ¯ ® AS sends EAP-Success to STA if authentication succeeds ¯ ® STA must decline if asked to use weak methods it can’s support STA breaks off if AS authentication fails AS breaks off communication if authentication fails 53

Authentication Digging Deeper: EAP (4) ® EAP provides no cryptographic protections No defense against forged EAP-Success ¯ Relies on concrete method to detect all attacks ¯ No cryptographic binding of method to EAP ¯ ® No strong notion of AS-STA binding ¯ ® “Mutual” authentication and binding must be inherited from concrete method Legacy 802. 1 X has no strong notion of a session EAP’s notion of session problematic, very weak, implicit ¯ Relies on session notion within concrete method ¯ Key identity problematic ¯ 802. 11 i fixes some of this (see key management discussion below) ¯ 54

Authentication 802. 1 X Defined in IEEE STD 802. 1 X-2001 ® Simple ® ¯ Simple transport for EAP messages ¯ Runs over all 802 LANs ¯ Allow/deny port filtering rules ® Inherits EAP architecture ¯ Authentication server/AP (aka “Authenticator”)/STA (aka “Supplicant”) 55

Authentication RADIUS (1) ® RADIUS is not part of 802. 11 i; back-end protocol is out of scope ¯ But RADIUS is the de facto back-end protocol RADIUS defined in RFC 2138 ® Request/response protocol initiated by AP ® Encapsulates EAP messages as a RADIUS attribute ¯ Response can convey station-specific parameters to the AP as well ¯ ® 4 messages Access-Request – for AP AS messages ¯ Access-Challenge – for AS AP messages forwarded to STA ¯ Access-Accept – for AS AP messages indicating authentication success ¯ Access-Reject – for AS AP message indicating authentication failure ¯ 56

Authentication RADIUS (2) ® RADIUS data origin authenticity ¯ AP receives weak data origin authenticity protection Relies on static key AP shares with AS ® AP inserts a random challenge into each RADIUS request ® AS returns MD 5(response data | challenge | key) with response ® ¯ No ® cryptographic protection to the AS AS relies on security of the AP-AS channel for protection ¯ Trivial attack strategy: ® Interject forged requests into the correct place in the request stream ® RADIUS server will generate valid response 57

Authentication RADIUS (3) ® RADIUS key wrapping defined in RFC 2548 ¯ Non-standard cross between 1 -time pad scheme and MD 5 in “CBC” mode digest 1 MD 5(secret | response data | salt), ciphertext 1 plaintext 1 digest 1 digest 2 MD 5(secret | ciphertext 1), ciphertext 2 plaintext 2 digest 2 digest 3 MD 5(secret | ciphertext 2), ciphertext 3 plaintext 2 digest 3 … ¯ Uses static key AP shares with AS ¯ No explicit binding of key to AP, STA ¯ Great deployment care and vigilance needed to prevent key publication!! 58

Authentication Digging Deeper: EAP-TLS is not part of 802. 11 i; neither is any other specific authentication method ® But EAP-TLS is the de facto 802. 11 i authentication method ® Can meet all 802. 11 i requirements ¯ Other widely deployed methods do not ¯ ® EAP-TLS = TLS Handshake over EAP-TLS defined by RFC 2716 ¯ TLS defined by RFC 2246 ¯ Always requires provisioning AS certificate on the STA ® Mutual authentication requires provisioning STA certificates ® 59

Authentication Example –EAP-TLS (1) STA AP AP-RADIUS Key 802. 1 X/EAP-Request Identity 802. 1 X/EAP-Response Identity (My ID) RADIUS Access Request/EAPResponse Identity 802. 1 X/EAP-Request(TLS) RADIUS Access Challenge/EAP-Request 802. 1 X/EAP-Response(TLS Client. Hello(random 1)) AS RADIUS Access Request/EAPResponse TLS Client. Hello 802. 1 X/EAP-Request(TLS Server. Hello(random 2) || TLS Certificate. Request || TLS server_key_exchange || TLS server_done) RADIUS Access Challenge/EAP-Request 60

Authentication Example – EAP-TLS (2) STA AS AP AP-RADIUS Key Master. Key = TLS-PRF(Pre. Master. Key, “master secret” || random 1 || random 2) 802. 1 X/EAP-Response(TLS client_key_exchange || TLS certificate. Verify || TLS change_cipher_suite || TLS finished 802. 1 X/EAP-Request(TLS change_cipher_suite || TLS finished) 802. 1 X/EAP-Response RADIUS Access Request/EAPResponse RADIUS Access Challenge/EAP-Request RADIUS Access Request/EAPResponse Identity PMK = TLS-PRF(Master. Key, “client EAP encryption” || random 1 || random 2) 802. 1 X/EAP-Success RADIUS Accept/EAPSuccess, PMK 61

Authentication Summary ® At the end of authentication ¯ The AS and STA have established a session if concrete EAP method does ¯ The AS and STA possess a mutually authenticated Master Key if concrete EAP method does ® Master Key represents decision to grant access based on authentication ¯ STA and AS have derived PMK ® PMK is an authorization token to enforce access control decision ¯ AS has distributed PMK to an AP (hopefully, to the STA’s AP) 62

Security Capabilities Discovery Overview Security no good unless you can find networks with “right” characteristics ® AP advertises capabilities in Beacon, Probe Response ® ¯ SSID in Beacon, Probe provides hint for right authentication credentials ® Performance optimization only; no security value ¯ RSN Information Element advertises ® All enabled authentication suites ® All enabled unicast cipher suites ® Multicast cipher suite ® STA selects authentication suite and unicast cipher suite in Association Request 63

Security Capabilities Discovery Station Probe Request Access Point Probe Response + RSN IE (AP supports CCMP Mcast, CCMP Ucast, 802. 1 X Auth) 802. 11 Open System Auth 802. 11 Open Auth (success) Association Req + RSN IE (STA requests CCMP Mcast, CCMP Ucast, 802. 1 X Auth) Association Response (success) 64

Security Capabilities Discovery Summary ® At the end of discovery ¯ STA knows ® The alleged SSID of the network ® The alleged authentication and cipher suites of the network ® These allow STA to locate correct credentials, instead of trial use of credentials for every network ¯ The AP knows which of its authentication and cipher suites the STA allegedly chose ¯ A STA and an AP have established an 802. 11 channel ¯ The associated STA and AP are ready to authenticate 65

Other Features Other 802. 11 i Features Pre-authentication and roaming ® PEAP and legacy authentication support ® Pre-shared key without authentication ® Ad hoc networks ® Password-to-Key mapping ® Random number generation ® 66

Other Features Pre-authentication 1 1 2 AP 1 2 STA AS 2 3 AP 2 67

Other Features PEAP Overview Wireless Station AP Authentication Server Step 1: Use EAP-TLS to authenticate AS to Station Step 2: Use TLS key to protect the channel between Station, AS Step 3: Use Legacy method protected by TLS key to authenticate Station to AS 68

Other Features PEAP Man-in-Middle Attack STA Mit. M PEAP Server AP AAA-H Server EAP/Identity Request EAP/Identity Response (anonymous@realm) Tunnel establishment Tunnel Keys Derived EAP-Method in Tunnel EAP/Identity Request EAP/Identity Response (user id@realm) EAP/ Request / Method Challenge EAP/Response/ Method Response EAP/ Success Inner Method Keys Derived WLAN Session Stolen Inner EAP Method Keys Derived & Not used 69

Other Features Pre-shared Key Wireless Station PSK, used directly as a PMK AP 802. 11 security capabilities discovery Enhanced 802. 1 X key mgmt (no authentication) CCMP, WRAP, or TKIP 70

Other Features Ad hoc networks Configure a network-wide pre-shared key and SSID ® Each STA in ad hoc network initiates 4 -way handshake based on PSK when ® ¯ It receives following from a STA with whom it hasn’t established communication ¯ Beacons with same SSID ¯ Probe Requests with same SSID ® Each STA distributes its own Group Key to each of the other STAs in ad hoc network 71

Other Features Password-to-Key Mapping ® Uses PKCS #5 v 2. 0 PBKDF 2 to generate a 256 -bit PSK from an ASCII password ¯ PSK = PBKDF 2 (Password, ssidlength, 4096, 256) ¯ Salt ® = SSID, so PSK different for different SSIDs Motive: Home users might configure passwords, but will never configure keys ¯ Is something better than nothing? 72

Other Features Randomness Needed All systems implementing crypto need cryptographic quality pseudo-random numbers ® Therefore, 802. 11 supplies implementation guidelines for minimal quality generators ® Suggests two techniques: ® ¯ Software-based sampling ¯ Hardware-based sampling 73

802. 11 i Summary New 802. 11 i data protocols provide confidentiality, data origin authenticity, replay protection ® These protocols require fresh key on every session ® Key management delivers keys used as authorization tokens, proving channel access is authorized ® Architecture ties keys to authentication ® 74

Feedback? 75