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