idnits 2.17.1 draft-ietf-ecrit-unauthenticated-access-10.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 (August 12, 2014) is 3516 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: February 13, 2015 Research in Motion UK Ltd 6 G. Bajko 8 H. Tschofenig 10 D. Kroeselberg 11 Siemens 12 August 12, 2014 14 Extensions to the Emergency Services Architecture for dealing with 15 Unauthenticated and Unauthorized Devices 16 draft-ietf-ecrit-unauthenticated-access-10.txt 18 Abstract 20 This document provides a problem statement, introduces terminology 21 and describes an extension for the base IETF emergency services 22 architecture to address cases where an emergency caller is not 23 authenticated, has no identifiable service provider, or has no 24 remaining credit with which to pay for access to the network. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 13, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Use Case Categories . . . . . . . . . . . . . . . . . . . . . 5 63 4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 5.1. End Host Profile . . . . . . . . . . . . . . . . . . . . 14 66 5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 14 67 5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 14 68 5.1.3. Location Determination and Location Configuration . . 14 69 5.1.4. Emergency Call Identification . . . . . . . . . . . . 14 70 5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 14 71 5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 15 74 5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 15 75 5.2.2. Location Determination and Location Configuration . . 15 76 5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 15 77 5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 15 78 5.3.2. Emergency Call Identification . . . . . . . . . . . . 15 79 5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 16 80 6. Lower Layer Considerations for NAA Case . . . . . . . . . . . 16 81 6.1. Link Layer Emergency Indication . . . . . . . . . . . . . 17 82 6.2. Securing Network Attachment in NAA Cases . . . . . . . . 18 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 88 10.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 Summoning police, the fire department or an ambulance in emergencies 94 is one of the fundamental and most-valued functions of the telephone. 95 As telephone functionality moves from circuit-switched telephony to 96 Internet telephony, its users rightfully expect that this core 97 functionality will continue to work at least as well as it has for 98 the older technology. New devices and services are being made 99 available that could be used to make a request for help, those 100 devices are not traditional telephones, and users are increasingly 101 expecting them to be used to place emergency calls. 103 Roughly speaking, the IETF emergency services architecture (see 104 [RFC6881] and [RFC6443]) divides responsibility for handling 105 emergency calls among the access network (ISP); the application 106 service provider (ASP), which may be a VoIP service provider (VSP); 107 and the provider of emergency signaling services, the emergency 108 service network (ESN). The access network may provide location 109 information to end systems, but does not have to provide any ASP 110 signaling functionality. The emergency caller can reach the ESN 111 either directly or through the ASP's outbound proxy. Any of the 112 three parties can provide the mapping from location to PSAP URI by 113 offering LoST [RFC5222] services. 115 In general, a set of automated configuration mechanisms allows a 116 device to function in a variety of architectures, without the user 117 being aware of the details on who provides location, mapping services 118 or call routing services. However, if emergency calling is to be 119 supported when the calling device lacks access network authorization 120 or does not have an ASP, one or more of the providers may need to 121 provide additional services and functions. 123 In all cases, the end device has to be able to perform a LoST lookup 124 and otherwise conduct the emergency call in the same manner as when 125 the three exceptional conditions discussed below do not apply. 127 We distinguish among three conditions: 129 No Access Authentication (NAA): In the NAA case, the emergency 130 caller does not posses valid credentials for the access network. 131 This includes the case where the access network allows pay-per- 132 use, as is common for wireless hotspots, but there is insufficient 133 time to enter credit card details and other registration 134 information required for access. It also covers all cases where 135 either no credentials are available at all, or the available 136 credentials do not work for the given IAP/ISP. As a result, the 137 NAA case basically combines the below NASP and ZBP cases, but at 138 the IAP/ISP level. Support for emergency call handling in the NAA 139 case is subject to the local policy of the ISP. Such policy may 140 vary substantially between ISPs and typically depends on external 141 factors that are not under the ISP control. 143 No ASP (NASP): The caller does not have an ASP at the time of the 144 call. This can occur either in case the caller does not possess 145 any valid subscription for a reachable ASP, or in case none of the 146 ASPs where the caller owns a valid subscription is reachable 147 through the ISP. 149 Note: The interoperability need is increased with this scenario 150 since the client software used by the emergency caller must be 151 compatible with the protocols and extensions deployed by the ESN. 153 Zero-balance ASP (ZBP): In the case of zero-balance ASP, the ASP can 154 authenticate the caller, but the caller is not authorized to use 155 ASP services, e.g., because the contract has expired or the 156 prepaid account for the customer has been depleted. 158 These three cases are not mutually exclusive. A caller in need of 159 help may, for example, be in a NAA and NASP situation, as explained 160 in more detail in Figure 1. Depending on local policy and 161 regulations, it may not be possible to place emergency calls in the 162 NAA case. Unless local regulations require user identification, it 163 should always be possible to place calls in the NASP case, with 164 minimal impact on the ISP. Unless the ESN requires that all calls 165 traverse a known set of VSPs, it is technically possible to let a 166 caller place an emergency call in the ZBP case. We discuss each case 167 in more details in Section 3. 169 As mentioned in the abstract some of the functionality provided in 170 this document is already available in the PSTN. Consequently, there 171 is real-world experience available and not all of it is positive. 172 For example, the functionality of SIM-less calls in today's cellular 173 system has lead to a fair amount of hoax or test calls in certain 174 countries. This causes overload situations at PSAPs, which is 175 considered harmful to the overall availability and reliability of 176 emergency services. 178 As an example, Federal Office of Communications (OFCOM, 179 Switzerland) provided statistics about emergency (112) calls in 180 Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not 181 offer SIM-less emergency calls except for almost a month in July 182 2000 where a significant increase in hoax and test calls was 183 reported. As a consequence, the functionality was disabled again. 184 More details can be found in the panel presentations of the 3rd 185 SDO Emergency Services Workshop [esw07]. 187 2. Terminology 189 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 190 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 191 and "OPTIONAL" are to be interpreted as described in RFC 2119 192 [RFC2119]. 194 This document reuses terminology from [RFC5687] and [RFC5012], namely 195 Internet Access Provider (IAP), Internet Service Provider (ISP), 196 Application Service Provider (ASP), Voice Service Provider (VSP), 197 Emergency Service Routing Proxy (ESRP), Public Safety Answering Point 198 (PSAP), Location Configuration Server (LCS), (emergency) service dial 199 string, and (emergency) service identifier. 201 3. Use Case Categories 203 On a very high-level, the steps to be performed by an end host that 204 is not attached to the network and the user starting to make an 205 emergency call are the following: 207 Link Layer Attachment: Some networks have added support for 208 unauthenticated emergency access, some other type of networks 209 advertise these capabilities using layer beacons. The end host 210 learns about these unauthenticated emergency services capabilities 211 either from the link layer type or from advertisement. 213 The end host uses the link layer specific network attachment 214 procedures defined for unauthenticated network access in order to 215 get access to the network. 217 Pre-Emergency Service Configuration: When the link layer network 218 attachment procedure is completed the end host learns basic 219 configuration information using DHCP from the ISP. The end host 220 uses a Location Configuration Protocol (LCP) to retrieve location 221 information. Subsequently, the LoST protocol [RFC5222] is used to 222 learn the relevant emergency numbers, and to obtain the PSAP URI 223 applicable for that location. 225 Emergency Call: In case of need for help, a user dials an emergency 226 number and the SIP UA initiates the emergency call procedures by 227 communicating with the PSAP. 229 Figure 1 compiles the basic logic taking place during network entry 230 for requesting an emergency service and shows the interrelation 231 between the three conditions described in the above section. 233 +-----Y 234 |Start| 235 `...../ 236 | 237 | Are credentials 238 | for network attachment 239 | available? 240 | 241 NO v YES 242 +----------------------------+ 243 | | 244 | | 245 V v 246 .............. ................ 247 | Idle: Wait | |Execute | 248 | for ES Call| |LLA Procedures| 249 | Initiation | "--------------' 250 "------------' | 251 Is | +---------->O 252 emergency | | | Is ASP 253 service | NO +-----Y | | configured? 254 network +--->| End | | +---------------+ 255 attachment| `...../ | YES | | NO 256 possible? | | | | 257 v | v v 258 +------------+ | +------------+ +------------+ 259 | Execute | | | Execute | | Execute | 260 | NAA |--------+ | Phone BCP | | NASP | 261 | Procedures | | Procedures | | Procedures | 262 +------------+ +------------+ +------------+ 263 Authorization for| | 264 making an | | 265 emergency call | | 266 with the ASP/VSP?| | 267 +--------------+ v 268 | NO | YES +-----Y 269 | | | Done| 270 v v `...../ 271 +------------+ +------------+ 272 | Execute | | Execute | 273 | ZBP | | Phone BCP | 274 | Procedures | | Procedures | 275 +------------+ +------------+ 276 | | 277 | | 278 v v 279 +-----Y +-----Y 280 | Done| | Done| 281 `...../ `...../ 283 Abbreviations: 284 LLA: Link Layer Attachment 285 ES: Emergency Services 287 Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios. 289 The diagrams below highlight the most important steps for the three 290 cases. 292 +-----Y 293 |Start| 294 `...../ 295 | 296 | No 297 | credentials 298 | for network access 299 | available 300 v 301 .............. 302 | Idle: Wait | 303 | for ES Call| 304 | Initiation | 305 "------------' 306 | 307 | 308 | 309 v 310 -- 311 // -- 312 / -- 313 // Is -- 314 / emergency -- 315 | service | NO +--------+ 316 | network |------>| Call | 317 | attachment | Failed | 318 \ possible? / `......./ 319 \ // 320 \\ // 321 \ // 322 \--/ 323 | 324 | YES 325 | 326 | 327 v 328 +------------+ 329 | Execute | 330 | NAA | 331 | Procedures | 332 +------------+ 333 | 334 | Network 335 | attachment 336 | in progress 337 v 338 /--\ Continue 339 | | with 340 | | application 341 \--/ layer interaction 343 Figure 2: Flow Diagram: NAA Scenario. 345 +-----+ 346 +------------|Start|-----------------+ 347 | `...../ | 348 v v 349 +------------+ +----------------+ 350 | NAA | | Regular | 351 | Procedures | | Network Access | 352 +------------+ | Procedures | 353 | +----------------+ 354 | | 355 | | 356 ----------------o--------------------+ 357 | 358 | 359 | 360 | 361 Network 362 Attachment 363 Completed 364 | 365 | 366 | 367 | 368 v 369 +------------+ +---------+ 370 | ASP | NO | See | 371 | Configured?|----->| main | 372 +------------+ | diagram | 373 | `......../ 374 | 375 | YES 376 | 377 v 378 //---- 379 / -- 380 // -- 381 / - +---------+ 382 | Authorization| YES | See | 383 | for making |------>| main | 384 | ES call | | diagram | 385 \ with / `......../ 386 \ VSP/ASP? // 387 \\ // 388 \ // 389 \--/ 390 | 391 | NO 392 | 393 | 394 v 395 +------------+ 396 | Execute | 397 | ZBP | 398 | Procedures | 399 +------------+ 400 | 401 | Call 402 | in progress 403 | 404 v 405 +--------+ 406 | Call | 407 Success| 408 `......./ 410 Figure 3: Flow Diagram: ZBP Scenario. 412 +-----+ 413 +------------|Start|-----------------+ 414 | `...../ | 415 v v 416 +------------+ +----------------+ 417 | NAA | | Regular | 418 | Procedures | | Network Access | 419 +------------+ | Procedures | 420 | +----------------+ 421 | | 422 | | 423 ----------------o--------------------+ 424 | 425 | 426 | 427 | 428 Network 429 Attachment 430 Completed 431 | 432 | 433 | 434 | 435 v 436 +------------+ +---------+ 437 | ASP | YES | See | 438 | Configured?|----->| main | 439 +------------+ | diagram | 440 | `......../ 441 | 442 | NO 443 | 444 v 445 +------------+ 446 | Execute | 447 | NASP | 448 | Procedures | 449 +------------+ 450 | 451 | Call 452 | in progress 453 | 454 v 455 +--------+ 456 | Call | 457 Success| 458 `......./ 460 Figure 4: Flow Diagram: NASP Scenario. 462 The "No Access Authentication (NAA)" procedures are described in 463 Section 6. The "Zero-balance ASP (ZBP)" procedures are described in 464 Section 4. The "No ASP (NASP)" procedures are described in 465 Section 5. The Phone BCP procedures are described in [RFC6881]. The 466 "Link Layer Attachment (LLA)" procedures are not described in this 467 document since they are specific to the link layer technology in use. 469 4. ZBP Considerations 471 ZBP includes all cases where a subscriber is known to an ASP, but 472 lacks the necessary authorization to access regular ASP services. 473 Example ZBP cases include empty prepaid accounts, barred accounts, 474 roaming and mobility restrictions, or any other conditions set by ASP 475 policy. 477 Local regulation might demand that emergency calls cannot proceed 478 without successful service authorization. In regulatory regimes, 479 however, it may be possible to allow emergency calls to continue 480 despite authorization failures. To distinguish an emergency call 481 from a regular call an ASP can identify emergency sessions by 482 inspecting the service URN [RFC5031] used in call setup. The ZBP 483 case therefore only affects the ASP. 485 Permitting a call despite authorization failures could present an 486 opportunity for abuse. The ASP may choose to verify the destination 487 of the emergency calls and to only permit calls to certain, pre- 488 configured entities (e.g., to local PSAPs). Section 7 discusses this 489 topic in more detail. 491 An ASP without a regulatory requirement to authorize emergency calls 492 can deny emergency call setup. Where an ASP does not authorize an 493 emergency call, the caller may be able to fall back to NASP 494 procedures. 496 5. NASP Considerations 498 To start the description we consider the sequence of steps that are 499 executed in an emergency call based on Figure 5. 501 o As an initial step the devices attaches to the network as shown in 502 step (1). This step is outside the scope of this section. 504 o When the link layer network attachment procedure is completed the 505 end host learns basic IP configuration information using DHCP from 506 the ISP, as shown in step (2). 508 o When the IP address configuration is completed then the end host 509 starts an interaction with the discovered Location Configuration 510 Server at the ISP, as shown in step (3). The ISP may in certain 511 deployments need to interact with the IAP. This protocol exchange 512 is shown in step (4). 514 o Once location information is obtained the end host triggers the 515 LoST protocol to obtain the address of the ESRP/PSAP. This step 516 is shown in (5). 518 o In step (6), the SIP UA initiates a SIP INVITE towards the 519 indicated ESRP. The INVITE message contains all the necessary 520 parameters required by Section 5.1.5. 522 o The ESRP receives the INVITE and processes it according to the 523 description in Section 5.3.3. 525 o The ESRP routes the call to the PSAP, as shown in (8), potentially 526 interacting with a LoST server first to determine the route. 528 o The PSAP evaluates the initial INVITE and aims to complete the 529 call setup. 531 o Finally, when the call setup is completed media traffic can be 532 exchanged between the PSAP and the SIP UA. 534 For editorial reasons the end-to-end SIP and media exchange between 535 the PSAP and SIP UA are not shown in Figure 5. 537 +-------+ 538 | PSAP | 539 | | 540 +-------+ 541 ^ 542 | (8) 543 | 544 +----------+(7) +----------+ 545 | LoST |<-->| ESRP | 546 | Server | | | 547 +----------+ +----------+ 548 ^ ^ 549 +----------------+----------------|--------------+ 550 | ISP | | | 551 |+----------+ | | +----------+| 552 || LCS-ISP | (3)| | | DHCP || 553 || |<-+ | | | Server || 554 |+----------+ | | | +----------+| 555 +-------^------+-+----------------|-----------^--+ 556 +-------|------+-+----------------|-----------|--+ 557 | IAP | (4) | |(5) | | | 558 | V | | | | | 559 |+----------+ | | | | | 560 || LCS-IAP | | | +--------+ | | | 561 || | | | | Link | |(6) | | 562 |+----------+ | | | Layer | | | | 563 | | | | Device | | (2)| | 564 | | | +--------+ | | | 565 | | | ^ | | | 566 | | | | | | | 567 +--------------+-|-------|--------|-----------|--+ 568 | | | | | 569 | | (1)| | | 570 | | | | | 571 | | | +----+ | 572 | | v | | 573 | | +----------+ | 574 | +->| End |<-------------+ 575 +___>| Host | 576 +----------+ 578 Figure 5: Architectural Overview 580 Note: Figure 5 does not indicate who operates the ESRP and the LoST 581 server. Various deployment options exist. 583 5.1. End Host Profile 585 5.1.1. LoST Server Discovery 587 The end host MUST discover a LoST server [RFC5222] using DHCP 588 [RFC5223] unless a LoST server has been provisioned using other 589 means. 591 5.1.2. ESRP Discovery 593 The end host MUST discover the ESRP using the LoST protocol [RFC5222] 594 unless a ESRP has been provisioned using other means. 596 5.1.3. Location Determination and Location Configuration 598 The end host MUST support location acquisition and the LCPs described 599 in Section 6.5 of [RFC6881]. The description in Section 6.5 and 6.6 600 of [RFC6881] regarding the interaction between the device and the LIS 601 applies to this document. 603 The SIP UA in the end host MUST attach available location information 604 in a PIDF-LO [RFC4119] when making an emergency call. When 605 constructing the PIDF-LO the guidelines in PIDF-LO profile [RFC5491] 606 MUST be followed. For civic location information the format defined 607 in [RFC5139] MUST be supported. 609 5.1.4. Emergency Call Identification 611 To determine which calls are emergency calls, some entity needs to 612 map a user entered dialstring into this URN scheme. A user may 613 "dial" 1-1-2, 9-1-1, etc., but the call would be sent to 614 urn:service:sos. This mapping SHOULD be performed at the endpoint 615 device. 617 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 618 as emergency calls for their home emergency dial string. 620 5.1.5. SIP Emergency Call Signaling 622 SIP signaling capabilities [RFC3261] are REQUIRED for end hosts. 624 The initial SIP signaling method is an INVITE. The SIP INVITE 625 request MUST be constructed according to the requirements in 626 Section 9.2 [RFC6881]. 628 Regarding callback behavior SIP UAs SHOULD place a globally routable 629 URI in a Contact: header. 631 5.1.6. Media 633 End points MUST comply with the media requirements for end points 634 placing an emergency call found in Section 14 of [RFC6881]. 636 5.1.7. Testing 638 The description in Section 15 of [RFC6881] is fully applicable to 639 this document. 641 5.2. IAP/ISP Profile 643 5.2.1. ESRP Discovery 645 An ISP MUST provision a DHCP server with information about LoST 646 servers [RFC5223]. An ISP operator may choose to deploy a LoST 647 server or to outsource it to other parties. 649 5.2.2. Location Determination and Location Configuration 651 The ISP is responsible for location determination and exposes this 652 information to the end points via location configuration protocols. 653 The considerations described in [RFC6444] are applicable to this 654 document. 656 The ISP MUST support one of the LCPs described in Section 6.5 of 657 [RFC6881]. The description in Section 6.5 and 6.6 of [RFC6881] 658 regarding the interaction between the end device and the LIS applies 659 to this document. 661 The interaction between the LIS at the ISP and the IAP is often 662 priorietary but the description in 663 [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. 665 5.3. ESRP Profile 667 5.3.1. Emergency Call Routing 669 The ESRP continues to route the emergency call to the PSAP 670 responsible for the physical location of the end host. This may 671 require further interactions with LoST servers but depends on the 672 specific deployment. 674 5.3.2. Emergency Call Identification 676 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 677 the 'urn:service:sos' tree). 679 5.3.3. SIP Emergency Call Signaling 681 SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The 682 ESRP MUST process the messages sent by the client, according to 683 Section 5.1.5. 685 Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT 686 restrict incoming calls to a particular set of ASPs. 688 6. Lower Layer Considerations for NAA Case 690 Some networks have added support for unauthenticated emergency 691 access, some other type of networks advertise these capabilities 692 using layer beacons. The end host learns about these unauthenticated 693 emergency services capabilities either from the link layer type or 694 from advertisement. 696 It is important to highlight that the NAA case is inherently a layer 697 2 problem, and the general form of the solution is to provide an 698 "emergency only" access type, with appropriate limits/monitoring to 699 prevent abuse. The described mechanisms are informative in nature 700 since the relationship to the IETF emergency services architecture is 701 only indirect, namely via some protocols developed within the IETF 702 (e.g., EAP and EAP methods) that require extensions to support this 703 functionality. 705 This section discusses different methods to indicate an emergency 706 service request as part of network attachment. It provides some 707 general considerations and recommendations that are not specific to 708 the access technology. 710 To perform network attachment and get access to the resources 711 provided by an IAP/ISP, the end host uses access technology specific 712 network attachment procedures, including for example network 713 detection and selection, authentication, and authorization. For 714 initial network attachment of an emergency service requester, the 715 method of how the emergency indication is given to the IAP/ISP is 716 specific to the access technology. However, a number of general 717 approaches can be identified: 719 Link layer emergency indication: The end host provides an 720 indication, e.g., an emergency parameter or flag, as part of the 721 link layer signaling for initial network attachment. Examples 722 include an emergency bit signalled in the IEEE 802.16-2009 723 wireless link. In IEEE 802.11 WLAN, an emergency support 724 indicator allows the station (i.e., end host in this context) to 725 download before association a Network Access Identifier (NAI), 726 which it can use to request server side authentication only for an 727 802.1x network. 729 Higher-layer emergency indication: Typically, emergency indication 730 is provided in the network access authentication procedure. The 731 emergency caller's end host provides an indication as part of the 732 access authentication exchanges. Authentication via the 733 Extensible Authentication Protocol (EAP) [RFC3748] is of 734 particular relevance here. Examples are the EAP NAI decoration 735 used in WiMAX networks and modification of the authentication 736 exchange in IEEE 802.11. [nwgstg3]. 738 6.1. Link Layer Emergency Indication 740 In general, link layer emergency indications provide good integration 741 into the actual network access procedure regarding the enabling of 742 means to recognize and prioritize an emergency service request from 743 an end host at a very early stage of the network attachment 744 procedure. However, support in end hosts for such methods cannot be 745 considered to be commonly available. 747 No general recommendations are given in the scope of this memo due to 748 the following reasons: 750 o Dependency on the specific access technology. 752 o Dependency on the specific access network architecture. Access 753 authorization and policy decisions typically happen at a different 754 layers of the protocol stack and in different entities than those 755 terminating the link-layer signaling. As a result, link layer 756 indications need to be distributed and translated between the 757 different involved protocol layers and entities. Appropriate 758 methods are specific to the actual architecture of the IAP/ISP 759 network. 761 o An advantage of combining emergency indications with the actual 762 network attachment procedure performing authentication and 763 authorization is the fact that the emergency indication can 764 directly be taken into account in the authentication and 765 authorization server that owns the policy for granting access to 766 the network resources. As a result, there is no direct dependency 767 on the access network architecture that otherwise would need to 768 take care of merging link-layer indications into the AA and policy 769 decision process. 771 o EAP signaling happens at a relatively early stage of network 772 attachment, so it is likely to match most requirements for 773 prioritization of emergency signaling. However, it does not cover 774 early stages of link layer activity in the network attachment 775 process. Possible conflicts may arise e.g. in case of MAC-based 776 filtering in entities terminating the link-layer signaling in the 777 network (like a base station). In normal operation, EAP related 778 information will only be recognized in the NAS. Any entity 779 residing between end host and NAS should not be expected to 780 understand/parse EAP messages. 782 o An emergency indication can be given by forming a specific NAI 783 that is used as the identity in EAP based authentication for 784 network entry. 786 6.2. Securing Network Attachment in NAA Cases 788 For network attachment in NAA cases, it may make sense to secure the 789 link-layer connection between the device and the IAP/ISP. This 790 especially holds for wireless access with examples being IEEE 802.11 791 or IEEE 802.16 based access. The latter even mandates secured 792 communication across the wireless link for all IAP/ISP networks based 793 on [nwgstg3]. 795 Therefore, for network attachment that is by default based on EAP 796 authentication it is desirable also for NAA network attachment to use 797 a key-generating EAP method (that provides an MSK key to the 798 authenticator to bootstrap further key derivation for protecting the 799 wireless link). 801 The following approaches to match the above can be identified: 803 1) Server-only Authentication: 805 The device of the emergency service requester performs an EAP 806 method with the IAP/ISP EAP server that performs server side 807 authentication only. An example for this is EAP-TLS [RFC5216]. 808 This provides a certain level of assurance about the IAP/ISP to 809 the device user. It requires the device to be provisioned with 810 appropriate trusted root certificates to be able to verify the 811 server certificate of the EAP server (unless this step is 812 explicitly skipped in the device in case of an emergency service 813 request). This method is used to provide access of devices 814 without existing credentials to an 802.1x network. The details 815 are incorporated into the not yet published 802.11-2011 816 specification. 818 2) Null Authentication: 820 In one case (e.g., WiMAX) an EAP method is performed. However, no 821 credentials specific to either the server or the device or 822 subscription are used as part of the authentication exchange. An 823 example for this would be an EAP-TLS exchange with using the 824 TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly 825 available static key for emergency access could be used. In the 826 latter case, the device would need to be provisioned with the 827 appropriate emergency key for the IAP/ISP in advance. In another 828 case (e.g., IEEE 802.11), no EAP method is used, so that empty 829 frames are transported during the over the air IEEE 802.1X 830 exchange. In this case the authentication state machine completes 831 with no cryptographic keys being exchanged. 833 3) Device Authentication: 835 This case extends the server-only authentication case. If the 836 device is configured with a device certificate and the IAP/ISP EAP 837 server can rely on a trusted root allowing the EAP server to 838 verify the device certificate, at least the device identity (e.g., 839 the MAC address) can be authenticated by the IAP/ISP in NAA cases. 840 An example for this are WiMAX devices that are shipped with device 841 certificates issued under the global WiMAX device public-key 842 infrastructure. To perform unauthenticated emergency calls, if 843 allowed by the IAP/ISP, such devices perform EAP-TLS based network 844 attachment with client authentication based on the device 845 certificate. 847 7. Security Considerations 849 The security threats discussed in [RFC5069] are applicable to this 850 document. 852 There are a couple of new vulnerabilities raised with unauthenticated 853 emergency services in NASP/NAA cases since the PSAP operator will 854 typically not possess any identity information about the emergency 855 caller via the signaling path itself. In countries where this 856 functionality is used for GSM networks today this has lead to a 857 significant amount of misuse. 859 In the context of NAA, the IAP and the ISP will probably want to make 860 sure that the claimed emergency caller indeed performs an emergency 861 call rather than using the network for other purposes, and thereby 862 acting fraudulent by skipping any authentication, authorization and 863 accounting procedures. By restricting access of the unauthenticated 864 emergency caller to the LoST server and the PSAP URI, traffic can be 865 restricted only to emergency calls. This can be accomplished with 866 traffic separation. The details, however, e.g. for using filtering, 867 depend on the deployed ISP architecture and are beyond the scope of 868 this document. 870 We only illustrate a possible model. If the ISP runs its own 871 (caching) LoST server, the ISP would maintain an access control list 872 populated with IP-address information obtained from LoST responses 873 (in the mappings). These URIs would either be URIs for contacting 874 further LoST servers or PSAP URIs. It may be necessary to translate 875 domain names returned in LoST responses to IP addresses. Since the 876 media destination addresses are not predictable, the ISP also has to 877 provide a SIP outbound proxy so that it can determine the media 878 addresses and add those to the filter list. 880 For the ZBP case the additional aspect of fraud has to be considered. 881 Unless the emergency call traverses a PSTN gateway or the ASP charges 882 for IP-to-IP calls, there is little potential for fraud. If the ASP 883 also operates the LoST server, the outbound proxy MAY restrict 884 outbound calls to the SIP URIs returned by the LoST server. It is 885 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 886 change. 888 RFC 6280 [RFC6280] discusses security vulnerabilities that are caused 889 by an adversary faking location information and thereby lying about 890 the actual location of the emergency caller. These threats may be 891 less problematic in the context of unauthenticated emergency when 892 location information can be verified by the ISP to fall within a 893 specific geographical area. 895 8. Acknowledgments 897 Parts of this document are derived from [RFC6881]. Participants of 898 the 2nd and 3rd SDO Emergency Services Workshop provided helpful 899 input. 901 We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc 902 Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT 903 meeting. 905 Furthermore, we would like to thank Martin Thomson and Bernard Aboba 906 for their detailed document review in preparation of the 81st IETF 907 meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A 908 number of changes to the document had been made in response to the AD 909 review by Richard Barnes. 911 We would also like to thank review comments from various IESG 912 members, including Stephen Farrell, Barry Leiba, Pete Resnick, 913 Spencer Dawkins, Joel Jaeggli, and Ted Lemon. 915 9. IANA Considerations 917 This document does not require actions by IANA. 919 10. References 921 10.1. Normative References 923 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 924 Emergency and Other Well-Known Services", RFC 5031, 925 January 2008. 927 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 928 Format", RFC 4119, December 2005. 930 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 931 Presence Information Data Format Location Object (PIDF-LO) 932 Usage Clarification, Considerations, and Recommendations", 933 RFC 5491, March 2009. 935 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 936 Format for Presence Information Data Format Location 937 Object (PIDF-LO)", RFC 5139, February 2008. 939 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 940 A., Peterson, J., Sparks, R., Handley, M., and E. 941 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 942 June 2002. 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, March 1997. 947 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 948 Communications Services in Support of Emergency Calling", 949 BCP 181, RFC 6881, March 2013. 951 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 952 Tschofenig, "LoST: A Location-to-Service Translation 953 Protocol", RFC 5222, August 2008. 955 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 956 Location-to-Service Translation (LoST) Servers Using the 957 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 958 August 2008. 960 10.2. Informative References 962 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 963 Location Configuration Protocol: Problem Statement and 964 Requirements", RFC 5687, March 2010. 966 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 967 "Framework for Emergency Calling Using Internet 968 Multimedia", RFC 6443, December 2011. 970 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 971 Emergency Context Resolution with Internet Technologies", 972 RFC 5012, January 2008. 974 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 975 A. Kuett, "Location Hiding: Problem Statement and 976 Requirements", RFC 6444, January 2012. 978 [I-D.winterbottom-geopriv-lis2lis-req] 979 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 980 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 981 (work in progress), November 2007. 983 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 984 Shanmugam, "Security Threats and Requirements for 985 Emergency Call Marking and Mapping", RFC 5069, January 986 2008. 988 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 989 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 990 3748, June 2004. 992 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 993 Authentication Protocol", RFC 5216, March 2008. 995 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 996 Tschofenig, H., and H. Schulzrinne, "An Architecture for 997 Location and Location Privacy in Internet Applications", 998 BCP 160, RFC 6280, July 2011. 1000 [esw07] "3rd SDO Emergency Services Workshop, 1001 http://www.emergency-services-coordination.info/2007Nov/", 1002 October 30th - November 1st 2007. 1004 [nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 1005 Architecture Stage-3 1006 http://www.wimaxforum.org/sites/wimaxforum.org/files/ 1007 technical_document/2009/09/DRAFT-T33-001-R015v01- 1008 O_Network-Stage3-Base.pdf", September 2009. 1010 Authors' Addresses 1012 Henning Schulzrinne 1013 Columbia University 1014 Department of Computer Science 1015 450 Computer Science Building 1016 New York, NY 10027 1017 US 1019 Phone: +1 212 939 7004 1020 Email: hgs+ecrit@cs.columbia.edu 1021 URI: http://www.cs.columbia.edu 1023 Stephen McCann 1024 Research in Motion UK Ltd 1025 200 Bath Road 1026 Slough, Berks SL1 3XE 1027 UK 1029 Phone: +44 1753 667099 1030 Email: smccann@rim.com 1031 URI: http://www.rim.com 1033 Gabor Bajko 1035 Email: gaborbajko@gmail.com 1037 Hannes Tschofenig 1038 Hall in Tirol 6060 1039 Austria 1041 Email: Hannes.Tschofenig@gmx.net 1042 URI: http://www.tschofenig.priv.at 1043 Dirk Kroeselberg 1044 Siemens 1045 Germany 1047 Email: dirk.kroeselberg@siemens.com