doc: ieee802.11-01/465r0 submission july 2001 carlos rios, lincom wirelessslide 1 a proposal to ieee...

Carlos Rios, LinCom Wireless

Slide 1

doc: IEEE802.11-01/465r0

Submission

July 2001

A Proposal to IEEE 802.11i:

Optional MAC-LevelAuthentication and Encryption Key

Management

Carlos RiosLinCom Wireless


Slide 2

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 3

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 4

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 5

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 6

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 7

doc: IEEE802.11-01/465r0

Submission

July 2001

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)


Slide 8

doc: IEEE802.11-01/465r0

Submission

July 2001

DHAKM RegistrationSTAc Data Exchange AP/PSTAa

Initial Conditions:Secret Key c; MAC Address MAc

Initial Conditions:Secret Key a; MAC Address MAa

Operator initiates STAc REE STAc indicator alerts Operator that Registration is in process MAa

Operator initiates AP/PSTAa REE. AP/PSTAa indicator alerts Operator that Registration is in process.AP/PSTAa transmits Beacon

STAc senses Beacon,Generates Random Numbers Y, PCalculates PK C= Ycmod(P)Sends C, P, Y to AP/PSTAa

MAc,Y, P, C Calculates PK A= Yamod(P)Selects Signature Vector H={Hm, Hn, Ho} not used before to Register other STAs

Calcs CKc= Ac= Yacmod(P)Calculates H[CKc]= {Hm[CKc], Hn[CKc], Ho[CKc]}

A, Hm, Hn, Ho, Hm[CKa]

Calcs CKa= Ca= Yacmod(P)Calculates H[CKa] = {Hm[CKa], Hn[CKa], Ho[CKa]}Sends A, H, Hm[CKa]

Compares Hm[CKa], Hm[CKc], if they match CKa=CKc, so STAc knows that sender of A has to be AP/PSTAaSends back Hn[CKc]

Hn[CKc]

Compares Hn[CKc], Hn[CKa], if they match AP/PSTAa knows sender of CKc has to be STAc Adds MAc, C, P, Y to ACL

Compares Ho[CKa], Ho[CKc], if match knows AP/PSTAa OKd registrationStores MAa, A, P, Y Calculates Seed Hc1 from CKc Exits, alerts Operator of Registration

Ho[CKa], OK

Sends Ho[CKa], Registration OK,Calcs Seed Ha1(=Hc1) from CKaExits, alerts Operator of Registration


Slide 9

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 10

doc: IEEE802.11-01/465r0

Submission

July 2001

DHAKM Key GenerationSTAc Data Exchange AP/PSTAa

Initial Conditions:SK c, MAC Address MAc, Knows MAa, A, P, Y, Hc1(=Ha1)

Initial Conditions:SK a, MAC Address MAa, ACL contains MAc, C, Y, P, Ha1(=Hc1)

User turns on STAc to begin a session. STAc scans for Beacons

MAa AP/PSTAa transmits Beacons

Senses BeaconSends Auth Req to AP/PSTAa Recognizes MAa and recovers A, P, YRecalculates CKc= Yacmod(P)Calculates H={Hj, Hk, Hl} from seed Hc1

MAc,

Finds MAc in ACL, but can’t know if really from STAc. Recovers C, Y, PRecalculates CKa= Ycamod(P)Calculates H={Hj, Hk, Hl} from seed Ha1

Calculates H[CKc]= {Hj[CKc], Hk[CKc], Hl[CKc]}Compares Hj[CKc], Hj[CKa]. If match, STAc knows that sender of Hj[CKa] knows a, has to be AP/PSTAa

Hj[CKa]

Calculates H[CKa] = {Hj[CKa], Hk[CKa], Hl[CKa]}Sends back Hj[CKa]

Generates random numbers Ys, PsCalcs Session Key term Cs=(Ys)cmod(Ps)Sends Hk[CKc], Ys, Ps, Cs

Hk[CKc], Ys,

Ps, Cs

Compares Hk[CKc] and Hk[CKa], if they match then AP/PSTAa knows that sender of Hk[CKc] has to be STAc.Calcs Session Key term As=(Ys)amod(Ps)

Compares Hl[CKc], Hl[CKa]. If match, knows that AP/PSTAa sent AsCalc Session Key SK=(As)cmod(Ps) =(Ys)acmod(Ps)Recalculates Hc2=Hc1+1= Ha2

Hl[CKa], As

Sends back Hl[CKa], As Calcs Session Key K=(Cs)amod(Ps) =(Ys)camod(Ps)Recalculates Ha2= Ha1+1= Hc2


Slide 11

doc: IEEE802.11-01/465r0

Submission

July 2001

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


Slide 12

doc: IEEE802.11-01/465r0

Submission

July 2001

DHAKM Key RegenerationSTAc Data Exchange AP/PSTAa

Initial Conditions:SK c, MA MAc, Knows MAa, A, P, Y, Hcm(=Ham)

Initial Conditions:SK a, MA MAa, ACL contains MAc, C, Y, P, Ham(=Hcm)

Session in progress, STAc determines need to expire and regenerate the encryption key shared with AP/PSTAa.

MAa AP/PSTAa sends traffic encrypted with current Session KeyAP/PSTAa transmits Beacon

Senses BeaconSends Auth Req to AP/PSTAa Recognizes MAa and recovers A, P, YRecalculates CK CKc= Yacmod(P)Calculates H={Hj, Hk, Hl} from seed Hcm

MAc,

Finds MAc in ACL, but can’t know if really from STAc. Recovers C, Y, PRecalculates CK CKa= Ycamod(P)Calculates H={Hj, Hk, Hl} from seed Ham

Calculates H[CKc]= {Hj[CKc], Hk[CKc], Hl[CKc]}Compares Hj[CKc], Hj[CKa]. If match, STAc knows AP/PSTAa sent Hj[CKa]

Hj[CKa]

Calculates H[CKa] = {Hj[CKa], Hk[CKa], Hl[CKa]}Sends back Hj[CKa]

Generates random numbers Ys, PsCalcs Session Key term Cs=(Ys)cmod(Ps)Sends Hk[CKc], Ys, Ps, Cs

Hk[CKc], Ys,

Ps, Cs

Compares Hk[CKc] and Hk[CKa], if match knows STAc sent Hk[CKc]Calcs Session Key term As=(Ys)amod(Ps)

Compares Hl[CKc], Hl[CKa]. If match, knows that AP/PSTAa sent AsCalcs Session Key SK=(As)cmod(Ps) =(Ys)acmod(Ps)Recalculates Hcn=Hcm+1= Ham

Hl[CKa], As

Sends back Hl[CKa], As Calcs Session Key K=(Cs)amod(Ps) =(Ys)camod(Ps)Recalculates Han= Ham+1= Hcn


Slide 13

doc: IEEE802.11-01/465r0

Submission

July 2001

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

doc: ieee802.11-01/465r0 submission july 2001 carlos rios, lincom wirelessslide 1 a proposal to ieee...

Documents