doc.: ieee 802.11-00/573a submission november 2001 cam-winget, chesson, housley, walkerslide 1...

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


doc.: IEEE 802.11-00/573a

Submission

Agenda

• Motivation, Constraints, and Requirements

• Protocol Definition

• Protocol Analysis

• Summary and Next Steps

November 2001


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


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


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


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


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


doc.: IEEE 802.11-00/573a

Submission


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


doc.: IEEE 802.11-00/573a

Submission


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


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


doc.: IEEE 802.11-00/573a

Submission


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


doc.: IEEE 802.11-00/573a

Submission


Old Access Point

Legitimate Station

New Access Point

Associate

1.

Rogue Station

Reassociate

2.



Problem Summary: new AP doesn’t know STA is authentic

November 2001


doc.: IEEE 802.11-00/573a

Submission


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


doc.: IEEE 802.11-00/573a

Submission


• 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


doc.: IEEE 802.11-00/573a

Submission

Agenda





November 2001


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


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





Authenticated KeyExchange

Authenticated KeyExchange

State 6: Authenticated,

Associated, Secure

DisassociationNotification

November 2001


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


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


doc.: IEEE 802.11-00/573a

Submission

Key Hierarchy

November 2001


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


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


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


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


doc.: IEEE 802.11-00/573a

Submission

Terminating a Security Association

• 802.11 Deauthentication

• Dissassociation

• Association

• Reassociation

• Rekey failure

November 2001


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


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


Transition Confirm

TransitionExchange


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


Not Applicable

Not Applicable

Key-mapping Keys Default Keys

November 2001


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


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


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


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


doc.: IEEE 802.11-00/573a

Submission

Agenda





November 2001


doc.: IEEE 802.11-00/573a

Submission

Protocol Analysis

• Security Properties

• Performance Characteristics

• Breaking the Race Condition

• Potential Roaming Support

• Implementation Considerations

November 2001


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


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


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


doc.: IEEE 802.11-00/573a

Submission

Rekey Frequency (TCP)

November 2001


doc.: IEEE 802.11-00/573a

Submission

Rekey Frequency (UDP)

November 2001


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


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


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


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


doc.: IEEE 802.11-00/573a

Submission

Potential for Roaming Support

Old Access Point

Legitimate Wireless Station

New Access Point

Reassociate

1.


3. Security Association Exchange


November 2001


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


doc.: IEEE 802.11-00/573a

Submission


• 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


doc.: IEEE 802.11-00/573a

Submission


• 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


doc.: IEEE 802.11-00/573a

Submission


• 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


doc.: IEEE 802.11-00/573a

Submission

Agenda





November 2001


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


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


doc.: IEEE 802.11-00/573a

Submission

Discussion

doc.: ieee 802.11-00/573a submission november 2001 cam-winget, chesson, housley, walkerslide 1...

Documents