Proposal for Emergency Services Requirement Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Proposal for Emergency Services Requirement Date: 2006-01-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:// 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 <stuart.kerry@philips.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 <patcom@ieee.org>. Stefano M. Faccin, Nokia John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 March 2006 Abstract This document describes a complete proposal for requirement I1 . These slides refer to document 06/0288r1. Stefano M. Faccin, Nokia John Doe, Some Company

March 2006 TGu Requirement I1 Define IEEE 802.11 functionality which would be required to support an Emergency Call (e.g. E911) service as part of an overall, multi-layer solution. Specifically: Capability Advertisement Authentication issues Stefano M. Faccin, Nokia

Clarifications Need to distinguish between March 2006 Clarifications Need to distinguish between IEEE 802.11 emergency services  direct support in IEEE 802.11 of such services, independently of what solutions are adopted at higher protocol layers support of higher layer emergency services  if the user dials “911” in a VoIP application (e.g. SIP based), the VoIP application may simply setup a SIP call, in which case it is transparent to 802.11. This would result in the establishment of a higher layer emergency service. In other cases, the terminal may react by dropping the connections for the VoIP application, and use the 802.11 emergency calls solution. Stefano M. Faccin, Nokia

March 2006 Key components Three key components of a TGu emergency services solution are: Network selection – determining whether the network provides support for emergency services. This is an extension of the network selection process. Network join – the STA needs to be able to join the network without any user credentials Admission control and traffic conditioning – the emergency services traffic needs to be admitted to the network as a high priority, and given appropriate QoS treatment. In addition, the AP needs to limit the use of the emergency service network access to emergency service traffic. Stefano M. Faccin, Nokia

March 2006 Assumptions It is assumed that there is a high layer standardized protocol (or protocol suite) for making emergency calls or using any other emergency services. Any authentication or encryption of the emergency services can occur at the higher layer rather than at the MAC layer. Maintenance of an existing connection is not required when the STA needs to make use of the emergency services. A pre-existing association with the AP could be discarded prior to the emergency call. Typically, in today’s networks supporting emergency services, there is no need and no interest in maintaining the current services and connections, since the priority is on the establishment of emergency services. The access point separates the backhaul of emergency services traffic from other traffic. This may be in the form of a separate physical link, dedicated VLAN, tunnelling protocol, etc. When using the emergency communications access only emergency services can be accessed. Access point has a dedicated connection to emergency services. This might be: Separate physical link Dedicated VLAN Tunnelling protocol Stefano M. Faccin, Nokia

SME Architecture To DS To 911 Svcs 911 SVC manager controls March 2006 Architecture To DS To 911 Svcs IEEE802.1X Authenticator 911 Svc Mgr 911 SVC manager controls emergency services channel switch based on the state from association services Association Svc 802.11 MAC SME Stefano M. Faccin, Nokia

Four Components Advertising Authentication Connection March 2006 Four Components Advertising Authentication Connection Support of Mobility Traffic Handling Stefano M. Faccin, Nokia

March 2006 Advertising Use a 911 capability bit in beacons, Probe Response, and Neighbor Reports Stefano M. Faccin, Nokia

Authentication There is no authentication or 4-way handshake March 2006 Authentication There is no authentication or 4-way handshake 802.11 MAC: open authentication may be deprecated and skipped All data frames for the STA are passed to emergency service channel once service is invoked Keys are never plumbed. Transmissions remain open and unencrypted There is no requirement for confidentiality of emergency calls If encryption is needed, such measures should be done at a higher level, not at the LAN level Stefano M. Faccin, Nokia

March 2006 Connection If TGw is supported, the STA performs an authenticated de-association. If TGw is not supported, the STA simply de-associates STA indicates request for emergency service by setting an “emergency services capabilities bit” during the association request in the Association Request frame. Setting the bit guarantees acceptance of the association request by the AP (subject to protocol compatibility) and no 802.11i 4-way handshake is required since no keys have been created due to authentication and therefore no encryption keys need to be setup between the STA and the AP. Receipt of an association request with the 911 capability bit set immediately results in tear-down of any existing security association for the station (if the station was already associated and authenticated) Stefano M. Faccin, Nokia

March 2006 Support of Mobility Assume that access to the emergency services has the same LLC transparency as the DS a transition to another AP would be transparent to the session Support of mobility in the direct signaling solution can take advantage of Fast Transition (FT), since support for FT in non-RSN is being revised. Support of mobility in VAP-solutions can also take advantage of FT. Stefano M. Faccin, Nokia

Traffic Handling Segregation of E911 traffic: Filtering March 2006 Traffic Handling Segregation of E911 traffic: all data frames generated by an STA that has asserted emergency services during the association request are bridged to a specific VLAN or routed to a specific router that only handles emergency call setup. In this way, there would be not point for a bad guy (BG) in connecting except for making the emergency call. Filtering In order to avoid abusive use of this proposed emergency services mechanisms, the AP should provide filtering mechanisms to limit the user traffic to only that necessary to make an emergency call. If such filtering is not in place then a malicious user may be able to get priority use of an access point, and be able to transfer arbitrary data without authentication. Any charging mechanisms would also be evaded. Such mechanisms are however out of scope Stefano M. Faccin, Nokia

March 2006 Analysis wrt G1 G1: All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices. Discovery/advertising: Discovery in beacons enables passive discovery => power saving is possible Discovery through probing may impact power saving, but is necessary in several scenarios Connection: power saving is not relevant Stefano M. Faccin, Nokia

Analysis wrt G2: Threats and solutions March 2006 Analysis wrt G2: Threats and solutions G2: All proposals (whichever requirements they address) shall describe the security Station using emergency services is completely unauthenticated Any station can forge emergency calls, but this is not worst than current cellular system when there is no SIM Authentication of caller may be needed at higher level if so required by the higher level solution and if the station/user has credentials Authentication and credential at higher layer are used to identify the calling party to emergency services, not the information at 802.11 layer (e.g. MAC address) Stefano M. Faccin, Nokia

Analysis wrt G2: Threats and solutions (cont.d) March 2006 Analysis wrt G2: Threats and solutions (cont.d) Fake call to emergency services could cause disconnect of legitimate station a normally authenticated station would be disconnected by a rogue station issuing a E911 call with same MAC address however, the authenticated station will share credentials with the AP and these can be used to prevent an E911 call until the station has disassociated first this raises the stakes for the TGw "lock-out" problem since a locked out station would also be unable to make an emergency call. same threat already exists and will be dealt with in TGw / TGu Stefano M. Faccin, Nokia

Analysis wrt G2: Threats and solutions (cont.d) March 2006 Analysis wrt G2: Threats and solutions (cont.d) Modification of association request from an unassociated/unauthenticated station could force station to connect to emergency service by mistake Attack: a man in the middle captures an association request and sets the E911 bit before forwarding to the AP This will not be detected since the association request is not MICed. However, the point is that the result is benign Not a security risk to the network Stefano M. Faccin, Nokia

Advantages of approach March 2006 Advantages of approach Very simple approach No “Special case” authentication No tagging of data frames to enable their traversal of AP Protected data channel inaccessible during emergency calls Easily retrofitted Does not interact with existing 802.11i or 802.11r mechanisms Performed in connection with association request handling at lower layer than security association management. Stefano M. Faccin, Nokia