1. Proposal for Emergency Services Requirement
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Proposal for Emergency Services Requirement
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
Stefano M. Faccin, Nokia
John Doe, Some Company

2. Month Year
doc.: IEEE 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

3. March 2006
TGu Requirement I1
Define IEEE 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

4. Clarifications Need to distinguish between
March 2006
Clarifications
Need to distinguish between
IEEE emergency services  direct support in IEEE 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 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 emergency calls solution.
Stefano M. Faccin, Nokia

5. 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

6. 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

7. 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

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

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

10. Authentication There is no authentication or 4-way handshake
March 2006
Authentication
There is no authentication or 4-way handshake
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

11. 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 i 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

12. 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

13. 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

14. 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

15. 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 layer (e.g. MAC address)
Stefano M. Faccin, Nokia

16. 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

17. 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

18. 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 i or r mechanisms
Performed in connection with association request handling at lower layer than security association management.
Stefano M. Faccin, Nokia