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