Post on 30-Dec-2015
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 1
doc.: IEEE 802.11-00/573a
Submission
Authenticated Key Exchange
Nancy Cam-Winget, Atheros
Greg Chesson, Atheros
Russ Housley, RSA Labs
Jesse Walker, Intel
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 2
doc.: IEEE 802.11-00/573a
Submission
Agenda
• Motivation, Constraints, and Requirements
• Protocol Definition
• Protocol Analysis
• Summary and Next Steps
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 3
doc.: IEEE 802.11-00/573a
Submission
Why?This work was motivated by 4 problems:
• Session Management
• Race Conditions
• Roaming and key hand-off
• WEP “rapid rekeying”
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 4
doc.: IEEE 802.11-00/573a
Submission
Problem 1: Session Management (1)• 802.11 security model doesn’t include the notion
of a secure session– 802.11 security either is on (there is a configured key)
or off– Nothing similar to station authentication, association
services
• Proper cipher suite operation requires not only synchronized key, but also synchronized sequence spaces and replay windows
• TGi security will not “work” until this is fixed!– A broken TGi draft cannot pass sponsor ballot!
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 5
doc.: IEEE 802.11-00/573a
Submission
Problem 1: Session Management (2)
• TGi Draft 1 attempts to rectify the lack of a security session implicitly– Glues security onto the association service
• This attempt is unsatisfactory– Political: What to do in an IBSS? Reality is many
implementations do not support associations in IBSS!– Usability: Reassociation too heavy-weight just to
update keys and sequence numbers, because reassociation interrupts the data flow.
– Technical: association service manages link characteristics, not security characteristics
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 6
doc.: IEEE 802.11-00/573a
Submission
Problem 1: Session Management (3)
Potential Solutions:• Continue with draft 1 model
– requires (Re)association in an IBSS. Straw poll of membership indicates substantial up-hill battle questionable whether we can get this past letter ballot
– Doesn’t address usability problem of poor performance
• Build a new session management mechanism independent of association– Must work in an IBSS, i.e., without association– Must support frequent state resynchronization where
policy dictates without degrading performance
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 7
doc.: IEEE 802.11-00/573a
Submission
Problem 2: Race Conditions (1)
• TGi Security uses 802.1X for master key establishment
• 802.1X traffic appears as 802.11 data– in-band communication
• Standard problem with in-band key distribution schemes: sender of last message cannot know with certainty whether it was delivered correctly and consumed
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 8
doc.: IEEE 802.11-00/573a
Submission
Problem 2: Race Conditions (2)
Access Point
Wireless Station
Last Key Distribution Message
After key established, both STA and AP must enforce key usage: in the clear data must be discarded as spoof
Dilemma for last message sender of in-band key distribution: enforce key usage? Or allow retransmissions?
Sender can’t resolve dilemma if its peer doesn’t guarantee to use distributed key!
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 9
doc.: IEEE 802.11-00/573a
Submission
Problem 2: Race Conditions (3)
Potential solutions to the race conditions:• Ignore them
– Requires the STA to reinitialize whenever this occurs– Inexcusable in a standard
• Expose 802.11 internals to 802.1X– Requires reopening 802.1X specification, and inserting
802.11 specific knowledge into them– Increase inter-dependence of 802.11 and 802.1X– Inadvisable in a standard
• Develop new out-of-band key synchronization
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 10
doc.: IEEE 802.11-00/573a
Submission
Problem 3: Roaming and Key Handoff (1)
• TGi wants to use 802.1X for authentication• Secure authentication in the 802.11 environment
very expensive– Must be public key based: EAP-TLS, EAP-SRP
• This requires too much overhead to do a full authentication on a roam
• Consensus is leaning toward a solution of replacing full authentication with some sort of TGi/TGf key hand-off mechanism
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 11
doc.: IEEE 802.11-00/573a
Submission
Problem 3: Roaming and Key Handoff (2)
Old Access Point
Legitimate Wireless Station
New Access Point
Reassociate
1.
2. Legitimate Station’s WEP key
3. Delete key from old AP
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 12
doc.: IEEE 802.11-00/573a
Submission
Problem 3: Roaming and Key Handoff (3)
Old Access Point
Legitimate Station
New Access Point
Associate
1.
Rogue Station
Reassociate
2.
3. Legitimate Station’s WEP key
4. Delete key from old AP
Problem Summary: new AP doesn’t know STA is authentic
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 13
doc.: IEEE 802.11-00/573a
Submission
Problem 3: Roaming and Key Handoff (4)
Old Access Point
Legitimate Station
Associate
1.
Rogue Access Point
Reassociate
2. 3. Data flow protected by old key, IV space
Problem Summary: STA doesn’t know new AP is live and authentic
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 14
doc.: IEEE 802.11-00/573a
Submission
Problem 3: Roaming and Key Handoff (5)
• Key hand-off requires a mutual reauthentication• But reauthentication must be light-weight• Authenticated exchange is required at MAC,
because we can’t assume 802.1X (think of static keys, proprietary authentication protocols, etc.)
• Potential Solutions:– Ignore the problem– Hand it to 802.1X or TGf for solution– Introduce a light-weight (symmetric key) mutual
authentication mechanism at the MAC
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 15
doc.: IEEE 802.11-00/573a
Submission
Problem 4: WEP Rapid Rekeying
• WEP IV space too small– Small IV space enables IV reuse attacks
– Rekey mechanism required to avoid these
• Fluhrer-Mantin-Shamir type attacks– Relies on observing enough packets to derive key
• Can’t rekeying more rapidly help?– Not as much as people would like, but some sort of
rekeying is needed for any solution
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 16
doc.: IEEE 802.11-00/573a
Submission
Motivation Summary
• Most urgent justification for MAC rekey protocol is security session management
• Correctness says we need a MAC-level handshake to avoid race conditions when using 802.1X
• Compelling long term justification for MAC level rekey also includes providing support for roaming
• Short-term WEP rapid rekey the least compelling reason to develop a MAC-level rekey protocol—and it is important enough by itself to seek a solution
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 17
doc.: IEEE 802.11-00/573a
Submission
Requirements (1)
• Protocol must address the motivations– Synchronize and manage cryptographic state– Simplify interface with 802.1X to avoid race condition– Support roaming and key handoff– Provide rapid rekey
• Protocol must work within existing security design– Security architecture must work with WEP keying
scheme (KeyIDs, key-mapping keys, default keys)– Must work in both BSS and IBSS
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 18
doc.: IEEE 802.11-00/573a
Submission
Requirements (2)
• Protocol exchanges must be secure– Must assure liveness: no replayed sessions
• Prevent rogue AP or STA from replaying earlier sessions that would reuse cryptographic state
– Protocol messages must be authentic
• Protocol must minimize packet loss• Must not change WEP, but must not preclude
changes, either• Cipher suite independence: must work with WEP
enhancements and with long term AES solution
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 19
doc.: IEEE 802.11-00/573a
Submission
Constraints• Existing WEP design
– Key namespace limitations– Key-mapping and Default keys
• Minimizing packet loss (synchronizing distributed state)
• Rekey Security
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 20
doc.: IEEE 802.11-00/573a
Submission
Constraint 1: Key Namespace Limitations
• 802.11 WEP keys are identified by the two WEP KeyID bits
• Each WEP KeyID identifies a full-duplex key
• To be backward compatible, key identified by a single KeyID must be switched simultaneously at peers
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 21
doc.: IEEE 802.11-00/573a
Submission
Half-Duplex Key Rollover (Not WEP)
A B
Data exchange, protected by old KeyID key
Decide to replace old key with new key; halt traffic
On confirmation, replace old key with new key; re-enable traffic
Communicate intent
Acknowledge intent
replace old key with new key
Data exchange, protected by new KeyID key
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 22
doc.: IEEE 802.11-00/573a
Submission
Observations on Full-Duplex Rekey Algorithms
• Full-duplex rekey can be constructed from two half-duplex rekey exchanges 4 message total!
• If same key identifier used for each half-duplex flow, the two exchanges have to be coordinated.
• The 4 message handshake can be reduced to 3 messages with proper coordination, but not 2 messages.
Expect a 3 message transition from old key to new key
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 23
doc.: IEEE 802.11-00/573a
Submission
Constraint 2: Key-mapping Keys and Default Keys
• Terminology– Key-mapping keys the 802.11 name for per-link keys– Default keys the 802.11 name for group keys
• Must support both types• All members of a group must switch group key
simultaneously some sort of broadcast or timer-based scheme must be used for key roll-over– But doesn’t scale well to per-link keys
• Key roll-over requires explicit key naming explicit message exchange required to roll-over of per-link keys– But doesn’t scale well to group keys
Expect different techniques for key-map and default keys
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 24
doc.: IEEE 802.11-00/573a
Submission
Constraint 3: Synchronize Distributed State (1)
• Problem: How to reliably synchronize WEP KeyID roll-over from old key to new?– Solution must be reliable, because
communication fails absolutely if cryptographic state become unsynchronized
• Solution: solved by theory of database concurrency control long ago: atomic commit, 2-phase commit, 3-phase commit, etc.
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 25
doc.: IEEE 802.11-00/573a
Submission
Constraint 3: Synchronize Distributed State (2)
• Atomic Commit Properties– 1 message exchange, but– A single failure blocks every participant
• 2-phase commit properties– 2 message exchanges– First exchange tells what change to make– Second exchange makes change permanent– Separation of change and commit allows for more
robust failure recovery options if one party can’t execute entire protocol
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 26
doc.: IEEE 802.11-00/573a
Submission
Constraint 3: Application to WEP KeyIDs
• Atomic Commit– No way to coordinate allocation, release of transitional
KeyID
– Only recovery vehicle is to restart entire link
• 2-phase Commit– Phase 1 failure delays rekey, doesn’t destroy channel
– Phase 1 success allows Phase 2 by reserving transitional KeyID
– Phase 2 failure destroys channel, but is less likely because resources (KeyIDs) allocated by Phase 1
Expect a 2-phase commit from old key to new key
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 27
doc.: IEEE 802.11-00/573a
Submission
Constraint 4: Secure Session Establishment
• Protocol must guarantee– Live peers– Fresh uniformly distributed keys– Freedom from message modification, replay
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 28
doc.: IEEE 802.11-00/573a
Submission
Constraint 4: Protocols to Ensure Liveness
A B A B A B
A securely learns B’s notion of time T
IDA,IDB,R,T, MIC(IDA,IDB,R,T)
IDA,IDB,R, MIC(IDA,IDB,R)
Nice paradigm—only 2 messages—but how to securely distribute B’s notion of time?
IDA,RA
IDB,IDA RA,RB,MIC(IDB,IDA,RA,RB)
IDB,RB , MIC(IDB,RB)
Lacks flexibility: A and B must know which role to play; only A can initiate; how does B signal it needs to restart?
IDA,IDB,RA
IDB,IdA,RA,RB,MIC(IDB,IDA,RA,RB)
IDB,IDA RB
IDA,IDB,RB,RA, MIC(IDA,IDB,RB,RA)
Most expensive but only solution with sufficient flexibility
Expect initialization based on 2 2-way handshakes
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 29
doc.: IEEE 802.11-00/573a
Submission
Constraint 4: Fresh Uniformly Distributed Keys
• Encryption key refresh – Add entropy to master key
– Guards from exhaustion of replay protection sequence
– Resynchronize cryptographic state on roam
• Rekey of master keys– Encryption Key entropy is also finite
– Rekey of master keys can be achieved via reauthentication (802.1X)
Expect key hierarchy based on key derivation
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 30
doc.: IEEE 802.11-00/573a
Submission
Constraint 4: Freedom from Forgery, Replay
• Protocol messages– Must have MIC– Must convey session-specific data established
at session start-up– Must have sequence number
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 31
doc.: IEEE 802.11-00/573a
Submission
Constraint Summary
• WEP key naming architecture forces at least a 3 message handshake to effect key roll-over using a message-based approach
• Rekey for default and key-map keys will differ• 2-phase commit architecture leads to more robust
behavior than an atomic commit architecture• A secure protocol that allows any party to initiate
rekey favors two 2-way handshakes over its alternatives
• Key hierarchy will maximize master key mileage
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 32
doc.: IEEE 802.11-00/573a
Submission
Agenda
• Motivation, Constraints, and Requirements
• Protocol Definition
• Protocol Analysis
• Summary and Next Steps
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 33
doc.: IEEE 802.11-00/573a
Submission
Proposed Security Service
• Fundamental data structure is security association– Security association = secure session
• New rekey protocol to construct and manage security associations
• 802.11 cipher suites applied only within security associations
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 34
doc.: IEEE 802.11-00/573a
Submission
Security as a STA ServiceState 1:
Unauthenticated,Unassociated,
State 2:Authenticated,Unassociated,
State 3:Authenticated,
Associated,
State 4:Unauthenticated,
Associated,
DeauthenticationNotification
DisassociationNotification
SuccessfulAuthentication
DeauthenticationNotification
ULAP Authentication
State 5:ULA authenticated,
Associated,
Invalid Secure Session
Invalid Secure Session
Invalid Secure Session
Invalid Secure Session
Invalid Secure Session
Authenticated KeyExchange
Authenticated KeyExchange
State 6: Authenticated,
Associated, Secure
DisassociationNotification
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 35
doc.: IEEE 802.11-00/573a
Submission
Service Operation
• Once established, Security Association enforces cipher suite usage– Protection based on temporal keys– All plaintext packets and packets with unknown keyids
discarded
• Security Association forces rekey when– Packet sequence space crosses a low-water mark for a key-
mapping key– Rekey timer expires for a default key
• Security Association establishment, rekey based on Rekey Messages
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 36
doc.: IEEE 802.11-00/573a
Submission
Keys
• Proposed key hierarchy defined as:– Master Key: acquired from ULA– Base Key: derived from Master Key– Temporal Key: derived from Base Key
• Rationale for key hierarchy– Allows precomputation of temporal keys
without compromising security– Guards against master key collisions
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 37
doc.: IEEE 802.11-00/573a
Submission
Key Hierarchy
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 38
doc.: IEEE 802.11-00/573a
Submission
Deriving Keys
• Master Key is 256 bits– 1st 128 bits to be used to derive base encryption key (MEK)– 2nd 128 bits used as authentication key (MAK)
• Base Key in message-based case:– Key-mapping Key Base Key ::= AES-CBC-MACMEK (MAC1 ||
MAC2 || Nonce1 || Nonce2 || Cipher-Suite)– Default Key Base Key ::= AES-CBC-MACMEK (
BSSID || Beacon-Nonce || Cipher-Suite)
• Temporal Key: Cipher-suite specific– Basic idea is to use counter mode AES to generate as much keying
material as required
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 39
doc.: IEEE 802.11-00/573a
Submission
Rekey messages
DurationFrameContro
l
FrameContro
l
SADAFrameContro
l
BSSIDFrameContro
l
SeqContro
l
FCSRekey
Info ElementBeacon Body
Action MgmtFrame
BeaconFrame
Key SeqNumber
KeyIDRekeyCount
MICCipher Suite
NonceRekeyPeriod
Version Number
DurationFrameContro
l
FrameContro
l
SADA BSSIDFrameContro
l
SeqContro
l
FCSRekey
Info ElementAction frame header
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 40
doc.: IEEE 802.11-00/573a
Submission
Rekey Information Element
All messages include the common Rekey Information ElementNonce: 16-byte message initiator’s nonceCipher Suite: Selected algorithms for privacy and integrity protocolVersion Number: this protocol’s version identifierKey Seq Number: Index to temporal key, also temporal key identifierKeyID: Index (0, 1, 2, or 3) into transitional key bufferRekey Count: Number of beacons before next key refreshRekey Period: Number of beacon intervals between key refreshesMIC: 1st 64 bits of AES-CBC-MACauth-key(DA || SA || BSSID
|| Nonce || Cipher suite || Version Number || Key Seq # || KeyID || Rekey Count || Rekey Period)
Key SeqNumber
KeyIDRekeyCount
MICCipher Suite
NonceRekeyPeriod
Version Number
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 41
doc.: IEEE 802.11-00/573a
Submission
Establishing a Security Association
PeerAPeerB
Security Association Request
Security Association
Request
Security Association
Response
• Each peer initiates its own Security Association sequences to ensure liveness• Provides mutual authentication to securely establish security association• Security association identified by matching nonces
Security Association Response
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 42
doc.: IEEE 802.11-00/573a
Submission
Terminating a Security Association
• 802.11 Deauthentication
• Dissassociation
• Association
• Reassociation
• Rekey failure
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 43
doc.: IEEE 802.11-00/573a
Submission
Rekey Architecture
2-phase commit protocol1. Enable exchange
• Deadline for deriving new temporal key Ki
• Reserves transitional key id to identify new key
2. Transition exchange • Fully enables new temporal key Ki • Obsoletes old temporal key Ki-1
• Releases transitional key id
Timers or messages can trigger exchanges
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 44
doc.: IEEE 802.11-00/573a
Submission
Rekey Concept
EnableExchange
New keyKi use keyIDx Ki
Obsolete Ki-1
Queue flushedkeyIDx Ki
keyIDTA/DA Ki keyIDx not used
Enable Request
Enable Response
Transition Request
Transition Response
Obsolete Ki-1
Queue flushedkeyIDTA/DA Ki
keyIDTA/DA Ki keyIDx not used
New keyKi use keyIDx Ki
Transition Confirm
TransitionExchange
New keyKi use keyIDx Ki
Obsolete Ki-1
Queue flushedkeyIDx Ki
keyIDy Ki keyIDx not used
Rekey Interval
Not Applicable
Rekey Beacon
Obsolete Ki-1
Queue flushedkeyIDy Ki
keyIDy Ki keyIDx not used
New keyKi use keyIDx Ki
Not Applicable
Not Applicable
Key-mapping Keys Default Keys
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 45
doc.: IEEE 802.11-00/573a
Submission
Key-Mapping Keys EnableNew keyKi ready to
Prepare to use keyIDx Ki
Enable Response: Acknowledges request, proves liveness and synchronization Ki
Both peers ready to start sending and receiving with new keyIDx
• Enable exchange triggers the rekey• Reserves transitional KeyID to identify new key• Either STA or AP can initiate the exchange
Optimization: STA can initiate by sending Enable Response• Session nonce, key sequence value, MIC prove liveness
Enable Request : keyIDx Ki
New keyKi ready to recieve using keyIDx Ki
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 46
doc.: IEEE 802.11-00/573a
Submission
Key-Mapping Keys Transition
No more packets using old key, flush queueKeyTA/DA Ki ready to send using KeyTA/DA
Ready to send and receive with KeyTA/DA Ki
Transition Request: Trigger to obsolete old KeyTA/DA
• AP initiates Transition Request to control reserved KeyID usage• AP sends Request when old key packets have been flushed
Transition Request, Response are promises never to send with old key• Session nonce, key sequence value, MIC prove liveness• Optimization: Transition Confirm not needed if STA never sent using transitional KeyID
Transition Response: Acknowledges request, proves liveness and KeyTA/DA Ki
keyIDTA/RA Ki
keyIDx not used
keyIDTA/DA Ki
keyIDx not used
Transition Confirm: Release use of keyIDx, proves liveness and KeyTA/DA Ki
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 47
doc.: IEEE 802.11-00/573a
Submission
Default Keys EnableNew keyKi ready to send using keyIDx Ki
Not Applicable: no response sent
Both peers ready to start sending and receiving with new keyIDx
• No messages used; timer based on TSFT triggers enable (refreshed with every beacon)• Rekey Beacon provides information to synchronize key and next interval• Requires adding MIC, nonce to the Beacon
New keyKi ready to receive using keyIDx Ki
New key must be derived betweenRekey Beacon intervals
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 48
doc.: IEEE 802.11-00/573a
Submission
Default Keys Transition
No more packets using old key, KeyIDy Ki ready to send using KeyIDy
Rekey Beacon frame triggers to use new key, Ki in keyIDx
Ready to send and receive with Keyy Ki
Not Applicable: no response sentBoth peers now using Ki
• Switch keys at Rekey Beacon interval timeout – this timeout is the “handshake”• New key identified by next KeyID before next Rekey Beacon
Ping-pong between two KeyIDs Since no messages, keys cannot be explicitly obsoleted, so KeyIDs have to be reserved for duration of security association
• Per-packet MIC required to make the scheme to be secure
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 49
doc.: IEEE 802.11-00/573a
Submission
Agenda
• Motivation, Constraints, and Requirements
• Protocol Definition
• Protocol Analysis
• Summary and Next Steps
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 50
doc.: IEEE 802.11-00/573a
Submission
Protocol Analysis
• Security Properties
• Performance Characteristics
• Breaking the Race Condition
• Potential Roaming Support
• Implementation Considerations
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 51
doc.: IEEE 802.11-00/573a
Submission
Security Properties: Protocol Ensures Liveness
A B
• Each party randomly selects nonce
• Its peer must MIC the nonce peer is alive
• Nonces in each pair of handshakes must match common notion of a live session
• IDs (MAC addresses) tie the exchange to these two peers
• Note: MIC must include Beacon Nonce in default key case
IDA,IDB,RA
IDb,Ida,RA,RB, MIC(IDb,IDa,RA,RB)
IDb,IDa RB,
IDA,IDB,RB,RA, MIC(IDA,IDB,RB,RA)
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 52
doc.: IEEE 802.11-00/573a
Submission
Security Properties: Chain of Trust
• We trust Master Key because it comes from ULA• We trust Base Key, because authenticated Security
Association exchange shows it is derived from (fresh) Master Key
• We trust Temporal Key, because it is derived from fresh Base key by authenticated Enable/Transition exchange
• We trust data packets, because its keys derived from trusted Temporal Key– This assumes a per-packet MIC and replay protection
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 53
doc.: IEEE 802.11-00/573a
Submission
Key Refresh Performance
Key-mapping Key• Requires 3 to 5 messages• Adjusts to packet rate• Number of rekeys governed
by the channel bandwidth, not number of STAs
• Allows graceful key transitions while minimizing queue flushing
Default Key• Rekey information
element must be present in every beacon
• Requires one rekey element per default key
• Must rekey at absolute maximum packet rate, or data halts when sequence space is exhausted
• No transition period
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 54
doc.: IEEE 802.11-00/573a
Submission
Rekey Frequency (TCP)
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 55
doc.: IEEE 802.11-00/573a
Submission
Rekey Frequency (UDP)
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 56
doc.: IEEE 802.11-00/573a
Submission
Performance Analysis
• Message-based rekeys on average packet rate– 11Mbps / 500b/pkt 1900 pkts/sec– @65536 pkts 34 sec– 3 to 5 msgs every 34 sec
• Countdown-scheme must rekey on absolute max packet rate– 11Mpbs / 48b/pkt 5200 pkts/sec– @65536 pkts 12.5 sec– @ n beacons/sec and 1 rekey element per key in beacon
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 57
doc.: IEEE 802.11-00/573a
Submission
Countdown vs Message-based message ratio per rekey interval
0
50
100
150
200
250
300
350
2 5 6 11 24 36 54
Mbit data rate
Cou
ntdo
wn
msg
s vs
. Mes
sage
-ba
sed
msg
s ra
tio
Using a 65536 packet rekey frequency for Message-based scheme
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 58
doc.: IEEE 802.11-00/573a
Submission
Rekey Rate vs. Bandwidth
0
20
40
60
80
100
120
140
160
2 5 6 11 24 36 54
Mbit data rate
Seco
nds
betw
een
reke
ys
CountdownMessage
Using a 65536 packet rekey frequency for Message-based scheme
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 59
doc.: IEEE 802.11-00/573a
Submission
Breaking the Race Condition
• Security Association exchange cannot complete unless 802.1X succeeds at distributing master key to both parties
• Security Association exchange does not block 802.1X retries
• Rekey protocol exchanges do not suffer from same race conditions because they use a separate channel– Management messages instead of Data messages
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 60
doc.: IEEE 802.11-00/573a
Submission
Potential for Roaming Support
Old Access Point
Legitimate Wireless Station
New Access Point
Reassociate
1.
2. Legitimate Station’s WEP key
3. Security Association Exchange
4. Delete key from old AP
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 61
doc.: IEEE 802.11-00/573a
Submission
Implementation Considerations (1)
• Requires Rekey Information Element– Needed for positive key synchronization (key-mapping
key case)– Controls rekey time interval (default key case)– Provides key identities in both cases– Messages required to establish first temporal key
(for both shared and per-link key types)
• Message-based method scales– Multiplex arbitrary number of enable sequences in
parallel – Rapid dispatch for transition sequences
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 62
doc.: IEEE 802.11-00/573a
Submission
Implementation Considerations (2)
• Count-down scheme requires adding Rekey Information Element to Beacon
• Security of Count-Down Scheme also requires TSFT to be MIC’d– The value of the Beacon TSFT is not known until Beacon
is passed to the PHY interesting implementation problem
• ESS-wide default key attractive for multicast/broadcast– But STA’s can’t trust any message as authentic until
establishing security association with sender
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 63
doc.: IEEE 802.11-00/573a
Submission
Implementation Considerations (3)
• Proposals defines one new management frame type for TGi– Cloned from TGe action frame– Extend ability of TGi to update security
parameters including rekeying– Protocol requires 7 action opcodes; the rest
should be reserved for future use
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 64
doc.: IEEE 802.11-00/573a
Submission
Implementation Considerations (4)
• No changes needed to cipher engines– But not precluded– But does restrict their use to within an SA context
• No dependence on external authentication service– But not precluded
• Protocol security depends on introducing MIC into Disassociation, Deauthentication messages– Use the master authentication key for this– It will also need the session nonce(s)
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 65
doc.: IEEE 802.11-00/573a
Submission
Agenda
• Motivation, Constraints, and Requirements
• Protocol Definition
• Protocol Analysis
• Summary and Next Steps
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 66
doc.: IEEE 802.11-00/573a
Submission
Summary
• Proposed rekey protocol– Provides solution to all its motivating problems– Is the simplest correct solution possible given
the problem requirements and constraints– Provides robust security and performance for
both key-mapping keys and default keys– Supports both short-term and long-term cipher
suite proposals
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 67
doc.: IEEE 802.11-00/573a
Submission
Next Steps
1. Finish review of state machines
2. Reissue doc 11-01-573 with reviewed state machines
3. Converge protocol with TGi/TGf key hand-off scheme
4. Adopt text from doc 11-01-573 as TGi draft
November 2001
Cam-Winget, Chesson, Housley, WalkerSlide 68
doc.: IEEE 802.11-00/573a
Submission
Discussion