1. Mechanism to update current session parameters
Month Year
September 2006
September 2006
Mechanism to update current session parameters
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Sood, Walker, Jalfon
Sood, Walker

2. Month Year
September 2006
September 2006
Abstract
STA implementations use (re)association request messages to update their current session parameters.
This proposal introduces one mechanism to clearly separate the means for updating session parameters to be distinct from an actual (re)associate state.
Sood, Walker, Jalfon
Sood, Walker

3. Agenda Problem Statement Suggested mechanism Conclusions
Month Year
September 2006
September 2006
Agenda
Problem Statement
Suggested mechanism
Conclusions
Sood, Walker, Jalfon
Sood, Walker

4. Month Year
September 2006
September 2006
Problem Statement
Some current STA implementations use (re)associate request messages to their AP to update the session parameters
So, why is this a problem?
(re)Associate semantics dictate that STA is requiring a new connection
REV-ma-D7.0-Redine: – STA be explicitly disconnected; e.g. service disruption
REV-ma-D7.0-Redline: – SAs be deleted, especially PTKSA
REV-ma-D7.0-Redline: – Reassociation can update params
Lack of instance identifiers in (re)associate messages make it impossible for AP to differentiate an existing session from a new one
In summary: update of security parameters should not be overloaded to (re)associate requests unless disruption of service is acceptable!
STAs need a cleaner mechanism to update its current session parameters with the associated AP
Sood, Walker, Jalfon
Sood, Walker

5. Month Year
September 2006
September 2006
Problem not solved by r
11r uses (ANonce, SNonce) combination as a session identifier, which is also included in (re)association messages
11r requires the use of 11r authentication prior to (re)association to create a PTKSA
If 11r AKM is negotiated, a STA wanting to update its session parameters using (re)associate must derive a new PTKSA.
Pretty burdensome, right? Especially, for low-powered STAs
Causes disruption in existing connection due to new 11r handshake
Sood, Walker, Jalfon
Sood, Walker

6. Proposed Mechanism New Class 3 Action Frame Category: Session Update
Month Year
September 2006
September 2006
Proposed Mechanism
New Class 3 Action Frame Category: Session Update
Action Field Values
Action field value
Description 1
Session-Update Request 2
Session-Update Response
Sood, Walker, Jalfon
Sood, Walker

7. Session-Update Request Format
Month Year
September 2006
September 2006
Session-Update Request Format
In an ESS, this message if sent from a non-AP STA to its currently associated AP
AP Address
Capability Information
Listen Interval
Supported Channels
QoS Capability
Category
Action
Request ID
AID
Octets: Variable, Defined Elsewhere
Additional IEs (Incl. Vendor Specific) can be appended to this frame, as needed
RSN is not included
Sood, Walker, Jalfon
Sood, Walker

8. Session-Update Response Format
Month Year
September 2006
September 2006
Session-Update Response Format
In an ESS, this message if sent from an AP to its associated non-AP STA, as a response to a prior Request
AID
STA Address
Capability Information
Listen Interval
Supported Channels
QoS Capability
Category
Action
Request ID
Octets: Variable, Defined Elsewhere
Shall match the Session-Update Request-ID
Accepted or Suggested Values
Sood, Walker, Jalfon
Sood, Walker

9. Session-Update Procedure
Month Year
September 2006
September 2006
Session-Update Procedure
STA AP
Successful Authentication and Association – 11i or 11r
Session-Update-Request(Req-ID, List-of-Params, IEs)
Session-Update-Response(Req-ID, List-of-Params, IEs)
Sood, Walker, Jalfon
Sood, Walker

10. Confidentiality, Authentication, and Replay Protection
Month Year
September 2006
September 2006
Confidentiality, Authentication, and Replay Protection
The proposed Action Frame is sent only after a STA has a successful and current association with an AP
TGw requirements (Done) and protocol (work-in-progress) for Unicast Action Frames protection will provide protection against eavesdropping, in-flight modification (integrity), MITM, and replay attacks.
Sood, Walker, Jalfon
Sood, Walker

11. Month Year
September 2006
September 2006
Summary
Provide a clean and secure mechanism for a STA to update its session parameters with its associated AP
Eliminate semantic overload of the (re)association message
Sood, Walker, Jalfon
Sood, Walker