idnits 2.17.1 draft-ietf-ecrit-unauthenticated-access-00.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 (September 21, 2010) is 4965 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-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-04 == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: March 25, 2011 Research in Motion UK Ltd 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 D. Kroeselberg 10 Nokia Siemens Networks 11 September 21, 2010 13 Extensions to the Emergency Services Architecture for dealing with 14 Unauthenticated and Unauthorized Devices 15 draft-ietf-ecrit-unauthenticated-access-00.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 March 25, 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 . . . . . . . . . . . . . . . . . . . . . 16 87 7.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 16 88 7.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16 89 7.1.3. Location Determination and Location Configuration . . 16 90 7.1.4. Emergency Call Identification . . . . . . . . . . . . 16 91 7.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 17 92 7.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 17 93 7.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 17 94 7.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 17 95 7.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 17 96 7.2.2. Location Determination and Location Configuration . . 17 97 7.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 18 98 7.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 18 99 7.3.2. Emergency Call Identification . . . . . . . . . . . . 18 100 7.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 18 101 7.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 18 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 Summoning police, the fire department or an ambulance in emergencies 113 is one of the fundamental and most-valued functions of the telephone. 114 As telephone functionality moves from circuit-switched telephony to 115 Internet telephony, its users rightfully expect that this core 116 functionality will continue to work at least as well as it has for 117 the older technology. New devices and services are being made 118 available that could be used to make a request for help, which are 119 not traditional telephones, and users are increasingly expecting them 120 to be used to place emergency calls. 122 Roughly speaking, the IETF emergency services architecture (see 123 [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 and otherwise conduct the emergency call in the same manner as when 144 the three exceptional conditions discussed below do not apply. 146 We distinguish between three conditions: 148 No access authorization (NAA): The current access network requires 149 access authorization and the caller does not have valid user 150 credentials. (This includes the case where the access network 151 allows pay-per-use, as is common for wireless hotspots, but there 152 is insufficient time to pay for access.) 154 No ASP (NASP): The caller does not have an ASP at the time of the 155 call. 157 Zero-balance ASP (ZBP): The caller has valid credentials with an 158 ASP, but is not allowed to access services like placing calls in 159 case of a VoIP service, e.g., because the user has a zero balance 160 in a prepaid account. 162 A user may well suffer from both NAA and NASP or ZBP at the same 163 time. Depending on local policy and regulations, it may not be 164 possible to place emergency calls in the NAA case. Unless local 165 regulations require user identification, it should always be possible 166 to place calls in the NASP case, with minimal impact on the ISP. 167 Unless the ESN requires that all calls traverse a known set of VSPs, 168 a caller should be able to place an emergency call in the ZBP case. 169 We discuss each case in separate sections below. 171 1.1. No Access Authorization (NAA) 173 In the NAA (No Access Authorization) case, the emergency caller does 174 not posses valid credentials for the access network. If local 175 regulations or policy allows or requires support for emergency calls 176 in NAA, the access network may or needs to cooperate in providing 177 emergency calling services. Support for NAA emergency calls is 178 subject to the local policy of the ISP. Such policy may vary 179 substantially between ISPs and typically depends on external factors 180 that are not under the ISP control. Hence, no global mandates for 181 supporting emergency calls in relation to NAA can be made. However, 182 it makes a lot of sense to offer appropriate building blocks that 183 enable ISPs to flexibly react on the local environment.Generally, the 184 ISP will want to ensure that devices do not pretend to place 185 emergency calls, but then abuse the access for obtaining more general 186 services fraudulently. 188 In particular, the ISP MUST allow emergency callers to acquire an IP 189 address and to reach a LoST server, either provided by the ISP or 190 some third party. It SHOULD also provide location information via 191 one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without 192 requiring authorization unless it can safely assume that all nodes in 193 the access network can determine their own location, e.g., via GPS. 195 The details of how filtering is performed depends on the details of 196 the ISP architecture and are beyond the scope of this document. We 197 illustrate a possible model. If the ISP runs its own LoST server, it 198 would maintain an access control list including all IP addresses 199 contained in responses returned by the LoST server, as well as the 200 LoST server itself. (It may need to translate the domain names 201 returned to IP addresses and hope that the resolution captures all 202 possible DNS responses.) Since the media destination addresses are 203 not predictable, the ISP also has to provide a SIP outbound proxy so 204 that it can determine the media addresses and add those to the filter 205 list. 207 1.2. No ASP (NASP) 209 In the second case, the emergency caller has no current ASP. This 210 case poses no particular difficulties unless it is assumed that only 211 ASPs provide LoST server or that ESNs only accept calls that reach it 212 through a set of known ASPs. However, since the calling device 213 cannot obtain configuration information from its ASP, the ISP MUST 214 provide the address of a LoST server via DHCP [RFC5223] if this model 215 is to be supported. The LoST server may be operated either by the 216 ISP or a third party. 218 1.3. Zero-Balance Application Service Provider (ZBP) 220 In the case of zero-balance ASP, the ASP can authenticate the caller, 221 but the caller is not authorized to use ASP services, e.g., because 222 the contract has expired or the prepaid account for the customer has 223 been depleted. Naturally, an ASP can simply disallow access by such 224 customers, so that all such customers find themselves in the NASP 225 situation described above. If ASPs desire or are required by 226 regulation to provide emergency calling services to such customers, 227 they need to provide LoST services to such customers and may need to 228 provide outbound SIP proxy services. As usual, the calling device 229 looks up the LoST server via SIP configuration. 231 Unless the emergency call traverses a PSTN gateway or the ASP charges 232 for IP-to-IP calls, there is little potential for fraud. If the ASP 233 also operates the LoST server, the outbound proxy MAY restrict 234 outbound calls to the SIP URIs returned by the LoST server. It is 235 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 236 change. 238 2. A Warning Note 240 At the time of writing there is no regulation in place that demands 241 the functionality described in this memo. SDOs have started their 242 work on this subject in a proactive fashion in the anticipation that 243 national regulation will demand it for a subset of network 244 environments. 246 There are also indications that the functionality of unauthenticated 247 emergency calls (called SIM-less calls) in today's cellular system in 248 certain countries leads to a fair amount of hoax or test calls. This 249 causes overload situations at PSAPs which is considered harmful to 250 the overall availability and reliability of emergency services. 252 As an example, Federal Office of Communications (OFCOM, 253 Switzerland) provided statistics about emergency (112) calls in 254 Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not 255 offer SIM-less emergency calls except for almost a month in July 256 2000 where a significant increase in hoax and test calls was 257 reported. As a consequence, the functionality was disabled again. 258 More details can be found in the panel presentations of the 3rd 259 SDO Emergency Services Workshop [esw07]. 261 3. Terminology 263 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 264 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 265 and "OPTIONAL" are to be interpreted as described in RFC 2119 266 [RFC2119]. 268 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 269 and [RFC5012], namely Internet Access Provider (IAP), Internet 270 Service Provider (ISP), Application Service Provider (ASP), Voice 271 Service Provider (VSP), Emergency Service Routing Proxy (ESRP), 272 Public Safety Answering Point (PSAP), Location Configuration Server 273 (LCS), (emergency) service dial string, and (emergency) service 274 identifier. 276 4. Considerations for ISPs to support Unauthenticated Emergency 277 Services without Architecture Extensions 279 This section provides a recommended configuration for unauthenticated 280 emergency services support without architecture extensions. 282 On a very high-level, the steps to be performed by an end host not 283 being attached to the network and the user starting to make an 284 emergency call are the following: 286 o Some radio networks have added support for unauthenticated 287 emergency access, some other type of networks advertise these 288 capabilities using layer beacons. The end host learns about these 289 unauthenticated emergency services capabilities either from the 290 link layer type or from advertisement. 291 o The end host uses the link layer specific network attachment 292 procedures defined for unauthenticated network access in order to 293 get access to emergency services. 295 o When the link layer network attachment procedure is completed the 296 end host learns basic configuration information using DHCP from 297 the ISP, including the address of the LoST server. 298 o The end host MUST use a Location Configuration Protocol (LCP) 299 supported by the IAP or ISP to learn its own location. 300 o The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to 301 query the LoST server and asks for the PSAP URI responsible for 302 that location. 303 o After the PSAP URI has been returned to the end host, the SIP UA 304 in the end host directly initiates a SIP INVITE towards the PSAP 305 URI. 307 The IAP and the ISP will probably want to make sure that the claimed 308 emergency caller indeed performs an emergency call rather than using 309 the network for other purposes, and thereby acting fraudulent by 310 skipping any authentication, authorization and accounting procedures. 311 By restricting access of the unauthenticated emergency caller to the 312 LoST server and the PSAP URI, traffic can be restricted only to 313 emergency calls (see also section 1.1). 315 Using the above procedures, the unauthenticated emergency caller will 316 be successful only if: 318 o the ISP (or the IAP) support an LCP that the end host can use to 319 learn its location. A list of mandatory-to-implement LCPs can be 320 found in [I-D.ietf-ecrit-phonebcp]). 321 o the ISP configures it's firewalls appropriately to allow emergency 322 calls to traverse the network towards the PSAP. 324 Some IAPs/ISPs may not be able to fulfill the above requirements. If 325 those IAPs/ISPs want to support unauthenticated emergency calls, then 326 they can deploy an extended architecture as described in Section 5. 328 5. Considerations for ISPs to support Unauthenticated Emergency 329 Services with Architecture Extensions 331 This section provides a recommended configuration for unauthenticated 332 emergency services support without architecture extensions. 334 For unauthenticated emergency services support it is insufficient to 335 provide mechanisms only at the link layer in order to bypass 336 authentication for the cases when: 338 o the IAP/ISP does not support any Location Configuration Protocol 339 o the IAP/ISP cannot assume the end hosts to support a Location 340 Configuration Protocol 342 o the IAP/ISP does not have knowledge of a LoST server (which would 343 assist the client to find the correct PSAP) 345 A modification to the emergency services architecture is necessary 346 since the IAP and the ISP need to make sure that the claimed 347 emergency caller indeed performs an emergency call rather than using 348 the network for other purposes, and thereby acting fraudulent by 349 skipping any authentication, authorization and accounting procedures. 350 Hence, without introducing some understanding of the specific 351 application the ISP (and consequently the IAP) will not be able to 352 detect and filter malicious activities. This leads to the 353 architecture described in Figure 1 where the IAP needs to implement 354 extensions to link layer procedures for unauthenticated emergency 355 service access and the ISP needs to deploy emergency services related 356 entities used for call routing, such as the Emergency Services 357 Routing Proxy (ESRP), a Location Configuration Server (LCS) and a 358 mapping database. 360 On a very high-level, the interaction is as follows starting with the 361 end host not being attached to the network and the user starting to 362 make an emergency call. 364 o Some radio networks have added support for unauthenticated 365 emergency access, some other type of networks advertise these 366 capabilities using layer beacons. The end host learns about these 367 unauthenticated emergency services capabilities either from the 368 link layer type or from advertisement. 369 o The end host uses the link layer specific network attachment 370 procedures defined for unauthenticated network access in order to 371 get access to emergency services. 372 o When the link layer network attachment procedure is completed the 373 end host learns basic configuration information using DHCP from 374 the ISP, including the address of the ESRP, as shown in (2). 375 o When the IP address configuration is completed then the SIP UA 376 initiates a SIP INVITE towards the indicated ESRP, as shown in 377 (3). The INVITE message contains all the necessary parameters 378 required by Section 7.1.5. 379 o The ESRP receives the INVITE and processes it according to the 380 description in Section 7.3.3. The location of the end host may 381 need to be determined using a protocol interaction shown in (4). 382 o Potentially, an interaction between the LCS of the ISP and the LCS 383 of the IAP may be necessary, see (5). 384 o Finally, the correct PSAP for the location of the end host has to 385 be evaluated, see (6). 386 o The ESRP routes the call to the PSAP, as shown in (7). 387 o The PSAP evaluates the initial INVITE and aims to complete the 388 call setup. 390 o Finally, when the call setup is completed media traffic can be 391 exchanged between the PSAP and the emergency caller. 393 For editorial reasons the end-to-end SIP and media exchange between 394 the PSAP and SIP UA are not shown in Figure 1. 396 Two important aspects are worth to highlight: 398 o The IAP/ISP needs to understand the concept of emergency calls or 399 other emergency applicationsand the SIP profile described in this 400 document. No other VoIP protocol profile, such as XMPP, Skype, 401 etc., are supported for emergency calls in this particular 402 architecture. Other profiles may be added in the future, but the 403 deployment effort is enormous since they have to be universally 404 deployed. 405 o The end host has no obligation to determine location information. 406 It may attach location information if it has location available 407 (e.g., from a GPS receiver). 409 Figure 1 shows that the ISP needs to deploy SIP-based emergency 410 services functionality. It is important to note that the ISP itself 411 may outsource the functionality by simply providing access to them 412 (e.g., it puts the IP address of an ESRP or a LoST server into an 413 allow-list). For editorial reasons this outsourcing is not shown. 415 +---------------------------+ 416 | | 417 | Emergency Network | 418 | Infrastructure | 419 | | 420 | +----------+ +----------+ | 421 | | PSAP | | ESRP | | 422 | | | | | | 423 | +----------+ +----------+ | 424 +-------------------^-------+ 425 | 426 | (7) 427 +------------------------+-----------------------+ 428 | ISP | | 429 | | | 430 |+----------+ v | 431 || Mapping | (6) +----------+ | 432 || Database |<----->| ESRP / | | 433 |+----------+ | SIP Proxy|<-+ | 434 |+----------+ +----------+ | +----------+| 435 || LCS-ISP | ^ | | DHCP || 436 || |<---------+ | | Server || 437 |+----------+ (4) | +----------+| 438 +-------^-------------------------+-----------^--+ 439 +-------|-------------------------+-----------|--+ 440 | IAP | (5) | | | 441 | V | | | 442 |+----------+ | | | 443 || LCS-IAP | +----------+ | | | 444 || | | Link | |(3) | | 445 |+----------+ | Layer | | | | 446 | | Device | | (2)| | 447 | +----------+ | | | 448 | ^ | | | 449 | | | | | 450 +------------------------+--------+-----------+--+ 451 | | | 452 (1)| | | 453 | | | 454 | +----+ | 455 v v | 456 +----------+ | 457 | End |<-------------+ 458 | Host | 459 +----------+ 461 Figure 1: Overview 463 It is important to note that a single ESRP may also offer it's 464 service to several ISPs. 466 6. NAA considerations for the network attachment procedure of IAPs/ISPs 468 This section discusses different methods to indicate an emergency 469 service request as part of network attachment. It provides some 470 general considerations and recommendations that are not specific to 471 the access technology. 473 To perform network attachment and get access to the resources 474 provided by an IAP/ISP, the end host uses access technology specific 475 network attachment procedures, including for example network 476 detection and selection, authentication, and authorization. For 477 initial network attachment of an emergency service requester, the 478 method of how the emergency indication is given to the IAP/ISP is 479 specific to the access technology. However, a number of general 480 approaches can be identified: 482 - Link layer emergency indication: The end host provides an 483 indication, e.g. an emergency parameter or flag, as part of the link 484 layer signaling for initial network attachment. Examples include an 485 emergency bit signalled in the IEEE 802.16-2009 wireless link. 486 signalling allows an IEEE 802.1X to occur without exchanging 487 cryptogrpahic keys 489 - Higher-layer emergency indication: Typically emergency indication 490 in access authentication. The emergency caller's end host provides 491 an indication as part of the access authentication exchanges. EAP 492 based authentication is of particular relevance here. [nwgstg3]. 494 6.1. Link layer emergency indication 496 In general, link layer emergency indications provide good integration 497 into the actual network access procedure regarding the enabling of 498 means to recognize and prioritize an emergency service request from 499 an end host at a very early stage of the network attachment 500 procedure. However, support in end hosts for such methods cannot be 501 considered to be commonly available. 503 No general recommendations are given in the scope of this memo due to 504 the following reasons: 506 - Dependency on the specific access technology. 508 - Dependency on the specific access network architecture. Access 509 authorization and policy decisions typically happen at a different 510 layers of the protocol stack and in different entities than those 511 terminating the link-layer signaling. As a result, link layer 512 indications need to be distributed and translated between the 513 different involved protocol layers and entities. Appropriate methods 514 are specific to the actual architecture of the IAP/ISP network. 516 6.2. Higher-layer emergency indication 518 This section focuses on emergency indications based on authentication 519 and authorization in EAP-based network access. 521 An advantage of combining emergency indications with the actual 522 network attachment procedure performing authentication and 523 authorization is the fact that the emergency indication can directly 524 be taken into account in the authentication and authorization server 525 that owns the policy for granting access to the network resources. 526 As a result, there is no direct dependency on the access network 527 architecture that otherwise would need to take care of merging link- 528 layer indications into the AA and policy decision process. 530 EAP signaling happens at a relatively early stage of network 531 attachment, so it is likely to match most requirements for 532 prioritization of emergency signaling. However, it does not cover 533 early stages of link layer activity in the network attachment 534 process. Possible conflicts may arise e.g. in case of MAC-based 535 filtering in entities terminating the link-layer signaling in the 536 network (like a base station). In normal operation, EAP related 537 information will only be recognized in the NAS. Any entity residing 538 between end host and NAS should not be expected to understand/parse 539 EAP messages. 541 The following potential methods to provide emergency indications in 542 combination with EAP-based network attachment, are recognized: 544 1) NAI-based emergency indication: 546 An emergency indication can be given by forming a specific NAI that 547 is used as the identity in EAP based authentication for network 548 entry. Methods include: 550 1.a) NAI Decoration: NAI decoration is commonly used in routing EAP 551 responses within the IAP/ISP AAA infrastructure. Additional 552 decoration can be used to add an indication that the network 553 attachment attempt is meant for accessing emergency services. 554 Potential advantages of such approach include that it requires only 555 minimal realization effort compared to link-layer indications with 556 good integration into the authentication and authorization 557 procedures. The same procedure can be used for all NAA cases (both 558 unauthenticated and unauthorized) as well as for normal attachment 559 with a valid subscription. A potential disadvantage is that such EAP 560 decoration is not globally defined across all different access 561 technologies. 563 1.b) Emergency NAI: The NAI comes with a realm or username part 564 indicating emergency (e.g. 'emergency@emergency.com'). An advantage 565 of this method for NAA cases is that no new requirements are put on 566 the involved signaling procedures. Only the identity used for 567 network entry is impacted. Potential disadvantages include that 568 different methods to indicate emergency for NAA cases and standard 569 emergency network attachments may be required. Also, modifying the 570 NAI itself (the username@realm part) may conflict with network 571 selection and network entry procedures, depending on the actual 572 access network. 574 2) Emergency EAP method 576 An emergency indication can be given by using a dedicated EAP method 577 that is reserved for emergency network attachment only. 579 2.a) Existing EAP method with new type: An existing EAP method may be 580 used. EAP methods themselves typically do not support emergency 581 indication. One option would be to pick a common EAP method like 582 EAP-TLS and allocate a new method type for the same method that is 583 exclusively reserved to emergency use. Such EAP method should be 584 chosen in a way that the same method can support NAA cases as well as 585 standard emergency network attachment. 587 2.b) Existing EAP method: Same as 2a), but without assigning a new 588 EAP method type for emergency. In this case some implicit indication 589 must be used. For example, in cases where EAP-TLS is used in network 590 attachment in combination with client certificates, the absence of a 591 client certificate could be interpreted by the network as a request 592 for emergency network attachment. 594 2.c) Emergency EAP method: A new EAP method could be defined that is 595 specifically designed for emergency network entry in NAA cases. Most 596 likely, such EAP method would not be usable for standard emergency 597 network attachment with an existing subscription. Such dedicated 598 emergency EAP method should be key-generating in compliance with 599 RFC3748 to enable the regular air interface security methods even in 600 unauthenticated operation. 602 6.3. Securing network attachment in NAA cases 604 For network attachment in NAA cases, it may make sense to secure the 605 link-layer connection between the device and the IAP/ISP. This 606 especially holds for wireless access with examples being based 607 access. The latter even mandates secured communication across the 608 wireless link for all IAP/ISP networks based on [nwgstg3]. 610 Therefore, for network attachment that is by default based on EAP 611 authentication it is desirable also for NAA network attachment to use 612 a key-generating EAP method (that provides an MSK key to the 613 authenticator to bootstrap further key derivation for protecting the 614 wireless link). 616 The following approaches to match the above can be identified: 618 1) Server-only authentication: The device of the emergency service 619 requester performs an EAP method with the IAP/ISP EAP server that 620 performs server authentication only. An example for this is EAP-TLS. 621 This provides a certain level of assurance about the IAP/ISP to the 622 device user. It requires the device to be provisioned with 623 appropriate trusted root certificates to be able to verify the server 624 certificate of the EAP server (unless this step is explicitly skipped 625 in the device in case of an emergency service request). 627 2) Null authentication: an EAP method is performed. However, no 628 credentials specific to either the server or the device or 629 subscription are used as part of the authentication exchange. An 630 example for this would be an EAP-TLS exchange with using the 631 TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly 632 available static key for emergency access could be used. In the 633 latter case, the device would need to be provisioned with the 634 appropriate emergency key for the IAP/ISP in advance. 636 3) Device authentication: This case extends the server-only 637 authentication case. If the device is configured with a device 638 certificate and the IAP/ISP EAP server can rely on a trusted root 639 allowing the EAP server to verify the device certificate, at least 640 the device identity (e.g. the MAC address) can be authenticated by 641 the IAP/ISP in NAA cases. An example for this are WiMAX devices that 642 are shipped with device certificates issued under the global WiMAX 643 device public-key infrastructure. To perform unauthenticated 644 emergency calls, if allowed by the IAP/ISP, such devices perform EAP- 645 TLS based network attachment with client authentication based on the 646 device certificate. 648 7. Profiles 649 7.1. End Host Profile 651 7.1.1. LoST Server Discovery 653 The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a 654 LoST server. If that attempt fails, the end host SHOULD attempt to 655 discover the address of an ESRP. 657 7.1.2. ESRP Discovery 659 The end host only needs an ESRP when location configuration or LoST 660 server discovery fails. If that is the case, then the end host MUST 661 use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option 662 for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6) 663 and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options 664 for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover 665 the address of an ESRP. This SIP proxy located in the ISP network 666 will be used as the ESRP for routing emergency calls. There is no 667 need to discovery a separate SIP proxy with specific emergency call 668 functionality since the internal procedure for emergency call 669 processing is subject of ISP internal operation. 671 7.1.3. Location Determination and Location Configuration 673 The end host SHOULD attempt to use the supported LCPs to configure 674 its location. If no LCP is supported in the end host or the location 675 configuration is not successful, then the end host MUST attempt to 676 discover an ESRP, which would assist the end host in providing the 677 location to the PSAP. 679 The SIP UA in the end host SHOULD attach the location information in 680 a PIDF-LO [RFC4119] when making an emergency call. When constructing 681 the PIDF-LO the guidelines in PIDF-LO profile 682 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. For civic 683 location information the format defined in [RFC5139] MUST be 684 supported. 686 7.1.4. Emergency Call Identification 688 To determine which calls are emergency calls, some entity needs to 689 map a user entered dialstring into this URN scheme. A user may 690 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 691 mapping SHOULD be performed at the endpoint device. 693 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 694 as emergency calls for their home emergency dial string (if known). 695 For visited emergency dial string the translation into the Service 696 URN mechanism is not mandatory since the ESRP in the ISPs network 697 knows the visited emergency dial strings. 699 7.1.5. SIP Emergency Call Signaling 701 SIP signaling capabilities [RFC3261] are mandated for end hosts. 703 The initial SIP signaling method is an INVITE. The SIP INVITE 704 request MUST be constructed according to the requirements in Section 705 9.2 [I-D.ietf-ecrit-phonebcp]. 707 Regarding callback behavior SIP UAs MUST have a globally routable URI 708 in a Contact: header. 710 7.1.6. Media 712 End points MUST comply with the media requirements for end points 713 placing an emergency call found in Section 14 of 714 [I-D.ietf-ecrit-phonebcp]. 716 7.1.7. Testing 718 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully 719 applicable to this document. 721 7.2. IAP/ISP Profile 723 7.2.1. ESRP Discovery 725 An ISP hosting an ESRP MUST implement the server side part of 726 "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for 727 Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and / 728 or the "Dynamic Host Configuration Protocol (DHCPv6) Options for 729 Session Initiation Protocol (SIP) Servers" [RFC3319]. 731 7.2.2. Location Determination and Location Configuration 733 The ISP not hosting an ESRP MUST support at least one widely used 734 LCP. The ISP hosting an ESRP MUST perform the neccesary steps to 735 determine the location of the end host. It is not necessary to 736 standardize a specific mechanism. 738 The role of the ISP is to operate the LIS. The usage of HELD 739 [I-D.ietf-geopriv-http-location-delivery] with the identity 740 extensions [I-D.ietf-geopriv-held-identity-extensions] may be a 741 possible choice. It might be necessary for the ISP to talk to the 742 IAP in order to determine the location of the end host. The work on 743 LIS-to-LIS communication may be relevant, see 744 [I-D.winterbottom-geopriv-lis2lis-req]. 746 7.3. ESRP Profile 748 7.3.1. Emergency Call Routing 750 The ESRP must route the emergency call to the PSAP responsible for 751 the physical location of the end host. However, a standardized 752 approach for determining the correct PSAP based on a given location 753 is useful but not mandatory. 755 For cases where a standardized protocol is used LoST 756 [I-D.ietf-ecrit-lost] is a suitable mechanism. 758 7.3.2. Emergency Call Identification 760 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 761 the 'urn:service:sos' tree) and additionally the national emergency 762 dial strings. The ESRP SHOULD perform a mapping of national 763 emergency dial strings to Service URNs to simplify processing at 764 PSAPs. 766 7.3.3. SIP Emergency Call Signaling 768 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 769 ESRP MUST process the messages sent by the client, according to 770 Section 7.1.5. Furthermore, the ESRP MUST be able to add a reference 771 to location information, as described in SIP Location Conveyance 772 [I-D.ietf-sip-location-conveyance], before forwarding the call to the 773 PSAP. The ISP MUST be prepared to receive incoming dereferencing 774 requests to resolve the reference to the location information. 776 7.3.4. Location Retrieval 778 The ESRP acts a location recipient and the usage of HELD 779 [I-D.ietf-geopriv-http-location-delivery] with the identity 780 extensions [I-D.ietf-geopriv-held-identity-extensions] may be a 781 possible choice. The ESRP would thereby act as a HELD client and the 782 corresponding LIS at the ISP as the HELD server. 784 The ESRP needs to obtain enough information to route the call. The 785 ESRP itself, however, does not necessarily need to process location 786 information obtained via HELD since it may be used as input to LoST 787 to obtain the PSAP URI. 789 8. Security Considerations 791 The security threats discussed in [RFC5069] are applicable to this 792 document. A number of security vulnerabilities discussed in 794 [I-D.ietf-geopriv-arch] around faked location information are less 795 problematic in this case since location information does not need to 796 be provided by the end host itself or it can be verified to fall 797 within a specific geographical area. 799 There are a couple of new vulnerabilities raised with unauthenticated 800 emergency services since the PSAP operator does is not in possession 801 of any identity information about the emergency call via the 802 signaling path itself. In countries where this functionality is used 803 for GSM networks today this has lead to a significant amount of 804 misuse. 806 The link layer mechanisms need to provide a special way of handling 807 unauthenticated emergency services. Although this subject is not a 808 topic for the IETF itself but there are at least a few high-level 809 assumptions that may need to be collected. This includes security 810 features that may be desirable. 812 9. Acknowledgments 814 Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp]. 815 The WiMax Forum contributed parts of the terminology. Participants 816 of the 2nd and 3rd SDO Emergency Services Workshop provided helpful 817 input. 819 10. IANA Considerations 821 This document does not require actions by IANA. 823 11. References 825 11.1. Normative References 827 [I-D.ietf-sip-location-conveyance] 828 Polk, J. and B. Rosen, "Location Conveyance for the 829 Session Initiation Protocol", 830 draft-ietf-sip-location-conveyance-13 (work in progress), 831 March 2009. 833 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 834 Emergency and Other Well-Known Services", RFC 5031, 835 January 2008. 837 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 838 Format", RFC 4119, December 2005. 840 [I-D.ietf-geopriv-pdif-lo-profile] 841 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 842 PIDF-LO Usage Clarification, Considerations and 843 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 844 (work in progress), November 2008. 846 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 847 Format for Presence Information Data Format Location 848 Object (PIDF-LO)", RFC 5139, February 2008. 850 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 851 (DHCP-for-IPv4) Option for Session Initiation Protocol 852 (SIP) Servers", RFC 3361, August 2002. 854 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 855 Protocol (DHCPv6) Options for Session Initiation Protocol 856 (SIP) Servers", RFC 3319, July 2003. 858 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 859 A., Peterson, J., Sparks, R., Handley, M., and E. 860 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 861 June 2002. 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, March 1997. 866 [I-D.ietf-ecrit-phonebcp] 867 Rosen, B. and J. Polk, "Best Current Practice for 868 Communications Services in support of Emergency Calling", 869 draft-ietf-ecrit-phonebcp-15 (work in progress), 870 July 2010. 872 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 873 Tschofenig, "LoST: A Location-to-Service Translation 874 Protocol", RFC 5222, August 2008. 876 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 877 Location-to-Service Translation (LoST) Servers Using the 878 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 879 August 2008. 881 11.2. Informative References 883 [I-D.ietf-ecrit-lost] 884 Hardie, T., Newton, A., Schulzrinne, H., and H. 885 Tschofenig, "LoST: A Location-to-Service Translation 886 Protocol", draft-ietf-ecrit-lost-10 (work in progress), 887 May 2008. 889 [I-D.ietf-geopriv-l7-lcp-ps] 890 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 891 Location Configuration Protocol; Problem Statement and 892 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 893 progress), July 2009. 895 [I-D.ietf-ecrit-framework] 896 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 897 "Framework for Emergency Calling using Internet 898 Multimedia", draft-ietf-ecrit-framework-11 (work in 899 progress), July 2010. 901 [I-D.ietf-geopriv-http-location-delivery] 902 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 903 "HTTP Enabled Location Delivery (HELD)", 904 draft-ietf-geopriv-http-location-delivery-16 (work in 905 progress), August 2009. 907 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 908 Emergency Context Resolution with Internet Technologies", 909 RFC 5012, January 2008. 911 [I-D.ietf-geopriv-held-identity-extensions] 912 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 913 Barnes, "Use of Device Identity in HTTP-Enabled Location 914 Delivery (HELD)", 915 draft-ietf-geopriv-held-identity-extensions-04 (work in 916 progress), June 2010. 918 [I-D.winterbottom-geopriv-lis2lis-req] 919 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 920 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 921 (work in progress), November 2007. 923 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 924 Shanmugam, "Security Threats and Requirements for 925 Emergency Call Marking and Mapping", RFC 5069, 926 January 2008. 928 [I-D.ietf-geopriv-arch] 929 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 930 Tschofenig, H., and H. Schulzrinne, "An Architecture for 931 Location and Location Privacy in Internet Applications", 932 draft-ietf-geopriv-arch-02 (work in progress), May 2010. 934 [esw07] "3rd SDO Emergency Services Workshop, 935 http://www.emergency-services-coordination.info/2007Nov/", 936 October 30th - November 1st 2007. 938 [nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network 939 Architecture Stage-3 940 http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech 941 nical_document/2009/09/ 942 DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf", 943 September 2009. 945 Authors' Addresses 947 Henning Schulzrinne 948 Columbia University 949 Department of Computer Science 950 450 Computer Science Building 951 New York, NY 10027 952 US 954 Phone: +1 212 939 7004 955 Email: hgs+ecrit@cs.columbia.edu 956 URI: http://www.cs.columbia.edu 958 Stephen McCann 959 Research in Motion UK Ltd 960 200 Bath Road 961 Slough, Berks SL1 3XE 962 UK 964 Phone: +44 1753 667099 965 Email: smccann@rim.com 966 URI: http://www.rim.com 968 Gabor Bajko 969 Nokia 971 Email: Gabor.Bajko@nokia.com 972 Hannes Tschofenig 973 Nokia Siemens Networks 974 Linnoitustie 6 975 Espoo 02600 976 Finland 978 Phone: +358 (50) 4871445 979 Email: Hannes.Tschofenig@gmx.net 980 URI: http://www.tschofenig.priv.at 982 Dirk Kroeselberg 983 Nokia Siemens Networks 984 St.-Martin-Str. 76 985 Munich 81541 986 Germany 988 Phone: +49 (89) 515933019 989 Email: Dirk.Kroeselberg@nsn.com