Wireless LAN Security with 802.1x, EAP-TLS, and PEAP

Wireless LAN Securitywith802.1x, EAP-TLS, andPEAP

Steve RileySenior ConsultantMCS Trustworthy Computing Services

So what’s the problem?

WEP is a euphemismWiredEquivalentPrivacy

Actually, it’s a lieIt isn’t equivalent to “wired privacy” at all!How can you secure the air?

So: WEP suckshttp://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

Wired equivalent privacy

WEP setup and RC4

Secret key shared between access pointand all clients

Encrypts traffic before transmissionPerforms integrity check after transmission

WEP uses RC4, a stream cipher[key] XOR [plaintext] à [ciphertext]

Maybe double-XOR for “better” security? Hah!

[ciphertext] XOR [key] à [plaintext]

Common attacks

Bit-flipping (encryption ≠ integrity)Flipping bit n in cipertext flips same bit inplaintext

Statistical attacksMultiple ciphertexts using same key permitdetermination of plaintext XOREnables statistical attacks to recover plaintextMore ciphertexts eases thisOnce one plaintext is known, recovering othersis trivial

WEP’s “defenses”

Integrity check (IC) fieldCRC-32 checksum, part of encrypted payloadNot keyedSubject to bit-flipping à can modify IC to makealtered message appear valid

Initialization vector (IV) added to keyAlters key somewhat for each packet24-bit field; contained in plaintext portionAlas, this small keyspace guarantees reuse

More IV problems

Say an AP constantly sends 1500-bytepackets at 11mbps

Keyspace exhausted in 5 hoursCould be quicker if packets are smaller

Key reuse causes even more collisionsSome cards reset IV to 0 after initializationSome cards increment by 1 after each packet

802.11 standard does not mandate newper-packet IV!

Classes of attacks

Key and IV reuseSmall IV space; no IV replay protection

Known plaintext attackCan recover stream of length N for a given IVThen forge packets of length N in absence ofkeyed IC

Partial known plaintext attackCan recover M bytes of keystream, M < NRepeated probing à extend keystream to N

Weaknesses in RC4 key schedulingalgorithm

Large class of weak keys can break secret key

Classes of attacks

Authentication forgingWEP encrypts challenge using client-chosenIVRecovery of keystream for a given IV allowsreuse of the IV for forging WEP authenticationDoesn’t provide key, so can’t join LAN

Realtime decryptionIV reuse and probing à construct dictionary ofIVs and keystreamsEnables decryption in real timeStorage: 1500 bytes of keystream for each IV;

24 b GB

Tools

WEPCrack—breaks 802.11 keyshttp://wepcrack.sourceforge.net/

AirSnort—breaks 802.11 keysNeeds only 5-10 million packetshttp://airsnort.shmoo.com/

NetStumbler—access pointreconnaissance

http://www.netstumbler.com

WEP suckage

Same key reused over and over againPer-packet IV isn’t enough

Need to increase keyspace an attackermust analyze

Generate new keys (not just IVs) periodicallyUse unique per-client keys

These are our first requirements…

Other problems

Rogue access pointsMutual authentication—AP authenticates toclient

Disassociation attacksAssoc/disassoc messages are unencrypted andunauthenticatedFix with keyed message integrity check

Unauthorized use or monitoringIncorporate user and computer authentication

802.1x

Solution today: 802.1x

Port-based access control mechanismdefined by IEEE

Works on anything, wired and wirelessAccess point must support 802.1xNo special WIC requirements

Allows choice of authentication methodsusing EAP

Chosen by peers at authentication timeAccess point doesn’t care about EAP methods

Manages keys automagicallyNo need to preprogram WICs

Is 802.1x enough?

NoIt does solve:

Key discovery by changing keys often andusing different keys for each clientRogue APs and man-in-the-middle attacks byperforming mutual device authenticationUnauthorized access by authenticating usersand computers

It does not solve:Packet and disassociation spoofing because802.1x doesn’t use a keyed MIC

Clarifying terminology

802.11 is the specification for over-the-airwireless networks802.1x is a PHY-independent specificationfor port-based access controlCombining them makes senseThere is no such thing as 802.11x

But there is work on something called 802.11i

802.1x over 802.11Supplicant Authenticator

AuthenticationServer

802.11 association

EAPOL-start

EAP-request/identity

EAP-response/identity

RADIUS-access-request

EAP-request RADIUS-access-challenge

EAP-response(credentials)

RADIUS-access-request

EAP-success RADIUS-access-accept

EAPOW-key (WEP)

Access blocked

Access allowed

Association andauthentication

The 802.11 association happens firstNeed to talk to the AP and get an IP addressOpen authentication—we don’t have the WEPkey yet

Access beyond AP prohibited until authNsucceeds

AP drops non-EAPOL trafficAfter key is sent in EAPOW-key, accessbeyond AP is allowed

Security conversation between supplicantand authentication server

Wireless NIC and AP are passthrough devices

Before authenticationControlled port preventssupplicant LAN accessUncontrolled port allowsauthenticator to contactauthentication server

Directory

Supplicant

AuthNServer

Authenticatorthe Air

After authenticationControlled port nowpermits supplicant toaccess LAN

Directory

Supplicant

AuthNServer

Authenticatorthe Air

802.11/802.1x state machineState 1

802.11 unauthenticatedUnassociated

State 2802.11 authenticated

Unassociated


Associated


Associated802.1x authenticated

Successful open authN

Successful assoc orreassoc

Successful 802.1x authN

DeauthN notification

Disassoc notification

EAPOL-logoff

DeauthNnotification

Class 1 frames

Class 1, 2 frames

Class 1, 2, 3frames

Class 1, 2, 3frames

Encryption keys

Client and RADIUS server generate per-user session WEP keys

Never sent over the airRADIUS server sends key to AP (encryptedwith RADIUS shared secret)

Access point has a global WEP keyUsed during AP authentication to clientSent in EAPOW-key messageEncrypted with session key

Session keys regenerated when…Key time exceeded (60 minute default)Client roams to new AP

Extensibleauthentication protocol

EAP

Link-layer security frameworkSimple encapsulation protocol forauthentication mechanismsRuns over any link layer, lossy or lossless

No built-in securityDoesn’t assume physically secure linkAuthentication methods must incorporate theirown security

Authentication methods

EAP allows choice of authenticationmethodsFor mutual authentication—

TLS: authentication server supplies certificateIKE: server demonstrates possession ofpreshared key or private key (certificate)Kerberos: server demonstrates knowledge ofsession key

AuthN supported in Windows

EAP-MD5 disallowed for wirelessCan’t create encrypted session betweensupplicant and authenticatorWould transfer password hashes in the clearCannot perform mutual authentication

Vulnerable to man-in-the-middle attacks

EAP-TLS in Windows XP releaseRequires client certificatesBest to have machine and user

Service pack 1 adds protected EAP

Protected EAP (PEAP)

Extension to EAPAllows use of any secure authenticationmechanism for EAP

No need to write individual EAP-enabledmethods

Windows PEAP allows:MS-CHAPv2—passwordsTLS—certificatesSecurID

For many deployments, passwords still(alas) are necessary

EAP architecture

TLS GSS_APIKerberos

PEAP IKE MD5

EAP

PPP 802.3 802.5 802.11 Anything…

methodlayer

EAPlayer

medialayer

MS

-CH

AP

v2

TL

S

Secu

rID

Note

Do not configure IAS and XP for both—EAP-TLS alonePEAP with any method

Man-in-the-middle vulnerabilityIf you need TLS and MS-CHAPv2together—

Deploy only PEAPSelect both MS-CHAPv2 and TLS methods

How it works:The Windows logonprocess over PEAP withMS-CHAPv2

Security requirements, again

Mutual device authenticationWorkstation and APNo rogue access pointsPrevents man-in-the-middle attacksEnsures key is transferred to correct entity

User authenticationNo unauthorized access or interception

WEP key uniqueness and regenerationStop packet/disassociation spoofing

Windows domain logon

Two logons occurMachineUser

Machine accounts look like user accountsCertificate credentialUser ID/password/domain credentialTake advantage of this

Windows PEAPauthentication

First phase—machine logon802.11 associationAuthenticate APAuthenticate computerTransition controlled port status

For machine account access to authorizedresources

Second phase—user logonAuthenticate userTransition controlled port status

For user account access to authorized resources

Windows PEAP authentication

First phase1. Supplicant performs regular 802.11

association2. Supplicant sets up TLS channel with

authenticator and requests authenticationserver’s certificate

3. Supplicant—Verifies name and dates on certificateValidates chain

Our requirements so far

Mutual device authenticationWorkstation and APNo rogue access points


WEP key uniqueness and regenerationPacket/disassociation spoofing


First phase4. Supplicant sends machine credentials to

authenticator over previously-establishedTLS channel

5. Authenticator checks validity bycontacting authentication server(RADIUS)

6. Authentication server contacts directory toverify credentials


First phase7. If valid, RADIUS generates WEP key8. Authenticator delivers key to supplicant

and transitions controlled port status topermit supplicant access to LAN (toresources allowed access throughmachine account only)

9. Computer logs on to domain






Second phase1. Logon dialog appears2. Supplicant sends user credentials to

authenticator3. Authenticator checks validity by

contacting authentication server(RADIUS)

4. Authentication server contacts directory5. If valid, authenticator extends controlled

port status to permit supplicant full accessto LAN

6. User logged on to domain





Why use machine accounts?

Domain logon required for:Machine group policiesComputer startup scriptsSoftware installation settings

When user account passwords expireNeed associated WIC and transitionedcontrolled port for user notification and changedialog

Machine account logon phase allows passwordexpiration notices and changes to occur normally

Cisco’s LEAP can’t deal with thisNo facility for machine authentication

Why passwords?

Not all customers are ready for a PKIManaging user certificates stored oncomputer hard drives will always be painful

Some personnel might roam amongcomputersSmartcards solve this

Technical and sociological issues can delay orprevent deployment

PEAP enables (pretty) secure wirelessnow

Allows easy migration to certificates andsmartcards later

Remaining vulnerabilities

Remaining vulnerabilities

Two related vulnerabilities not addressedwith 802.1x

Bit flipping with known IVs à packet spoofingDisassociation denials of service

Simple addition to 802.1x will solve both

Bit-flipping attacks

WEP doesn’t perform per-packetauthentication

IC is not a keyed message integrity checkFlipped bits in WEP packet à recalculated IC

To spoof or replay:Flip bits in WEP packet where IV is knownAP accepts packetLayer 3 device rejects, sends predictableresponseBuild response database and derive key

Disassociation attacks

802.11 associate/disassociate messagesare unauthenticated and unencryptedAttacker can forge disassociation message

Bothersome denials of service

Solution: keyed IC

Change behavior of WEP’s ICDerive key from seed value, source anddestination MACs, payload

Any change to these will alter the IC

Include in every WEP packet

Deployment

System requirements

Client: Windows XP service pack 1Server: Windows Server 2003 IAS

Internet Authentication Service—our RADIUSserverCertificate on IAS computer

Backporting to Windows 2000Client and IAS must have SP3No zero-config support in the clientSee KB article 313664Supports only TLS and MS-CHAPv2

Future EAP methods in XP and 2003 might not bebackported

Setup

1. Build Windows Server 2003 IAS server2. Join to domain3. Enroll computer certificate4. Register IAS in Active Directory5. Configure RADIUS logging6. Add AP as RADIUS client7. Configure AP for RADIUS and 802.1x8. Create wireless client access policy9. Configure clients

Don’t forget to import CA root

Access policy

Policy conditionNAS-port-type = Wireless IEEE 802.11 andWireless otherWindows-group = <some group in AD>

Optional; allows administrative controlShould contain user and computer accounts

ProfileNo regular authentication methodsEAP type: protected EAP; use certificate fromstep 3Encryption: only strongest (MPPE 128-bit)Attributes: Ignore-user-dialin-properties =True

What else?

Interoperability

PEAP standards authorsMicrosoftCiscoRSA

Our implementation is version 0Not compatible with version 1

Working towards interoperabilityPEAP allows servers and clients to supportmultiple versions

802.1x alternative

WPA (Wi-Fi protected access)Includes TKIP (temporal key integrityprotection)

Uses RC4, rotates keys every 10,000 packetsCombines shared 128-bit key with client MACand 128-bit IVProvides key uniqueness

WPA relies on 802.1x for user and mutualdevice authenticationIn beta now for Windows XP

The future—long term

IEEE is working on 802.11iReplacement for WEPIncludes TKIP, 802.1x, and keyed ICUses AESAddresses all currently known vulnerabilitiesand poor implementation decisions

Need to be IEEE member to read work inprogressExpected ratification in September 2003

References

Security of the WEP Algorithmhttp://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

802.1x--Port Based Network AccessControl

http://www.ieee802.org/1/pages/802.1x.html

PPP Extensible Authentication Protocolhttp://www.ietf.org/rfc/rfc2284.txt

PPP EAP-TLS Authentication Protocolhttp://www.ietf.org/rfc/rfc2176.txt

Protected EAP Protocolftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-

© 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Documents

Wireless LAN Security with 802.1x, EAP-TLS, and PEAP