idnits 2.17.1 draft-schulzrinne-ecrit-unauthenticated-access-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2010) is 5037 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-14 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-10 == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-held-identity-extensions-04 == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). 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, 2011 Research in Motion UK Ltd 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 D. Kroeselberg 10 Nokia Siemens Networks 11 July 11, 2010 13 Extensions to the Emergency Services Architecture for dealing with 14 Unauthenticated and Unauthorized Devices 15 draft-schulzrinne-ecrit-unauthenticated-access-08.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, the device does not have credentials for network 28 access, does not have a VoIP provider or application service provider 29 (ASP), or the credentials have become invalid, e.g., because the user 30 has exhausted 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 January 12, 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 1.1. No Access Authorization (NAA) . . . . . . . . . . . . . . 5 72 1.2. No ASP (NASP) . . . . . . . . . . . . . . . . . . . . . . 6 73 1.3. Zero-Balance Application Service Provider (ZBP) . . . . . 6 74 2. A Warning Note . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4. Considerations for ISPs to support Unauthenticated 77 Emergency Services without Architecture Extensions . . . . . . 7 78 5. Considerations for ISPs to support Unauthenticated 79 Emergency Services with Architecture Extensions . . . . . . . 8 80 6. NAA considerations for the network attachment procedure of 81 IAPs/ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. Link layer emergency indication . . . . . . . . . . . . . 12 83 6.2. Higher-layer emergency indication . . . . . . . . . . . . 13 84 6.3. Securing network attachment in NAA cases . . . . . . . . . 14 85 7. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 7.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 15 87 7.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 15 88 7.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 15 89 7.1.3. Location Determination and Location Configuration . . 15 90 7.1.4. Emergency Call Identification . . . . . . . . . . . . 15 91 7.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 16 92 7.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 16 94 7.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 16 95 7.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16 96 7.2.2. Location Determination and Location Configuration . . 16 97 7.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 17 98 7.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 17 99 7.3.2. Emergency Call Identification . . . . . . . . . . . . 17 100 7.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 17 101 7.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 17 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 110 1. Introduction 112 Summoning police, the fire department or an ambulance in emergencies 113 is one of the fundamental and most-valued functions of the telephone. 114 As telephone functionality moves from circuit-switched telephony to 115 Internet telephony, its users rightfully expect that this core 116 functionality will continue to work at least as well as it has for 117 the older technology. New devices and services are being made 118 available that could be used to make a request for help, which are 119 not traditional telephones, and users are increasingly expecting them 120 to be used to place emergency calls. 122 Roughly speaking, the IETF emergency services architecture (see 123 [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides 124 responsibility for handling emergency calls between the access 125 network (ISP), the application service provider (ASP) that may be a 126 VoIP service provider and the provider of emergency signaling 127 services, the emergency service network (ESN). The access network 128 may provide location information to end systems, but does not have to 129 provide any ASP signaling functionality. The emergency caller can 130 reach the ESN either directly or through the ASP's outbound proxy. 131 Any of the three parties can provide the mapping from location to 132 PSAP URI by offering LoST [RFC5222] services. 134 In general, a set of automated configuration mechanisms allows a 135 device to function in a variety of architectures, without the user 136 being aware of the details on who provides location, mapping services 137 or call routing services. However, if emergency calling is to be 138 supported when the calling device lacks access network authorization 139 or does not have an ASP, one or more of the providers may need to 140 provide additional services and functions. 142 In all cases, the end device MUST be able to perform a LoST lookup 143 once it has established IP connectivity, and otherwise conduct the 144 emergency call in the same manner as when the three exceptional 145 conditions discussed below do not apply. 147 We distinguish between three conditions: 149 No access authorization (NAA): The current access network requires 150 access authorization and the caller does not have valid user 151 credentials. (This includes the case where the access network 152 allows pay-per-use, as is common for wireless hotspots, but there 153 is insufficient time to pay for access.) 155 No ASP (NASP): The caller does not have an ASP at the time of the 156 call. 158 Zero-balance ASP (ZBP): The caller has valid credentials with an 159 ASP, but is not allowed to access services like placing calls in 160 case of a VoIP service, e.g., because the user has a zero balance 161 in a prepaid account. 163 A user may well suffer from both NAA and NASP or ZBP at the same 164 time. Depending on local policy and regulations, it may not be 165 possible to place emergency calls in the NAA case. Unless local 166 regulations require user identification, it should always be possible 167 to place calls in the NASP case, with minimal impact on the ISP. 168 Unless the ESN requires that all calls traverse a known set of VSPs, 169 a caller should be able to place an emergency call in the ZBP case. 170 We discuss each case in separate sections below. 172 1.1. No Access Authorization (NAA) 174 In the NAA (No Access Authorization) case, the emergency caller does 175 not posses valid credentials for the access network. If local 176 regulations or policy allows or requires support for emergency calls 177 in NAA, the access network may or needs to cooperate in providing 178 emergency calling services. Support for NAA emergency calls is 179 subject to the local policy of the ISP. Such policy may vary 180 substantially between ISPs and typically depends on external factors 181 that are not under the ISP control. Hence, no global mandates for 182 supporting emergency calls in relation to NAA can be made. However, 183 it makes a lot of sense to offer appropriate building blocks that 184 enable ISPs to flexibly react on the local environment. Generally, 185 the ISP will want to ensure that devices do not pretend to place 186 emergency calls, but then abuse the access for obtaining more general 187 services fraudulently. 189 In particular, the ISP MUST allow emergency callers to acquire an IP 190 address and to reach a LoST server, either provided by the ISP or 191 some third party. It SHOULD also provide location information via 192 one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without 193 requiring authorization unless it can safely assume that all nodes in 194 the access network can determine their own location, e.g., via GPS. 196 The details of how filtering is performed depends on the details of 197 the ISP architecture and are beyond the scope of this document. We 198 illustrate a possible model. If the ISP runs its own LoST server, it 199 would maintain an access control list including all IP addresses 200 contained in responses returned by the LoST server, as well as the 201 LoST server itself. (It may need to translate the domain names 202 returned to IP addresses and hope that the resolution captures all 203 possible DNS responses.) Since the media destination addresses are 204 not predictable, the ISP also has to provide a SIP outbound proxy so 205 that it can determine the media addresses and add those to the filter 206 list. 208 1.2. No ASP (NASP) 210 In the second case, the emergency caller has no current ASP. This 211 case poses no particular difficulties unless it is assumed that only 212 ASPs provide LoST server or that ESNs only accept calls that reach it 213 through a set of known ASPs. However, since the calling device 214 cannot obtain configuration information from its ASP, the ISP MUST 215 provide the address of a LoST server via DHCP [RFC5223] if this model 216 is to be supported. The LoST server may be operated either by the 217 ISP or a third party. 219 1.3. Zero-Balance Application Service Provider (ZBP) 221 In the case of zero-balance ASP, the ASP can authenticate the caller, 222 but the caller is not authorized to use ASP services, e.g., because 223 the contract has expired or the prepaid account for the customer has 224 been depleted. Naturally, an ASP can simply disallow access by such 225 customers, so that all such customers find themselves in the NASP 226 situation described above. If ASPs desire or are required by 227 regulation to provide emergency calling services to such customers, 228 they need to provide LoST services to such customers and may need to 229 provide outbound SIP proxy services. As usual, the calling device 230 looks up the LoST server via SIP configuration. 232 Unless the emergency call traverses a PSTN gateway or the ASP charges 233 for IP-to-IP calls, there is little potential for fraud. If the ASP 234 also operates the LoST server, the outbound proxy MAY restrict 235 outbound calls to the SIP URIs returned by the LoST server. It is 236 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 237 change. 239 2. A Warning Note 241 At the time of writing there is no regulation in place that demands 242 the functionality described in this memo. SDOs have started their 243 work on this subject in a proactive fashion in the anticipation that 244 national regulation will demand it for a subset of network 245 environments. 247 There are also indications that the functionality of unauthenticated 248 emergency calls (called SIM-less calls) in today's cellular system in 249 certain countries leads to a fair amount of hoax or test calls. This 250 causes overload situations at PSAPs which is considered harmful to 251 the overall availability and reliability of emergency services. 253 As an example, Federal Office of Communications (OFCOM, 254 Switzerland) provided statistics about emergency (112) calls in 255 Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not 256 offer SIM-less emergency calls except for almost a month in July 257 2000 where a significant increase in hoax and test calls was 258 reported. As a consequence, the functionality was disabled again. 259 More details can be found in the panel presentations of the 3rd 260 SDO Emergency Services Workshop [esw07]. 262 3. Terminology 264 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 265 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 266 and "OPTIONAL" are to be interpreted as described in RFC 2119 267 [RFC2119]. 269 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 270 and [RFC5012], namely Internet Access Provider (IAP), Internet 271 Service Provider (ISP), Application Service Provider (ASP), Voice 272 Service Provider (VSP), Emergency Service Routing Proxy (ESRP), 273 Public Safety Answering Point (PSAP), Location Configuration Server 274 (LCS), (emergency) service dial string, and (emergency) service 275 identifier. 277 4. Considerations for ISPs to support Unauthenticated Emergency 278 Services without Architecture Extensions 280 This section provides a recommended configuration for unauthenticated 281 emergency services support without architecture extensions. 283 On a very high-level, the steps to be performed by an end host not 284 being attached to the network and the user starting to make an 285 emergency call are the following: 287 o Some radio networks have added support for unauthenticated 288 emergency access, some other type of networks advertise these 289 capabilities using layer beacons. The end host learns about these 290 unauthenticated emergency services capabilities either from the 291 link layer type or from link layer advertisement. 292 o A security association may be established for the purpose of data 293 confidentiality at the link layer. However, since the link layer 294 is limited to a broadcast domain, it would be better to establish 295 a security association at higher layers. 296 o The end host uses the link layer specific network attachment 297 procedures defined for unauthenticated network access in order to 298 get access to emergency services. 299 o When the link layer network attachment procedure is completed the 300 end host learns basic configuration information using DHCP from 301 the ISP, including the address of the LoST server. 302 o The end host MUST use a Location Configuration Protocol (LCP) 303 supported by the IAP or ISP to learn its own location. 304 o The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to 305 query the LoST server and asks for the PSAP URI responsible for 306 that location. 307 o After the PSAP URI has been returned to the end host, the SIP UA 308 in the end host directly initiates a SIP INVITE towards the PSAP 309 URI. 311 The IAP and the ISP will probably want to make sure that the claimed 312 emergency caller indeed performs an emergency call rather than using 313 the network for other purposes, and thereby acting fraudulent by 314 skipping any authentication, authorization and accounting procedures. 315 By restricting access of the unauthenticated emergency caller to the 316 LoST server and the PSAP URI, traffic can be restricted only to 317 emergency calls (see also section 1.1). 319 Using the above procedures, the unauthenticated emergency caller will 320 be successful only if: 322 o the ISP (or the IAP) support an LCP that the end host can use to 323 learn its location. A list of mandatory-to-implement LCPs can be 324 found in [I-D.ietf-ecrit-phonebcp]). 325 o the ISP configures it's firewalls appropriately to allow emergency 326 calls to traverse the network towards the PSAP. 328 Some IAPs/ISPs may not be able to fulfill the above requirements. If 329 those IAPs/ISPs want to support unauthenticated emergency calls, then 330 they can deploy an extended architecture as described in Section 5. 332 5. Considerations for ISPs to support Unauthenticated Emergency 333 Services with Architecture Extensions 335 This section provides a recommended configuration for unauthenticated 336 emergency services support without architecture extensions. 338 For unauthenticated emergency services support it is insufficient to 339 provide mechanisms only at the link layer in order to bypass 340 authentication for the cases when: 342 o the IAP/ISP does not support any Location Configuration Protocol 343 o the IAP/ISP cannot assume the end hosts to support a Location 344 Configuration Protocol 345 o the IAP/ISP does not have knowledge of a LoST server (which would 346 assist the client to find the correct PSAP) 348 A modification to the emergency services architecture is necessary 349 since the IAP and the ISP need to make sure that the claimed 350 emergency caller indeed performs an emergency call rather than using 351 the network for other purposes, and thereby acting fraudulent by 352 skipping any authentication, authorization and accounting procedures. 353 Hence, without introducing some understanding of the specific 354 application the ISP (and consequently the IAP) will not be able to 355 detect and filter malicious activities. This leads to the 356 architecture described in Figure 1 where the IAP needs to implement 357 extensions to link layer procedures for unauthenticated emergency 358 service access and the ISP needs to deploy emergency services related 359 entities used for call routing, such as the Emergency Services 360 Routing Proxy (ESRP), a Location Configuration Server (LCS) and a 361 mapping database. 363 On a very high-level, the interaction is as follows starting with the 364 end host not being attached to the network and the user starting to 365 make an emergency call. 367 o Some radio networks have added support for unauthenticated 368 emergency access, some other type of networks advertise these 369 capabilities using layer beacons. The end host learns about these 370 unauthenticated emergency services capabilities either from the 371 link layer type or from link layer advertisement. 372 o A security association may be established for the purpose of data 373 confidentiality at the link layer. However, since the link layer 374 is limited to a broadcast domain, it would be better to establish 375 a security association at higher layers. 376 o The end host uses the link layer specific network attachment 377 procedures defined for unauthenticated network access in order to 378 get access to emergency services. 379 o When the link layer network attachment procedure is completed the 380 end host learns basic configuration information using DHCP from 381 the ISP, including the address of the ESRP, as shown in (2). 382 o When the IP address configuration is completed then the SIP UA 383 initiates a SIP INVITE towards the indicated ESRP, as shown in 384 (3). The INVITE message contains all the necessary parameters 385 required by Section 7.1.5. 386 o The ESRP receives the INVITE and processes it according to the 387 description in Section 7.3.3. The location of the end host may 388 need to be determined using a protocol interaction shown in (4). 390 o Potentially, an interaction between the LCS of the ISP and the LCS 391 of the IAP may be necessary, see (5). 392 o Finally, the correct PSAP for the location of the end host has to 393 be evaluated, see (6). 394 o The ESRP routes the call to the PSAP, as shown in (7). 395 o The PSAP evaluates the initial INVITE and aims to complete the 396 call setup. 397 o Finally, when the call setup is completed media traffic can be 398 exchanged between the PSAP and the emergency caller. 400 For editorial reasons the end-to-end SIP and media exchange between 401 the PSAP and SIP UA are not shown in Figure 1. 403 Two important aspects are worth to highlight: 405 o The IAP/ISP needs to understand the concept of emergency calls or 406 other emergency applicationsand the SIP profile described in this 407 document. No other VoIP protocol profile, such as XMPP, Skype, 408 etc., are supported for emergency calls in this particular 409 architecture. Other profiles may be added in the future, but the 410 deployment effort is enormous since they have to be universally 411 deployed. 412 o The end host has no obligation to determine location information. 413 It may attach location information if it has location available 414 (e.g., from a GPS receiver). 416 Figure 1 shows that the ISP needs to deploy SIP-based emergency 417 services functionality. It is important to note that the ISP itself 418 may outsource the functionality by simply providing access to them 419 (e.g., it puts the IP address of an ESRP or a LoST server into an 420 allow-list). For editorial reasons this outsourcing is not shown. 422 +---------------------------+ 423 | | 424 | Emergency Network | 425 | Infrastructure | 426 | | 427 | +----------+ +----------+ | 428 | | PSAP | | ESRP | | 429 | | | | | | 430 | +----------+ +----------+ | 431 +-------------------^-------+ 432 | 433 | (7) 434 +------------------------+-----------------------+ 435 | ISP | | 436 | | | 437 |+----------+ v | 438 || Mapping | (6) +----------+ | 439 || Database |<----->| ESRP / | | 440 |+----------+ | SIP Proxy|<-+ | 441 |+----------+ +----------+ | +----------+| 442 || LCS-ISP | ^ | | DHCP || 443 || |<---------+ | | Server || 444 |+----------+ (4) | +----------+| 445 +-------^-------------------------+-----------^--+ 446 +-------|-------------------------+-----------|--+ 447 | IAP | (5) | | | 448 | V | | | 449 |+----------+ | | | 450 || LCS-IAP | +----------+ | | | 451 || | | Link | |(3) | | 452 |+----------+ | Layer | | | | 453 | | Device | | (2)| | 454 | +----------+ | | | 455 | ^ | | | 456 | | | | | 457 +------------------------+--------+-----------+--+ 458 | | | 459 (1)| | | 460 | | | 461 | +----+ | 462 v v | 463 +----------+ | 464 | End |<-------------+ 465 | Host | 466 +----------+ 468 Figure 1: Overview 470 It is important to note that a single ESRP may also offer it's 471 service to several ISPs. 473 6. NAA considerations for the network attachment procedure of IAPs/ISPs 475 This section discusses different methods to indicate an emergency 476 service request as part of network attachment. It provides general 477 considerations related to the access that provides the actual IP 478 connectivity, without assuming a specific access technology. No 479 specific recommendations are provided by this version of the 480 document. 482 To perform network attachment and get access to the resources 483 provided by an IAP/ISP, the end host uses access technology specific 484 network attachment procedures, including for example network 485 detection and selection, authentication and authorization, or setup 486 of service flows providing a specific quality-of-service level. For 487 initial network attachment of an emergency service requester, the 488 method of how the emergency indication is given to the IAP/ISP is 489 specific to the access technology. However, a number of general 490 approaches can be identified: 492 - Link layer emergency indication: The end host provides an 493 indication, e.g. an emergency parameter or flag, as part of the link 494 layer signaling for initial network attachment. Examples include an 495 explicit emergency bit signalled in the IEEE 802.16-2009 wireless 496 link, or tokens in 802.11 access that allow an access network to 497 indicate emergency capability to devices and can be mirrored back in 498 case a device actually requests emergency services during network 499 entry as part of the lower-layer signaling. 501 - Higher-layer emergency indication: Typically emergency indication 502 in access authentication that is transparent to any access-specific 503 lower-layer signaling. The emergency caller's end host provides an 504 indication as part of the access authentication exchanges. EAP based 505 authentication is of particular relevance here. 507 6.1. Link layer emergency indication 509 In general, link layer emergency indications provide good integration 510 into the actual network access procedures. This allows to recognize 511 and prioritize an emergency service request from an end host at a 512 very early stage of the network attachment procedure. However, 513 support in end hosts for such methods cannot be expected to be 514 commonly available. 516 No general recommendations are given in the scope of this memo due to 517 the following reasons: 519 - Dependency on the specific access technology. 521 - Dependency on the specific access network architecture. Access 522 authorization and policy decisions typically happen at a different 523 layers of the protocol stack and in different entities than those 524 terminating the link-layer signaling. As a result, link layer 525 indications need to be distributed and translated between the 526 different involved protocol layers and entities. Appropriate methods 527 are specific to the actual architecture of the IAP/ISP network. 529 6.2. Higher-layer emergency indication 531 This section discusses pros and cons of emergency indications based 532 on authentication and authorization in EAP-based network access. No 533 general recommendations like a preferred method to indicate emergency 534 are given in this version of the document. 536 An advantage of combining emergency indications with the actual 537 network attachment signaling performing authentication and 538 authorization is the fact that the emergency indication can directly 539 be taken into account in the authentication and authorization server. 540 Such server implements the policy for granting access to the network 541 resources. As a result, there is no direct dependency on the access 542 network architecture that would otherwise need to take care of 543 merging link-layer indications into the AA and policy decision 544 process. 546 EAP signaling happens at a relatively early stage of network 547 attachment, so it is likely to match most requirements for 548 prioritization of emergency network entry. However, it does not 549 cover early stages of link layer activity in the network attachment 550 process. Possible conflicts may arise e.g. in case of MAC-based 551 filtering in entities terminating the link-layer signaling in the 552 network (like a base station). In normal operation, EAP messages 553 including information like the EAP identity will only be recognized 554 in the NAS. Note that otherwise, a NAS is agnostic to the actual EAP 555 method. Any entity residing between end host and NAS cannot be 556 expected to understand or digest information that is exchanged as 557 part of EAP messages, like EAP-related identities. 559 In practice, due to lack of a common standard there is no single way 560 to provide higher layer emergency indication during initial network 561 entry as part of the NAI-formatted EAP identity, and different 562 systems use different methods. Examples include directly selecting a 563 special EAP identity (e.g. the NAI including the string 'emergency'), 564 or NAI decoration. 566 6.3. Securing network attachment in NAA cases 568 For network attachment in NAA cases, it may make sense to secure the 569 link-layer connection between the device and the IAP/ISP. This 570 especially holds for wireless access with an example being IEEE 571 802.16 based access that mandates secured communication across the 572 wireless link for all IAP/ISP networks based on [nwgstg3]. 574 Therefore, for network attachment that is by default based on EAP 575 authentication it is desirable also for NAA network attachment to use 576 a key-generating EAP method (that provides an MSK key to the 577 authenticator to bootstrap further key derivation for protecting the 578 wireless link). 580 The following approaches to match the above can be identified. No 581 preference is given for one of the following methods as requirements 582 may vary depending on the specific environment: 584 1) Server-only authentication: The device of the emergency service 585 requester performs an EAP method with the IAP/ISP EAP server that 586 performs server authentication only. An example for this is EAP-TLS. 587 This provides a certain level of assurance about the IAP/ISP to the 588 device user. It requires the device to be provisioned with 589 appropriate trusted root certificates to be able to verify the server 590 certificate of the EAP server (unless this step is explicitly skipped 591 in the device in case of an emergency service request). 593 2) Null authentication: an EAP method is performed. However, no 594 credentials specific to either the server or the device or 595 subscription are used as part of the authentication exchange. An 596 example for this would be an EAP-TLS exchange with using the 597 TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly 598 available static key for emergency access could be used. In the 599 latter case, the device would need to be provisioned with the 600 appropriate emergency key for the IAP/ISP in advance. 602 3) Device authentication: This case extends the server-only 603 authentication case. If the device is configured with a device 604 certificate and the IAP/ISP EAP server can rely on a trusted root 605 allowing the EAP server to verify the device certificate, at least 606 the device identity (e.g. the MAC address) can be authenticated by 607 the IAP/ISP in NAA cases. An example for this are WiMAX devices that 608 are shipped with device certificates issued under the global WiMAX 609 device public-key infrastructure. To perform unauthenticated 610 emergency calls, if allowed by the IAP/ISP, such devices perform EAP- 611 TLS based network attachment with client authentication based on the 612 device certificate. 614 7. Profiles 616 7.1. End Host Profile 618 7.1.1. LoST Server Discovery 620 The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a 621 LoST server. If that attempt fails, the end host SHOULD attempt to 622 discover the address of an ESRP. 624 7.1.2. ESRP Discovery 626 The end host only needs an ESRP when location configuration or LoST 627 server discovery fails. If that is the case, then the end host MUST 628 use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option 629 for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6) 630 and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options 631 for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover 632 the address of an ESRP. This SIP proxy located in the ISP network 633 will be used as the ESRP for routing emergency calls. There is no 634 need to discovery a separate SIP proxy with specific emergency call 635 functionality since the internal procedure for emergency call 636 processing is subject of ISP internal operation. 638 7.1.3. Location Determination and Location Configuration 640 The end host SHOULD attempt to use the supported LCPs to configure 641 its location. If no LCP is supported in the end host or the location 642 configuration is not successful, then the end host MUST attempt to 643 discover an ESRP, which would assist the end host in providing the 644 location to the PSAP. 646 The SIP UA in the end host SHOULD attach the location information in 647 a PIDF-LO [RFC4119] when making an emergency call. When constructing 648 the PIDF-LO the guidelines in PIDF-LO profile 649 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. For civic 650 location information the format defined in [RFC5139] MUST be 651 supported. 653 7.1.4. Emergency Call Identification 655 To determine which calls are emergency calls, some entity needs to 656 map a user entered dialstring into this URN scheme. A user may 657 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 658 mapping SHOULD be performed at the endpoint device. It is 659 recommended that the endpoint device be provisioned with relevant URN 660 information. 662 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 663 as emergency calls for their home emergency dial string (if known). 664 For visited emergency dial string the translation into the Service 665 URN mechanism is not mandatory since the ESRP in the ISPs network 666 knows the visited emergency dial strings. 668 7.1.5. SIP Emergency Call Signaling 670 SIP signaling capabilities [RFC3261] are mandated for end hosts. 672 The initial SIP signaling method is an INVITE. The SIP INVITE 673 request MUST be constructed according to the requirements in Section 674 9.2 [I-D.ietf-ecrit-phonebcp]. 676 Regarding callback behavior SIP UAs MUST have a globally routable URI 677 in a Contact: header. 679 7.1.6. Media 681 End points MUST comply with the media requirements for end points 682 placing an emergency call found in Section 14 of 683 [I-D.ietf-ecrit-phonebcp]. 685 7.1.7. Testing 687 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully 688 applicable to this document. 690 7.2. IAP/ISP Profile 692 7.2.1. ESRP Discovery 694 An ISP hosting an ESRP MUST implement the server side part of 695 "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for 696 Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and / 697 or the "Dynamic Host Configuration Protocol (DHCPv6) Options for 698 Session Initiation Protocol (SIP) Servers" [RFC3319]. 700 7.2.2. Location Determination and Location Configuration 702 The ISP not hosting an ESRP MUST support at least one widely used 703 LCP. The ISP hosting an ESRP MUST perform the neccesary steps to 704 determine the location of the end host. It is not necessary to 705 standardize a specific mechanism. 707 The role of the ISP is to operate the LIS. The usage of HELD 708 [I-D.ietf-geopriv-http-location-delivery] with the identity 709 extensions [I-D.ietf-geopriv-held-identity-extensions] may be a 710 possible choice. It might be necessary for the ISP to talk to the 711 IAP in order to determine the location of the end host. The work on 712 LIS-to-LIS communication may be relevant, see 713 [I-D.winterbottom-geopriv-lis2lis-req]. 715 7.3. ESRP Profile 717 7.3.1. Emergency Call Routing 719 The ESRP must route the emergency call to the PSAP responsible for 720 the physical location of the end host. However, a standardized 721 approach for determining the correct PSAP based on a given location 722 is useful but not mandatory. 724 For cases where a standardized protocol is used LoST 725 [I-D.ietf-ecrit-lost] is a suitable mechanism. 727 7.3.2. Emergency Call Identification 729 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 730 the 'urn:service:sos' tree) and additionally the national emergency 731 dial strings. The ESRP SHOULD perform a mapping of national 732 emergency dial strings to Service URNs to simplify processing at 733 PSAPs. 735 7.3.3. SIP Emergency Call Signaling 737 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 738 ESRP MUST process the messages sent by the client, according to 739 Section 7.1.5. Furthermore, the ESRP MUST be able to add a reference 740 to location information, as described in SIP Location Conveyance 741 [I-D.ietf-sip-location-conveyance], before forwarding the call to the 742 PSAP. The ISP MUST be prepared to receive incoming dereferencing 743 requests to resolve the reference to the location information. 745 7.3.4. Location Retrieval 747 The ESRP acts a location recipient and the usage of HELD 748 [I-D.ietf-geopriv-http-location-delivery] with the identity 749 extensions [I-D.ietf-geopriv-held-identity-extensions] may be a 750 possible choice. The ESRP would thereby act as a HELD client and the 751 corresponding LIS at the ISP as the HELD server. 753 The ESRP needs to obtain enough information to route the call. The 754 ESRP itself, however, does not necessarily need to process location 755 information obtained via HELD since it may be used as input to LoST 756 to obtain the PSAP URI. 758 8. Security Considerations 760 The security threats discussed in [RFC5069] are applicable to this 761 document. A number of security vulnerabilities discussed in 762 [I-D.ietf-geopriv-arch] around faked location information are less 763 problematic in this case since location information does not need to 764 be provided by the end host itself or it can be verified to fall 765 within a specific geographical area. 767 There are a couple of new vulnerabilities raised with unauthenticated 768 emergency services since the PSAP operator does is not in possession 769 of any identity information about the emergency call via the 770 signaling path itself. In countries where this functionality is used 771 for GSM networks today this has lead to a significant amount of 772 misuse. 774 The link layer mechanisms need to provide a special way of handling 775 unauthenticated emergency services. Although this subject is not a 776 topic for the IETF itself but there are at least a few high-level 777 assumptions that may need to be collected. This includes security 778 features that may be desirable. 780 9. Acknowledgments 782 Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp]. 783 The WiMax Forum contributed parts of the terminology. Participants 784 of the 2nd and 3rd SDO Emergency Services Workshop provided helpful 785 input. 787 10. IANA Considerations 789 This document does not require actions by IANA. 791 11. References 793 11.1. Normative References 795 [I-D.ietf-sip-location-conveyance] 796 Polk, J. and B. Rosen, "Location Conveyance for the 797 Session Initiation Protocol", 798 draft-ietf-sip-location-conveyance-13 (work in progress), 799 March 2009. 801 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 802 Emergency and Other Well-Known Services", RFC 5031, 803 January 2008. 805 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 806 Format", RFC 4119, December 2005. 808 [I-D.ietf-geopriv-pdif-lo-profile] 809 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 810 PIDF-LO Usage Clarification, Considerations and 811 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 812 (work in progress), November 2008. 814 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 815 Format for Presence Information Data Format Location 816 Object (PIDF-LO)", RFC 5139, February 2008. 818 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 819 (DHCP-for-IPv4) Option for Session Initiation Protocol 820 (SIP) Servers", RFC 3361, August 2002. 822 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 823 Protocol (DHCPv6) Options for Session Initiation Protocol 824 (SIP) Servers", RFC 3319, July 2003. 826 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 827 A., Peterson, J., Sparks, R., Handley, M., and E. 828 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 829 June 2002. 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [I-D.ietf-ecrit-phonebcp] 835 Rosen, B. and J. Polk, "Best Current Practice for 836 Communications Services in support of Emergency Calling", 837 draft-ietf-ecrit-phonebcp-14 (work in progress), 838 January 2010. 840 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 841 Tschofenig, "LoST: A Location-to-Service Translation 842 Protocol", RFC 5222, August 2008. 844 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 845 Location-to-Service Translation (LoST) Servers Using the 846 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 847 August 2008. 849 11.2. Informative References 851 [I-D.ietf-ecrit-lost] 852 Hardie, T., Newton, A., Schulzrinne, H., and H. 853 Tschofenig, "LoST: A Location-to-Service Translation 854 Protocol", draft-ietf-ecrit-lost-10 (work in progress), 855 May 2008. 857 [I-D.ietf-geopriv-l7-lcp-ps] 858 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 859 Location Configuration Protocol; Problem Statement and 860 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 861 progress), July 2009. 863 [I-D.ietf-ecrit-framework] 864 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 865 "Framework for Emergency Calling using Internet 866 Multimedia", draft-ietf-ecrit-framework-10 (work in 867 progress), July 2009. 869 [I-D.ietf-geopriv-http-location-delivery] 870 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 871 "HTTP Enabled Location Delivery (HELD)", 872 draft-ietf-geopriv-http-location-delivery-16 (work in 873 progress), August 2009. 875 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 876 Emergency Context Resolution with Internet Technologies", 877 RFC 5012, January 2008. 879 [I-D.ietf-geopriv-held-identity-extensions] 880 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 881 Barnes, "Use of Device Identity in HTTP-Enabled Location 882 Delivery (HELD)", 883 draft-ietf-geopriv-held-identity-extensions-04 (work in 884 progress), June 2010. 886 [I-D.winterbottom-geopriv-lis2lis-req] 887 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 888 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 889 (work in progress), November 2007. 891 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 892 Shanmugam, "Security Threats and Requirements for 893 Emergency Call Marking and Mapping", RFC 5069, 894 January 2008. 896 [I-D.ietf-geopriv-arch] 897 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 898 Tschofenig, H., and H. Schulzrinne, "An Architecture for 899 Location and Location Privacy in Internet Applications", 900 draft-ietf-geopriv-arch-02 (work in progress), May 2010. 902 [esw07] "3rd SDO Emergency Services Workshop, 903 http://www.emergency-services-coordination.info/2007Nov/", 904 October 30th - November 1st 2007. 906 [nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 907 Architecture Stage-3 908 http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech 909 nical_document/2009/09/ 910 DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf", 911 September 2009. 913 Authors' Addresses 915 Henning Schulzrinne 916 Columbia University 917 Department of Computer Science 918 450 Computer Science Building 919 New York, NY 10027 920 US 922 Phone: +1 212 939 7004 923 Email: hgs+ecrit@cs.columbia.edu 924 URI: http://www.cs.columbia.edu 926 Stephen McCann 927 Research in Motion UK Ltd 928 200 Bath Road 929 Slough, Berks SL1 3XE 930 UK 932 Phone: +44 1753 667099 933 Email: smccann@rim.com 934 URI: http://www.rim.com 936 Gabor Bajko 937 Nokia 939 Email: Gabor.Bajko@nokia.com 940 Hannes Tschofenig 941 Nokia Siemens Networks 942 Linnoitustie 6 943 Espoo 02600 944 Finland 946 Phone: +358 (50) 4871445 947 Email: Hannes.Tschofenig@gmx.net 948 URI: http://www.tschofenig.priv.at 950 Dirk Kroeselberg 951 Nokia Siemens Networks 952 St.-Martin-Str. 76 953 Munich 81541 954 Germany 956 Phone: +49 (89) 515933019 957 Email: Dirk.Kroeselberg@nsn.com