Sept 2005 doc IEEE 802 11 050901 r

  • Slides: 16
Download presentation
Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Partial Proposal to TGw

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Partial Proposal to TGw - AMID Date: 2005 -09 -16 Authors: Notice: This document has been prepared to assist IEEE 802. 11. 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 802. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http: // ieee 802. 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 <stuart. [email protected] com> 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 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected] org>. Submission 1 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Abstract This submission describes

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Abstract This submission describes the concept of “Association MAC Identifier” (AMID) which can be used to avoid deadlock conditions due to loss of key material in management protections. Submission 2 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 MAC Addresses • The

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 MAC Addresses • The MAC Address serves two purposes: 1. 2. • It uniquely identifies the interface “in the entire world” It is used as a local identifier to distinguish between devices in the layer 2 network. We contend that these are different requirements that are connected only because of history not because of purpose Submission 3 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Distinguisher vs. Identity •

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Distinguisher vs. Identity • For use as a “network distinguisher”, MAC address only needs to be unique with the local layer 2 network - not globally! • “Identity” should be based on the credentials of the user - that can be properly authenticated. We contend that such credentials should not be overloaded with the network identifier. • Unique MAC address can serve both roles (as now) but has limitations Submission 4 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Limitation of static MAC

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Limitation of static MAC address • A device can only make a single connection through a physical interface. – This is an arbitrary constraint imposed due to history – There is no reason why a device couldn’t support multiple instances on the network through the same physical connection (other than the MAC address constraint) Submission 5 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Why is this relevant

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Why is this relevant to TGw? • A major reason that TGi did not include management protection was because of the “lockout problem” when state is lost. • The problem exists because the MAC Address becomes unusable for a period if the key state is lost. • If the STA is not limited to a single MAC address there is no problem Submission 6 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Therefore we propose: 1.

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Therefore we propose: 1. Within the local BSS, the STA is not required to use its MAC address as identifier 2. An arbitrary MAC address is created each time a new association is attempted. 3. – We call the arbitrary address “Association MAC Identifier” (AMID) – AMID can be a random value* (or STA could choose to use its actual MAC address) If STA loses state it can reconnect using new AMID value. Old session will time out *with local administration bit set Submission 7 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Basic Concept - summary

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Basic Concept - summary • The STA does not use its real MAC address when communicating to the AP • Instead it uses an arbitrary MAC Address called “Association MAC ID” (AMID) • A different value is chosen each time the station connects • The real MAC address is sent confidentially to the AP during 4 way handshake Submission 8 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Overall concept • Real

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Overall concept • Real MAC address is used on DS and layers above the STA MAC • AMID is used only for frames across the wireless link • All management frames use session AMID but the real MAC address is inserted at UNITDATA SAP REAL MAC UNITDATA SAP AP DS Submission AMID used here 9 STA MAC 802. 11 MAC/ encryption REAL MAC STA LLC layer Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Solving the lockout problem

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Solving the lockout problem Scenario: – STA connects using real MAC address and has keys for disassociate – STA loses state (e. g. due to unexpected reboot) – STA cannot now re-connect because AP requires authenticated dissassociate first. Solution: – Using a new AMID value, STA can initiate a new connection at any time. It just repeats the first time connect procedure using the new AMID – Previous session will time out and be discarded Submission 10 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Acquiring the AMID 1.

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Acquiring the AMID 1. 2. 3. 4. 5. Submission Station selects random MAC address for AMID Station sends MAC Auth frame using AMID If AMID is unique at AP, it sends “success” message If AMID is in use AP sends “fail” message AMID is assigned until authenticated de-auth message (or agreed time limit) 11 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Implementation considerations • Very

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Implementation considerations • Very simple to implement because AMID is used in all time critical processing - change is transparent to most of the STA implementation. • AMID / Real Mac Address substitution only occurs on MSDUs • STA can always choose to use Real MAC address instead of AMID based on policy • AP must advertise AMID support. Thus operator can “turn it off” if needed for diagnostics. Submission 12 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Relation to TGr Mechanism

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Relation to TGr Mechanism • Temporal key handshake occurs partly before and partly during association • The handshake occurring before association could be over the DS or over the air. • Implications: – STA must acquire AMID from new AP before starting handshake (i. e. do the open MAC auth first) – TGr broker function must be aware of AMID Submission 13 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Small change to TGr

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Small change to TGr supports AMID • TGr will use action frame to carry “over the DS” communication • Action frame goes from STA to broker (usually current AP) which forwards to target AP • Action frame contains source MAC address of station • Need to also include AMID in action frame - the target AP must know value of AMID since STA will use AMID to associate! State must be established using AMID. • For non TGw operation AMID field = source MAC • No other change needed to TGr Submission 14 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Probing • Probe requests

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Probing • Probe requests are sent using a well known fixed source MAC address • Response is broadcast Submission 15 Jon Edney, Nokia

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Summary • Use of

Sept 2005 doc. : IEEE 802. 11 -05/0901 r 0 Summary • Use of AMID removes limitations of single fixed MAC address • Use of AMID solves key-loss lockout problem • Use of AMID is transparent outside the BSS • Low additional implementation overheads REAL MAC UNITDATA SAP AP DS Submission AMID used here 16 STA MAC 802. 11 MAC/ encryption REAL MAC STA LLC layer Jon Edney, Nokia