DISPATCH S. Gundavelli Internet-Draft M. Grayson Intended status: Standards Track Cisco Expires: 14 July 2024 11 January 2024 Emergency Communication Services over Wi-Fi Access Networks draft-gundavelli-dispatch-e911-wifi-02 Abstract This document introduces an approach to enable emergency services over Wi-Fi access networks. These services encompass emergency services such as 911 in North America, 112 in the European Union, and equivalent emergency services in other regulatory domains. The proposed approach aims to provide a comprehensive solution for supporting emergency communication across different regions and regulatory frameworks. Leveraging the legal framework and infrastructure of the OpenRoaming federation, this proposal aims to extend emergency calling capabilities to the vast number of OpenRoaming Wi-Fi hotspots that have already been deployed. The approach addresses critical challenges related to emergency calling, including discovery and authentication procedures for accessing networks that support emergency services, emergency access credentials, the configuration of emergency voice services, accurate location determination of the emergency caller, and call spofing. By providing a comprehensive solution, this proposal ensures that emergency communication services can be seamlessly and effectively supported within the IEEE 802.11-based Wi-Fi ecosystem leveraging Passpoint Profiles. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Gundavelli & Grayson Expires 14 July 2024 [Page 1]
Internet-Draft Emergency Communication Services January 2024 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 July 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Emergency Service Architectures - Current Art . . . . . . . . 5 3.1. IETF Protocol Support . . . . . . . . . . . . . . . . . . 5 3.2. NG911 and NG112 Emergency Systems . . . . . . . . . . . . 6 3.3. 3GPP Emergency Service Architecture . . . . . . . . . . . 7 4. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Scenario Description . . . . . . . . . . . . . . . . . . 8 4.2. Technical Architecture . . . . . . . . . . . . . . . . . 9 5. Key Service Requirements . . . . . . . . . . . . . . . . . . 11 6. Access Network Location . . . . . . . . . . . . . . . . . . . 12 7. WLAN Network Identification and Selection . . . . . . . . . . 12 8. Legal and Regulatory Requirements . . . . . . . . . . . . . . 13 9. Authentication on the emergency RCOI WLAN . . . . . . . . . . 13 10. Authentication using the sos.fcc-authorized.org realm . . . . 13 11. Emergency CSCF operation for end-users using sos.fcc-authorized.org credentials . . . . . . . . . . . 14 12. Emergency calling by OpenRoaming subscribers on MNOs . . . . 14 13. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Gundavelli & Grayson Expires 14 July 2024 [Page 2]
Internet-Draft Emergency Communication Services January 2024 17.1. Normative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The Federal Communications Commission's (FCC) Communications Security, Reliability, and Interoperability Council (CSRIC) have completed a report that is currently under FCC review. The report focuses on the utilization of Wi-Fi technology for accessing emergency 911 services in areas without mobile coverage. It provides an overview of non-proprietary standards capable of facilitating 911 services over Wi-Fi networks based on the IEEE 802.11 technology. Additionally, the report highlights the potential need for legal and regulatory adjustments to address concerns related to liability, privacy, and security when enabling public access to 911 services via Wi-Fi. The study looked at the technical feasibility and cost of: * making telecommunications service provider-owned Wi-Fi access points, and other communications technologies operating on unlicensed spectrum, available to the general public for access to 9-1-1 services, without requiring any login credentials, during times of emergency when mobile service is unavailable; * the provision by non-telecommunications service provider-owned Wi- Fi access points of public access to 9-1-1 services during times of emergency when mobile service is unavailable; and * alternative means of providing the public with access to 9-1-1 services during times of emergency when mobile service is unavailable." These initiatives showcase the dedication of regulatory entities to enhance access to emergency services through Wi-Fi-based networks. It is important to note that these efforts are not limited to any one specific regulatory domain but represent a widespread trend. This document introduces an approach that aligns with ongoing efforts to enhance emergency communication services over unlicensed Wi-Fi access networks. It proposes utilizing the OpenRoaming federation [I-D.tomas-openroaming] of Wi-Fi access providers and Identity Providers to facilitate the provision of emergency services. Gundavelli & Grayson Expires 14 July 2024 [Page 3]
Internet-Draft Emergency Communication Services January 2024 By leveraging a pre-configured emergency passpoint profile, any Wi- Fi-enabled device situated within the coverage area of an OpenRoaming hotspot that supports emergency services will have the capability to access the available emergency communication services provided in that region. 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology All the terms used in this document are to be interpreted as defined in the IETF and 3GPP specifications. For convenience, the definitions for some of the terms are provided below. OpenRoaming (OR) A federation that provides the framework for connecting unprecedented footprint of millions of Wi-Fi hotspots with identity providers. Identity Provider (IDP) An entity that manages identity credentials and policies for devices and provides authentications services. Access Network Provider (ANP) An entity providing internet connectivity services. Passpoint Profile Passpoint is a Wi-Fi Alliance (WFA) protocol that enables mobile devices to discover and authenticate to Wi-Fi hotspots that provide internet access. Profile includes the user's credentials and the access network identifiers. Roaming Consortium Identifier (RCOI) It is a 3-octet, or a 5-octet value carried in the 802.11 beacon information element (IE). It is also sent in the ANQP messages. RCOI identifies the groups or identity providers that are supported by the network. Gundavelli & Grayson Expires 14 July 2024 [Page 4]
Internet-Draft Emergency Communication Services January 2024 Connectivity Location Function (CLF) It maintains mappings between the endpoint's dynamically assigned IP address and its physical location. An enhanced CLF maintains the mapping between the devices' access point identifier (BSSID) and the physical location. Public Safety Answering Point (PSAP) A PSAP is a facility where emergency calls are received under the responsibility of a public authority. Route Determination Function (RDF) It resolves a physical location, either a civic address or a geo- spatial address to the serving PSAP. P-CSCF Proxy Call Session Control Function. P-CSCF is a specific 3GPP function ([TS23501]) defined in their IMS architecture. It largely a 3GPP variant of the IETF SIP Proxy function [RFC3261]. E-CSCF Enhanced Call Session Control Function. It takes the requests from P-CSCF (Proxy CSCF) and routes the emergency sessions to the PSAP based on CLF and RDF queries. 3. Emergency Service Architectures - Current Art 3.1. IETF Protocol Support The IETF has made significant contributions to the development of emergency architectures, which serve as the foundation for Next Generation 911 and 112 systems. These efforts encompass a wide range of protocols and cover essential aspects, including location determination and other relevant elements. The following key specifications highlight these contributions: [RFC4119], [RFC4676], [RFC5222], [RFC5985], [RFC6225], [RFC6442], [RFC6443] [RFC6881], [RFC7852], and [RFC8876], Gundavelli & Grayson Expires 14 July 2024 [Page 5]
Internet-Draft Emergency Communication Services January 2024 However, it is worth noting that a substantial portion of the work conducted by the IETF predates the current industry focus on roaming in Wi-Fi networks using Passpoint profiles and identity federation rameworks, as well as the infrastructure established by the OpenRoaming federation. There is inherent value in standardizing emergency communication approaches that align with these newer industry developments around Wi-Fi roaming. The primary objective of these efforts is to enable individuals with Wi-Fi devices within the coverage area of an OpenRoaming hotspot to connect to the network without requiring specific access credentials. This allows them to make emergency calls seamlessly and without any barriers. This can save lives! 3.2. NG911 and NG112 Emergency Systems Next Generation 911 (NG911) is the new emergency communication system designed to enhance the effectiveness and efficiency of emergency services. NG911 builds upon the existing 911 emergency response infrastructure by integrating newer capabilities. The implementation of the NG911 architecture is planned to occur in multiple phases. The first phase focuses on enhancing the existing legacy 911 architecture. Following this, a transitional phase will be implemented to gradually transition to the full-fledged NG911 system. Finally, the End State NG911 Service architecture will be established to provide the ultimate NG911 capabilities. NG911 leverages IP-based networks to transmit emergency communications, enabling seamless integration with various digital platforms and devices. It enables individuals to contact emergency services not only through traditional phone calls but also through text messages, multimedia messages, and even real-time video streaming. This provides greater flexibility for individuals with diverse communication preferences or accessibility needs. One of the significant advantages of NG911 is the ability to receive more detailed location information from callers. Traditional 911 systems rely on the location of the calling device or the cell tower used for the call, which can sometimes result in imprecise location data. NG911 leverages Global Navigation Satellite Systems (GNSS) to obtain more accurate and reliable location information, allowing emergency services to respond more swiftly and precisely. NG911 architecture is based on IETF standards. The SIP UA which is authenticated to the P-CSCF, creates a SIP INVITE that includes location information in the form of a Presence Information Data Format Location Object (PIDF-LO) in the body of the message. The Gundavelli & Grayson Expires 14 July 2024 [Page 6]
Internet-Draft Emergency Communication Services January 2024 P-CSCF passes the SIP INVITE to the E-CSCF. The E-CSCF passes the SIP INVITE message to the LRF to obtain location and routing information for the emergency call. LRF will use the Location to Service Translation (LoST) protocol [RFC5222] to query the RDF. The RDF will determine routing based on the routing location NG112 is the new emergency communication system designed to improve emergency services by integratung modern technologies and capabilities. It is a European initiative that aims to enhance the existing emergency response infrastructure, building upon the legacy of the widely recognized emergency number, 112. NG112 largely follows the NG911 architecture and is based on IETF standards. 3.3. 3GPP Emergency Service Architecture The 3rd Generation Partnership Project (3GPP) has developed an Emergency Service architecture that enables effective and reliable emergency communication services within cellular networks. This architecture encompasses various components and protocols designed to ensure prompt emergency assistance. The essential component of the architecture is the Emergency Services (ES) functionality, which allows users to dial emergency numbers, such as 112 or 911, to access emergency services. ES interfaces with the cellular network infrastructure to establish emergency calls and deliver them to the appropriate Public Safety Answering Point (PSAP) or emergency call center. Additionally, the architecture includes the Location Services (LCS) system, which enables accurate positioning of emergency callers. LCS uses various positioning methods, including GPS, and network-based methods, to determine the caller's location and transmit it to the PSAP for effective emergency response. The 3GPP Emergency Service architecture also incorporates support for multimedia services, such as text messages, images, and videos, enabling individuals to provide additional information to emergency services during critical situations. Overall, the 3GPP Emergency Service architecture ensures that cellular networks have the necessary capabilities to handle emergency calls, deliver accurate location information, and support multimedia communication for effective emergency response and public safety. Gundavelli & Grayson Expires 14 July 2024 [Page 7]
Internet-Draft Emergency Communication Services January 2024 4. Proposed Approach WBA's OpenRoaming is a roaming federation service of Access Network Providers (ANPs) and Identity Providers (IDPs), enabling an automatic and secure Wi-Fi experience globally. WBA OpenRoaming creates the framework to seamlessly connect devices to the access networks that are part of the federation. For further insights into the architectural specifics of WBA's OpenRoaming, please refer to the document, [I-D.tomas-openroaming]. ANP-1 --\ _----_ /-- IDP-1 \ Access _( Open )_ Identity / ANP-2 ---<== Network ---( Roaming )--- Providers <==-- IDP-2 / Providers (_ _) \ ANP-3 --/ '----' \-- IDP-3 Figure 1: OpenRoaming Federation The solution presented in this proposal utilizes the legal framework and core components of the OpenRoaming federation to extend emergency calling capabilities (e.g. 911/112) to tens of thousands of existing OpenRoaming hotspots operating on unlicensed Wi-Fi networks. The following text explains the architectural framework of this approach. 4.1. Scenario Description * A Wi-Fi-enabled device equipped with a pre-installed emergency passpoint profile and located within the coverage area of an OpenRoaming hotspot. The device does not have the access network credentials for that hotspot, other than the emergency passpoint profile. * The hotspot is configured to facilitate emergency communication services. It advertises the emergency RCOI (Roaming Consortium Identifier) in the IEEE 802.11 beacon messages. * When a user dials the emergency calling number designated for their regulatory domain (such as 911/112), their device initiates a search for Wi-Fi networks that support emergency services by comparing the RCOI field of the passpoint profile. Upon finding a match, temporary access to the network is granted. The user's location is relayed to the Identity Provider (IDP) by the access network. Gundavelli & Grayson Expires 14 July 2024 [Page 8]
Internet-Draft Emergency Communication Services January 2024 * The device obtains the emergency service configuration from the IDP designated for the emergency realm, and specific to that locale. * User makes the emergency call registration. User's location reported in the call signaling is cross correlated with the location reported by the access network. * User's call is routed to the nearest PSAP. 4.2. Technical Architecture IDP +===================================+ | IDP: (e.g.)sos.fcc-authorized.org)| | +---+ +------+ | | |CLF|--------------|E-CSCF| | | +---+ CLF Query +------+ | | | for Location | |---><PSAP> | +---+ +------+ | | |AAA| |P-CSCF| | | +---+ +------+ | +===================================+ . : . /|\ : /|\ | : | _----_ | : | _( Open )_ | : | ----( Roaming )............: | (_ _) | : | '----' | : | | _-----_ | (RADIUS Signaling)| _( )_ | (SIP Signaling) | ( Access )- | RADIUS Attributes | -(_Network)- | P-Access-Network-Info (BSSID, Civic-Loc | '-----' | SIP Header (RFC 3455) /Geo-Loc and SLT)| | | and RFC 7315 Defined | | | 3GPP Header for carrying \|/ | | BSSID and/or SLT . +----+ | | AP | | +----+ | : | : \|/ +========+ | Device | (Emergency Passpoint Profile) +========+ Gundavelli & Grayson Expires 14 July 2024 [Page 9]
Internet-Draft Emergency Communication Services January 2024 Figure 2: Technical Architecture The E-CSCF (Emergency Call Session Control Function) and P-CSCF (Proxy-Call Session Control Function) are well-defined functions within the IMS (IP Multimedia Subsystem) architecture as specified by 3GPP. These functions can be utilized for emergency calling purposes, or alternatively, they can be substituted with an IETF SIP Proxy [RFC3261], to support the necessary calling services. There will be a designated Identity Provider (IDP) and designated emergency calling services for supporting emergency calling service (e.g., 911/112). The AAA server in the IDP supports the realm for that region (e.g. "@sos.fcc-authorized.org") and the EMERGENCY-RCOI policies (i.e., for example an 911/112 specific HotSpot2.0 Roaming Consortium or RCOI). There will also be dedicated P/E-CSCF (Proxy/ Emergency Call Services Control Function) for supporting emergency calling services. DNS servers for the realm will be configured to enable ANPs to dynamically discover the designated IDP's AAA servers. The devices are pre-configured with a HotSpot2.0/Passpoint profile, which includes the emergency RCOI, and a common identity, e.g., anonymous@sos.fcc-athorized.org. Device eco-systems vendors can pre- configure this profile into every device at the time of manufacturing or push an updated profile using established carrier-bundle based provisioning. This anonymous profile will be common for all devices. This allows the device to discover Wi-Fi access networks that support emergency services (e.g. 911/112). Furthermore, the SIP User Agent in the mobile device will be able to use P/E-CSCF configuration obtained from the Wi-Fi access network. Wi-Fi access networks that are part of the OpenRoaming federation and willing to support emergency communication services will configure the emergency RCOI on their WLAN equipment. WLAN OEM suppliers can augment existing OpenRoaming provisioning interfaces with emergency RCOI settings. These networks allow any devices without access credentials to connect to the network for emergency calling. The Wi- Fi access network will recover the realm from the identity and use DNS system to discover the designated IDP's AAA servers. OpenRoaming already requires access networks to provide their Civic Location and/or Geo-spatial coordinates in the IDP signaling messages. The location information may be manually configured or can be obtained from a reliable source. The device will also be able to discover emergency voice services (CSCF) and the related configuration from the access network or from a cloud entity. This allows device to be able to use the emergency services when connected to access networks that are not part of the OpenRoaming federation. NOTE that this assumes that the device has basic internet Gundavelli & Grayson Expires 14 July 2024 [Page 10]
Internet-Draft Emergency Communication Services January 2024 connectivity and can initiate emergency calls without requiring emergency calling support from the access network. The device can include location elements, obtained either from the access network or from a cloud function, and include them in the SIP signaling using the Geolocation header fields defined in RFC 6442. The E-CSCF function will retrieve the location elements from the signaling messages from the device. For supporting the architecture based on this approach, we need the following updates to the WBA OpenRoaming architecture. * enhancement to WBA OpenRoaming technical framework to include use of emergency RCOI. * enhancements to OpenRoaming templated legal terms for access network providers on use of emergency RCOI and associated requirements, e.g., related to use of existing defined RFC 5580 location attributes. * updates to WBA WRIX offered-service VSA to include new string for "openroaming-emergency" service definition. * definition of policies required to be enforced by ANP when filter- id attribute mirrors the "openroaming-emergency" tag. 5. Key Service Requirements An emergency call handling service shall be designated to handle Wi- Fi-enabled emergency calls (e.g. 911/112), along with an IDP function for the respective realm e.g., "sos.fcc-authorized.org", where an existing MNO cannot (non-provisioned device or MNO core is unavailable). This should consider third-party providers such as IDPaaS/MNO/Voice Service Providers to host these services. Broadband service providers and HotSpot venue operators shall provide the Civic-Location and or the Geo-spatial coordinates of the venue, and the emergency voice service configuration to the device in the IP address configuration procedures. Consumer devices should be pre-configured by OEMs or through established carrier-bundle based provisioning with a HotSpot2.0/ Passpoint profile, including the emergency RCOI and a common identity such as (e.g.) "anonymous@sos.fcc-authorized.org.". Gundavelli & Grayson Expires 14 July 2024 [Page 11]
Internet-Draft Emergency Communication Services January 2024 6. Access Network Location Location of the caller is a key element in the emergency-service workflow. Emergency response centers must be able to determine the location of the caller before service is dispatched. A caller may be too young, frightened or confused to provide the location of emergency, therefore automatic location determination by PSAP is an essential requirement. The device making the emergency call must be able to obtain the Civic and/or Geo-spatial coordinates for inclusion in SIP Registration messages. Reliance on GPS is not an option for most indoor environments. The WLANs supporting emergency 911 services should be capable of providing the Civic Location or the Geo-Spatial coordinates of the caller, or of the access point. An OpenRoaming access point must be manually configured with the Civic and/or the Geo-Spatial coordinates or able to derive location through other means. For example, an access point operating in 6 GHz Standard Power mode is required to include its geo-location in the spectrum grant requests sent to the AFC. In some environments, the access point can learn the location information from a connected ethernet switch, or from a broadband service provider network. Furthermore, any access points supporting indoor localization services will be able to meet the location requirement. It is proposed to re-use the definition of location signaling in OpenRoaming, enabling the access point to provide the Civic address and/or the Geo-spatial coordinates of the device or of the access point to the IDP for CLF population. A confidence-level indicator is also optionally included in the reported location-data, based on RFC 7459 considerations. This parameter is indicative of the uncertainity and the confidence level of the reported location. 7. WLAN Network Identification and Selection The OpenRoaming federation makes extensive use of Passpoint specified Roaming Consortium Organization Identifiers (RCOIs) for defining polices that are supported by particular access network providers (ANPs) and those policies supported by individual identity providers (IDPs). The supported RCOIs are provisioned in WLAN equipment by the ANPs and configured in the Passpoint profile of devices managed by IDPs. Only when there is a match of RCOIs between WLAN and Passpoint profile will an authentication exchange be triggered. It is proposed to define the use of an emergency-RCOI for use in the systems to support Emergency Communication service (e.g. 911/112). Gundavelli & Grayson Expires 14 July 2024 [Page 12]
Internet-Draft Emergency Communication Services January 2024 8. Legal and Regulatory Requirements The OpenRoaming federation has a foundation in a legal framework, whereby the Wireless Broadband Alliance (WBA) as the federation's policy authority is responsible for defining the framework under which the federation operates. WBA defines the privacy policy that providers are required to comply with as well as end-user terms and conditions. In addition, WBA defines the legal templated terms that are used between OpenRoaming brokers and OpenRoaming providers, defining immutable terms that all OpenRoaming providers need to agree to. Finally, WBA agrees legal terms directly with OpenRoaming brokers, including terms that require OpenRoaming brokers to use the WBA templated terms in their agreements with providers. It is proposed that these legal agreements be amended with terms that cover operation of emergency service and allow provisions to indemnify ANPs against any liabilities resulting from emergency call failures. 9. Authentication on the emergency RCOI WLAN The requirements include being able to support emergency calls for users without valid credentials to fully authenticate to the WLAN, in this case a credential that has been issued by a specific OpenRoaming IDP designated to support users without a full credential. 3GPP has defined an approach that uses a 3GPP defined vendor specific EAP method called EAP-3GPP-LimitedService for supporting devices without credentials. However, this vendor specific EAP method is not widely supported. Instead, this use-case leverages the well supported EAP- TTLS method with a common set of credentials used by all users wanting to access on the emergency-RCOI WLAN. The EAP-Identity shall be specified as anonymous@sos.fcc-authorized.org with common credentials being used in the inner method. 10. Authentication using the sos.fcc-authorized.org realm OpenRoaming dynamically discovers the signaling peers used to authenticate end-users using DNS. The same approaches are re-used by ANPs to discover the signaling systems used to support the EAP-server for the sos.fcc-authorized.org realm. The EAP-server will use the common credentials to authenticate users without valid OpenRoaming credentials onto the WLAN. OpenRoaming defines the RADIUS messages exchanged between ANP and IDP. These include the "offered-service" vendor specific attribute as well as RFC 5580 defined location attributes. It is proposed to define a new value for the offered service, e.g., "openroaming-emergency" to unambiguously indicate that the authentication has come from a WLAN configured with the emergency RCOI. Gundavelli & Grayson Expires 14 July 2024 [Page 13]
Internet-Draft Emergency Communication Services January 2024 11. Emergency CSCF operation for end-users using sos.fcc-authorized.org credentials Whereas 3GPP defines the E-CSCF as always operating in the access network, in this use-case the E-CSCF is a common function that can be leveraged by all OpenRoaming ANPs that have configured the emergency- RCOI. This means that the E-CSCF isn't coupled to the access network by which it can recover network provided location information. Instead, in this use-case we leverage the existing OpenRoaming specifications that define the signaling of civic and geo-spatial location in the RADIUS exchange between ANP and IDP. Unlike in cellular networks, users on WLAN systems will frequently be allocated private IP addresses. This IP address information can be included in the RADIUS exchange between ANP and IDP, but because it will frequently represent a private address, it cannot be used to uniquely identify a user. Instead, it is proposed to enhance the Connectivity Location Function (CLF) to allow querying based on Basic Service Set ID (BSSID) which represents the MAC address of the WLAN radio interface that is serving a user, and optionally a Secure Location Tag (SLT) which the WLAN system will deliver it to the device. The BSSID and/or the SLT will be included in the P-ANI SIP header sent by the device as well as being included in the ANP to IDP RADIUS signaling. It's proposed that the definition of the IDP hosting the sos.fcc-authorized.org realm includes support for enhanced CLF capability that enables the IDP to be queried by an E-CSCF based on BSSID and/or SLT. The IDP can then match the BSSID and/or SLT with that received in RADIUS messages originated from individual ANPs and return the corresponding location information to the E-CSCF. 12. Emergency calling by OpenRoaming subscribers on MNOs End users who have been provisioned with a full OpenRoaming profile will successfully authenticate onto the OpenRoaming ANP using their standard profile and standard OpenRoaming RCOI. As an OpenRoaming IDP, the MNO is able to similarly match the civic-location and/or geospatial location of authentication requests with the BSSID and/or the SLT signaled by the ANP. The MNO operating the CSCF is able to recover the BSSID and/or the SLT from the P-ANI header and determine the location of their own users. 13. Call Flows Gundavelli & Grayson Expires 14 July 2024 [Page 14]
Internet-Draft Emergency Communication Services January 2024 +---+ +---+ +----+ +---+ +---+ +----+ +----+ |Dev| |AP | |DHCP| |DNS| |AAA| |P/E | |PSAP| +---+ +---+ +----+ +---+ +---+ |CSCF| +----+ | | | | | +----+ | | | | | | | | <1> <2> | | <3> | | | | | | | | | |<---<4>-->| | | | | | |<---<5>-->| | | | | | |<---<6>-->| | | | | | | |<----------<7>-------->| | | | | |<----------<8>------------------>| | | | | <9> | | | | |<-----------<10>------| | | | | | | | | | | | | <11> | | <12> | | | | | | | | | |---<13>-->|----------------<14>------------>| | | |<--------------------------<15>------------>| | | |<---------|<---------------<16>-------------| | | |<---<17>->| | | | | | | | | | <18> | | |<--------------------------<19>-------------|-------->| | | | | | |<--<20>--| | | | | | | <21> | |<---------------------------------------------------->|<-<22>->| 1. Passpoint Profile with Emergency-RCOI, ananonymous@sos.fcc-authorized.org. 2. Advertises E-RCOI on that BSSID, Civic & Geo-Location Attributes configured on the AP. 3. IDP & Voice Services for Emergency Calling. Possibly managed by FCC or WBA. Manages policies for E-RCOI\nand "sos.fcc.org" identities. 4. 802.11u with RCOI in Beacon IE 5. Attach to SSID matching the E-RCOI 6. Authentication Exchange (No credential validation) 7. Realm Lookup (sos.fcc.org) / IDP Discovery. 8. TLS Tunnel Setup, Authentication ID federated issued certs. 9. Generates location tag (SLT) based\non device indoor positioning, or location configuration of the AP. 10. Delivery of SLT from AN over ANQP/AssocResp/DHCP/IPv6 ND 11. BSSID + SLT (optional) + Location Attributes sent to IDP in the below RADIUS message exchange 12. E-CSCF FQDN and Emergency\nCalling numbers sent to AN in the below RADIUS message exchange Gundavelli & Grayson Expires 14 July 2024 [Page 15]
Internet-Draft Emergency Communication Services January 2024 13. EAP-ID/Resp / 802.1x 14. EAP over RADUIUS (TLS) 15. EAP-TTLS with well-known credentials 16. EAP-Success 17. Delivers IMS Configuration over 802.11, DHCP, or IPv6 ND 18. Updates the local CLF to include BSSID and/or SLT to Location Mapping 19. SIP UA Registration includes BSSID and SLT (optional) in the P-ANI Header. 20. CLF Query for Location Check using BSSID and/or SLT 21. Determination of PSAP based on query to RDF 22. Emergency Call Routed to PSAP with location Figure 3: Emergency e911 Services over Wi-Fi Access Following is some additional text explaining above interactions. * The device is pre-configured with the emergency passpoint profile, which includes the emergency RCOI, and a common identity, (e.g.) "anonymous@sos.fcc.org". This allows the device to discover access networks that support emergency communication services (e.g. 911/112). * The device may be preconfigured with a generic Emergency SIP (non- IMS) Profile. * An 802.11 access network supporting EAP-based authentication method and is part of the OpenRoaming federation is either configured with the Civic-Location and/or the Geo Spatial coordinates of the access point or has the ability to derive location coordinates through other means. * The access network for supporting emergency services (e.g. 911/112) will advertise the emergency RCOI in the 802.11 Beacon messages, and furthermore will respond to any ANQP queries on the supported services. Gundavelli & Grayson Expires 14 July 2024 [Page 16]
Internet-Draft Emergency Communication Services January 2024 * A device that is in coverage of a WLAN but without any valid conventional access-network credentials may use the UI interaction to trigger the selection of the profile containing the emergency RCOI. The end user's selection of an emergency calling application, or interaction with the default phone application (e.g., by selecting the emergency call option in the UI or by dialing an emergency phone number) may trigger the selection of the Passport profile with the emergency RCOI, resulting in the device performing a network-attach for emergency-call access. * The device will use the default identity, "anonymous@sos.fcc.org" from passpoint profile in the initial authentication message exchange, allowing the access network to discover the AAA server / IDP for EAP authentication. * The access network using the realm portion of the identity, "sos.fcc.org." will perform a DNS lookup the AAA server for the IDP supporting the emergency RCOI and the realm. * The access network and the AAA server will establish a secure TLS tunnel for securing the 802.1x/EAP traffic between the device and the IDP. The authentication of the peers will be based on the OpenRoaming federation issued X.509 certificates. * The device will complete the EAP authentication using the common credentials from the emergency passpoint profile. The 802.1x/EAP messages are tunneled as RADIUS messages between the access point and the AAA server. * The access point will generate secure location tag (SLT) for the device. The SLT will be delivered to the device over one of the protocols (ANQP/802.11/DHCP/IPv6 ND). SLT is a tag representative of the device' location. In another variation, SLT can be a composite object composed of a signed location by the access network or a cloud function, along with the identifiers of the signing entity. Functions such as E-CSCF will be able to verify the location by verifying the signature of the signing entity. * Prior to including the access network reported Civic Location, the Identity Provider (IDP) has the option to conduct a location validation check. If the reported location fails the validity test, the IDP can still add the location entry to the CLF. However, the entry can be flagged to indicate that the address did not pass the location validation test. * The access point includes the BSSID of the access point in the Calling-Station-Id attribute (RFC 2865) and/or the SLT in a new attribute to be defined. Gundavelli & Grayson Expires 14 July 2024 [Page 17]
Internet-Draft Emergency Communication Services January 2024 * The access point will also include the attributes for carrying the Civic Location and/or the Geo-Spatial coordinates of the access point (RFC 5580). * The AAA server will send the IMS configuration (E-CSCF FQDN) supporting emergency call routing services to the access point. * A success EAP transaction between the device and the AAA server will result in the AAA server sending EAP-SUCCESS to the device. * The AAA server will update the local CLF function with the location of the access point, using BSSID and/or the SLT as location identifiers. * The access point delivers the IMS configuration to the client over one of the interfaces (802.11/ANQP/DHCP/IPv6 ND). ANP will apply policies which limits the usage of the network over emergency RCOI only for emergency calling. Furthermore, the ANP will apply QoS policies on the emergency session for ensuring the call meets the SLA defined for the emergency service. ANP will prioritize traffic and sessions on emergency RCOI over other RCOIs. * The IMS client in the device performs registration with the emergency IMS system. The UA inserts the P-Access-Network-Info header field in the SIP message using the 3GPP 24.229 defined fields. It contains the BSSID of the access point (access- type="IEEE-802.11", wlan-node-id="BSSID", and optionally a secure- location-tag=SLT). A new parameter, "secure-location-tag" will be defined. * The E-CSCF function uses the BSSID and/or the SLT from the P-ANI header for determination of the device's location. It queries the CLF for retrieving the Civic and/or the Geo-spatial coordinates of the access point. The E-CSCF function may query the RDF function for the PSAP destination address. * The E-CSCF will route the emergency call to the nearest PSAP. 14. IANA Considerations This document does not requires any IANA actions. Gundavelli & Grayson Expires 14 July 2024 [Page 18]
Internet-Draft Emergency Communication Services January 2024 15. Security Considerations A rogue user or a compromised device may potentially trigger a volume of emergency calls, including calls spoofing the caller's real location. The value set for the field, "i-wlan-node-id" in the PANI header can potentially be a false BSSID which maps to a different location in the CLF database. In this use-case, we eliminate this threat with the use of SLT (Secure Location Tag) that the network will generate dynamically and will provide it to the device for inclusion in emergency call signaling. A trusted OpenRoaming access network signals the same location tag along with the civic and/or geo-spatial coordinates to the IDP. The CSCF function will retrieve the SLT from the call signaling from the device and will look up the civic location and/or geo-spatial coordinates of the device by querying the CLF database populated by the IDP. SLT serves as an index to the real-location and the generated tag is valid for a short duration, thereby eliminating any replay attacks. A rogue user or a compromised device may also initiate a volume of emergency calls, including a valid caller's location. This threat is not a new threat and exists even in today's emergency services supported over wireline and cellular architectures. 16. Acknowledgements We had many discussions with the members of FCC CSRIC 8 WG and that feedback greatly us greatly in developing this proposal. Special thanks to Brian Rosen for a through review and detailed comments and advice. We also like to thanks Dale R. Worley, Roland Jesske, and Christer Holmberg for all the discussions. Finally, we like to thank ART area director, Murray Kucherawy and DISPATCH working group chairs for facilating the discussions in the working group. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. Gundavelli & Grayson Expires 14 July 2024 [Page 19]
Internet-Draft Emergency Communication Services January 2024 17.2. Informative References [I-D.tomas-openroaming] Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work in Progress, Internet-Draft, draft-tomas-openroaming-00, 14 June 2023, <https://datatracker.ietf.org/doc/html/ draft-tomas-openroaming-00>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, <https://www.rfc-editor.org/info/rfc4119>. [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4676, DOI 10.17487/RFC4676, October 2006, <https://www.rfc-editor.org/info/rfc4676>. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, <https://www.rfc-editor.org/info/rfc5222>. [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, DOI 10.17487/RFC5985, September 2010, <https://www.rfc-editor.org/info/rfc5985>. [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, DOI 10.17487/RFC6225, July 2011, <https://www.rfc-editor.org/info/rfc6225>. [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, DOI 10.17487/RFC6442, December 2011, <https://www.rfc-editor.org/info/rfc6442>. Gundavelli & Grayson Expires 14 July 2024 [Page 20]
Internet-Draft Emergency Communication Services January 2024 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2011, <https://www.rfc-editor.org/info/rfc6443>. [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <https://www.rfc-editor.org/info/rfc6881>. [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, <https://www.rfc-editor.org/info/rfc7852>. [RFC8876] Rosen, B., Schulzrinne, H., Tschofenig, H., and R. Gellens, "Non-interactive Emergency Calls", RFC 8876, DOI 10.17487/RFC8876, September 2020, <https://www.rfc-editor.org/info/rfc8876>. [TS23501] 23.501, 3. T., "Numbering, addressing and identification", 2021. Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America Email: sgundave@cisco.com Mark Grayson Cisco 11 New Square Park Bedfont Lakes United Kingdom Email: mgrayson@cisco.com Gundavelli & Grayson Expires 14 July 2024 [Page 21]