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