summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7406.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7406.txt')
-rw-r--r--doc/rfc/rfc7406.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc7406.txt b/doc/rfc/rfc7406.txt
new file mode 100644
index 0000000..c148492
--- /dev/null
+++ b/doc/rfc/rfc7406.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) H. Schulzrinne
+Request for Comments: 7406 Columbia University
+Category: Informational S. McCann
+ISSN: 2070-1721 BlackBerry Ltd
+ G. Bajko
+ MediaTek
+ H. Tschofenig
+
+ D. Kroeselberg
+ Siemens Corporate Technology
+ December 2014
+
+
+ Extensions to the Emergency Services Architecture for Dealing With
+ Unauthenticated and Unauthorized Devices
+
+Abstract
+
+ This document provides a problem statement, introduces terminology,
+ and describes an extension for the base IETF emergency services
+ architecture to address cases where an emergency caller is not
+ authenticated, has no identifiable service provider, or has no
+ remaining credit with which to pay for access to the network.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7406.
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 1]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+ (http://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 Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Use-Case Categories . . . . . . . . . . . . . . . . . . . . . 5
+ 4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 5.1. End-Host Profile . . . . . . . . . . . . . . . . . . . . 15
+ 5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 15
+ 5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 15
+ 5.1.3. Location Determination and Location Configuration . . 15
+ 5.1.4. Emergency Call Identification . . . . . . . . . . . . 15
+ 5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 15
+ 5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 16
+ 5.2.2. Location Determination and Location Configuration . . 16
+ 5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 16
+ 5.3.2. Emergency Call Identification . . . . . . . . . . . . 16
+ 5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 17
+ 6. Lower-Layer Considerations for NAA Case . . . . . . . . . . . 17
+ 6.1. Link-Layer Emergency Indication . . . . . . . . . . . . . 18
+ 6.2. Securing Network Attachment in NAA Cases . . . . . . . . 19
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 22
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 2]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+1. Introduction
+
+ Summoning police, the fire department, or an ambulance in emergencies
+ is one of the fundamental and most-valued functions of the telephone.
+ As telephony functionality moves from circuit-switched telephony to
+ Internet telephony, its users rightfully expect that this core
+ functionality will continue to work at least as well as it has for
+ the older technology. New devices and services are being made
+ available that could be used to make a request for help; those
+ devices are not traditional telephones, and users are increasingly
+ expecting them to be able to place emergency calls.
+
+ Roughly speaking, the IETF emergency services architecture (see
+ [RFC6881] and [RFC6443]) divides responsibility for handling
+ emergency calls among the access network (Internet Access Provider
+ (IAP) or ISP); the application service provider (ASP), which may be a
+ VoIP service provider (VSP); and the provider of emergency signaling
+ services, the emergency service network (ESN). The access network
+ may provide location information to end systems but does not have to
+ provide any ASP signaling functionality. The emergency caller can
+ reach the ESN either directly or through the ASP's outbound proxy.
+ Any of the three parties can provide the mapping from location to the
+ Public Safety Answering Point (PSAP) URI by offering Location-to-
+ Service Translation (LoST) [RFC5222] services.
+
+ In general, a set of automated configuration mechanisms allows a
+ device to function in a variety of architectures, without the user
+ being aware of the details on who provides location, mapping
+ services, or call-routing services. However, if emergency calling is
+ to be supported when the calling device lacks access network
+ authorization or does not have an ASP, one or more of the providers
+ may need to provide additional services and functions.
+
+ In all cases, the end device has to be able to perform a LoST lookup
+ and otherwise conduct the emergency call in the same manner as when
+ the three exceptional conditions discussed below do not apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 3]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ We distinguish among three conditions:
+
+ No Access Authentication (NAA): In the NAA case, the emergency
+ caller does not posses valid credentials for the access network.
+ This includes the case where the access network allows
+ pay-per-use, as is common for wireless hotspots, but there is
+ insufficient time to enter credit card details and other
+ registration information required for access. It also covers all
+ cases where either no credentials are available at all or the
+ available credentials do not work for the given IAP/ISP. As a
+ result, the NAA case basically combines the No ASP (NASP) and
+ zero-balance ASP (ZBP) cases below, but at the IAP/ISP level.
+ Support for emergency call handling in the NAA case is subject to
+ the local policy of the ISP. Such policy may vary substantially
+ between ISPs and typically depends on external factors that are
+ not under the ISP control.
+
+ No ASP (NASP): The caller does not have an ASP at the time of the
+ call. This can occur in case the caller either does not possess
+ any valid subscription for a reachable ASP or does possess a valid
+ subscription but none of the ASPs are reachable through the ISP.
+
+ Note: The interoperability need is increased with this scenario
+ since the client software used by the emergency caller must be
+ compatible with the protocols and extensions deployed by the ESN.
+
+ Zero-balance ASP (ZBP): In the case of a zero-balance ASP, the ASP
+ can authenticate the caller, but the caller is not authorized to
+ use ASP services, e.g., because the contract has expired or the
+ prepaid account for the customer has been depleted.
+
+ These three cases are not mutually exclusive. A caller in need of
+ help may, for example, be both in an NAA and NASP situation, as
+ explained in more detail in Figure 1. Depending on local policy and
+ regulations, it may not be possible to place emergency calls in the
+ NAA case. Unless local regulations require user identification, it
+ should always be possible to place calls in the NASP case, with
+ minimal impact on the ISP. Unless the ESN requires that all calls
+ traverse a known set of Voice Service Providers (VSPs), it is
+ technically possible to let a caller place an emergency call in the
+ ZBP case. We discuss each case in more detail in Section 3.
+
+ Some of the functionality provided in this document is already
+ available in the Public Switched Telephone Network (PSTN).
+ Consequently, there is real-world experience available and not all of
+ it is positive. For example, the functionality of calls without
+ Subscriber Identity Modules (SIMs) in today's cellular system has
+ lead to a fair amount of hoax or test calls in certain countries.
+
+
+
+Schulzrinne, et al. Informational [Page 4]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ This causes overload situations at PSAPs, which is considered harmful
+ to the overall availability and reliability of emergency services.
+
+ As an example, the Federal Office of Communications (OFCOM,
+ Switzerland) provided statistics about emergency (112) calls in
+ Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not
+ offer SIM-less emergency calls except for almost a month in July
+ 2000 where a significant increase in hoax and test calls was
+ reported. As a consequence, the functionality was disabled again.
+ More details can be found in the panel presentations of the 3rd
+ Standards Development Organization (SDO) Emergency Services
+ Workshop [esw07].
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+ This document reuses terminology from [RFC5687] and [RFC5012], namely
+ Internet Access Provider (IAP), Internet Service Provider (ISP),
+ Application Service Provider (ASP), Voice Service Provider (VSP),
+ Emergency Service Routing Proxy (ESRP), Public Safety Answering Point
+ (PSAP), Location Configuration Server (LCS), (emergency) service dial
+ string, and (emergency) service identifier.
+
+3. Use-Case Categories
+
+ An end host needs to perform the following steps if it is not
+ attached to the network and the user is starting to place an
+ emergency call:
+
+ Link-Layer Attachment: Some networks have added support for
+ unauthenticated emergency access while others have advertised
+ these capabilities using layer beacons (multicast or broadcast
+ announcements). The end host learns about these unauthenticated
+ emergency services capabilities from either the link layer type or
+ advertisement.
+
+ The end host uses the link-layer-specific network attachment
+ procedures defined for unauthenticated network access in order to
+ get access to the network.
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 5]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ Pre-emergency Service Configuration: When the link-layer network
+ attachment procedure is completed, the end host learns basic
+ configuration information using DHCP from the ISP. The end host
+ uses a Location Configuration Protocol (LCP) to retrieve location
+ information. Subsequently, the LoST protocol [RFC5222] is used to
+ learn the relevant emergency numbers and to obtain the PSAP URI
+ applicable for that location.
+
+ Emergency Call: In case of the need for help, a user dials an
+ emergency number and the SIP User Agent (UA) initiates the
+ emergency call procedures by communicating with the PSAP.
+
+ Figure 1 compiles the basic logic taking place during network entry
+ for requesting an emergency service and shows the interrelation
+ between the three conditions described earlier.
+
+
+ +-----Y
+ |Start|
+ `...../
+ |
+ | Are credentials
+ | for network attachment
+ | available?
+ |
+ NO v YES
+ +----------------------------+
+ | |
+ | |
+ V v
+ .............. ................
+ | Idle: Wait | |Execute |
+ | for ES Call| |LLA Procedures|
+ | Initiation | "--------------'
+ "------------' |
+ Is | +---------->O
+ emergency | | | Is ASP
+ service | NO +-----Y | | configured?
+ network +--->| End | | +---------------+
+ attachment| `...../ | YES | | NO
+ possible? | | | |
+ v | v v
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 6]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ +------------+ | +------------+ +------------+
+ | Execute | | | Execute | | Execute |
+ | NAA |--------+ | Phone BCP | | NASP |
+ | Procedures | | Procedures | | Procedures |
+ +------------+ +------------+ +------------+
+ Authorization for| |
+ making an | |
+ emergency call | |
+ with the ASP/VSP?| |
+ +--------------+ v
+ | NO | YES +-----Y
+ | | | Done|
+ v v `...../
+ +------------+ +------------+
+ | Execute | | Execute |
+ | ZBP | | Phone BCP |
+ | Procedures | | Procedures |
+ +------------+ +------------+
+ | |
+ | |
+ v v
+ +-----Y +-----Y
+ | Done| | Done|
+ `...../ `...../
+
+ Abbreviations:
+ LLA: Link-Layer Attachment
+ ES: Emergency Services
+
+ Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 7]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ The diagrams below highlight the most important steps for the three
+ cases.
+
+ +-----Y
+ |Start|
+ `...../
+ |
+ | No
+ | credentials
+ | for network access
+ | available
+ v
+ ..............
+ | Idle: Wait |
+ | for ES Call|
+ | Initiation |
+ "------------'
+ |
+ |
+ |
+ v
+ --
+ // --
+ / --
+ // Is --
+ / emergency --
+ | service | NO +--------+
+ | network |------>| Call |
+ | attachment | Failed |
+ \ possible? / `......../
+ \ //
+ \\ //
+ \ //
+ \--/
+ |
+ | YES
+ |
+ |
+ v
+ +------------+
+ | Execute |
+ | NAA |
+ | Procedures |
+ +------------+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 8]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ |
+ | Network
+ | attachment
+ | in progress
+ v
+ /--\ Continue
+ | | with
+ | | application-layer
+ \--/ interaction
+
+ Figure 2: Flow Diagram: NAA Scenario
+
+
+ +-----+
+ +------------|Start|-----------------+
+ | `...../ |
+ v v
+ +------------+ +----------------+
+ | NAA | | Regular |
+ | Procedures | | Network Access |
+ +------------+ | Procedures |
+ | +----------------+
+ | |
+ | |
+ ----------------o--------------------+
+ |
+ |
+ |
+ |
+ Network
+ Attachment
+ Completed
+ |
+ |
+ |
+ |
+ v
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 9]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ +------------+ +---------+
+ | ASP | NO | See |
+ | Configured?|----->| main |
+ +------------+ | diagram |
+ | `........./
+ |
+ | YES
+ |
+ v
+ //----
+ / --
+ // --
+ / - +---------+
+ | Authorization| YES | See |
+ | for making |------>| main |
+ | ES call | | diagram |
+ \ with / `........./
+ \ VSP/ASP? //
+ \\ //
+ \ //
+ \--/
+ |
+ | NO
+ |
+ |
+ v
+ +------------+
+ | Execute |
+ | ZBP |
+ | Procedures |
+ +------------+
+ |
+ | Call
+ | in progress
+ |
+ v
+ +--------+
+ | Call |
+ Success|
+ `......../
+
+ Figure 3: Flow Diagram: ZBP Scenario
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 10]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ +-----+
+ +------------|Start|-----------------+
+ | `...../ |
+ v v
+ +------------+ +----------------+
+ | NAA | | Regular |
+ | Procedures | | Network Access |
+ +------------+ | Procedures |
+ | +----------------+
+ | |
+ | |
+ ----------------o--------------------+
+ |
+ |
+ |
+ |
+ Network
+ Attachment
+ Completed
+ |
+ |
+ |
+ |
+ v
+ +------------+ +---------+
+ | ASP | YES | See |
+ | Configured?|----->| main |
+ +------------+ | diagram |
+ | `........./
+ |
+ | NO
+ |
+ v
+ +------------+
+ | Execute |
+ | NASP |
+ | Procedures |
+ +------------+
+ |
+ | Call
+ | in progress
+ |
+ v
+ +--------+
+ | Call |
+ | Success|
+ `......../
+ Figure 4: Flow Diagram: NASP Scenario
+
+
+
+Schulzrinne, et al. Informational [Page 11]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ The NAA procedures are described in Section 6. The ZBP procedures
+ are described in Section 4. The NASP procedures are described in
+ Section 5. The Phone BCP procedures are described in [RFC6881]. The
+ LLA procedures are not described in this document since they are
+ specific to the link-layer technology in use.
+
+4. ZBP Considerations
+
+ ZBP includes all cases where a subscriber is known to an ASP but
+ lacks the necessary authorization to access regular ASP services.
+ Example ZBP cases include empty prepaid accounts, barred accounts,
+ roaming and mobility restrictions, or any other conditions set by ASP
+ policy.
+
+ Local regulation might demand that emergency calls cannot proceed
+ without successful service authorization. In some regulatory
+ regimes, however, it may be possible to allow emergency calls to
+ continue despite authorization failures. To distinguish an emergency
+ call from a regular call, an ASP can identify emergency sessions by
+ inspecting the service URN [RFC5031] used in call setup. The ZBP
+ case, therefore, only affects the ASP.
+
+ Permitting a call despite authorization failures could present an
+ opportunity for abuse. The ASP may choose to verify the destination
+ of the emergency calls and to only permit calls to certain,
+ preconfigured entities (e.g., to local PSAPs). Section 7 discusses
+ this topic in more detail.
+
+ An ASP without a regulatory requirement to authorize emergency calls
+ can deny emergency call setup. Where an ASP does not authorize an
+ emergency call, the caller may be able to fall back to NASP
+ procedures.
+
+5. NASP Considerations
+
+ To start the description, we consider the sequence of steps that are
+ executed in an emergency call based on Figure 5.
+
+ o As an initial step, the devices attach to the network as shown in
+ step (1). This step is outside the scope of this section.
+
+ o When the link-layer network attachment procedure is completed, the
+ end host learns basic IP configuration information using DHCP from
+ the ISP, as shown in step (2).
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 12]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ o When the end host has configured the IP address, it starts an
+ interaction with the discovered LCS at the ISP, as shown in step
+ (3). In certain deployments, the ISP may need to interact with
+ the IAP. This protocol exchange is shown in step (4).
+
+ o Once location information is obtained, the end host triggers the
+ LoST protocol to obtain the address of the ESRP/PSAP. This is
+ shown in step (5).
+
+ o In step (6), the SIP UA initiates a SIP INVITE request towards the
+ indicated ESRP. The INVITE message contains all the necessary
+ parameters required by Section 5.1.5.
+
+ o The ESRP receives the INVITE and processes it according to the
+ description in Section 5.3.3.
+
+ o The ESRP routes the call to the PSAP, as shown in step (8),
+ potentially interacting with a LoST server first to determine the
+ route.
+
+ o The PSAP evaluates the initial INVITE and aims to complete the
+ call setup.
+
+ o Finally, when the call setup is completed, media traffic can be
+ exchanged between the PSAP and the SIP UA.
+
+ For brevity, the end-to-end SIP and media exchange between the PSAP
+ and SIP UA are not shown in Figure 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 13]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ +-------+
+ | PSAP |
+ | |
+ +-------+
+ ^
+ | (8)
+ |
+ +----------+(7) +----------+
+ | LoST |<-->| ESRP |
+ | Server | | |
+ +----------+ +----------+
+ ^ ^
+ +----------------+----------------|--------------+
+ | ISP | | |
+ |+----------+ | | +----------+|
+ || LCS-ISP | (3)| | | DHCP ||
+ || |<-+ | | | Server ||
+ |+----------+ | | | +----------+|
+ +-------^------+-+----------------|-----------^--+
+ +-------|------+-+----------------|-----------|--+
+ | IAP | (4) | |(5) | | |
+ | V | | | | |
+ |+----------+ | | | | |
+ || LCS-IAP | | | +--------+ | | |
+ || | | | | Link- | |(6) | |
+ |+----------+ | | | Layer | | | |
+ | | | | Device | | (2)| |
+ | | | +--------+ | | |
+ | | | ^ | | |
+ | | | | | | |
+ +--------------+-|-------|--------|-----------|--+
+ | | | | |
+ | | (1)| | |
+ | | | | |
+ | | | +----+ |
+ | | v | |
+ | | +----------+ |
+ | +->| End |<-------------+
+ +___>| Host |
+ +----------+
+
+ Figure 5: Architectural Overview
+
+ Note: Figure 5 does not indicate who operates the ESRP and the LoST
+ server. Various deployment options exist.
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 14]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+5.1. End-Host Profile
+
+5.1.1. LoST Server Discovery
+
+ The end host MUST discover a LoST server [RFC5222] using DHCP
+ [RFC5223] unless a LoST server has been provisioned using other
+ means.
+
+5.1.2. ESRP Discovery
+
+ The end host MUST discover the ESRP using the LoST protocol [RFC5222]
+ unless a ESRP has been provisioned using other means.
+
+5.1.3. Location Determination and Location Configuration
+
+ The end host MUST support location acquisition and the LCPs described
+ in Section 6.5 of [RFC6881]. The description in Sections 6.5 and 6.6
+ of [RFC6881] regarding the interaction between the device and the
+ Location Information Server (LIS) applies to this document.
+
+ The SIP UA in the end host MUST attach available location information
+ in a Presence Information Data Format Location Object (PIDF-LO)
+ [RFC4119] when making an emergency call. When constructing the
+ PIDF-LO, the guidelines in the PIDF-LO profile [RFC5491] MUST be
+ followed. For civic location information, the format defined in
+ [RFC5139] MUST be supported.
+
+5.1.4. Emergency Call Identification
+
+ To determine which calls are emergency calls, some entity needs to
+ map a user-entered dial string into this URN scheme. A user may
+ "dial" 1-1-2, 9-1-1, etc., but the call would be sent to
+ urn:service:sos. This mapping SHOULD be performed at the endpoint
+ device.
+
+ End hosts MUST use the Service URN mechanism [RFC5031] to mark calls
+ as emergency calls for their home emergency dial string.
+
+5.1.5. SIP Emergency Call Signaling
+
+ SIP signaling capabilities [RFC3261] are REQUIRED for end hosts.
+
+ The initial SIP signaling method is an INVITE. The SIP INVITE
+ request MUST be constructed according to the requirements in
+ Section 9.2 of [RFC6881].
+
+ To enable callbacks, SIP UAs SHOULD place a globally routable URI in
+ a Contact header field.
+
+
+
+Schulzrinne, et al. Informational [Page 15]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+5.1.6. Media
+
+ Endpoints MUST comply with the media requirements for endpoints
+ placing an emergency call as described in Section 14 of [RFC6881].
+
+5.1.7. Testing
+
+ The description in Section 15 of [RFC6881] is fully applicable to
+ this document.
+
+5.2. IAP/ISP Profile
+
+5.2.1. ESRP Discovery
+
+ An ISP MUST provision a DHCP server with information about LoST
+ servers [RFC5223]. An ISP operator may choose to deploy a LoST
+ server or to outsource it to other parties.
+
+5.2.2. Location Determination and Location Configuration
+
+ The ISP is responsible for location determination and exposes this
+ information to the endpoints via location configuration protocols.
+ The considerations described in [RFC6444] are applicable to this
+ document.
+
+ The ISP MUST support one of the LCPs described in Section 6.5 of
+ [RFC6881]. The description in Sections 6.5 and 6.6 of [RFC6881]
+ regarding the interaction between the end device and the LIS applies
+ to this document.
+
+ The interaction between the LIS at the ISP and the IAP is often
+ proprietary, but the description in [LIS] may be relevant to the
+ reader.
+
+5.3. ESRP Profile
+
+5.3.1. Emergency Call Routing
+
+ The ESRP continues to route the emergency call to the PSAP
+ responsible for the physical location of the end host. This may
+ require further interactions with LoST servers but depends on the
+ specific deployment.
+
+5.3.2. Emergency Call Identification
+
+ The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,
+ the 'urn:service:sos' tree).
+
+
+
+
+Schulzrinne, et al. Informational [Page 16]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+5.3.3. SIP Emergency Call Signaling
+
+ SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The
+ ESRP MUST process the messages sent by the client, according to
+ Section 5.1.5.
+
+ Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT
+ restrict incoming calls to a particular set of ASPs.
+
+6. Lower-Layer Considerations for NAA Case
+
+ Some networks have added support for unauthenticated emergency access
+ while others have advertised these capabilities using layer beacons.
+ The end host learns about these unauthenticated emergency services
+ capabilities either from the link-layer type or from advertisement.
+
+ It is important to highlight that the NAA case is inherently a Layer
+ 2 problem, and the general form of the solution is to provide an
+ "emergency only" access type, with appropriate limits or monitoring
+ to prevent abuse. The described mechanisms are informative in nature
+ since the relationship to the IETF emergency services architecture is
+ only indirect, namely via some protocols developed within the IETF
+ (e.g., EAP and EAP methods) that require extensions to support this
+ functionality.
+
+ This section discusses different methods to indicate an emergency
+ service request as part of network attachment. It provides some
+ general considerations and recommendations that are not specific to
+ the access technology.
+
+ To perform network attachment and get access to the resources
+ provided by an IAP/ISP, the end host uses access technology-specific
+ network attachment procedures, including, for example, network
+ detection and selection, authentication, and authorization. For
+ initial network attachment of an emergency service requester, the
+ method of how the emergency indication is given to the IAP/ISP is
+ specific to the access technology. However, a number of general
+ approaches can be identified:
+
+ Link-layer emergency indication: The end host provides an
+ indication, e.g., an emergency parameter or flag, as part of the
+ link-layer signaling for initial network attachment. Examples
+ include an emergency bit signaled in the IEEE 802.16-2009 wireless
+ link. In IEEE 802.11 WLAN [IEEE802.11], an emergency support
+ indicator allows the station (i.e., end host in this context) to
+ download before association to a Network Access Identifier (NAI),
+ which it can use to request server-side authentication only for an
+ IEEE 802.1X network.
+
+
+
+Schulzrinne, et al. Informational [Page 17]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ Higher-layer emergency indication: Typically, emergency indication
+ is provided in the network access authentication procedure. The
+ emergency caller's end host provides an indication as part of the
+ access authentication exchanges. Authentication via the EAP
+ [RFC3748] is of particular relevance here. Examples are the EAP
+ NAI decoration used in Worldwide Interoperability for Microwave
+ Access (WiMAX) networks and modification of the authentication
+ exchange in IEEE 802.11 [nwgstg3].
+
+6.1. Link-Layer Emergency Indication
+
+ In general, link-layer emergency indications provide good integration
+ into the actual network access procedure regarding the enabling of
+ means to recognize and prioritize an emergency service request from
+ an end host at a very early stage of the network attachment
+ procedure. However, support in end hosts for such methods cannot be
+ considered to be commonly available.
+
+ No general recommendations are given in the scope of this memo due to
+ the following reasons:
+
+ o Dependency on the specific access technology.
+
+ o Dependency on the specific access network architecture. Access
+ authorization and policy decisions typically happen at different
+ layers of the protocol stack and in different entities than those
+ terminating the link-layer signaling. As a result, link-layer
+ indications need to be distributed and translated between the
+ different protocol layers and entities involved. Appropriate
+ methods are specific to the actual architecture of the IAP/ISP
+ network.
+
+ o An advantage of combining emergency indications with the actual
+ network attachment procedure performing authentication and
+ authorization is the fact that the emergency indication can
+ directly be taken into account in the authentication and
+ authorization server that owns the policy for granting access to
+ the network resources. As a result, there is no direct dependency
+ on the access network architecture that otherwise would need to
+ take care of merging link-layer indications into the
+ authentication, authorization, and policy decision process.
+
+ o EAP signaling happens at a relatively early stage of network
+ attachment, so it is likely to match most requirements for
+ prioritization of emergency signaling. However, it does not cover
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 18]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ early stages of link-layer activity in the network attachment
+ process. Possible conflicts may arise, e.g., in case of filtering
+ based on Media Access Control (MAC) in entities terminating link-
+ layer signaling in the network (like a base station). In normal
+ operation, EAP-related information will only be recognized in the
+ Network Access Server (NAS). Any entity residing between the end
+ host and NAS should not be expected to understand/parse EAP
+ messages.
+
+ o An emergency indication can be given by forming a specific NAI
+ that is used as the identity in EAP-based authentication for
+ network entry.
+
+6.2. Securing Network Attachment in NAA Cases
+
+ For network attachment in NAA cases, it may make sense to secure the
+ link-layer connection between the device and the IAP/ISP. This
+ especially holds for wireless access with examples being access based
+ on IEEE 802.11 or IEEE 802.16. The latter even mandates secured
+ communication across the wireless link for all IAP/ISP networks based
+ on [nwgstg3].
+
+ Therefore, for network attachment that is by default based on EAP
+ authentication, it is desirable also for NAA network attachment to
+ use a key-generating EAP method (that provides a Master Session Key
+ (MSK) to the authenticator to bootstrap further key derivation for
+ protecting the wireless link).
+
+ To match the above, the following approaches can be identified:
+
+ 1) Server-Only Authentication:
+
+ The device of the emergency service requester performs an EAP
+ method with the IAP/ISP EAP server that performs server-side
+ authentication only. An example for this is EAP-TLS [RFC5216].
+ This provides a certain level of assurance about the IAP/ISP to
+ the device user. It requires the device to be provisioned with
+ appropriate trusted root certificates to be able to verify the
+ server certificate of the EAP server (unless this step is
+ explicitly skipped in the device in case of an emergency service
+ request). This method is used to provide access of devices
+ without existing credentials to an IEEE 802.1X network. The
+ details are incorporated in the IEEE 802.11-2012 specification
+ [IEEE802.11].
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 19]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ 2) Null Authentication:
+
+ In one case (e.g., WiMAX), an EAP method is performed. However,
+ no credentials specific to either the server or the device or
+ subscription are used as part of the authentication exchange. An
+ example for this would be an EAP-TLS exchange using the
+ TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly
+ available static key for emergency access could be used. In the
+ latter case, the device would need to be provisioned with the
+ appropriate emergency key for the IAP/ISP in advance. In another
+ case (e.g., IEEE 802.11), no EAP method is used, so that empty
+ frames are transported during the over-the-air IEEE 802.1X
+ exchange. In this case, the authentication state machine
+ completes with no cryptographic keys being exchanged.
+
+ 3) Device Authentication:
+
+ This case extends the server-only authentication case. If the
+ device is configured with a device certificate and the IAP/ISP EAP
+ server can rely on a trusted root allowing the EAP server to
+ verify the device certificate, at least the device identity (e.g.,
+ the MAC address) can be authenticated by the IAP/ISP in NAA cases.
+ An example for this is WiMAX devices that are shipped with device
+ certificates issued under the global WiMAX device public-key
+ infrastructure. To perform unauthenticated emergency calls, if
+ allowed by the IAP/ISP, such devices perform network attachment
+ based on EAP-TLS with client authentication based on the device
+ certificate.
+
+7. Security Considerations
+
+ The security threats discussed in [RFC5069] are applicable to this
+ document.
+
+ The NASP and NAA cases introduce new vulnerabilities since the PSAP
+ operator will typically not have any information about the identity
+ of the caller via the signaling path. Today, in countries where this
+ functionality is used for Global System for Mobile Communications
+ (GSM) networks, this has lead to a significant amount of misuse.
+
+ In the context of NAA, the IAP and the ISP will probably want to make
+ sure that the claimed emergency caller indeed performs an emergency
+ call rather than using the network for other purposes, and thereby
+ acting fraudulent by skipping any authentication, authorization, and
+ accounting procedures. By restricting access of the unauthenticated
+ emergency caller to the LoST server and the PSAP URI, traffic can be
+ restricted only to emergency calls. This can be accomplished with
+ traffic separation. However, the details, e.g., for using filtering,
+
+
+
+Schulzrinne, et al. Informational [Page 20]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ depend on the deployed ISP architecture and are beyond the scope of
+ this document.
+
+ We only illustrate a possible model. If the ISP runs its own
+ (caching) LoST server, the ISP would maintain an access control list
+ populated with IP-address information obtained from LoST responses
+ (in the mappings). These URIs would either be URIs for contacting
+ further LoST servers or PSAP URIs. It may be necessary to translate
+ domain names returned in LoST responses to IP addresses. Since the
+ media destination addresses are not predictable, the ISP also has to
+ provide a SIP outbound proxy so that it can determine the media
+ addresses and add those to the filter list.
+
+ For the ZBP case, the additional aspect of fraud has to be
+ considered. Unless the emergency call traverses a PSTN gateway or
+ the ASP charges for IP-to-IP calls, there is little potential for
+ fraud. If the ASP also operates the LoST server, the outbound proxy
+ MAY restrict outbound calls to the SIP URIs returned by the LoST
+ server. It is NOT RECOMMENDED to rely on a fixed list of SIP URIs,
+ as that list may change.
+
+ RFC 6280 [RFC6280] discusses security vulnerabilities that are caused
+ by an adversary faking location information and thereby lying about
+ the actual location of the emergency caller. These threats may be
+ less problematic in the context of an unauthenticated emergency when
+ location information can be verified by the ISP to fall within a
+ specific geographical area.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002, <http://www.rfc-editor.org/info/rfc3261>.
+
+ [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
+ Format", RFC 4119, December 2005,
+ <http://www.rfc-editor.org/info/rfc4119>.
+
+ [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
+ Emergency and Other Well-Known Services", RFC 5031,
+ January 2008, <http://www.rfc-editor.org/info/rfc5031>.
+
+
+
+Schulzrinne, et al. Informational [Page 21]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
+ Format for Presence Information Data Format Location
+ Object (PIDF-LO)", RFC 5139, February 2008,
+ <http://www.rfc-editor.org/info/rfc5139>.
+
+ [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
+ Tschofenig, "LoST: A Location-to-Service Translation
+ Protocol", RFC 5222, August 2008,
+ <http://www.rfc-editor.org/info/rfc5222>.
+
+ [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
+ Location-to-Service Translation (LoST) Servers Using the
+ Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
+ August 2008, <http://www.rfc-editor.org/info/rfc5223>.
+
+ [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
+ Presence Information Data Format Location Object (PIDF-LO)
+ Usage Clarification, Considerations, and Recommendations",
+ RFC 5491, March 2009,
+ <http://www.rfc-editor.org/info/rfc5491>.
+
+ [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
+ Communications Services in Support of Emergency Calling",
+ BCP 181, RFC 6881, March 2013,
+ <http://www.rfc-editor.org/info/rfc6881>.
+
+8.2. Informative References
+
+ [IEEE802.11]
+ IEEE, "IEEE Standard for Information Technology -
+ Telecommunications and information exchange between
+ systems - Local and metropolitan area networks - Specific
+ requirements Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) Specifications", IEEE Std
+ 802.11-2012, March 2012,
+ <http://standards.ieee.org/about/get/802/802.11.html>.
+
+ [LIS] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
+ Requirements", Work in Progress, draft-winterbottom-
+ geopriv-lis2lis-req-01, November 2007.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
+ 3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 22]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+ [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
+ Emergency Context Resolution with Internet Technologies",
+ RFC 5012, January 2008,
+ <http://www.rfc-editor.org/info/rfc5012>.
+
+ [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
+ Shanmugam, "Security Threats and Requirements for
+ Emergency Call Marking and Mapping", RFC 5069, January
+ 2008, <http://www.rfc-editor.org/info/rfc5069>.
+
+ [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
+ Authentication Protocol", RFC 5216, March 2008,
+ <http://www.rfc-editor.org/info/rfc5216>.
+
+ [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
+ Location Configuration Protocol: Problem Statement and
+ Requirements", RFC 5687, March 2010,
+ <http://www.rfc-editor.org/info/rfc5687>.
+
+ [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+ Tschofenig, H., and H. Schulzrinne, "An Architecture for
+ Location and Location Privacy in Internet Applications",
+ BCP 160, RFC 6280, July 2011,
+ <http://www.rfc-editor.org/info/rfc6280>.
+
+ [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
+ "Framework for Emergency Calling Using Internet
+ Multimedia", RFC 6443, December 2011,
+ <http://www.rfc-editor.org/info/rfc6443>.
+
+ [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and
+ A. Kuett, "Location Hiding: Problem Statement and
+ Requirements", RFC 6444, January 2012,
+ <http://www.rfc-editor.org/info/rfc6444>.
+
+ [esw07] "3rd Standards Development Organziations (SDO) Emergency
+ Services Workshop", October 30th - November 1st 2007,
+ <http://www.emergency-services-
+ coordination.info/2007Nov/>.
+
+ [nwgstg3] WiMAX Forum, "WiMAX Forum Network Architecture - Detailed
+ Protocols and Procedures Base Specification", Stage-3 WMF-
+ T33-001-R022V02, April 2014, <http://resources.wimaxforum.
+ org/sites/wimaxforum.org/files/technical_document/2014/05/
+ WMF-T33-001-R022v02_Network-Stage3-Base.pdf>.
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 23]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+Acknowledgments
+
+ Parts of this document are derived from [RFC6881]. Participants of
+ the 2nd and 3rd SDO Emergency Services Workshop provided helpful
+ input.
+
+ We would like to thank Richard Barnes, Marc Linsner, James Polk,
+ Brian Rosen, and Martin Thomson for their feedback at the IETF#80
+ Emergency Context Resolution with Internet Technology (ECRIT)
+ meeting.
+
+ Furthermore, we would like to thank Martin Thomson and Bernard Aboba
+ for their detailed document review in preparation of the 81st IETF
+ meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A
+ number of changes to the document had been made in response to the AD
+ review by Richard Barnes.
+
+ Various IESG members provided review comments, including Spencer
+ Dawkins, Stephen Farrell, Joel Jaeggli, Barry Leiba, Ted Lemon, and
+ Pete Resnick.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 24]
+
+RFC 7406 Unauthenticated Emergency Service December 2014
+
+
+Authors' Addresses
+
+ Henning Schulzrinne
+ Columbia University
+ Department of Computer Science
+ 450 Computer Science Building
+ New York, NY 10027
+ United States
+
+ Phone: +1 212 939 7004
+ EMail: hgs+ecrit@cs.columbia.edu
+ URI: http://www.cs.columbia.edu
+
+
+ Stephen McCann
+ BlackBerry Ltd
+ 200 Bath Road
+ Slough, Berks SL1 3XE
+ United Kingdom
+
+ Phone: +44 1753 667099
+ EMail: smccann@blackberry.com
+ URI: http://www.blackberry.com
+
+
+ Gabor Bajko
+ MediaTek
+
+ EMail: gabor.bajko@mediatek.com
+
+
+ Hannes Tschofenig
+ Hall in Tirol 6060
+ Austria
+
+ EMail: Hannes.Tschofenig@gmx.net
+ URI: http://www.tschofenig.priv.at
+
+
+ Dirk Kroeselberg
+ Siemens Corporate Technology
+ Otto-Hahn-Ring 6
+ Munich 81739
+ Germany
+
+ EMail: dirk.kroeselberg@siemens.com
+
+
+
+
+
+Schulzrinne, et al. Informational [Page 25]
+