idnits 2.17.00 (12 Aug 2021) /tmp/idnits2904/draft-ietf-ecrit-unauthenticated-access-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2013) is 3234 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Standards Track S. McCann 5 Expires: January 14, 2014 Research in Motion UK Ltd 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 Nokia Siemens Networks 10 D. Kroeselberg 11 Siemens 12 July 13, 2013 14 Extensions to the Emergency Services Architecture for dealing with 15 Unauthenticated and Unauthorized Devices 16 draft-ietf-ecrit-unauthenticated-access-07.txt 18 Abstract 20 The IETF emergency services architecture assumes that the calling 21 device has acquired rights to use the access network or that no 22 authentication is required for the access network, such as for public 23 wireless access points. Subsequent protocol interactions, such as 24 obtaining location information, learning the address of the Public 25 Safety Answering Point (PSAP) and the emergency call itself are 26 largely decoupled from the underlying network access procedures. 28 In some cases, however, the device does not have these credentials 29 for network access, does not have a VoIP service provider, or the 30 credentials have become invalid, e.g., because the user has exhausted 31 their prepaid balance or the account has expired. 33 This document provides a problem statement, introduces terminology 34 and describes an extension for the base IETF emergency services 35 architecture to address these scenarios. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 14, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Use Case Categories . . . . . . . . . . . . . . . . . . . . . 5 74 4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 5.1. End Host Profile . . . . . . . . . . . . . . . . . . . . 10 77 5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 10 78 5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 10 79 5.1.3. Location Determination and Location Configuration . . 10 80 5.1.4. Emergency Call Identification . . . . . . . . . . . . 10 81 5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 10 82 5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 11 85 5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 11 86 5.2.2. Location Determination and Location Configuration . . 11 87 5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 11 88 5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 11 89 5.3.2. Emergency Call Identification . . . . . . . . . . . . 12 90 5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 12 91 6. Lower Layer Considerations for NAA Case . . . . . . . . . . . 12 92 6.1. Link Layer Emergency Indication . . . . . . . . . . . . . 13 93 6.2. Securing Network Attachment in NAA Cases . . . . . . . . 14 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 10.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 Summoning police, the fire department or an ambulance in emergencies 105 is one of the fundamental and most-valued functions of the telephone. 106 As telephone functionality moves from circuit-switched telephony to 107 Internet telephony, its users rightfully expect that this core 108 functionality will continue to work at least as well as it has for 109 the older technology. New devices and services are being made 110 available that could be used to make a request for help, which are 111 not traditional telephones, and users are increasingly expecting them 112 to be used to place emergency calls. 114 Roughly speaking, the IETF emergency services architecture (see 115 [RFC6881] and [RFC6443]) divides responsibility for handling 116 emergency calls between the access network (ISP), the application 117 service provider (ASP) that may be a VoIP service provider and the 118 provider of emergency signaling services, the emergency service 119 network (ESN). The access network may provide location information 120 to end systems, but does not have to provide any ASP signaling 121 functionality. The emergency caller can reach the ESN either 122 directly or through the ASP's outbound proxy. Any of the three 123 parties can provide the mapping from location to PSAP URI by offering 124 LoST [RFC5222] services. 126 In general, a set of automated configuration mechanisms allows a 127 device to function in a variety of architectures, without the user 128 being aware of the details on who provides location, mapping services 129 or call routing services. However, if emergency calling is to be 130 supported when the calling device lacks access network authorization 131 or does not have an ASP, one or more of the providers may need to 132 provide additional services and functions. 134 In all cases, the end device has to be able to perform a LoST lookup 135 and otherwise conduct the emergency call in the same manner as when 136 the three exceptional conditions discussed below do not apply. 138 We distinguish between three conditions: 140 No Access Authentication (NAA): In the NAA case, the emergency 141 caller does not posses valid credentials for the access network. 142 This includes the case where the access network allows pay-per- 143 use, as is common for wireless hotspots, but there is insufficient 144 time to enter credit card details and other registration 145 information required for access. It also covers all cases where 146 either no credentials are available at all, or the available 147 credentials do not work for the given IAP/ISP. As a result, the 148 NAA case basically combines the below NASP and ZBP cases, but at 149 the IAP/ISP level. Support for emergency call handling in the NAA 150 case is subject to the local policy of the ISP. Such policy may 151 vary substantially between ISPs and typically depends on external 152 factors that are not under the ISP control. 154 No ASP (NASP): The caller does not have an ASP at the time of the 155 call. This can occur either in case the caller does not possess 156 any valid subscription for a reachable ASP, or in case none of the 157 ASPs where the caller owns a valid subscription is reachable 158 through the ISP. 160 Note: The interoperability need is increased with this scenario 161 since the client software used by the emergency caller must be 162 compatible with the protocols and extensions deployed by the ESN. 164 Zero-balance ASP (ZBP): In the case of zero-balance ASP, the ASP can 165 authenticate the caller, but the caller is not authorized to use 166 ASP services, e.g., because the contract has expired or the 167 prepaid account for the customer has been depleted. 169 These three cases are not mutually exclusive. A caller in need for 170 help may find himself/herself in, for example, a NAA and NASP 171 situation, as explained in more details in Figure 1. Depending on 172 local policy and regulations, it may not be possible to place 173 emergency calls in the NAA case. Unless local regulations require 174 user identification, it should always be possible to place calls in 175 the NASP case, with minimal impact on the ISP. Unless the ESN 176 requires that all calls traverse a known set of VSPs, it is 177 technically possible to let a caller place an emergency call in the 178 ZBP case. We discuss each case in more details in Section 3. 180 Note: At the time of writing there is no regulation in place that 181 demands the functionality described in this memo. SDOs have started 182 their work on this subject in a proactive fashion in the anticipation 183 that national regulation will demand it for a subset of network 184 environments. 186 There are also indications that the functionality of unauthenticated 187 emergency calls (called SIM-less calls) in today's cellular system in 188 certain countries leads to a fair amount of hoax or test calls. This 189 causes overload situations at PSAPs which is considered harmful to 190 the overall availability and reliability of emergency services. 192 As an example, Federal Office of Communications (OFCOM, Switzerland) 193 provided statistics about emergency (112) calls in Switzerland from 194 Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less 195 emergency calls except for almost a month in July 2000 where a 196 significant increase in hoax and test calls was reported. As a 197 consequence, the functionality was disabled again. More details can 198 be found in the panel presentations of the 3rd SDO Emergency Services 199 Workshop [esw07]. 201 2. Terminology 203 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 204 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 205 and "OPTIONAL" are to be interpreted as described in RFC 2119 206 [RFC2119]. 208 This document reuses terminology from [RFC5687] and [RFC5012], namely 209 Internet Access Provider (IAP), Internet Service Provider (ISP), 210 Application Service Provider (ASP), Voice Service Provider (VSP), 211 Emergency Service Routing Proxy (ESRP), Public Safety Answering Point 212 (PSAP), Location Configuration Server (LCS), (emergency) service dial 213 string, and (emergency) service identifier. 215 3. Use Case Categories 217 On a very high-level, the steps to be performed by an end host not 218 being attached to the network and the user starting to make an 219 emergency call are the following: 221 Link Layer Attachment: Some radio networks have added support for 222 unauthenticated emergency access, some other type of networks 223 advertise these capabilities using layer beacons. The end host 224 learns about these unauthenticated emergency services capabilities 225 either from the link layer type or from advertisement. 227 The end host uses the link layer specific network attachment 228 procedures defined for unauthenticated network access in order to 229 get access to the network. 231 Pre-Emergency Service Configuration: When the link layer network 232 attachment procedure is completed the end host learns basic 233 configuration information using DHCP from the ISP. The end host 234 uses a Location Configuration Protocol (LCP) to retrieve location 235 information. Subsequently, the LoST protocol [RFC5222] is used to 236 learn the relevant emergency numbers, and to obtain the PSAP URI 237 applicable for that location. 239 Emergency Call: In case of need for help, a user dials an emergency 240 number and the SIP UA initiates the emergency call procedures by 241 communicating with the PSAP. 243 Figure 1 compiles the basic logic taking place during network entry 244 for requesting an emergency service and shows the interrelation 245 between the three conditions described in the above section. 247 +-----Y 248 |Start| 249 `...../ 250 | 251 | Are credentials 252 | for network attachment 253 | available? 254 | 255 NO v YES 256 +----------------------------+ 257 | | 258 | | 259 V v 260 .............. ................ 261 | Idle: Wait | |Execute | 262 | for ES Call| |LLA Procedures| 263 | Initiation | "--------------' 264 "------------' | 265 Is | +---------->O 266 emergency | | | Is ASP 267 service | NO +-----Y | | configured? 268 network +--->| End | | +---------------+ 269 attachment| `...../ | YES | | NO 270 possible? | | | | 271 v | v v 272 +------------+ | +------------+ +------------+ 273 | Execute | | | Execute | | Execute | 274 | NAA |--------+ | Phone BCP | | NASP | 275 | Procedures | | Procedures | | Procedures | 276 +------------+ +------------+ +------------+ 277 Authorization for| | 278 making an | | 280 emergency call | | 281 with the ASP/VSP?| | 282 +--------------+ v 283 | NO | YES +-----Y 284 | | | Done| 285 v v `...../ 286 +------------+ +------------+ 287 | Execute | | Execute | 288 | ZBP | | Phone BCP | 289 | Procedures | | Procedures | 290 +------------+ +------------+ 291 | | 292 | | 293 v v 294 +-----Y +-----Y 295 | Done| | Done| 296 `...../ `...../ 298 Abbreviations: 299 LLA: Link Layer Attachment 300 ES: Emergency Services 302 Figure 1: Flow Diagram 304 The "No Access Authentication (NAA)" procedures are described in 305 Section 6. The "Zero-balance ASP (ZBP)" procedures are described in 306 Section 4. The "No ASP (NASP)" procedures are described in 307 Section 5. The Phone BCP procedures are described in [RFC6881]. The 308 "Link Layer Attachment (LLA)" procedures are not described in this 309 document since they are specific to the link layer technology in use. 311 4. ZBP Considerations 313 ZBP includes all cases where a subscriber is known to an ASP, but 314 lacks the necessary authorization to access regular ASP services. 315 Example ZBP cases include empty prepaid accounts, barred accounts, 316 roaming and mobility restrictions, or any other conditions set by ASP 317 policy. 319 Local regulation might demand that emergency calls cannot proceed 320 without successful service authorization. In regulatory regimes, 321 however, it may be possible to allow emergency calls to continue 322 despite authorization failures. To distinguish an emergency call 323 from a regular call an ASP can identify emergency sessions by 324 inspecting the service URN [RFC5031] used in call setup. The ZBP 325 case therefore only affects the ASP. 327 Permitting a call despite authorization failures could present an 328 opportunity for abuse. The ASP may choose to verify the destination 329 of the emergency calls and to only permit calls to certain, pre- 330 configured entities (e.g., to local PSAPs). Section 7 discusses this 331 topic in more detail. 333 An ASP without a regulatory requirement to authorize emergency calls 334 can deny emergency call setup. Where an ASP does not authorize an 335 emergency call, the caller may be able to fall back to NASP 336 procedures. 338 5. NASP Considerations 340 To start the description we consider the sequence of steps that are 341 executed in an emergency call based on Figure 2. 343 o As an initial step the devices attaches to the network as shown in 344 step (1). This step is outside the scope of this section. 346 o When the link layer network attachment procedure is completed the 347 end host learns basic IP configuration information using DHCP from 348 the ISP, as shown in step (2). 350 o When the IP address configuration is completed then the end host 351 starts an interaction with the discovered Location Configuration 352 Server at the ISP, as shown in step (3). The ISP may in certain 353 deployments need to interact with the IAP. This protocol exchange 354 is shown in step (4). 356 o Once location information is obtained the end host triggers the 357 LoST protocol to obtain the address of the ESRP/PSAP. This step 358 is shown in (5). 360 o In step (6), the SIP UA initiates a SIP INVITE towards the 361 indicated ESRP. The INVITE message contains all the necessary 362 parameters required by Section 5.1.5. 364 o The ESRP receives the INVITE and processes it according to the 365 description in Section 5.3.3. 367 o The ESRP routes the call to the PSAP, as shown in (8), potentially 368 interacting with a LoST server first to determine the route. 370 o The PSAP evaluates the initial INVITE and aims to complete the 371 call setup. 373 o Finally, when the call setup is completed media traffic can be 374 exchanged between the PSAP and the SIP UA. 376 For editorial reasons the end-to-end SIP and media exchange between 377 the PSAP and SIP UA are not shown in Figure 2. 379 +-------+ 380 | PSAP | 381 | | 382 +-------+ 383 ^ 384 | (8) 385 | 386 +----------+(7) +----------+ 387 | LoST |<-->| ESRP | 388 | Server | | | 389 +----------+ +----------+ 390 ^ ^ 391 +----------------+----------------|--------------+ 392 | ISP | | | 393 |+----------+ | | +----------+| 394 || LCS-ISP | (3)| | | DHCP || 395 || |<-+ | | | Server || 396 |+----------+ | | | +----------+| 397 +-------^------+-+----------------|-----------^--+ 398 +-------|------+-+----------------|-----------|--+ 399 | IAP | (4) | |(5) | | | 400 | V | | | | | 401 |+----------+ | | | | | 402 || LCS-IAP | | | +--------+ | | | 403 || | | | | Link | |(6) | | 404 |+----------+ | | | Layer | | | | 405 | | | | Device | | (2)| | 406 | | | +--------+ | | | 407 | | | ^ | | | 408 | | | | | | | 409 +--------------+-|-------|--------|-----------|--+ 410 | | | | | 411 | | (1)| | | 412 | | | | | 413 | | | +----+ | 414 | | v | | 415 | | +----------+ | 416 | +->| End |<-------------+ 417 +___>| Host | 418 +----------+ 420 Figure 2: Architectural Overview 422 Note: Figure 2 does not indicate who operates the ESRP and the LoST 423 server. Various deployment options exist. 425 5.1. End Host Profile 427 5.1.1. LoST Server Discovery 429 The end host MUST discover a LoST server [RFC5222] using DHCP 430 [RFC5223]. 432 5.1.2. ESRP Discovery 434 The end host MUST discover the ESRP using the LoST protocol 435 [RFC5222]. 437 5.1.3. Location Determination and Location Configuration 439 The end host MUST support location acquisition and the LCPs described 440 in Section 6.5 of [RFC6881]. The description in Section 6.5 and 6.6 441 of [RFC6881] regarding the interaction between the device and the LIS 442 applies to this document. 444 The SIP UA in the end host MUST attach available location information 445 in a PIDF-LO [RFC4119] when making an emergency call. When 446 constructing the PIDF-LO the guidelines in PIDF-LO profile [RFC5491] 447 MUST be followed. For civic location information the format defined 448 in [RFC5139] MUST be supported. 450 5.1.4. Emergency Call Identification 452 To determine which calls are emergency calls, some entity needs to 453 map a user entered dialstring into this URN scheme. A user may 454 "dial" 1-1-2, 9-1-1, etc., but the call would be sent to 455 urn:service:sos. This mapping SHOULD be performed at the endpoint 456 device. 458 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 459 as emergency calls for their home emergency dial string. 461 5.1.5. SIP Emergency Call Signaling 463 SIP signaling capabilities [RFC3261] are mandated for end hosts. 465 The initial SIP signaling method is an INVITE. The SIP INVITE 466 request MUST be constructed according to the requirements in 467 Section 9.2 [RFC6881]. 469 Regarding callback behavior SIP UAs SHOULD place a globally routable 470 URI in a Contact: header. 472 5.1.6. Media 474 End points MUST comply with the media requirements for end points 475 placing an emergency call found in Section 14 of [RFC6881]. 477 5.1.7. Testing 479 The description in Section 15 of [RFC6881] is fully applicable to 480 this document. 482 5.2. IAP/ISP Profile 484 5.2.1. ESRP Discovery 486 An ISP MUST provision a DHCP server with information about LoST 487 servers [RFC5223]. An ISP operator may choose to deploy a LoST 488 server or to outsource it to other parties. 490 5.2.2. Location Determination and Location Configuration 492 The ISP is responsible for location determination and exposes this 493 information to the end points via location configuration protocols. 494 The considerations described in [RFC6444] are applicable to this 495 document. 497 The ISP MUST support one of the LCPs described in Section 6.5 of 498 [RFC6881]. The description in Section 6.5 and 6.6 of [RFC6881] 499 regarding the interaction between the end device and the LIS applies 500 to this document. 502 The interaction between the LIS at the ISP and the IAP is often 503 priorietary but the description in 504 [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. 506 5.3. ESRP Profile 508 5.3.1. Emergency Call Routing 510 The ESRP continues to route the emergency call to the PSAP 511 responsible for the physical location of the end host. This may 512 require further interactions with LoST servers but depends on the 513 specific deployment. 515 5.3.2. Emergency Call Identification 517 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 518 the 'urn:service:sos' tree). 520 5.3.3. SIP Emergency Call Signaling 522 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 523 ESRP MUST process the messages sent by the client, according to 524 Section 5.1.5. 526 6. Lower Layer Considerations for NAA Case 528 Some radio networks have added support for unauthenticated emergency 529 access, some other type of networks advertise these capabilities 530 using layer beacons. The end host learns about these unauthenticated 531 emergency services capabilities either from the link layer type or 532 from advertisement. 534 This section discusses different methods to indicate an emergency 535 service request as part of network attachment. It provides some 536 general considerations and recommendations that are not specific to 537 the access technology. 539 To perform network attachment and get access to the resources 540 provided by an IAP/ISP, the end host uses access technology specific 541 network attachment procedures, including for example network 542 detection and selection, authentication, and authorization. For 543 initial network attachment of an emergency service requester, the 544 method of how the emergency indication is given to the IAP/ISP is 545 specific to the access technology. However, a number of general 546 approaches can be identified: 548 Link layer emergency indication: The end host provides an 549 indication, e.g., an emergency parameter or flag, as part of the 550 link layer signaling for initial network attachment. Examples 551 include an emergency bit signalled in the IEEE 802.16-2009 552 wireless link. In IEEE 802.11 WLAN, an emergency support 553 indicator allows the STA to download before association an NAI 554 which it can use to request server side authentication only for an 555 802.1x network. 557 Higher-layer emergency indication: Typically emergency indication in 558 access authentication. The emergency caller's end host provides 559 an indication as part of the access authentication exchanges. EAP 560 based authentication is of particular relevance here. Examples 561 are the EAP NAI decoration used in WiMAX networks and modification 562 of the authentication exchange in IEEE 802.11. [nwgstg3]. 564 6.1. Link Layer Emergency Indication 566 In general, link layer emergency indications provide good integration 567 into the actual network access procedure regarding the enabling of 568 means to recognize and prioritize an emergency service request from 569 an end host at a very early stage of the network attachment 570 procedure. However, support in end hosts for such methods cannot be 571 considered to be commonly available. 573 No general recommendations are given in the scope of this memo due to 574 the following reasons: 576 o Dependency on the specific access technology. 578 o Dependency on the specific access network architecture. Access 579 authorization and policy decisions typically happen at a different 580 layers of the protocol stack and in different entities than those 581 terminating the link-layer signaling. As a result, link layer 582 indications need to be distributed and translated between the 583 different involved protocol layers and entities. Appropriate 584 methods are specific to the actual architecture of the IAP/ISP 585 network. 587 o An advantage of combining emergency indications with the actual 588 network attachment procedure performing authentication and 589 authorization is the fact that the emergency indication can 590 directly be taken into account in the authentication and 591 authorization server that owns the policy for granting access to 592 the network resources. As a result, there is no direct dependency 593 on the access network architecture that otherwise would need to 594 take care of merging link-layer indications into the AA and policy 595 decision process. 597 o EAP signaling happens at a relatively early stage of network 598 attachment, so it is likely to match most requirements for 599 prioritization of emergency signaling. However, it does not cover 600 early stages of link layer activity in the network attachment 601 process. Possible conflicts may arise e.g. in case of MAC-based 602 filtering in entities terminating the link-layer signaling in the 603 network (like a base station). In normal operation, EAP related 604 information will only be recognized in the NAS. Any entity 605 residing between end host and NAS should not be expected to 606 understand/parse EAP messages. 608 o An emergency indication can be given by forming a specific NAI 609 that is used as the identity in EAP based authentication for 610 network entry. 612 6.2. Securing Network Attachment in NAA Cases 614 For network attachment in NAA cases, it may make sense to secure the 615 link-layer connection between the device and the IAP/ISP. This 616 especially holds for wireless access with examples being IEEE 802.11 617 or IEEE 802.16 based access. The latter even mandates secured 618 communication across the wireless link for all IAP/ISP networks based 619 on [nwgstg3]. 621 Therefore, for network attachment that is by default based on EAP 622 authentication it is desirable also for NAA network attachment to use 623 a key-generating EAP method (that provides an MSK key to the 624 authenticator to bootstrap further key derivation for protecting the 625 wireless link). 627 The following approaches to match the above can be identified: 629 1) Server-only Authentication: 631 The device of the emergency service requester performs an EAP 632 method with the IAP/ISP EAP server that performs server side 633 authentication only. An example for this is EAP-TLS. This 634 provides a certain level of assurance about the IAP/ISP to the 635 device user. It requires the device to be provisioned with 636 appropriate trusted root certificates to be able to verify the 637 server certificate of the EAP server (unless this step is 638 explicitly skipped in the device in case of an emergency service 639 request). This method is used to provide access of devices 640 without existing credentials to an 802.1x network. The details 641 are incorporated into the not yet published 802.11-2011 642 specification. 644 2) Null Authentication: 646 In one case (e.g., WiMAX) an EAP method is performed. However, no 647 credentials specific to either the server or the device or 648 subscription are used as part of the authentication exchange. An 649 example for this would be an EAP-TLS exchange with using the 650 TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly 651 available static key for emergency access could be used. In the 652 latter case, the device would need to be provisioned with the 653 appropriate emergency key for the IAP/ISP in advance. In another 654 case (e.g., IEEE 802.11), no EAP method is used, so that empty 655 frames are transported during the over the air IEEE 802.1X 656 exchange. In this case the authentication state machine completes 657 with no cryptographic keys being exchanged. 659 3) Device Authentication: 661 This case extends the server-only authentication case. If the 662 device is configured with a device certificate and the IAP/ISP EAP 663 server can rely on a trusted root allowing the EAP server to 664 verify the device certificate, at least the device identity (e.g., 665 the MAC address) can be authenticated by the IAP/ISP in NAA cases. 666 An example for this are WiMAX devices that are shipped with device 667 certificates issued under the global WiMAX device public-key 668 infrastructure. To perform unauthenticated emergency calls, if 669 allowed by the IAP/ISP, such devices perform EAP-TLS based network 670 attachment with client authentication based on the device 671 certificate. 673 7. Security Considerations 675 The security threats discussed in [RFC5069] are applicable to this 676 document. 678 There are a couple of new vulnerabilities raised with unauthenticated 679 emergency services in NASP/NAA cases since the PSAP operator will 680 typically not possess any identity information about the emergency 681 call via the signaling path itself. In countries where this 682 functionality is used for GSM networks today this has lead to a 683 significant amount of misuse. 685 In the context of NAA, the IAP and the ISP will probably want to make 686 sure that the claimed emergency caller indeed performs an emergency 687 call rather than using the network for other purposes, and thereby 688 acting fraudulent by skipping any authentication, authorization and 689 accounting procedures. By restricting access of the unauthenticated 690 emergency caller to the LoST server and the PSAP URI, traffic can be 691 restricted only to emergency calls. This can be accomplished with 692 traffic separation. The details, however, e.g. for using filtering, 693 depend on the deployed ISP architecture and are beyond the scope of 694 this document. 696 We only illustrate a possible model. If the ISP runs its own LoST 697 server, it would maintain an access control list including all IP 698 addresses contained in responses returned by the LoST server, as well 699 as the LoST server itself. (It may need to translate the domain 700 names returned to IP addresses and hope that the resolution captures 701 all possible DNS responses.) Since the media destination addresses 702 are not predictable, the ISP also has to provide a SIP outbound proxy 703 so that it can determine the media addresses and add those to the 704 filter list. 706 For the ZBP case the additional aspect of fraud has to be considered. 707 Unless the emergency call traverses a PSTN gateway or the ASP charges 708 for IP-to-IP calls, there is little potential for fraud. If the ASP 709 also operates the LoST server, the outbound proxy MAY restrict 710 outbound calls to the SIP URIs returned by the LoST server. It is 711 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 712 change. 714 Finally, a number of security vulnerabilities discussed in [RFC6280] 715 around faked location information are less problematic in the context 716 of unauthenticated emergency since location information does not need 717 to be provided by the end host itself or it can be verified to fall 718 within a specific geographical area. 720 8. Acknowledgments 722 Parts of this document are derived from [RFC6881]. Participants of 723 the 2nd and 3rd SDO Emergency Services Workshop provided helpful 724 input. 726 We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc 727 Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT 728 meeting. 730 Furthermore, we would like to thank Martin Thomson and Bernard Aboba 731 for their detailed document review in preparation of the 81st IETF 732 meeting. 734 9. IANA Considerations 736 This document does not require actions by IANA. 738 10. References 740 10.1. Normative References 742 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 743 Emergency and Other Well-Known Services", RFC 5031, 744 January 2008. 746 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 747 Format", RFC 4119, December 2005. 749 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 750 Presence Information Data Format Location Object (PIDF-LO) 751 Usage Clarification, Considerations, and Recommendations", 752 RFC 5491, March 2009. 754 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 755 Format for Presence Information Data Format Location 756 Object (PIDF-LO)", RFC 5139, February 2008. 758 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 759 A., Peterson, J., Sparks, R., Handley, M., and E. 760 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 761 June 2002. 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 767 Communications Services in Support of Emergency Calling", 768 BCP 181, RFC 6881, March 2013. 770 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 771 Tschofenig, "LoST: A Location-to-Service Translation 772 Protocol", RFC 5222, August 2008. 774 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 775 Location-to-Service Translation (LoST) Servers Using the 776 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 777 August 2008. 779 10.2. Informative References 781 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 782 Location Configuration Protocol: Problem Statement and 783 Requirements", RFC 5687, March 2010. 785 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 786 "Framework for Emergency Calling Using Internet 787 Multimedia", RFC 6443, December 2011. 789 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 790 Emergency Context Resolution with Internet Technologies", 791 RFC 5012, January 2008. 793 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 794 A. Kuett, "Location Hiding: Problem Statement and 795 Requirements", RFC 6444, January 2012. 797 [I-D.winterbottom-geopriv-lis2lis-req] 798 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 799 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 800 (work in progress), November 2007. 802 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 803 Shanmugam, "Security Threats and Requirements for 804 Emergency Call Marking and Mapping", RFC 5069, January 805 2008. 807 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 808 Tschofenig, H., and H. Schulzrinne, "An Architecture for 809 Location and Location Privacy in Internet Applications", 810 BCP 160, RFC 6280, July 2011. 812 [esw07] , "3rd SDO Emergency Services Workshop, 813 http://www.emergency-services-coordination.info/2007Nov/", 814 October 30th - November 1st 2007. 816 [nwgstg3] , "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 817 Architecture Stage-3 818 http://www.wimaxforum.org/sites/wimaxforum.org/files/ 819 technical_document/2009/09/DRAFT-T33-001-R015v01 820 -O_Network-Stage3-Base.pdf", September 2009. 822 Authors' Addresses 824 Henning Schulzrinne 825 Columbia University 826 Department of Computer Science 827 450 Computer Science Building 828 New York, NY 10027 829 US 831 Phone: +1 212 939 7004 832 Email: hgs+ecrit@cs.columbia.edu 833 URI: http://www.cs.columbia.edu 834 Stephen McCann 835 Research in Motion UK Ltd 836 200 Bath Road 837 Slough, Berks SL1 3XE 838 UK 840 Phone: +44 1753 667099 841 Email: smccann@rim.com 842 URI: http://www.rim.com 844 Gabor Bajko 845 Nokia 847 Email: Gabor.Bajko@nokia.com 849 Hannes Tschofenig 850 Nokia Siemens Networks 851 Linnoitustie 6 852 Espoo 02600 853 Finland 855 Phone: +358 (50) 4871445 856 Email: Hannes.Tschofenig@gmx.net 857 URI: http://www.tschofenig.priv.at 859 Dirk Kroeselberg 860 Siemens 861 Germany 863 Email: dirk.kroeselberg@siemens.com