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