[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-schulzrinne-ecrit-unauthenticated-access) 00 01 02 03 04 05 06 07 08 09

ECRIT                                                     H. Schulzrinne
Internet-Draft                                       Columbia University
Intended status: Standards Track                               S. McCann
Expires: March 25, 2011                        Research in Motion UK Ltd
                                                                G. Bajko
                                                                   Nokia
                                                           H. Tschofenig
                                                          D. Kroeselberg
                                                  Nokia Siemens Networks
                                                      September 21, 2010


   Extensions to the Emergency Services Architecture for dealing with
                Unauthenticated and Unauthorized Devices
             draft-ietf-ecrit-unauthenticated-access-00.txt

Abstract

   The IETF emergency services architecture assumes that the calling
   device has acquired rights to use the access network or that no
   authentication is required for the access network, such as for public
   wireless access points.  Subsequent protocol interactions, such as
   obtaining location information, learning the address of the Public
   Safety Answering Point (PSAP) and the emergency call itself are
   largely decoupled from the underlying network access procedures.

   In some cases, the device does not have credentials for network
   access, does not have a VoIP provider or application service provider
   (ASP), or the credentials have become invalid, e.g., because the user
   has exhausted their prepaid balance or the account has expired.

   This document provides a problem statement, introduces terminology
   and describes an extension for the base IETF emergency services
   architecture to address these scenarios.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference



Schulzrinne, et al.      Expires March 25, 2011                 [Page 1]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 25, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

































Schulzrinne, et al.      Expires March 25, 2011                 [Page 2]

Internet-Draft      Unauthenticated Emergency Service     September 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  No Access Authorization (NAA)  . . . . . . . . . . . . . .  5
     1.2.  No ASP (NASP)  . . . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Zero-Balance Application Service Provider (ZBP)  . . . . .  6
   2.  A Warning Note . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Considerations for ISPs to support Unauthenticated
       Emergency Services without Architecture Extensions . . . . . .  7
   5.  Considerations for ISPs to support Unauthenticated
       Emergency Services with Architecture Extensions  . . . . . . .  8
   6.  NAA considerations for the network attachment procedure of
       IAPs/ISPs  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Link layer emergency indication  . . . . . . . . . . . . . 12
     6.2.  Higher-layer emergency indication  . . . . . . . . . . . . 13
     6.3.  Securing network attachment in NAA cases . . . . . . . . . 14
   7.  Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  End Host Profile . . . . . . . . . . . . . . . . . . . . . 16
       7.1.1.  LoST Server Discovery  . . . . . . . . . . . . . . . . 16
       7.1.2.  ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16
       7.1.3.  Location Determination and Location Configuration  . . 16
       7.1.4.  Emergency Call Identification  . . . . . . . . . . . . 16
       7.1.5.  SIP Emergency Call Signaling . . . . . . . . . . . . . 17
       7.1.6.  Media  . . . . . . . . . . . . . . . . . . . . . . . . 17
       7.1.7.  Testing  . . . . . . . . . . . . . . . . . . . . . . . 17
     7.2.  IAP/ISP Profile  . . . . . . . . . . . . . . . . . . . . . 17
       7.2.1.  ESRP Discovery . . . . . . . . . . . . . . . . . . . . 17
       7.2.2.  Location Determination and Location Configuration  . . 17
     7.3.  ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 18
       7.3.1.  Emergency Call Routing . . . . . . . . . . . . . . . . 18
       7.3.2.  Emergency Call Identification  . . . . . . . . . . . . 18
       7.3.3.  SIP Emergency Call Signaling . . . . . . . . . . . . . 18
       7.3.4.  Location Retrieval . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22










Schulzrinne, et al.      Expires March 25, 2011                 [Page 3]

Internet-Draft      Unauthenticated Emergency Service     September 2010


1.  Introduction

   Summoning police, the fire department or an ambulance in emergencies
   is one of the fundamental and most-valued functions of the telephone.
   As telephone functionality moves from circuit-switched telephony to
   Internet telephony, its users rightfully expect that this core
   functionality will continue to work at least as well as it has for
   the older technology.  New devices and services are being made
   available that could be used to make a request for help, which are
   not traditional telephones, and users are increasingly expecting them
   to be used to place emergency calls.

   Roughly speaking, the IETF emergency services architecture (see
   [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides
   responsibility for handling emergency calls between the access
   network (ISP), the application service provider (ASP) that may be a
   VoIP service provider and the provider of emergency signaling
   services, the emergency service network (ESN).  The access network
   may provide location information to end systems, but does not have to
   provide any ASP signaling functionality.  The emergency caller can
   reach the ESN either directly or through the ASP's outbound proxy.
   Any of the three parties can provide the mapping from location to
   PSAP URI by offering LoST [RFC5222] services.

   In general, a set of automated configuration mechanisms allows a
   device to function in a variety of architectures, without the user
   being aware of the details on who provides location, mapping services
   or call routing services.  However, if emergency calling is to be
   supported when the calling device lacks access network authorization
   or does not have an ASP, one or more of the providers may need to
   provide additional services and functions.

   In all cases, the end device MUST be able to perform a LoST lookup
   and otherwise conduct the emergency call in the same manner as when
   the three exceptional conditions discussed below do not apply.

   We distinguish between three conditions:

   No access authorization (NAA):  The current access network requires
      access authorization and the caller does not have valid user
      credentials.  (This includes the case where the access network
      allows pay-per-use, as is common for wireless hotspots, but there
      is insufficient time to pay for access.)








Schulzrinne, et al.      Expires March 25, 2011                 [Page 4]

Internet-Draft      Unauthenticated Emergency Service     September 2010


    No ASP (NASP):  The caller does not have an ASP at the time of the
      call.

   Zero-balance ASP (ZBP):  The caller has valid credentials with an
      ASP, but is not allowed to access services like placing calls in
      case of a VoIP service, e.g., because the user has a zero balance
      in a prepaid account.


   A user may well suffer from both NAA and NASP or ZBP at the same
   time.  Depending on local policy and regulations, it may not be
   possible to place emergency calls in the NAA case.  Unless local
   regulations require user identification, it should always be possible
   to place calls in the NASP case, with minimal impact on the ISP.
   Unless the ESN requires that all calls traverse a known set of VSPs,
   a caller should be able to place an emergency call in the ZBP case.
   We discuss each case in separate sections below.

1.1.  No Access Authorization (NAA)

   In the NAA (No Access Authorization) case, the emergency caller does
   not posses valid credentials for the access network.  If local
   regulations or policy allows or requires support for emergency calls
   in NAA, the access network may or needs to cooperate in providing
   emergency calling services.  Support for NAA emergency calls is
   subject to the local policy of the ISP.  Such policy may vary
   substantially between ISPs and typically depends on external factors
   that are not under the ISP control.  Hence, no global mandates for
   supporting emergency calls in relation to NAA can be made.  However,
   it makes a lot of sense to offer appropriate building blocks that
   enable ISPs to flexibly react on the local environment.Generally, the
   ISP will want to ensure that devices do not pretend to place
   emergency calls, but then abuse the access for obtaining more general
   services fraudulently.

   In particular, the ISP MUST allow emergency callers to acquire an IP
   address and to reach a LoST server, either provided by the ISP or
   some third party.  It SHOULD also provide location information via
   one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without
   requiring authorization unless it can safely assume that all nodes in
   the access network can determine their own location, e.g., via GPS.

   The details of how filtering is performed depends on the details of
   the ISP architecture and are beyond the scope of this document.  We
   illustrate a possible model.  If the ISP runs its own LoST server, it
   would maintain an access control list including all IP addresses
   contained in responses returned by the LoST server, as well as the
   LoST server itself.  (It may need to translate the domain names



Schulzrinne, et al.      Expires March 25, 2011                 [Page 5]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   returned to IP addresses and hope that the resolution captures all
   possible DNS responses.)  Since the media destination addresses are
   not predictable, the ISP also has to provide a SIP outbound proxy so
   that it can determine the media addresses and add those to the filter
   list.

1.2.  No ASP (NASP)

   In the second case, the emergency caller has no current ASP.  This
   case poses no particular difficulties unless it is assumed that only
   ASPs provide LoST server or that ESNs only accept calls that reach it
   through a set of known ASPs.  However, since the calling device
   cannot obtain configuration information from its ASP, the ISP MUST
   provide the address of a LoST server via DHCP [RFC5223] if this model
   is to be supported.  The LoST server may be operated either by the
   ISP or a third party.

1.3.  Zero-Balance Application Service Provider (ZBP)

   In the case of zero-balance ASP, the ASP can authenticate the caller,
   but the caller is not authorized to use ASP services, e.g., because
   the contract has expired or the prepaid account for the customer has
   been depleted.  Naturally, an ASP can simply disallow access by such
   customers, so that all such customers find themselves in the NASP
   situation described above.  If ASPs desire or are required by
   regulation to provide emergency calling services to such customers,
   they need to provide LoST services to such customers and may need to
   provide outbound SIP proxy services.  As usual, the calling device
   looks up the LoST server via SIP configuration.

   Unless the emergency call traverses a PSTN gateway or the ASP charges
   for IP-to-IP calls, there is little potential for fraud.  If the ASP
   also operates the LoST server, the outbound proxy MAY restrict
   outbound calls to the SIP URIs returned by the LoST server.  It is
   NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may
   change.


2.  A Warning Note

   At the time of writing there is no regulation in place that demands
   the functionality described in this memo.  SDOs have started their
   work on this subject in a proactive fashion in the anticipation that
   national regulation will demand it for a subset of network
   environments.

   There are also indications that the functionality of unauthenticated
   emergency calls (called SIM-less calls) in today's cellular system in



Schulzrinne, et al.      Expires March 25, 2011                 [Page 6]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   certain countries leads to a fair amount of hoax or test calls.  This
   causes overload situations at PSAPs which is considered harmful to
   the overall availability and reliability of emergency services.

      As an example, Federal Office of Communications (OFCOM,
      Switzerland) provided statistics about emergency (112) calls in
      Switzerland from Jan. 1997 to Nov. 2001.  Switzerland did not
      offer SIM-less emergency calls except for almost a month in July
      2000 where a significant increase in hoax and test calls was
      reported.  As a consequence, the functionality was disabled again.
      More details can be found in the panel presentations of the 3rd
      SDO Emergency Services Workshop [esw07].


3.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119
   [RFC2119].

   This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]
   and [RFC5012], namely Internet Access Provider (IAP), Internet
   Service Provider (ISP), Application Service Provider (ASP), Voice
   Service Provider (VSP), Emergency Service Routing Proxy (ESRP),
   Public Safety Answering Point (PSAP), Location Configuration Server
   (LCS), (emergency) service dial string, and (emergency) service
   identifier.


4.  Considerations for ISPs to support Unauthenticated Emergency
    Services without Architecture Extensions

   This section provides a recommended configuration for unauthenticated
   emergency services support without architecture extensions.

   On a very high-level, the steps to be performed by an end host not
   being attached to the network and the user starting to make an
   emergency call are the following:

   o  Some radio networks have added support for unauthenticated
      emergency access, some other type of networks advertise these
      capabilities using layer beacons.  The end host learns about these
      unauthenticated emergency services capabilities either from the
      link layer type or from advertisement.
   o  The end host uses the link layer specific network attachment
      procedures defined for unauthenticated network access in order to
      get access to emergency services.



Schulzrinne, et al.      Expires March 25, 2011                 [Page 7]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   o  When the link layer network attachment procedure is completed the
      end host learns basic configuration information using DHCP from
      the ISP, including the address of the LoST server.
   o  The end host MUST use a Location Configuration Protocol (LCP)
      supported by the IAP or ISP to learn its own location.
   o  The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to
      query the LoST server and asks for the PSAP URI responsible for
      that location.
   o  After the PSAP URI has been returned to the end host, the SIP UA
      in the end host directly initiates a SIP INVITE towards the PSAP
      URI.

   The IAP and the ISP will probably want to make sure that the claimed
   emergency caller indeed performs an emergency call rather than using
   the network for other purposes, and thereby acting fraudulent by
   skipping any authentication, authorization and accounting procedures.
   By restricting access of the unauthenticated emergency caller to the
   LoST server and the PSAP URI, traffic can be restricted only to
   emergency calls (see also section 1.1).

   Using the above procedures, the unauthenticated emergency caller will
   be successful only if:

   o  the ISP (or the IAP) support an LCP that the end host can use to
      learn its location.  A list of mandatory-to-implement LCPs can be
      found in [I-D.ietf-ecrit-phonebcp]).
   o  the ISP configures it's firewalls appropriately to allow emergency
      calls to traverse the network towards the PSAP.

   Some IAPs/ISPs may not be able to fulfill the above requirements.  If
   those IAPs/ISPs want to support unauthenticated emergency calls, then
   they can deploy an extended architecture as described in Section 5.


5.  Considerations for ISPs to support Unauthenticated Emergency
    Services with Architecture Extensions

   This section provides a recommended configuration for unauthenticated
   emergency services support without architecture extensions.

   For unauthenticated emergency services support it is insufficient to
   provide mechanisms only at the link layer in order to bypass
   authentication for the cases when:

   o  the IAP/ISP does not support any Location Configuration Protocol
   o  the IAP/ISP cannot assume the end hosts to support a Location
      Configuration Protocol




Schulzrinne, et al.      Expires March 25, 2011                 [Page 8]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   o  the IAP/ISP does not have knowledge of a LoST server (which would
      assist the client to find the correct PSAP)

   A modification to the emergency services architecture is necessary
   since the IAP and the ISP need to make sure that the claimed
   emergency caller indeed performs an emergency call rather than using
   the network for other purposes, and thereby acting fraudulent by
   skipping any authentication, authorization and accounting procedures.
   Hence, without introducing some understanding of the specific
   application the ISP (and consequently the IAP) will not be able to
   detect and filter malicious activities.  This leads to the
   architecture described in Figure 1 where the IAP needs to implement
   extensions to link layer procedures for unauthenticated emergency
   service access and the ISP needs to deploy emergency services related
   entities used for call routing, such as the Emergency Services
   Routing Proxy (ESRP), a Location Configuration Server (LCS) and a
   mapping database.

   On a very high-level, the interaction is as follows starting with the
   end host not being attached to the network and the user starting to
   make an emergency call.

   o  Some radio networks have added support for unauthenticated
      emergency access, some other type of networks advertise these
      capabilities using layer beacons.  The end host learns about these
      unauthenticated emergency services capabilities either from the
      link layer type or from advertisement.
   o  The end host uses the link layer specific network attachment
      procedures defined for unauthenticated network access in order to
      get access to emergency services.
   o  When the link layer network attachment procedure is completed the
      end host learns basic configuration information using DHCP from
      the ISP, including the address of the ESRP, as shown in (2).
   o  When the IP address configuration is completed then the SIP UA
      initiates a SIP INVITE towards the indicated ESRP, as shown in
      (3).  The INVITE message contains all the necessary parameters
      required by Section 7.1.5.
   o  The ESRP receives the INVITE and processes it according to the
      description in Section 7.3.3.  The location of the end host may
      need to be determined using a protocol interaction shown in (4).
   o  Potentially, an interaction between the LCS of the ISP and the LCS
      of the IAP may be necessary, see (5).
   o  Finally, the correct PSAP for the location of the end host has to
      be evaluated, see (6).
   o  The ESRP routes the call to the PSAP, as shown in (7).
   o  The PSAP evaluates the initial INVITE and aims to complete the
      call setup.




Schulzrinne, et al.      Expires March 25, 2011                 [Page 9]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   o  Finally, when the call setup is completed media traffic can be
      exchanged between the PSAP and the emergency caller.

   For editorial reasons the end-to-end SIP and media exchange between
   the PSAP and SIP UA are not shown in Figure 1.

   Two important aspects are worth to highlight:

   o  The IAP/ISP needs to understand the concept of emergency calls or
      other emergency applicationsand the SIP profile described in this
      document.  No other VoIP protocol profile, such as XMPP, Skype,
      etc., are supported for emergency calls in this particular
      architecture.  Other profiles may be added in the future, but the
      deployment effort is enormous since they have to be universally
      deployed.
   o  The end host has no obligation to determine location information.
      It may attach location information if it has location available
      (e.g., from a GPS receiver).

   Figure 1 shows that the ISP needs to deploy SIP-based emergency
   services functionality.  It is important to note that the ISP itself
   may outsource the functionality by simply providing access to them
   (e.g., it puts the IP address of an ESRP or a LoST server into an
   allow-list).  For editorial reasons this outsourcing is not shown.



























Schulzrinne, et al.      Expires March 25, 2011                [Page 10]

Internet-Draft      Unauthenticated Emergency Service     September 2010


         +---------------------------+
         |                           |
         | Emergency Network         |
         | Infrastructure            |
         |                           |
         | +----------+ +----------+ |
         | | PSAP     | | ESRP     | |
         | |          | |          | |
         | +----------+ +----------+ |
         +-------------------^-------+
                             |
                             | (7)
    +------------------------+-----------------------+
    | ISP                    |                       |
    |                        |                       |
    |+----------+            v                       |
    || Mapping  |  (6)  +----------+                 |
    || Database |<----->| ESRP /   |                 |
    |+----------+       | SIP Proxy|<-+              |
    |+----------+       +----------+  |  +----------+|
    || LCS-ISP  |          ^          |  | DHCP     ||
    ||          |<---------+          |  | Server   ||
    |+----------+     (4)             |  +----------+|
    +-------^-------------------------+-----------^--+
    +-------|-------------------------+-----------|--+
    | IAP   | (5)                     |           |  |
    |       V                         |           |  |
    |+----------+                     |           |  |
    || LCS-IAP  |       +----------+  |           |  |
    ||          |       | Link     |  |(3)        |  |
    |+----------+       | Layer    |  |           |  |
    |                   | Device   |  |        (2)|  |
    |                   +----------+  |           |  |
    |                        ^        |           |  |
    |                        |        |           |  |
    +------------------------+--------+-----------+--+
                             |        |           |
                          (1)|        |           |
                             |        |           |
                             |   +----+           |
                             v   v                |
                        +----------+              |
                        | End      |<-------------+
                        | Host     |
                        +----------+

                            Figure 1: Overview




Schulzrinne, et al.      Expires March 25, 2011                [Page 11]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   It is important to note that a single ESRP may also offer it's
   service to several ISPs.


6.  NAA considerations for the network attachment procedure of IAPs/ISPs

   This section discusses different methods to indicate an emergency
   service request as part of network attachment.  It provides some
   general considerations and recommendations that are not specific to
   the access technology.

   To perform network attachment and get access to the resources
   provided by an IAP/ISP, the end host uses access technology specific
   network attachment procedures, including for example network
   detection and selection, authentication, and authorization.  For
   initial network attachment of an emergency service requester, the
   method of how the emergency indication is given to the IAP/ISP is
   specific to the access technology.  However, a number of general
   approaches can be identified:

   - Link layer emergency indication: The end host provides an
   indication, e.g. an emergency parameter or flag, as part of the link
   layer signaling for initial network attachment.  Examples include an
   emergency bit signalled in the IEEE 802.16-2009 wireless link.
   signalling allows an IEEE 802.1X to occur without exchanging
   cryptogrpahic keys

   - Higher-layer emergency indication: Typically emergency indication
   in access authentication.  The emergency caller's end host provides
   an indication as part of the access authentication exchanges.  EAP
   based authentication is of particular relevance here. [nwgstg3].

6.1.  Link layer emergency indication

   In general, link layer emergency indications provide good integration
   into the actual network access procedure regarding the enabling of
   means to recognize and prioritize an emergency service request from
   an end host at a very early stage of the network attachment
   procedure.  However, support in end hosts for such methods cannot be
   considered to be commonly available.

   No general recommendations are given in the scope of this memo due to
   the following reasons:

   - Dependency on the specific access technology.

   - Dependency on the specific access network architecture.  Access
   authorization and policy decisions typically happen at a different



Schulzrinne, et al.      Expires March 25, 2011                [Page 12]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   layers of the protocol stack and in different entities than those
   terminating the link-layer signaling.  As a result, link layer
   indications need to be distributed and translated between the
   different involved protocol layers and entities.  Appropriate methods
   are specific to the actual architecture of the IAP/ISP network.

6.2.  Higher-layer emergency indication

   This section focuses on emergency indications based on authentication
   and authorization in EAP-based network access.

   An advantage of combining emergency indications with the actual
   network attachment procedure performing authentication and
   authorization is the fact that the emergency indication can directly
   be taken into account in the authentication and authorization server
   that owns the policy for granting access to the network resources.
   As a result, there is no direct dependency on the access network
   architecture that otherwise would need to take care of merging link-
   layer indications into the AA and policy decision process.

   EAP signaling happens at a relatively early stage of network
   attachment, so it is likely to match most requirements for
   prioritization of emergency signaling.  However, it does not cover
   early stages of link layer activity in the network attachment
   process.  Possible conflicts may arise e.g. in case of MAC-based
   filtering in entities terminating the link-layer signaling in the
   network (like a base station).  In normal operation, EAP related
   information will only be recognized in the NAS.  Any entity residing
   between end host and NAS should not be expected to understand/parse
   EAP messages.

   The following potential methods to provide emergency indications in
   combination with EAP-based network attachment, are recognized:

   1) NAI-based emergency indication:

   An emergency indication can be given by forming a specific NAI that
   is used as the identity in EAP based authentication for network
   entry.  Methods include:

   1.a) NAI Decoration: NAI decoration is commonly used in routing EAP
   responses within the IAP/ISP AAA infrastructure.  Additional
   decoration can be used to add an indication that the network
   attachment attempt is meant for accessing emergency services.
   Potential advantages of such approach include that it requires only
   minimal realization effort compared to link-layer indications with
   good integration into the authentication and authorization
   procedures.  The same procedure can be used for all NAA cases (both



Schulzrinne, et al.      Expires March 25, 2011                [Page 13]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   unauthenticated and unauthorized) as well as for normal attachment
   with a valid subscription.  A potential disadvantage is that such EAP
   decoration is not globally defined across all different access
   technologies.

   1.b) Emergency NAI: The NAI comes with a realm or username part
   indicating emergency (e.g. 'emergency@emergency.com').  An advantage
   of this method for NAA cases is that no new requirements are put on
   the involved signaling procedures.  Only the identity used for
   network entry is impacted.  Potential disadvantages include that
   different methods to indicate emergency for NAA cases and standard
   emergency network attachments may be required.  Also, modifying the
   NAI itself (the username@realm part) may conflict with network
   selection and network entry procedures, depending on the actual
   access network.

   2) Emergency EAP method

   An emergency indication can be given by using a dedicated EAP method
   that is reserved for emergency network attachment only.

   2.a) Existing EAP method with new type: An existing EAP method may be
   used.  EAP methods themselves typically do not support emergency
   indication.  One option would be to pick a common EAP method like
   EAP-TLS and allocate a new method type for the same method that is
   exclusively reserved to emergency use.  Such EAP method should be
   chosen in a way that the same method can support NAA cases as well as
   standard emergency network attachment.

   2.b) Existing EAP method: Same as 2a), but without assigning a new
   EAP method type for emergency.  In this case some implicit indication
   must be used.  For example, in cases where EAP-TLS is used in network
   attachment in combination with client certificates, the absence of a
   client certificate could be interpreted by the network as a request
   for emergency network attachment.

   2.c) Emergency EAP method: A new EAP method could be defined that is
   specifically designed for emergency network entry in NAA cases.  Most
   likely, such EAP method would not be usable for standard emergency
   network attachment with an existing subscription.  Such dedicated
   emergency EAP method should be key-generating in compliance with
   RFC3748 to enable the regular air interface security methods even in
   unauthenticated operation.

6.3.  Securing network attachment in NAA cases

   For network attachment in NAA cases, it may make sense to secure the
   link-layer connection between the device and the IAP/ISP.  This



Schulzrinne, et al.      Expires March 25, 2011                [Page 14]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   especially holds for wireless access with examples being based
   access.  The latter even mandates secured communication across the
   wireless link for all IAP/ISP networks based on [nwgstg3].

   Therefore, for network attachment that is by default based on EAP
   authentication it is desirable also for NAA network attachment to use
   a key-generating EAP method (that provides an MSK key to the
   authenticator to bootstrap further key derivation for protecting the
   wireless link).

   The following approaches to match the above can be identified:

   1) Server-only authentication: The device of the emergency service
   requester performs an EAP method with the IAP/ISP EAP server that
   performs server authentication only.  An example for this is EAP-TLS.
   This provides a certain level of assurance about the IAP/ISP to the
   device user.  It requires the device to be provisioned with
   appropriate trusted root certificates to be able to verify the server
   certificate of the EAP server (unless this step is explicitly skipped
   in the device in case of an emergency service request).

   2) Null authentication: an EAP method is performed.  However, no
   credentials specific to either the server or the device or
   subscription are used as part of the authentication exchange.  An
   example for this would be an EAP-TLS exchange with using the
   TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a publicly
   available static key for emergency access could be used.  In the
   latter case, the device would need to be provisioned with the
   appropriate emergency key for the IAP/ISP in advance.

   3) Device authentication: This case extends the server-only
   authentication case.  If the device is configured with a device
   certificate and the IAP/ISP EAP server can rely on a trusted root
   allowing the EAP server to verify the device certificate, at least
   the device identity (e.g. the MAC address) can be authenticated by
   the IAP/ISP in NAA cases.  An example for this are WiMAX devices that
   are shipped with device certificates issued under the global WiMAX
   device public-key infrastructure.  To perform unauthenticated
   emergency calls, if allowed by the IAP/ISP, such devices perform EAP-
   TLS based network attachment with client authentication based on the
   device certificate.


7.  Profiles







Schulzrinne, et al.      Expires March 25, 2011                [Page 15]

Internet-Draft      Unauthenticated Emergency Service     September 2010


7.1.  End Host Profile

7.1.1.  LoST Server Discovery

   The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a
   LoST server.  If that attempt fails, the end host SHOULD attempt to
   discover the address of an ESRP.

7.1.2.  ESRP Discovery

   The end host only needs an ESRP when location configuration or LoST
   server discovery fails.  If that is the case, then the end host MUST
   use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option
   for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6)
   and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options
   for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover
   the address of an ESRP.  This SIP proxy located in the ISP network
   will be used as the ESRP for routing emergency calls.  There is no
   need to discovery a separate SIP proxy with specific emergency call
   functionality since the internal procedure for emergency call
   processing is subject of ISP internal operation.

7.1.3.  Location Determination and Location Configuration

   The end host SHOULD attempt to use the supported LCPs to configure
   its location.  If no LCP is supported in the end host or the location
   configuration is not successful, then the end host MUST attempt to
   discover an ESRP, which would assist the end host in providing the
   location to the PSAP.

   The SIP UA in the end host SHOULD attach the location information in
   a PIDF-LO [RFC4119] when making an emergency call.  When constructing
   the PIDF-LO the guidelines in PIDF-LO profile
   [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed.  For civic
   location information the format defined in [RFC5139] MUST be
   supported.

7.1.4.  Emergency Call Identification

   To determine which calls are emergency calls, some entity needs to
   map a user entered dialstring into this URN scheme.  A user may
   "dial" 1-1-2, but the call would be sent to urn:service:sos.  This
   mapping SHOULD be performed at the endpoint device.

   End hosts MUST use the Service URN mechanism [RFC5031] to mark calls
   as emergency calls for their home emergency dial string (if known).
   For visited emergency dial string the translation into the Service
   URN mechanism is not mandatory since the ESRP in the ISPs network



Schulzrinne, et al.      Expires March 25, 2011                [Page 16]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   knows the visited emergency dial strings.

7.1.5.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for end hosts.

   The initial SIP signaling method is an INVITE.  The SIP INVITE
   request MUST be constructed according to the requirements in Section
   9.2 [I-D.ietf-ecrit-phonebcp].

   Regarding callback behavior SIP UAs MUST have a globally routable URI
   in a Contact: header.

7.1.6.  Media

   End points MUST comply with the media requirements for end points
   placing an emergency call found in Section 14 of
   [I-D.ietf-ecrit-phonebcp].

7.1.7.  Testing

   The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully
   applicable to this document.

7.2.  IAP/ISP Profile

7.2.1.  ESRP Discovery

   An ISP hosting an ESRP MUST implement the server side part of
   "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for
   Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and /
   or the "Dynamic Host Configuration Protocol (DHCPv6) Options for
   Session Initiation Protocol (SIP) Servers" [RFC3319].

7.2.2.  Location Determination and Location Configuration

   The ISP not hosting an ESRP MUST support at least one widely used
   LCP.  The ISP hosting an ESRP MUST perform the neccesary steps to
   determine the location of the end host.  It is not necessary to
   standardize a specific mechanism.

   The role of the ISP is to operate the LIS.  The usage of HELD
   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.ietf-geopriv-held-identity-extensions] may be a
   possible choice.  It might be necessary for the ISP to talk to the
   IAP in order to determine the location of the end host.  The work on
   LIS-to-LIS communication may be relevant, see
   [I-D.winterbottom-geopriv-lis2lis-req].



Schulzrinne, et al.      Expires March 25, 2011                [Page 17]

Internet-Draft      Unauthenticated Emergency Service     September 2010


7.3.  ESRP Profile

7.3.1.  Emergency Call Routing

   The ESRP must route the emergency call to the PSAP responsible for
   the physical location of the end host.  However, a standardized
   approach for determining the correct PSAP based on a given location
   is useful but not mandatory.

   For cases where a standardized protocol is used LoST
   [I-D.ietf-ecrit-lost] is a suitable mechanism.

7.3.2.  Emergency Call Identification

   The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,
   the 'urn:service:sos' tree) and additionally the national emergency
   dial strings.  The ESRP SHOULD perform a mapping of national
   emergency dial strings to Service URNs to simplify processing at
   PSAPs.

7.3.3.  SIP Emergency Call Signaling

   SIP signaling capabilities [RFC3261] are mandated for the ESRP.  The
   ESRP MUST process the messages sent by the client, according to
   Section 7.1.5.  Furthermore, the ESRP MUST be able to add a reference
   to location information, as described in SIP Location Conveyance
   [I-D.ietf-sip-location-conveyance], before forwarding the call to the
   PSAP.  The ISP MUST be prepared to receive incoming dereferencing
   requests to resolve the reference to the location information.

7.3.4.  Location Retrieval

   The ESRP acts a location recipient and the usage of HELD
   [I-D.ietf-geopriv-http-location-delivery] with the identity
   extensions [I-D.ietf-geopriv-held-identity-extensions] may be a
   possible choice.  The ESRP would thereby act as a HELD client and the
   corresponding LIS at the ISP as the HELD server.

   The ESRP needs to obtain enough information to route the call.  The
   ESRP itself, however, does not necessarily need to process location
   information obtained via HELD since it may be used as input to LoST
   to obtain the PSAP URI.


8.  Security Considerations

   The security threats discussed in [RFC5069] are applicable to this
   document.  A number of security vulnerabilities discussed in



Schulzrinne, et al.      Expires March 25, 2011                [Page 18]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   [I-D.ietf-geopriv-arch] around faked location information are less
   problematic in this case since location information does not need to
   be provided by the end host itself or it can be verified to fall
   within a specific geographical area.

   There are a couple of new vulnerabilities raised with unauthenticated
   emergency services since the PSAP operator does is not in possession
   of any identity information about the emergency call via the
   signaling path itself.  In countries where this functionality is used
   for GSM networks today this has lead to a significant amount of
   misuse.

   The link layer mechanisms need to provide a special way of handling
   unauthenticated emergency services.  Although this subject is not a
   topic for the IETF itself but there are at least a few high-level
   assumptions that may need to be collected.  This includes security
   features that may be desirable.


9.  Acknowledgments

   Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp].
   The WiMax Forum contributed parts of the terminology.  Participants
   of the 2nd and 3rd SDO Emergency Services Workshop provided helpful
   input.


10.  IANA Considerations

   This document does not require actions by IANA.


11.  References

11.1.  Normative References

   [I-D.ietf-sip-location-conveyance]
              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-13 (work in progress),
              March 2009.

   [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              January 2008.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.



Schulzrinne, et al.      Expires March 25, 2011                [Page 19]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   [I-D.ietf-geopriv-pdif-lo-profile]
              Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO Usage Clarification, Considerations and
              Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
              (work in progress), November 2008.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCP-for-IPv4) Option for Session Initiation Protocol
              (SIP) Servers", RFC 3361, August 2002.

   [RFC3319]  Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
              Protocol (DHCPv6) Options for Session Initiation Protocol
              (SIP) Servers", RFC 3319, July 2003.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency Calling",
              draft-ietf-ecrit-phonebcp-15 (work in progress),
              July 2010.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC5223]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
              Location-to-Service Translation (LoST) Servers Using the
              Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
              August 2008.

11.2.  Informative References

   [I-D.ietf-ecrit-lost]
              Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", draft-ietf-ecrit-lost-10 (work in progress),
              May 2008.



Schulzrinne, et al.      Expires March 25, 2011                [Page 20]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
              progress), July 2009.

   [I-D.ietf-ecrit-framework]
              Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling using Internet
              Multimedia", draft-ietf-ecrit-framework-11 (work in
              progress), July 2010.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-16 (work in
              progress), August 2009.

   [RFC5012]  Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              RFC 5012, January 2008.

   [I-D.ietf-geopriv-held-identity-extensions]
              Winterbottom, J., Thomson, M., Tschofenig, H., and R.
              Barnes, "Use of Device Identity in HTTP-Enabled Location
              Delivery (HELD)",
              draft-ietf-geopriv-held-identity-extensions-04 (work in
              progress), June 2010.

   [I-D.winterbottom-geopriv-lis2lis-req]
              Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
              Requirements", draft-winterbottom-geopriv-lis2lis-req-01
              (work in progress), November 2007.

   [RFC5069]  Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
              Shanmugam, "Security Threats and Requirements for
              Emergency Call Marking and Mapping", RFC 5069,
              January 2008.

   [I-D.ietf-geopriv-arch]
              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              draft-ietf-geopriv-arch-02 (work in progress), May 2010.

   [esw07]    "3rd SDO Emergency Services Workshop,
              http://www.emergency-services-coordination.info/2007Nov/",
              October 30th - November 1st 2007.



Schulzrinne, et al.      Expires March 25, 2011                [Page 21]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   [nwgstg3]  "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network
              Architecture Stage-3
              http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech
              nical_document/2009/09/
              DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf",
              September 2009.


Authors' Addresses

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu


   Stephen McCann
   Research in Motion UK Ltd
   200 Bath Road
   Slough, Berks  SL1 3XE
   UK

   Phone: +44 1753 667099
   Email: smccann@rim.com
   URI:   http://www.rim.com


   Gabor Bajko
   Nokia

   Email: Gabor.Bajko@nokia.com














Schulzrinne, et al.      Expires March 25, 2011                [Page 22]

Internet-Draft      Unauthenticated Emergency Service     September 2010


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   Dirk Kroeselberg
   Nokia Siemens Networks
   St.-Martin-Str. 76
   Munich  81541
   Germany

   Phone: +49 (89) 515933019
   Email: Dirk.Kroeselberg@nsn.com
































Schulzrinne, et al.      Expires March 25, 2011                [Page 23]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/