idnits 2.17.1 draft-ietf-ecrit-unauthenticated-access-09.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 3, 2014) is 3585 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 4, 2015 Research in Motion UK Ltd 6 G. Bajko 7 Nokia 8 H. Tschofenig 10 D. Kroeselberg 11 Siemens 12 July 3, 2014 14 Extensions to the Emergency Services Architecture for dealing with 15 Unauthenticated and Unauthorized Devices 16 draft-ietf-ecrit-unauthenticated-access-09.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 January 4, 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 Note: At the time of writing there is no regulation in place that 170 demands the functionality described in this memo. SDOs have started 171 their work on this subject in a proactive fashion in the anticipation 172 that national regulation will demand it for a subset of network 173 environments. 175 As mentioned in the abstract some of the functionality provided in 176 this document is already available in the PSTN. Consequently, there 177 is real-world experience available and not all of it is positive. 178 For example, the functionality of SIM-less calls in today's cellular 179 system has lead to a fair amount of hoax or test calls in certain 180 countries. This causes overload situations at PSAPs, which is 181 considered harmful to the overall availability and reliability of 182 emergency services. 184 As an example, Federal Office of Communications (OFCOM, 185 Switzerland) provided statistics about emergency (112) calls in 186 Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not 187 offer SIM-less emergency calls except for almost a month in July 188 2000 where a significant increase in hoax and test calls was 189 reported. As a consequence, the functionality was disabled again. 190 More details can be found in the panel presentations of the 3rd 191 SDO Emergency Services Workshop [esw07]. 193 2. Terminology 195 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 196 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 197 and "OPTIONAL" are to be interpreted as described in RFC 2119 198 [RFC2119]. 200 This document reuses terminology from [RFC5687] and [RFC5012], namely 201 Internet Access Provider (IAP), Internet Service Provider (ISP), 202 Application Service Provider (ASP), Voice Service Provider (VSP), 203 Emergency Service Routing Proxy (ESRP), Public Safety Answering Point 204 (PSAP), Location Configuration Server (LCS), (emergency) service dial 205 string, and (emergency) service identifier. 207 3. Use Case Categories 209 On a very high-level, the steps to be performed by an end host that 210 is not attached to the network and the user starting to make an 211 emergency call are the following: 213 Link Layer Attachment: Some networks have added support for 214 unauthenticated emergency access, some other type of networks 215 advertise these capabilities using layer beacons. The end host 216 learns about these unauthenticated emergency services capabilities 217 either from the link layer type or from advertisement. 219 The end host uses the link layer specific network attachment 220 procedures defined for unauthenticated network access in order to 221 get access to the network. 223 Pre-Emergency Service Configuration: When the link layer network 224 attachment procedure is completed the end host learns basic 225 configuration information using DHCP from the ISP. The end host 226 uses a Location Configuration Protocol (LCP) to retrieve location 227 information. Subsequently, the LoST protocol [RFC5222] is used to 228 learn the relevant emergency numbers, and to obtain the PSAP URI 229 applicable for that location. 231 Emergency Call: In case of need for help, a user dials an emergency 232 number and the SIP UA initiates the emergency call procedures by 233 communicating with the PSAP. 235 Figure 1 compiles the basic logic taking place during network entry 236 for requesting an emergency service and shows the interrelation 237 between the three conditions described in the above section. 239 +-----Y 240 |Start| 241 `...../ 242 | 243 | Are credentials 244 | for network attachment 245 | available? 246 | 247 NO v YES 248 +----------------------------+ 249 | | 250 | | 251 V v 252 .............. ................ 253 | Idle: Wait | |Execute | 254 | for ES Call| |LLA Procedures| 255 | Initiation | "--------------' 256 "------------' | 257 Is | +---------->O 258 emergency | | | Is ASP 259 service | NO +-----Y | | configured? 260 network +--->| End | | +---------------+ 261 attachment| `...../ | YES | | NO 262 possible? | | | | 263 v | v v 264 +------------+ | +------------+ +------------+ 265 | Execute | | | Execute | | Execute | 266 | NAA |--------+ | Phone BCP | | NASP | 267 | Procedures | | Procedures | | Procedures | 268 +------------+ +------------+ +------------+ 269 Authorization for| | 270 making an | | 271 emergency call | | 272 with the ASP/VSP?| | 273 +--------------+ v 274 | NO | YES +-----Y 275 | | | Done| 276 v v `...../ 277 +------------+ +------------+ 278 | Execute | | Execute | 279 | ZBP | | Phone BCP | 280 | Procedures | | Procedures | 281 +------------+ +------------+ 282 | | 283 | | 284 v v 285 +-----Y +-----Y 286 | Done| | Done| 287 `...../ `...../ 289 Abbreviations: 290 LLA: Link Layer Attachment 291 ES: Emergency Services 293 Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios. 295 The diagrams below highlight the most important steps for the three 296 cases. 298 +-----Y 299 |Start| 300 `...../ 301 | 302 | No 303 | credentials 304 | for network access 305 | available 306 v 307 .............. 308 | Idle: Wait | 309 | for ES Call| 310 | Initiation | 311 "------------' 312 | 313 | 314 | 315 v 316 -- 317 // -- 318 / -- 319 // Is -- 320 / emergency -- 321 | service | NO +--------+ 322 | network |------>| Call | 323 | attachment | Failed | 324 \ possible? / `......./ 325 \ // 326 \\ // 327 \ // 328 \--/ 329 | 330 | YES 331 | 332 | 333 v 334 +------------+ 335 | Execute | 336 | NAA | 337 | Procedures | 338 +------------+ 339 | 340 | Network 341 | attachment 342 | in progress 343 v 344 /--\ Continue 345 | | with 346 | | application 347 \--/ layer interaction 349 Figure 2: Flow Diagram: NAA Scenario. 351 +-----+ 352 +------------|Start|-----------------+ 353 | `...../ | 354 v v 355 +------------+ +----------------+ 356 | NAA | | Regular | 357 | Procedures | | Network Access | 358 +------------+ | Procedures | 359 | +----------------+ 360 | | 361 | | 362 ----------------o--------------------+ 363 | 364 | 365 | 366 | 367 Network 368 Attachment 369 Completed 370 | 371 | 372 | 373 | 374 v 375 +------------+ +---------+ 376 | ASP | NO | See | 377 | Configured?|----->| main | 378 +------------+ | diagram | 379 | `......../ 380 | 381 | YES 382 | 383 v 384 //---- 385 / -- 386 // -- 387 / - +---------+ 388 | Authorization| YES | See | 389 | for making |------>| main | 390 | ES call | | diagram | 391 \ with / `......../ 392 \ VSP/ASP? // 393 \\ // 394 \ // 395 \--/ 396 | 397 | NO 398 | 399 | 400 v 401 +------------+ 402 | Execute | 403 | ZBP | 404 | Procedures | 405 +------------+ 406 | 407 | Call 408 | in progress 409 | 410 v 411 +--------+ 412 | Call | 413 Success| 414 `......./ 416 Figure 3: Flow Diagram: ZBP Scenario. 418 +-----+ 419 +------------|Start|-----------------+ 420 | `...../ | 421 v v 422 +------------+ +----------------+ 423 | NAA | | Regular | 424 | Procedures | | Network Access | 425 +------------+ | Procedures | 426 | +----------------+ 427 | | 428 | | 429 ----------------o--------------------+ 430 | 431 | 432 | 433 | 434 Network 435 Attachment 436 Completed 437 | 438 | 439 | 440 | 441 v 442 +------------+ +---------+ 443 | ASP | YES | See | 444 | Configured?|----->| main | 445 +------------+ | diagram | 446 | `......../ 447 | 448 | NO 449 | 450 v 451 +------------+ 452 | Execute | 453 | NASP | 454 | Procedures | 455 +------------+ 456 | 457 | Call 458 | in progress 459 | 460 v 461 +--------+ 462 | Call | 463 Success| 464 `......./ 466 Figure 4: Flow Diagram: NASP Scenario. 468 The "No Access Authentication (NAA)" procedures are described in 469 Section 6. The "Zero-balance ASP (ZBP)" procedures are described in 470 Section 4. The "No ASP (NASP)" procedures are described in 471 Section 5. The Phone BCP procedures are described in [RFC6881]. The 472 "Link Layer Attachment (LLA)" procedures are not described in this 473 document since they are specific to the link layer technology in use. 475 4. ZBP Considerations 477 ZBP includes all cases where a subscriber is known to an ASP, but 478 lacks the necessary authorization to access regular ASP services. 479 Example ZBP cases include empty prepaid accounts, barred accounts, 480 roaming and mobility restrictions, or any other conditions set by ASP 481 policy. 483 Local regulation might demand that emergency calls cannot proceed 484 without successful service authorization. In regulatory regimes, 485 however, it may be possible to allow emergency calls to continue 486 despite authorization failures. To distinguish an emergency call 487 from a regular call an ASP can identify emergency sessions by 488 inspecting the service URN [RFC5031] used in call setup. The ZBP 489 case therefore only affects the ASP. 491 Permitting a call despite authorization failures could present an 492 opportunity for abuse. The ASP may choose to verify the destination 493 of the emergency calls and to only permit calls to certain, pre- 494 configured entities (e.g., to local PSAPs). Section 7 discusses this 495 topic in more detail. 497 An ASP without a regulatory requirement to authorize emergency calls 498 can deny emergency call setup. Where an ASP does not authorize an 499 emergency call, the caller may be able to fall back to NASP 500 procedures. 502 5. NASP Considerations 504 To start the description we consider the sequence of steps that are 505 executed in an emergency call based on Figure 5. 507 o As an initial step the devices attaches to the network as shown in 508 step (1). This step is outside the scope of this section. 510 o When the link layer network attachment procedure is completed the 511 end host learns basic IP configuration information using DHCP from 512 the ISP, as shown in step (2). 514 o When the IP address configuration is completed then the end host 515 starts an interaction with the discovered Location Configuration 516 Server at the ISP, as shown in step (3). The ISP may in certain 517 deployments need to interact with the IAP. This protocol exchange 518 is shown in step (4). 520 o Once location information is obtained the end host triggers the 521 LoST protocol to obtain the address of the ESRP/PSAP. This step 522 is shown in (5). 524 o In step (6), the SIP UA initiates a SIP INVITE towards the 525 indicated ESRP. The INVITE message contains all the necessary 526 parameters required by Section 5.1.5. 528 o The ESRP receives the INVITE and processes it according to the 529 description in Section 5.3.3. 531 o The ESRP routes the call to the PSAP, as shown in (8), potentially 532 interacting with a LoST server first to determine the route. 534 o The PSAP evaluates the initial INVITE and aims to complete the 535 call setup. 537 o Finally, when the call setup is completed media traffic can be 538 exchanged between the PSAP and the SIP UA. 540 For editorial reasons the end-to-end SIP and media exchange between 541 the PSAP and SIP UA are not shown in Figure 5. 543 +-------+ 544 | PSAP | 545 | | 546 +-------+ 547 ^ 548 | (8) 549 | 550 +----------+(7) +----------+ 551 | LoST |<-->| ESRP | 552 | Server | | | 553 +----------+ +----------+ 554 ^ ^ 555 +----------------+----------------|--------------+ 556 | ISP | | | 557 |+----------+ | | +----------+| 558 || LCS-ISP | (3)| | | DHCP || 559 || |<-+ | | | Server || 560 |+----------+ | | | +----------+| 561 +-------^------+-+----------------|-----------^--+ 562 +-------|------+-+----------------|-----------|--+ 563 | IAP | (4) | |(5) | | | 564 | V | | | | | 565 |+----------+ | | | | | 566 || LCS-IAP | | | +--------+ | | | 567 || | | | | Link | |(6) | | 568 |+----------+ | | | Layer | | | | 569 | | | | Device | | (2)| | 570 | | | +--------+ | | | 571 | | | ^ | | | 572 | | | | | | | 573 +--------------+-|-------|--------|-----------|--+ 574 | | | | | 575 | | (1)| | | 576 | | | | | 577 | | | +----+ | 578 | | v | | 579 | | +----------+ | 580 | +->| End |<-------------+ 581 +___>| Host | 582 +----------+ 584 Figure 5: Architectural Overview 586 Note: Figure 5 does not indicate who operates the ESRP and the LoST 587 server. Various deployment options exist. 589 5.1. End Host Profile 591 5.1.1. LoST Server Discovery 593 The end host MUST discover a LoST server [RFC5222] using DHCP 594 [RFC5223]. 596 5.1.2. ESRP Discovery 598 The end host MUST discover the ESRP using the LoST protocol 599 [RFC5222]. 601 5.1.3. Location Determination and Location Configuration 603 The end host MUST support location acquisition and the LCPs described 604 in Section 6.5 of [RFC6881]. The description in Section 6.5 and 6.6 605 of [RFC6881] regarding the interaction between the device and the LIS 606 applies to this document. 608 The SIP UA in the end host MUST attach available location information 609 in a PIDF-LO [RFC4119] when making an emergency call. When 610 constructing the PIDF-LO the guidelines in PIDF-LO profile [RFC5491] 611 MUST be followed. For civic location information the format defined 612 in [RFC5139] MUST be supported. 614 5.1.4. Emergency Call Identification 616 To determine which calls are emergency calls, some entity needs to 617 map a user entered dialstring into this URN scheme. A user may 618 "dial" 1-1-2, 9-1-1, etc., but the call would be sent to 619 urn:service:sos. This mapping SHOULD be performed at the endpoint 620 device. 622 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 623 as emergency calls for their home emergency dial string. 625 5.1.5. SIP Emergency Call Signaling 627 SIP signaling capabilities [RFC3261] are REQUIRED for end hosts. 629 The initial SIP signaling method is an INVITE. The SIP INVITE 630 request MUST be constructed according to the requirements in 631 Section 9.2 [RFC6881]. 633 Regarding callback behavior SIP UAs SHOULD place a globally routable 634 URI in a Contact: header. 636 5.1.6. Media 638 End points MUST comply with the media requirements for end points 639 placing an emergency call found in Section 14 of [RFC6881]. 641 5.1.7. Testing 643 The description in Section 15 of [RFC6881] is fully applicable to 644 this document. 646 5.2. IAP/ISP Profile 648 5.2.1. ESRP Discovery 650 An ISP MUST provision a DHCP server with information about LoST 651 servers [RFC5223]. An ISP operator may choose to deploy a LoST 652 server or to outsource it to other parties. 654 5.2.2. Location Determination and Location Configuration 656 The ISP is responsible for location determination and exposes this 657 information to the end points via location configuration protocols. 658 The considerations described in [RFC6444] are applicable to this 659 document. 661 The ISP MUST support one of the LCPs described in Section 6.5 of 662 [RFC6881]. The description in Section 6.5 and 6.6 of [RFC6881] 663 regarding the interaction between the end device and the LIS applies 664 to this document. 666 The interaction between the LIS at the ISP and the IAP is often 667 priorietary but the description in 668 [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. 670 5.3. ESRP Profile 672 5.3.1. Emergency Call Routing 674 The ESRP continues to route the emergency call to the PSAP 675 responsible for the physical location of the end host. This may 676 require further interactions with LoST servers but depends on the 677 specific deployment. 679 5.3.2. Emergency Call Identification 681 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 682 the 'urn:service:sos' tree). 684 5.3.3. SIP Emergency Call Signaling 686 SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The 687 ESRP MUST process the messages sent by the client, according to 688 Section 5.1.5. 690 Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT 691 restrict incoming calls to a particular set of ASPs. 693 6. Lower Layer Considerations for NAA Case 695 Some networks have added support for unauthenticated emergency 696 access, some other type of networks advertise these capabilities 697 using layer beacons. The end host learns about these unauthenticated 698 emergency services capabilities either from the link layer type or 699 from advertisement. 701 It is important to highlight that the NAA case is inherently a layer 702 2 problem, and the general form of the solution is to provide an 703 "emergency only" access type, with appropriate limits/monitoring to 704 prevent abuse. The described mechanisms are informative in nature 705 since the relationship to the IETF emergency services architecture is 706 only indirect, namely via some protocols developed within the IETF 707 (e.g., EAP and EAP methods) that require extensions to support this 708 functionality. 710 This section discusses different methods to indicate an emergency 711 service request as part of network attachment. It provides some 712 general considerations and recommendations that are not specific to 713 the access technology. 715 To perform network attachment and get access to the resources 716 provided by an IAP/ISP, the end host uses access technology specific 717 network attachment procedures, including for example network 718 detection and selection, authentication, and authorization. For 719 initial network attachment of an emergency service requester, the 720 method of how the emergency indication is given to the IAP/ISP is 721 specific to the access technology. However, a number of general 722 approaches can be identified: 724 Link layer emergency indication: The end host provides an 725 indication, e.g., an emergency parameter or flag, as part of the 726 link layer signaling for initial network attachment. Examples 727 include an emergency bit signalled in the IEEE 802.16-2009 728 wireless link. In IEEE 802.11 WLAN, an emergency support 729 indicator allows the station (i.e., end host in this context) to 730 download before association a Network Access Identifier (NAI), 731 which it can use to request server side authentication only for an 732 802.1x network. 734 Higher-layer emergency indication: Typically, emergency indication 735 is provided in the network access authentication procedure. The 736 emergency caller's end host provides an indication as part of the 737 access authentication exchanges. Authentication via the 738 Extensible Authentication Protocol (EAP) [RFC3748] is of 739 particular relevance here. Examples are the EAP NAI decoration 740 used in WiMAX networks and modification of the authentication 741 exchange in IEEE 802.11. [nwgstg3]. 743 6.1. Link Layer Emergency Indication 745 In general, link layer emergency indications provide good integration 746 into the actual network access procedure regarding the enabling of 747 means to recognize and prioritize an emergency service request from 748 an end host at a very early stage of the network attachment 749 procedure. However, support in end hosts for such methods cannot be 750 considered to be commonly available. 752 No general recommendations are given in the scope of this memo due to 753 the following reasons: 755 o Dependency on the specific access technology. 757 o Dependency on the specific access network architecture. Access 758 authorization and policy decisions typically happen at a different 759 layers of the protocol stack and in different entities than those 760 terminating the link-layer signaling. As a result, link layer 761 indications need to be distributed and translated between the 762 different involved protocol layers and entities. Appropriate 763 methods are specific to the actual architecture of the IAP/ISP 764 network. 766 o An advantage of combining emergency indications with the actual 767 network attachment procedure performing authentication and 768 authorization is the fact that the emergency indication can 769 directly be taken into account in the authentication and 770 authorization server that owns the policy for granting access to 771 the network resources. As a result, there is no direct dependency 772 on the access network architecture that otherwise would need to 773 take care of merging link-layer indications into the AA and policy 774 decision process. 776 o EAP signaling happens at a relatively early stage of network 777 attachment, so it is likely to match most requirements for 778 prioritization of emergency signaling. However, it does not cover 779 early stages of link layer activity in the network attachment 780 process. Possible conflicts may arise e.g. in case of MAC-based 781 filtering in entities terminating the link-layer signaling in the 782 network (like a base station). In normal operation, EAP related 783 information will only be recognized in the NAS. Any entity 784 residing between end host and NAS should not be expected to 785 understand/parse EAP messages. 787 o An emergency indication can be given by forming a specific NAI 788 that is used as the identity in EAP based authentication for 789 network entry. 791 6.2. Securing Network Attachment in NAA Cases 793 For network attachment in NAA cases, it may make sense to secure the 794 link-layer connection between the device and the IAP/ISP. This 795 especially holds for wireless access with examples being IEEE 802.11 796 or IEEE 802.16 based access. The latter even mandates secured 797 communication across the wireless link for all IAP/ISP networks based 798 on [nwgstg3]. 800 Therefore, for network attachment that is by default based on EAP 801 authentication it is desirable also for NAA network attachment to use 802 a key-generating EAP method (that provides an MSK key to the 803 authenticator to bootstrap further key derivation for protecting the 804 wireless link). 806 The following approaches to match the above can be identified: 808 1) Server-only Authentication: 810 The device of the emergency service requester performs an EAP 811 method with the IAP/ISP EAP server that performs server side 812 authentication only. An example for this is EAP-TLS [RFC5216]. 813 This provides a certain level of assurance about the IAP/ISP to 814 the device user. It requires the device to be provisioned with 815 appropriate trusted root certificates to be able to verify the 816 server certificate of the EAP server (unless this step is 817 explicitly skipped in the device in case of an emergency service 818 request). This method is used to provide access of devices 819 without existing credentials to an 802.1x network. The details 820 are incorporated into the not yet published 802.11-2011 821 specification. 823 2) Null Authentication: 825 In one case (e.g., WiMAX) an EAP method is performed. However, no 826 credentials specific to either the server or the device or 827 subscription are used as part of the authentication exchange. An 828 example for this would be an EAP-TLS exchange with using the 829 TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly 830 available static key for emergency access could be used. In the 831 latter case, the device would need to be provisioned with the 832 appropriate emergency key for the IAP/ISP in advance. In another 833 case (e.g., IEEE 802.11), no EAP method is used, so that empty 834 frames are transported during the over the air IEEE 802.1X 835 exchange. In this case the authentication state machine completes 836 with no cryptographic keys being exchanged. 838 3) Device Authentication: 840 This case extends the server-only authentication case. If the 841 device is configured with a device certificate and the IAP/ISP EAP 842 server can rely on a trusted root allowing the EAP server to 843 verify the device certificate, at least the device identity (e.g., 844 the MAC address) can be authenticated by the IAP/ISP in NAA cases. 845 An example for this are WiMAX devices that are shipped with device 846 certificates issued under the global WiMAX device public-key 847 infrastructure. To perform unauthenticated emergency calls, if 848 allowed by the IAP/ISP, such devices perform EAP-TLS based network 849 attachment with client authentication based on the device 850 certificate. 852 7. Security Considerations 854 The security threats discussed in [RFC5069] are applicable to this 855 document. 857 There are a couple of new vulnerabilities raised with unauthenticated 858 emergency services in NASP/NAA cases since the PSAP operator will 859 typically not possess any identity information about the emergency 860 caller via the signaling path itself. In countries where this 861 functionality is used for GSM networks today this has lead to a 862 significant amount of misuse. 864 In the context of NAA, the IAP and the ISP will probably want to make 865 sure that the claimed emergency caller indeed performs an emergency 866 call rather than using the network for other purposes, and thereby 867 acting fraudulent by skipping any authentication, authorization and 868 accounting procedures. By restricting access of the unauthenticated 869 emergency caller to the LoST server and the PSAP URI, traffic can be 870 restricted only to emergency calls. This can be accomplished with 871 traffic separation. The details, however, e.g. for using filtering, 872 depend on the deployed ISP architecture and are beyond the scope of 873 this document. 875 We only illustrate a possible model. If the ISP runs its own 876 (caching) LoST server, the ISP would maintain an access control list 877 populated with IP-address information obtained from LoST responses 878 (in the mappings). These URIs would either be URIs for contacting 879 further LoST servers or PSAP URIs. It may be necessary to translate 880 domain names returned in LoST responses to IP addresses. Since the 881 media destination addresses are not predictable, the ISP also has to 882 provide a SIP outbound proxy so that it can determine the media 883 addresses and add those to the filter list. 885 For the ZBP case the additional aspect of fraud has to be considered. 886 Unless the emergency call traverses a PSTN gateway or the ASP charges 887 for IP-to-IP calls, there is little potential for fraud. If the ASP 888 also operates the LoST server, the outbound proxy MAY restrict 889 outbound calls to the SIP URIs returned by the LoST server. It is 890 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 891 change. 893 RFC 6280 [RFC6280] discusses security vulnerabilities that are caused 894 by an adversary faking location information and thereby lying about 895 the actual location of the emergency caller. These threats may be 896 less problematic in the context of unauthenticated emergency when 897 location information can be verified by the ISP to fall within a 898 specific geographical area. 900 8. Acknowledgments 902 Parts of this document are derived from [RFC6881]. Participants of 903 the 2nd and 3rd SDO Emergency Services Workshop provided helpful 904 input. 906 We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc 907 Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT 908 meeting. 910 Furthermore, we would like to thank Martin Thomson and Bernard Aboba 911 for their detailed document review in preparation of the 81st IETF 912 meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A 913 number of changes to the document had been made in response to the AD 914 review by Richard Barnes. 916 9. IANA Considerations 918 This document does not require actions by IANA. 920 10. References 922 10.1. Normative References 924 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 925 Emergency and Other Well-Known Services", RFC 5031, 926 January 2008. 928 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 929 Format", RFC 4119, December 2005. 931 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 932 Presence Information Data Format Location Object (PIDF-LO) 933 Usage Clarification, Considerations, and Recommendations", 934 RFC 5491, March 2009. 936 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 937 Format for Presence Information Data Format Location 938 Object (PIDF-LO)", RFC 5139, February 2008. 940 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 941 A., Peterson, J., Sparks, R., Handley, M., and E. 942 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 943 June 2002. 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, March 1997. 948 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 949 Communications Services in Support of Emergency Calling", 950 BCP 181, RFC 6881, March 2013. 952 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 953 Tschofenig, "LoST: A Location-to-Service Translation 954 Protocol", RFC 5222, August 2008. 956 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 957 Location-to-Service Translation (LoST) Servers Using the 958 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 959 August 2008. 961 10.2. Informative References 963 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 964 Location Configuration Protocol: Problem Statement and 965 Requirements", RFC 5687, March 2010. 967 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 968 "Framework for Emergency Calling Using Internet 969 Multimedia", RFC 6443, December 2011. 971 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 972 Emergency Context Resolution with Internet Technologies", 973 RFC 5012, January 2008. 975 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 976 A. Kuett, "Location Hiding: Problem Statement and 977 Requirements", RFC 6444, January 2012. 979 [I-D.winterbottom-geopriv-lis2lis-req] 980 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 981 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 982 (work in progress), November 2007. 984 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 985 Shanmugam, "Security Threats and Requirements for 986 Emergency Call Marking and Mapping", RFC 5069, January 987 2008. 989 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 990 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 991 3748, June 2004. 993 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 994 Authentication Protocol", RFC 5216, March 2008. 996 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 997 Tschofenig, H., and H. Schulzrinne, "An Architecture for 998 Location and Location Privacy in Internet Applications", 999 BCP 160, RFC 6280, July 2011. 1001 [esw07] "3rd SDO Emergency Services Workshop, 1002 http://www.emergency-services-coordination.info/2007Nov/", 1003 October 30th - November 1st 2007. 1005 [nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 1006 Architecture Stage-3 1007 http://www.wimaxforum.org/sites/wimaxforum.org/files/ 1008 technical_document/2009/09/DRAFT-T33-001-R015v01- 1009 O_Network-Stage3-Base.pdf", September 2009. 1011 Authors' Addresses 1013 Henning Schulzrinne 1014 Columbia University 1015 Department of Computer Science 1016 450 Computer Science Building 1017 New York, NY 10027 1018 US 1020 Phone: +1 212 939 7004 1021 Email: hgs+ecrit@cs.columbia.edu 1022 URI: http://www.cs.columbia.edu 1024 Stephen McCann 1025 Research in Motion UK Ltd 1026 200 Bath Road 1027 Slough, Berks SL1 3XE 1028 UK 1030 Phone: +44 1753 667099 1031 Email: smccann@rim.com 1032 URI: http://www.rim.com 1034 Gabor Bajko 1035 Nokia 1037 Email: Gabor.Bajko@nokia.com 1039 Hannes Tschofenig 1040 Hall in Tirol 6060 1041 Austria 1043 Email: Hannes.Tschofenig@gmx.net 1044 URI: http://www.tschofenig.priv.at 1045 Dirk Kroeselberg 1046 Siemens 1047 Germany 1049 Email: dirk.kroeselberg@siemens.com