idnits 2.17.1 draft-ietf-ecrit-unauthenticated-access-01.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 25, 2010) is 4903 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: 'RFC5223' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'I-D.winterbottom-geopriv-lis2lis-req' is defined on line 926, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-03 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-15 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-11 == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-held-identity-extensions-05 Summary: 0 errors (**), 0 flaws (~~), 8 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 28, 2011 Research in Motion UK Ltd 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 D. Kroeselberg 10 Nokia Siemens Networks 11 October 25, 2010 13 Extensions to the Emergency Services Architecture for dealing with 14 Unauthenticated and Unauthorized Devices 15 draft-ietf-ecrit-unauthenticated-access-01.txt 17 Abstract 19 The IETF emergency services architecture assumes that the calling 20 device has acquired rights to use the access network or that no 21 authentication is required for the access network, such as for public 22 wireless access points. Subsequent protocol interactions, such as 23 obtaining location information, learning the address of the Public 24 Safety Answering Point (PSAP) and the emergency call itself are 25 largely decoupled from the underlying network access procedures. 27 In some cases, however, the device does not have these credentials 28 for network access, does not have a VoIP service provider, or the 29 credentials have become invalid, e.g., because the user has exhausted 30 their prepaid balance or the account has expired. 32 This document provides a problem statement, introduces terminology 33 and describes an extension for the base IETF emergency services 34 architecture to address these scenarios. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 28, 2011. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Use Case Categories . . . . . . . . . . . . . . . . . . . . . 6 73 4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 11 76 5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 11 77 5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 11 78 5.1.3. Location Determination and Location Configuration . . 11 79 5.1.4. Emergency Call Identification . . . . . . . . . . . . 11 80 5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 12 81 5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 12 83 5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 12 84 5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 12 85 5.2.2. Location Determination and Location Configuration . . 12 86 5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 13 88 5.3.2. Emergency Call Identification . . . . . . . . . . . . 13 89 5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 13 90 5.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 13 91 6. Lower Layer Considerations for NAA Case . . . . . . . . . . . 14 92 6.1. Link Layer Emergency Indication . . . . . . . . . . . . . 14 93 6.2. Higher-Layer Emergency Indication . . . . . . . . . . . . 15 94 6.3. Securing Network Attachment in NAA Cases . . . . . . . . . 17 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Summoning police, the fire department or an ambulance in emergencies 106 is one of the fundamental and most-valued functions of the telephone. 107 As telephone functionality moves from circuit-switched telephony to 108 Internet telephony, its users rightfully expect that this core 109 functionality will continue to work at least as well as it has for 110 the older technology. New devices and services are being made 111 available that could be used to make a request for help, which are 112 not traditional telephones, and users are increasingly expecting them 113 to be used to place emergency calls. 115 Roughly speaking, the IETF emergency services architecture (see 116 [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides 117 responsibility for handling emergency calls between the access 118 network (ISP), the application service provider (ASP) that may be a 119 VoIP service provider and the provider of emergency signaling 120 services, the emergency service network (ESN). The access network 121 may provide location information to end systems, but does not have to 122 provide any ASP signaling functionality. The emergency caller can 123 reach the ESN either directly or through the ASP's outbound proxy. 124 Any of the three parties can provide the mapping from location to 125 PSAP URI by offering LoST [RFC5222] services. 127 In general, a set of automated configuration mechanisms allows a 128 device to function in a variety of architectures, without the user 129 being aware of the details on who provides location, mapping services 130 or call routing services. However, if emergency calling is to be 131 supported when the calling device lacks access network authorization 132 or does not have an ASP, one or more of the providers may need to 133 provide additional services and functions. 135 In all cases, the end device has to be able to perform a LoST lookup 136 and otherwise conduct the emergency call in the same manner as when 137 the three exceptional conditions discussed below do not apply. 139 We distinguish between three conditions: 141 No Access Authentication (NAA): In the NAA case, the emergency 142 caller does not posses valid credentials for the access network. 143 This includes the case where the access network allows pay-per- 144 use, as is common for wireless hotspots, but there is insufficient 145 time to enter credit card details and other registration 146 information required for access. It also covers all cases where 147 either no credentials are available at all, or the available 148 credentials do not work for the given IAP/ISP. As a result, the 149 NAA case basically combines the below NASP and ZBP cases, but at 150 the IAP/ISP level. Support for emergency call handling in the NAA 151 case is subject to the local policy of the ISP. Such policy may 152 vary substantially between ISPs and typically depends on external 153 factors that are not under the ISP control. 155 No ASP (NASP): The caller does not have an ASP at the time of the 156 call. This can occur either in case the caller does not possess 157 any valid subscription for a reachable ASP, or in case none of the 158 ASPs where the caller owns a valid subscription is reachable 159 through the ISP. 161 Note: The interoperability need is increased with this scenario 162 since the client software used by the emergency caller must be 163 compatible with the protocols and extensions deployed by the ESN. 165 Zero-balance ASP (ZBP): In the case of zero-balance ASP, the ASP can 166 authenticate the caller, but the caller is not authorized to use 167 ASP services, e.g., because the contract has expired or the 168 prepaid account for the customer has been depleted. 170 These three cases are not mutually exclusive. A caller in need for 171 help may find himself/herself in, for example, a NAA and NASP 172 situation, as explained in more details in Figure 1. Depending on 173 local policy and regulations, it may not be possible to place 174 emergency calls in the NAA case. Unless local regulations require 175 user identification, it should always be possible to place calls in 176 the NASP case, with minimal impact on the ISP. Unless the ESN 177 requires that all calls traverse a known set of VSPs, it is 178 technically possible to let a caller place an emergency call in the 179 ZBP case. We discuss each case in more details in Section 3. 181 Note: At the time of writing there is no regulation in place that 182 demands the functionality described in this memo. SDOs have started 183 their work on this subject in a proactive fashion in the anticipation 184 that national regulation will demand it for a subset of network 185 environments. 187 There are also indications that the functionality of unauthenticated 188 emergency calls (called SIM-less calls) in today's cellular system in 189 certain countries leads to a fair amount of hoax or test calls. This 190 causes overload situations at PSAPs which is considered harmful to 191 the overall availability and reliability of emergency services. 193 As an example, Federal Office of Communications (OFCOM, Switzerland) 194 provided statistics about emergency (112) calls in Switzerland from 195 Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less emergency 196 calls except for almost a month in July 2000 where a significant 197 increase in hoax and test calls was reported. As a consequence, the 198 functionality was disabled again. More details can be found in the 199 panel presentations of the 3rd SDO Emergency Services Workshop 200 [esw07]. 202 2. Terminology 204 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 205 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 206 and "OPTIONAL" are to be interpreted as described in RFC 2119 207 [RFC2119]. 209 This document reuses terminology from [RFC5687] and [RFC5012], namely 210 Internet Access Provider (IAP), Internet Service Provider (ISP), 211 Application Service Provider (ASP), Voice Service Provider (VSP), 212 Emergency Service Routing Proxy (ESRP), Public Safety Answering Point 213 (PSAP), Location Configuration Server (LCS), (emergency) service dial 214 string, and (emergency) service identifier. 216 3. Use Case Categories 218 On a very high-level, the steps to be performed by an end host not 219 being attached to the network and the user starting to make an 220 emergency call are the following: 222 Link Layer Attachment: Some radio networks have added support for 223 unauthenticated emergency access, some other type of networks 224 advertise these capabilities using layer beacons. The end host 225 learns about these unauthenticated emergency services capabilities 226 either from the link layer type or from advertisement. 228 The end host uses the link layer specific network attachment 229 procedures defined for unauthenticated network access in order to 230 get access to the network. 232 Pre-Emergency Service Configuration: When the link layer network 233 attachment procedure is completed the end host learns basic 234 configuration information using DHCP from the ISP, including the 235 address of the LoST server. The end host uses a Location 236 Configuration Protocol (LCP) to retrieve location information. 237 Subsequently, the LoST protocol [RFC5222] is used to learn the 238 relevant emergency numbers, and to obtain the PSAP URI applicable 239 for that location. 241 Emergency Call: In case of need for help, a user dials an emergency 242 number and the SIP UA initiates the emergency call procedures by 243 communicating with the PSAP. 245 Figure 1 compiles the basic logic taking place during network entry 246 for requesting an emergency service and shows the interrelation 247 between the three conditions described in the above section. 249 +-----Y 250 |Start| 251 `...../ 252 | 253 | Are credentials 254 | for network attachment 255 | available? 256 | 257 NO v YES 258 +----------------------------+ 259 | | 260 | | 261 V v 262 .............. ................ 263 | Idle: Wait | |Execute | 264 | for ES Call| |LLA Procedures| 265 | Initiation | "--------------' 266 "------------' | 267 Is | +---------->O 268 emergency | | | Is ASP 269 service | NO +-----Y | | configured? 270 network +--->| End | | +---------------+ 271 attachment| `...../ | YES | | NO 272 possible? | | | | 273 v | v v 274 +------------+ | +------------+ +------------+ 275 | Execute | | | Execute | | Execute | 276 | NAA |--------+ | Phone BCP | | NASP | 277 | Procedures | | Procedures | | Procedures | 278 +------------+ +------------+ +------------+ 279 Authorization for| | 280 Emergency Call? | | 281 +--------------+ v 282 | NO | YES +-----Y 283 | | | Done| 284 v v `...../ 285 +------------+ +------------+ 286 | Execute | | Execute | 287 | ZBP | | Phone BCP | 288 | Procedures | | Procedures | 289 +------------+ +------------+ 290 | | 291 | | 292 v v 293 +-----Y +-----Y 294 | Done| | Done| 295 `...../ `...../ 297 Abbreviations: 298 LLA: Link Layer Attachment 299 ES: Emergency Services 301 Figure 1: Flow Diagram 303 4. ZBP Considerations 305 Although subject to local regulatory mandates, it is expected that 306 for most ASPs even with a lack of authorization for regular service 307 an otherwise authenticated and known subscriber must be granted 308 access to emergency services. Naturally, without an obligation to 309 support emergency services in ZBP cases an ASP can simply disallow 310 access by such customers. As a result, all such subscribers may fall 311 back into a NASP situation as described above. 313 If ASPs desire or are required by regulation to provide emergency 314 services to subscribers with valid credentials that only fail 315 authorization, the emergency services nature of a call can easily be 316 determined by inspecting the call setup procedure for the presence of 317 the emergency service URNs. This example shows that in the context 318 of this document no specific considerations apply to the ZBP case due 319 to the fact that the ASP will be able to relate the service request 320 to an existing subscription or user and will be in control of 321 adjusting any authorization decision based on its deployemnt specific 322 policy. It is, however, noted that specific security considerations 323 apply due to the fact that emergency service access will likely be 324 granted with limited authorization only, see Section 7. 326 ZBP cases in the context of this document cover all cases where an 327 otherwise valid subscription lacks authorization to access or regular 328 ASP services, i.e., a lack of authorization that would block the 329 subscriber from using the service for emergency purpose. Example ZBP 330 cases include empty prepaid accounts, barred accounts, or certain 331 roaming or mobility restrictions. The exact list of cases where 332 emergency services need to be supported by the ASP is local to the 333 ASP policy and deployment, and is therefore beyond the scope of this 334 document. 336 5. NASP Considerations 338 To start the description we consider the sequence of steps that are 339 executed in an emergency call based on Figure 2. 341 o As an initial step the devices attaches to the network as shown in 342 step (1). This step is outside the scope of this section. 343 o When the link layer network attachment procedure is completed the 344 end host learns basic configuration information using DHCP from 345 the ISP, including the address of the ESRP, as shown in step (2). 346 o When the IP address configuration is completed then the SIP UA 347 initiates a SIP INVITE towards the indicated ESRP, as shown in 348 (3). The INVITE message contains all the necessary parameters 349 required by Section 5.1.5. 350 o The ESRP receives the INVITE and processes it according to the 351 description in Section 5.3.3. The location of the end host may 352 need to be determined using a protocol interaction shown in (4). 353 o Potentially, an interaction between the LCS of the ISP and the LCS 354 of the IAP may be necessary, see (5). 355 o Finally, the correct PSAP for the location of the end host has to 356 be evaluated, see (6). 357 o The ESRP routes the call to the PSAP, as shown in (7). 358 o The PSAP evaluates the initial INVITE and aims to complete the 359 call setup. 360 o Finally, when the call setup is completed media traffic can be 361 exchanged between the PSAP and the emergency caller. 363 For editorial reasons the end-to-end SIP and media exchange between 364 the PSAP and SIP UA are not shown in Figure 2. 366 Two important aspects are worth to highlight: 368 o The IAP/ISP needs to understand the concept of emergency calls or 369 other emergency applicationsand the SIP profile described in this 370 document. No other VoIP protocol profile, such as XMPP, Skype, 371 etc., are supported for emergency calls in this particular 372 architecture. Other profiles may be added in the future, but the 373 deployment effort is enormous since they have to be universally 374 deployed. 375 o The end host has no obligation to determine location information. 376 It may attach location information if it has location available 377 (e.g., from a GPS receiver). 379 Figure 2 shows that the ISP needs to deploy SIP-based emergency 380 services functionality. It is important to note that the ISP itself 381 may outsource the functionality by simply providing access to them 382 (e.g., it puts the IP address of an ESRP or a LoST server into an 383 allow-list). For editorial reasons this outsourcing is not shown. 385 +-------+ +-------+ 386 | PSAP | (7) | ESRP | 387 | |<----->| | 388 +-------+ +-------+ 389 ^ 390 | (7) 391 v 392 +----------+ (6) +----------+ 393 | Mapping |<----->| ESRP | 394 | Database | | |<-+ 395 +----------+ +----------+ | 396 ^ | 397 +------------------------|--------|--------------+ 398 | ISP | | | 399 |+----------+ | | +----------+| 400 || LCS-ISP | | | | DHCP || 401 || |<-----------+ | | Server || 402 |+----------+ (4) | +----------+| 403 +-------^-------------------------|-----------^--+ 404 +-------|-------------------------|-----------|--+ 405 | IAP | (5) | | | 406 | V | | | 407 |+----------+ | | | 408 || LCS-IAP | +--------+ | | | 409 || | | Link | |(3) | | 410 |+----------+ | Layer | | | | 411 | | Device | | (2)| | 412 | +--------+ | | | 413 | ^ | | | 414 | | | | | 415 +------------------------|--------|-----------|--+ 416 | | | 417 (1)| | | 418 | | | 419 | +----+ | 420 v v | 421 +----------+ | 422 | End |<-------------+ 423 | Host | 424 +----------+ 426 Figure 2: Architectural Overview 428 Note: Figure 2 does not indicate who runs the ESRP or the mapping 429 database. There are different options available. 431 5.1. End Host Profile 433 5.1.1. LoST Server Discovery 435 The end host MAY attempt to use [RFC5222] to discover a LoST server. 436 If that attempt fails, the end host SHOULD attempt to discover the 437 address of an ESRP. 439 5.1.2. ESRP Discovery 441 The end host only needs an ESRP when location configuration or LoST 442 server discovery fails. If that is the case, then the end host MUST 443 use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option 444 for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6) 445 and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options 446 for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover 447 the address of an ESRP. This SIP proxy located in the ISP network 448 will be used as the ESRP for routing emergency calls. There is no 449 need to discovery a separate SIP proxy with specific emergency call 450 functionality since the internal procedure for emergency call 451 processing is subject of ISP internal operation. 453 5.1.3. Location Determination and Location Configuration 455 The end host SHOULD attempt to use the supported LCPs to configure 456 its location. If no LCP is supported in the end host or the location 457 configuration is not successful, then the end host MUST attempt to 458 discover an ESRP, which would assist the end host in providing the 459 location to the PSAP. 461 The SIP UA in the end host MUST attach available location information 462 in a PIDF-LO [RFC4119] when making an emergency call. When 463 constructing the PIDF-LO the guidelines in PIDF-LO profile [RFC5491] 464 MUST be followed. For civic location information the format defined 465 in [RFC5139] MUST be supported. 467 5.1.4. Emergency Call Identification 469 To determine which calls are emergency calls, some entity needs to 470 map a user entered dialstring into this URN scheme. A user may 471 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 472 mapping SHOULD be performed at the endpoint device. 474 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 475 as emergency calls for their home emergency dial string (if known). 476 For visited emergency dial string the translation into the Service 477 URN mechanism is not mandatory since the ESRP in the ISPs network 478 knows the visited emergency dial strings. 480 5.1.5. SIP Emergency Call Signaling 482 SIP signaling capabilities [RFC3261] are mandated for end hosts. 484 The initial SIP signaling method is an INVITE. The SIP INVITE 485 request MUST be constructed according to the requirements in Section 486 9.2 [I-D.ietf-ecrit-phonebcp]. 488 Regarding callback behavior SIP UAs MUST have a globally routable URI 489 in a Contact: header. 491 5.1.6. Media 493 End points MUST comply with the media requirements for end points 494 placing an emergency call found in Section 14 of 495 [I-D.ietf-ecrit-phonebcp]. 497 5.1.7. Testing 499 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully 500 applicable to this document. 502 5.2. IAP/ISP Profile 504 5.2.1. ESRP Discovery 506 An ISP hosting an ESRP MUST implement the server side part of 507 "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for 508 Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and / 509 or the "Dynamic Host Configuration Protocol (DHCPv6) Options for 510 Session Initiation Protocol (SIP) Servers" [RFC3319]. 512 5.2.2. Location Determination and Location Configuration 514 When receiving an INVITE message the following steps are done: 515 1. If the INVITE message does not include location information the 516 ESRP-registrar MUST use HELD identity 517 [I-D.ietf-geopriv-held-identity-extensions] to obtain the 518 location of the device as both a location value and reference. 519 In order to contact the LIS the ESRP-registrar SHOULD determine 520 the LIS address using the mechanism described in 521 [I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar 522 MAY use other methods for LIS determination where available. 523 2. If the INVITE message contains a location URI then the ESRP- 524 registrar MUST dereference it so that it has a location available 525 to route the impending emergency call. The ESRP-registrar MAY 526 validate the LIS address in the location URI with that of the LIS 527 serving the network from which the INVITE message originated. 528 3. The INVITE message contains location information by value. Any 529 actions performed by the ESRP-registrar to valid this information 530 are specific to the jurisdiction in which the ESRP operates and 531 are out of the scope of this document. 533 5.3. ESRP Profile 535 5.3.1. Emergency Call Routing 537 The ESRP must route the emergency call to the PSAP responsible for 538 the physical location of the end host. However, a standardized 539 approach for determining the correct PSAP based on a given location 540 is useful but not mandatory. 542 For cases where a standardized protocol is used LoST [RFC5222] is a 543 suitable mechanism. 545 5.3.2. Emergency Call Identification 547 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 548 the 'urn:service:sos' tree) and additionally the national emergency 549 dial strings. The ESRP SHOULD perform a mapping of national 550 emergency dial strings to Service URNs to simplify processing at 551 PSAPs. 553 5.3.3. SIP Emergency Call Signaling 555 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 556 ESRP MUST process the messages sent by the client, according to 557 Section 5.1.5. Furthermore, the ESRP MUST be able to add a reference 558 to location information, as described in SIP Location Conveyance 559 [I-D.ietf-sipcore-location-conveyance], before forwarding the call to 560 the PSAP. The ISP MUST be prepared to receive incoming dereferencing 561 requests to resolve the reference to the location information. 563 5.3.4. Location Retrieval 565 The ESRP acts a location recipient and the usage of HELD [RFC5985] 566 with the identity extensions 567 [I-D.ietf-geopriv-held-identity-extensions] may be a possible choice. 568 The ESRP would thereby act as a HELD client and the corresponding LIS 569 at the ISP as the HELD server. 571 The ESRP needs to obtain enough information to route the call. The 572 ESRP itself, however, does not necessarily need to process location 573 information obtained via HELD since it may be used as input to LoST 574 to obtain the PSAP URI. 576 6. Lower Layer Considerations for NAA Case 578 Some radio networks have added support for unauthenticated emergency 579 access, some other type of networks advertise these capabilities 580 using layer beacons. The end host learns about these unauthenticated 581 emergency services capabilities either from the link layer type or 582 from advertisement. 584 This section discusses different methods to indicate an emergency 585 service request as part of network attachment. It provides some 586 general considerations and recommendations that are not specific to 587 the access technology. 589 To perform network attachment and get access to the resources 590 provided by an IAP/ISP, the end host uses access technology specific 591 network attachment procedures, including for example network 592 detection and selection, authentication, and authorization. For 593 initial network attachment of an emergency service requester, the 594 method of how the emergency indication is given to the IAP/ISP is 595 specific to the access technology. However, a number of general 596 approaches can be identified: 598 Link layer emergency indication: The end host provides an 599 indication, e.g. an emergency parameter or flag, as part of the 600 link layer signaling for initial network attachment. Examples 601 include an emergency bit signalled in the IEEE 802.16-2009 602 wireless link. signalling allows an IEEE 802.1X to occur without 603 exchanging cryptogrpahic keys. 605 Higher-layer emergency indication: Typically emergency indication in 606 access authentication. The emergency caller's end host provides 607 an indication as part of the access authentication exchanges. EAP 608 based authentication is of particular relevance here. [nwgstg3]. 610 6.1. Link Layer Emergency Indication 612 In general, link layer emergency indications provide good integration 613 into the actual network access procedure regarding the enabling of 614 means to recognize and prioritize an emergency service request from 615 an end host at a very early stage of the network attachment 616 procedure. However, support in end hosts for such methods cannot be 617 considered to be commonly available. 619 No general recommendations are given in the scope of this memo due to 620 the following reasons: 621 o Dependency on the specific access technology. 622 o Dependency on the specific access network architecture. Access 623 authorization and policy decisions typically happen at a different 624 layers of the protocol stack and in different entities than those 625 terminating the link-layer signaling. As a result, link layer 626 indications need to be distributed and translated between the 627 different involved protocol layers and entities. Appropriate 628 methods are specific to the actual architecture of the IAP/ISP 629 network. 631 6.2. Higher-Layer Emergency Indication 633 This section focuses on emergency indications based on authentication 634 and authorization in EAP-based network access. 636 An advantage of combining emergency indications with the actual 637 network attachment procedure performing authentication and 638 authorization is the fact that the emergency indication can directly 639 be taken into account in the authentication and authorization server 640 that owns the policy for granting access to the network resources. 641 As a result, there is no direct dependency on the access network 642 architecture that otherwise would need to take care of merging link- 643 layer indications into the AA and policy decision process. 645 EAP signaling happens at a relatively early stage of network 646 attachment, so it is likely to match most requirements for 647 prioritization of emergency signaling. However, it does not cover 648 early stages of link layer activity in the network attachment 649 process. Possible conflicts may arise e.g. in case of MAC-based 650 filtering in entities terminating the link-layer signaling in the 651 network (like a base station). In normal operation, EAP related 652 information will only be recognized in the NAS. Any entity residing 653 between end host and NAS should not be expected to understand/parse 654 EAP messages. 656 The following potential methods to provide emergency indications in 657 combination with EAP-based network attachment, are recognized: 659 1. NAI-based emergency indication: 661 An emergency indication can be given by forming a specific NAI 662 that is used as the identity in EAP based authentication for 663 network entry. Methods include: 665 2. 666 1.a) NAI Decoration: 668 NAI decoration is commonly used in routing EAP responses 669 within the IAP/ISP AAA infrastructure. Additional decoration 670 can be used to add an indication that the network attachment 671 attempt is meant for accessing emergency services. Potential 672 advantages of such approach include that it requires only 673 minimal realization effort compared to link-layer indications 674 with good integration into the authentication and 675 authorization procedures. The same procedure can be used for 676 all NAA cases (both unauthenticated and unauthorized) as well 677 as for normal attachment with a valid subscription. A 678 potential disadvantage is that such EAP decoration is not 679 globally defined across all different access technologies. 681 1.b) Emergency NAI: 683 The NAI comes with a realm or username part indicating 684 emergency (e.g. 'emergency@emergency.com'). An advantage of 685 this method for NAA cases is that no new requirements are put 686 on the involved signaling procedures. Only the identity used 687 for network entry is impacted. Potential disadvantages 688 include that different methods to indicate emergency for NAA 689 cases and standard emergency network attachments may be 690 required. Also, modifying the NAI itself (the username@realm 691 part) may conflict with network selection and network entry 692 procedures, depending on the actual access network. 693 3. Emergency EAP method 695 An emergency indication can be given by using a dedicated EAP 696 method that is reserved for emergency network attachment only. 697 2.a) Existing EAP method with New Method Type: 699 An existing EAP method may be used. EAP methods themselves 700 typically do not support emergency indication. One option 701 would be to pick a common EAP method like EAP-TLS and allocate 702 a new method type for the same method that is exclusively 703 reserved to emergency use. Such EAP method should be chosen 704 in a way that the same method can support NAA cases as well as 705 standard emergency network attachment. 707 2.b) Existing EAP Method: 709 Same as 2a), but without assigning a new EAP method type for 710 emergency. In this case some implicit indication must be 711 used. For example, in cases where EAP-TLS is used in network 712 attachment in combination with client certificates, the 713 absence of a client certificate could be interpreted by the 714 network as a request for emergency network attachment. 716 2.c) Emergency EAP Method: 718 A new EAP method could be defined that is specifically 719 designed for emergency network entry in NAA cases. Most 720 likely, such EAP method would not be usable for standard 721 emergency network attachment with an existing subscription. 722 Such dedicated emergency EAP method should be key-generating 723 in compliance with RFC3748 to enable the regular air interface 724 security methods even in unauthenticated operation. 726 6.3. Securing Network Attachment in NAA Cases 728 For network attachment in NAA cases, it may make sense to secure the 729 link-layer connection between the device and the IAP/ISP. This 730 especially holds for wireless access with examples being based 731 access. The latter even mandates secured communication across the 732 wireless link for all IAP/ISP networks based on [nwgstg3]. 734 Therefore, for network attachment that is by default based on EAP 735 authentication it is desirable also for NAA network attachment to use 736 a key-generating EAP method (that provides an MSK key to the 737 authenticator to bootstrap further key derivation for protecting the 738 wireless link). 740 The following approaches to match the above can be identified: 742 1) Server-only Authentication: 744 The device of the emergency service requester performs an EAP 745 method with the IAP/ISP EAP server that performs server 746 authentication only. An example for this is EAP-TLS. This 747 provides a certain level of assurance about the IAP/ISP to the 748 device user. It requires the device to be provisioned with 749 appropriate trusted root certificates to be able to verify the 750 server certificate of the EAP server (unless this step is 751 explicitly skipped in the device in case of an emergency service 752 request). 754 2) Null Authentication: 756 an EAP method is performed. However, no credentials specific to 757 either the server or the device or subscription are used as part 758 of the authentication exchange. An example for this would be an 759 EAP-TLS exchange with using the TLS_DH_anon (anonymous) 760 ciphersuite. Alternatively, a publicly available static key for 761 emergency access could be used. In the latter case, the device 762 would need to be provisioned with the appropriate emergency key 763 for the IAP/ISP in advance. 765 3) Device Authentication: 767 This case extends the server-only authentication case. If the 768 device is configured with a device certificate and the IAP/ISP EAP 769 server can rely on a trusted root allowing the EAP server to 770 verify the device certificate, at least the device identity (e.g., 771 the MAC address) can be authenticated by the IAP/ISP in NAA cases. 772 An example for this are WiMAX devices that are shipped with device 773 certificates issued under the global WiMAX device public-key 774 infrastructure. To perform unauthenticated emergency calls, if 775 allowed by the IAP/ISP, such devices perform EAP-TLS based network 776 attachment with client authentication based on the device 777 certificate. 779 7. Security Considerations 781 The security threats discussed in [RFC5069] are applicable to this 782 document. 784 There are a couple of new vulnerabilities raised with unauthenticated 785 emergency services in NASP/NAA cases since the PSAP operator will 786 typically not possess any identity information about the emergency 787 call via the signaling path itself. In countries where this 788 functionality is used for GSM networks today this has lead to a 789 significant amount of misuse. 791 In the context of NAA, the IAP and the ISP will probably want to make 792 sure that the claimed emergency caller indeed performs an emergency 793 call rather than using the network for other purposes, and thereby 794 acting fraudulent by skipping any authentication, authorization and 795 accounting procedures. By restricting access of the unauthenticated 796 emergency caller to the LoST server and the PSAP URI, traffic can be 797 restricted only to emergency calls. This can be accomplished with 798 traffic separation. The details, however, e.g. for using filtering, 799 depend on the deployed ISP architecture and are beyond the scope of 800 this document. 802 We only illustrate a possible model. If the ISP runs its own LoST 803 server, it would maintain an access control list including all IP 804 addresses contained in responses returned by the LoST server, as well 805 as the LoST server itself. (It may need to translate the domain 806 names returned to IP addresses and hope that the resolution captures 807 all possible DNS responses.) Since the media destination addresses 808 are not predictable, the ISP also has to provide a SIP outbound proxy 809 so that it can determine the media addresses and add those to the 810 filter list. 812 For the ZBP case the additional aspect of fraud has to be considered. 813 Unless the emergency call traverses a PSTN gateway or the ASP charges 814 for IP-to-IP calls, there is little potential for fraud. If the ASP 815 also operates the LoST server, the outbound proxy MAY restrict 816 outbound calls to the SIP URIs returned by the LoST server. It is 817 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 818 change. 820 Finally, a number of security vulnerabilities discussed in 821 [I-D.ietf-geopriv-arch] around faked location information are less 822 problematic in the context of unauthenticated emergency since 823 location information does not need to be provided by the end host 824 itself or it can be verified to fall within a specific geographical 825 area. 827 8. Acknowledgments 829 Parts of this document are derived from [I-D.ietf-ecrit-phonebcp]. 830 Participants of the 2nd and 3rd SDO Emergency Services Workshop 831 provided helpful input. 833 9. IANA Considerations 835 This document does not require actions by IANA. 837 10. References 839 10.1. Normative References 841 [I-D.ietf-sipcore-location-conveyance] 842 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 843 for the Session Initiation Protocol", 844 draft-ietf-sipcore-location-conveyance-03 (work in 845 progress), July 2010. 847 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 848 Emergency and Other Well-Known Services", RFC 5031, 849 January 2008. 851 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 852 Format", RFC 4119, December 2005. 854 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 855 Presence Information Data Format Location Object (PIDF-LO) 856 Usage Clarification, Considerations, and Recommendations", 857 RFC 5491, March 2009. 859 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 860 Format for Presence Information Data Format Location 861 Object (PIDF-LO)", RFC 5139, February 2008. 863 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 864 (DHCP-for-IPv4) Option for Session Initiation Protocol 865 (SIP) Servers", RFC 3361, August 2002. 867 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 868 Protocol (DHCPv6) Options for Session Initiation Protocol 869 (SIP) Servers", RFC 3319, July 2003. 871 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 872 A., Peterson, J., Sparks, R., Handley, M., and E. 873 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 874 June 2002. 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, March 1997. 879 [I-D.ietf-ecrit-phonebcp] 880 Rosen, B. and J. Polk, "Best Current Practice for 881 Communications Services in support of Emergency Calling", 882 draft-ietf-ecrit-phonebcp-15 (work in progress), 883 July 2010. 885 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 886 Tschofenig, "LoST: A Location-to-Service Translation 887 Protocol", RFC 5222, August 2008. 889 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 890 Location-to-Service Translation (LoST) Servers Using the 891 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 892 August 2008. 894 10.2. Informative References 896 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 897 Location Configuration Protocol: Problem Statement and 898 Requirements", RFC 5687, March 2010. 900 [I-D.ietf-ecrit-framework] 901 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 902 "Framework for Emergency Calling using Internet 903 Multimedia", draft-ietf-ecrit-framework-11 (work in 904 progress), July 2010. 906 [I-D.thomson-geopriv-res-gw-lis-discovery] 907 Thomson, M. and R. Bellis, "Location Information Server 908 (LIS) Discovery using IP address and Reverse DNS", 909 draft-thomson-geopriv-res-gw-lis-discovery-04 (work in 910 progress), September 2010. 912 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 913 RFC 5985, September 2010. 915 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 916 Emergency Context Resolution with Internet Technologies", 917 RFC 5012, January 2008. 919 [I-D.ietf-geopriv-held-identity-extensions] 920 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 921 Barnes, "Use of Device Identity in HTTP-Enabled Location 922 Delivery (HELD)", 923 draft-ietf-geopriv-held-identity-extensions-05 (work in 924 progress), October 2010. 926 [I-D.winterbottom-geopriv-lis2lis-req] 927 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 928 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 929 (work in progress), November 2007. 931 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 932 Shanmugam, "Security Threats and Requirements for 933 Emergency Call Marking and Mapping", RFC 5069, 934 January 2008. 936 [I-D.ietf-geopriv-arch] 937 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 938 Tschofenig, H., and H. Schulzrinne, "An Architecture for 939 Location and Location Privacy in Internet Applications", 940 draft-ietf-geopriv-arch-03 (work in progress), 941 October 2010. 943 [esw07] "3rd SDO Emergency Services Workshop, 944 http://www.emergency-services-coordination.info/2007Nov/", 945 October 30th - November 1st 2007. 947 [nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 948 Architecture Stage-3 949 http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech 950 nical_document/2009/09/ 951 DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf", 952 September 2009. 954 Authors' Addresses 956 Henning Schulzrinne 957 Columbia University 958 Department of Computer Science 959 450 Computer Science Building 960 New York, NY 10027 961 US 963 Phone: +1 212 939 7004 964 Email: hgs+ecrit@cs.columbia.edu 965 URI: http://www.cs.columbia.edu 967 Stephen McCann 968 Research in Motion UK Ltd 969 200 Bath Road 970 Slough, Berks SL1 3XE 971 UK 973 Phone: +44 1753 667099 974 Email: smccann@rim.com 975 URI: http://www.rim.com 977 Gabor Bajko 978 Nokia 980 Email: Gabor.Bajko@nokia.com 982 Hannes Tschofenig 983 Nokia Siemens Networks 984 Linnoitustie 6 985 Espoo 02600 986 Finland 988 Phone: +358 (50) 4871445 989 Email: Hannes.Tschofenig@gmx.net 990 URI: http://www.tschofenig.priv.at 991 Dirk Kroeselberg 992 Nokia Siemens Networks 993 St.-Martin-Str. 76 994 Munich 81541 995 Germany 997 Phone: +49 (89) 515933019 998 Email: Dirk.Kroeselberg@nsn.com