[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 draft-ietf-ecrit-trustworthy-location

ECRIT                                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status:  Informational                           H. Schulzrinne
Expires:  January 8, 2009                            Columbia University
                                                            July 7, 2008

                    Trustworthy Location Information

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 8, 2009.

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 1]

Internet-Draft      Trustworthy Location Information           July 2008


   For location-based applications, such as emergency calling or
   roadside assistance, the identity of the requestor is less important
   than accurate and trustworthy location information.

   A number of protocols are available to supply end systems with either
   civic or geodetic information.  For some applications it is an
   important requirement that location information has not been modified
   in transit or by the end point itself.

   This document investigates different threats, the adversary model,
   and outlines three possible solutions.  The document concludes with a
   suggestion on how to move forward.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Emergency Services . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Location Spoofing  . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Call Identity Spoofing . . . . . . . . . . . . . . . . . .  8
   5.  Solution Proposals . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Location Signing . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Location by Reference  . . . . . . . . . . . . . . . . . . 10
     5.3.  Proxy Adding Location  . . . . . . . . . . . . . . . . . . 12
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 2]

Internet-Draft      Trustworthy Location Information           July 2008

1.  Introduction

   Much of the focus in trustable networks has been on ensuring the
   reliability of personal identity information or verifying privileges.
   However, in some cases, access to trustworthy location information is
   more important than identity since some services are meant to be
   widely available, regardless of the identity of the requestor.
   Emergency services, such as fire department, ambulance and police,
   but also commercial services such as food delivery and roadside
   assistance are among those.  Customers, competitors or emergency
   callers lie about their location to harm the service provider or to
   deny services to others, by tying up the service capacity.  In
   addition, if third parties can modify the information, they can deny
   services to the requestor.

   Physical security is often based on location.  As a trivial example,
   light switches in buildings are not typically protected by keycards
   or passwords, but are only accessible to those within the perimeter
   of the building.  Merchants processing credit card payments already
   use location information to estimate the risk that a transaction is
   fraudulent, based on the HTTP client's IP address (that is then
   translated to location).  In all these cases, trustworthy location
   information can be used to augment identity information or, in some
   cases, avoid the need for role-based authorization.

   A number of standardization organizations have developed mechanisms
   to make civic and geodetic location available to the end host.
   Examples for these protocols are LLDP-MED, DHCP extensions (see [2],
   [3]), HELD (see [4]) or the protocols developed within the IEEE as
   part of their link-layer specifications.  The server offering this
   information is usually called a Location Information Server (LIS).
   In many cases, the end host itself can determine its location, e.g.,
   via GPS.  The location information is then provided, by reference or
   value, to the service-providing entities, i.e. location recipients,
   via application protocols, such as SIP or HTTP.

   This document investigates the security threats in Section 4, and
   outlines three solutions in Section 5 that should serve as a
   discussion starter.  We use emergency services an example to
   illustrate the security problems and the architectural impact, as the
   problems have been typically discussed in that context since the
   stakes are high, but the issues apply also to other examples as cited

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 3]

Internet-Draft      Trustworthy Location Information           July 2008

2.  Terminology

   This document re-uses a lot of the terminology defined in Section 3
   of [1].

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 4]

Internet-Draft      Trustworthy Location Information           July 2008

3.  Emergency Services

   Users of the legacy telephone network can summon emergency services
   such as ambulance, fire and police using a well-known emergency
   service number (e.g., 9-1-1 in North America, 1-1-2 in Europe).
   Location information is used to route emergency calls to the
   appropriate regional Public Safety Answering Point (PSAP) that serves
   the caller to dispatch first-level responders to the emergency site.

   Regulators have already started to demand emergency service support
   for voice over IP.  However, enabling such critical public services
   using the Internet is challenging, as many of the assumptions of the
   PSTN no longer hold.  In particular, while the local telephone
   company provides both the physical access and the phone service, VoIP
   allows and encourages to split these two roles between the Access
   Infrastructure Provider (AIP) and Application (Voice) Service
   Provider (VSP).  The VSP may be located far away from the AIP and may
   either have no business relationship with that AIP or may be a
   competitor.  It is also likely that the VSP will have no relationship
   with the PSAP and will therefore be unknown.

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 5]

Internet-Draft      Trustworthy Location Information           July 2008

4.  Threats

   IP-based emergency calling faces many security threats, most of which
   are well-known from other realms, such as protecting the privacy of
   communications or against denial-of-service attacks using packet
   flooding.  Here, we focus specifically on a higher-layer threat that
   is unique to services where semi-anonymous users can request
   expensive services.

   Prank calls have been a problem for emergency services, dating back
   to the time of street corner call boxes.  Individual prank calls
   waste emergency services and possibly endanger bystanders or
   emergency service personnel as they rush to the reported scene of a
   fire or accident.  A more recent concern is that massive prank calls
   can be used to disrupt emergency services, e.g., during a mass-
   casualty event and thus be used as a means to amplify the effect of a
   terror attack, for example.

   Emergency services have three finite resources subject to denial of
   service attacks:  the network and server infrastructure, call takers
   and dispatchers, and the first responders, such as fire fighters and
   police officers.  Protecting the network infrastructure is similar to
   protecting other high-value service providers, except that
   trustworthy location information may be used to filter call setup
   requests, to weed out requests that are out of area.  PSAPs even for
   large cities may only have a handful of PSAP call takers on duty, so
   even if they can, by questioning the caller, eliminate a lot of prank
   calls, they are quickly overwhelmed by even a small-scale attack.
   Finally, first responder resources are scarce, particularly during
   mass-casualty events.

   Currently, emergency services rely on the fact that location spoofing
   is difficult for normal users.  Additionally, the identity of most
   callers can be ascertained, so that the threat of severe punishments
   reduces prank calls.  Mechanically placing a large number of
   emergency calls that appear to come from different locations is also
   difficult.  Calls from payphones are subject to greater scrutiny by
   the call taker.  In the current system, it would be very difficult
   for an attacker from country 'Foo' to attack the emergency services
   infrastructure located in country 'Bar'.

   One of the main motivations of an adversary in the emergency services
   context is to prevent callers from utilizing emergency service
   support.  This can be done by a variety of means, such as
   impersonating a PSAP or directory servers, attacking SIP signaling
   elements and location servers.

   Attackers may want to modify, prevent or delay emergency calls.  In

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 6]

Internet-Draft      Trustworthy Location Information           July 2008

   some cases, this will lead the PSAP to dispatch emergency personnel
   to an emergency that does not exist and, hence, the personnel might
   not be available to other callers.  It might also be possible for an
   attacker to impede the users from reaching an appropriate PSAP by
   modifying the location of an end host or the information returned
   from the mapping protocol.  In some countries, regulators may not
   demand authentication of the emergency caller, as is true for PSTN-
   based emergency calls placed from payphones or no-account cell phones
   today.  Furthermore, if identities can easily be crafted, then the
   value of emergency caller authentication might be limited.  As a
   consequence, an attacker can forge emergency call information without
   being traced.

   The above-mentioned attacks are mostly targeting individual emergency
   callers or a very small fraction of them.  If attacks are, however,
   launched against the mapping architecture or against PSAP entities, a
   larger region and a large number of potential emergency callers are
   affected, particularly targeting the call takers at the PSAP.

   In this context, three adversary models need to be considered:

   External adversary model:  The end host, e.g., an emergency caller
      whose location is going to be communicated, is honest and the
      adversary may be located between the end host and the location
      server or between the end host and the PSAP.  None of the
      emergency service infrastructure elements act maliciously.

   Malicious infrastructure adversary model:  The emergency call routing
      elements, such as the LIS, the LoST infrastructure, used for
      mapping locations to PSAP address, or call routing elements, may
      act maliciously.

   Malicious end host adversary model:  The end host itself acts
      maliciously, whether the owner is aware of this or whether it is
      acting as a bot.

   We will focus only on the malicious end host adversary model since it
   follows today's most common adversary model on the Internet that
   includes bot nets.

4.1.  Location Spoofing

   An adversary can provide false location information in order to fool
   the emergency personnel.  Such an attack is particularly easy if
   location information is attached to the emergency call by the end
   host and is either not verified or cannot be verified by anyone.
   Only entities that are close to the caller can verify the correctness
   of location information.

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 7]

Internet-Draft      Trustworthy Location Information           July 2008

   The following list presents threats specific to location information

   Place shifting:  Trudy, the adversary, pretends to be at an arbitrary
      location.  In some cases, place shifting can be limited in range,
      e.g., to the coverage area of a particular cell tower.

   Time shifting:  Trudy pretends to be at a location she was a while

   Location theft:  Trudy observes Alice's location and replays it as
      her own.

   Location swapping:  Trudy and Malory, located in different locations,
      can collude and swap location information and pretend to be in
      each other's location.

4.2.  Call Identity Spoofing

   If an adversary can place emergency calls without disclosing its
   identity, then prank calls are more difficult to be traced.  There
   are at least two different forms of authentication in this context;
   network access authentication and authentication of the emergency
   caller at the application layer.  This differentiation is created by
   the split between the AIP and the VSP whereby different identities
   are involved.

   Trying to find an adversary that did not authenticate itself to the
   VSP is difficult even though there is still a chance that network
   access authentication was exercised.  If there is no authentication
   (neither to the PSAP, to the VSP nor to the AIP) then it is very
   challenging to trace the call back in order to a make a particular
   entity accountable.  This might, for example, be the case with an
   open IEEE 802.11 WLAN access point even if the owner of the access
   point can be determined.

   However, unlike for the existing telephone system, it is possible to
   imagine that VoIP emergency calls could require strong identity, as
   providing such identity information is not necessarily coupled to
   having a business relationship with the AIP, ISP or VSP.  However,
   due to the time-critical nature of emergency calls, it is unlikely
   that multi-layers authentication can be used, so that in most cases,
   only the device placing the call will be able to be identified,
   making the system vulnerable to botnet attacks.  Furthermore,
   deploying additional credentials for emergency service purposes, such
   as certificates, increases costs, introduces a significant
   administrative overhead and is only useful if widely used.

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 8]

Internet-Draft      Trustworthy Location Information           July 2008

5.  Solution Proposals

   This section presents three solution approaches to mitigate the
   threats discussed.

5.1.  Location Signing

   One way to avoid location spoofing is to let a trusted location
   server sign the location information before it is sent to the end
   host, i.e., the entity subject to the location determination process.
   The signed location information is then verified by the location
   recipient and not by the target.  Figure 1 shows the communication
   model with the target requesting signed location in step (a), the
   location server returns it in step (b) and it is then conveyed to the
   location recipient in step (c) who verifies it.  For SIP, the
   procedures described in [5] are applicable for location conveyance.

                +-----------+               +-----------+
                |           |               | Location  |
                |    LIS    |               | Recipient |
                |           |               |           |
                +-+-------+-+               +----+------+
                  ^       |                    --^
                  |       |                  --
    Geopriv       |Req.   |                --
    Location      |Signed |Signed        -- Geopriv
    Configuration |Loc.   |Loc.        --   Using Protocol
    Protocol      |(a)    |(b)       --     (e.g., SIP)
                  |       v        --       (c)
                +-+-------+-+    --
                | Target /  |  --
                | End Host  +
                |           |

                        Figure 1: Location Signing

   Additional information, such as timestamps or expiration times, has
   to be included together with the signed location to limit replay
   attacks.  If the location is retrieved from a location server, even a
   stationary end host has to periodically obtain a fresh signed
   location, or incur the additional delay of querying during the
   emergency call.

   Bot nets are also unlikely to be deterred by location signing.
   However, accurate location information would limit the usable subset
   of the bot net, as only hosts within the PSAP serving area would be

Tschofenig & Schulzrinne  Expires January 8, 2009               [Page 9]

Internet-Draft      Trustworthy Location Information           July 2008

   useful in placing calls.

   To prevent location-swapping attacks it is necessary to include some
   some target specific identity information.  The included information
   depends on the purpose, namely either real-time verification by the
   location recipient or for the purpose of a post-mortem analysis when
   the location recipient wants to determine the legal entity behind the
   target for prosecution (if this is possible).  As an example, a
   solution proposal is provided by [6].

   Still, for large-scale attacks launched by bot nets, this is unlikely
   to be helpful.  Location signing is also difficult when the host
   provides its own location via GPS, which is likely to be a common
   occurrence for mobile devices.  Trusted computing approaches, with
   tamper-proof GPS modules, may be needed in that case.  After all, a
   device can always pretend to have a GPS device and the recipient has
   no way of verifying this or forcing disclosure of non-GPS-derived
   location information.

   Location verification may be most useful if it is used in conjunction
   with other mechanisms.  For example, a call taker can verify that the
   region that corresponds to the IP address of the media stream roughly
   corresponds to the location information reported by the caller.  To
   make the use of bot nets more difficult, a CAPTCHA-style test may be
   applied to suspicious calls, although this idea is quite
   controversial for emergency services, at the danger of delaying or
   even rejecting valid calls.

5.2.  Location by Reference

   The location-by-reference concept was developed so that end hosts
   could avoid having to periodically query the location server for up-
   to-date location information in a mobile environment.  Additionally,
   if operators do not want to disclose location information to the end
   host without charging them, location-by-reference provides a
   reasonable alternative.

   Figure 2 shows the communication model with the target requesting a
   location reference in step (a), the location server returns the
   reference in step (b), and it is then conveyed to the location
   recipient in step (c).  The location recipient needs to resolve the
   reference with a request in step (d).  Finally, location information
   is returned to the Location Recipient afterwards.  For location
   conveyance in SIP, the procedures described in [5] are applicable.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 10]

Internet-Draft      Trustworthy Location Information           July 2008

                +-----------+  Geopriv      +-----------+
                |           |  Location     | Location  |
                |    LIS    +<------------->+ Recipient |
                |           | Dereferencing |           |
                +-+-------+-+ Protocol (d)  +----+------+
                  ^       |                    --^
                  |       |                  --
    Geopriv       |Req.   |                --
    Location      |LbyR   |LbyR          -- Geopriv
    Configuration |(a)    |(b)         --   Using Protocol
    Protocol      |       |          --     (e.g., SIP)
                  |       V        --       (c)
                +-+-------+-+    --
                | Target /  |  --
                | End Host  +
                |           |

                      Figure 2: Location by Reference

   The details for the dereferencing operations vary with the type of
   reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence
   URI.  HTTP-Enabled Location Delivery (HELD) [4] is an example of a
   protocol that is able to return such references.

   For location-by-reference, the location server needs to maintain one
   or several URIs for each target, timing out these URIs after a
   certain amount of time.  References need to expire to prevent the
   recipient of such a URL from being able to permanently track a host
   and to offer garbage collection functionality for the location

   Off-path adversaries must be prevented from obtaining the target's
   location.  The reference contains a randomized component that
   prevents third parties from guessing it.  When the location recipient
   fetches up-to-date location information from the location server, it
   can also be assured that the location information is fresh and not
   replayed.  However, this does not address location swapping.

   However, location-by-reference does not offer significant security
   benefits if the end host uses GPS to determine its location.  At
   best, a network provider can use cell tower or triangulation
   information to limit the inaccuracy of user-provided location

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 11]

Internet-Draft      Trustworthy Location Information           July 2008

5.3.  Proxy Adding Location

   Instead of making location information available to the end host, it
   is possible to allow an entity in the AIP, or associated with the
   AIP, to retrieve the location information on behalf of the end point.
   This solution is possible when the application layer messages are
   routed through an entity with the ability to determine the location
   information of the end point, for example based on the end host's IP
   or MAC address.

   When the untrustworthy end host does not have the ability to access
   location information, it cannot modify it either.  Proxies can use
   various techniques, including SIP Identity, to ensure that
   modifications to the location in transit can be detected by the
   location recipient (e.g., the PSAP).  As noted above, this is
   unlikely to work for GPS-based location determination techniques.

   The obvious disadvantage of this approach is that there is a need to
   deploy application layer entities, such as SIP proxies, at AIPs or
   associated with AIPs.  In case of devices that lack credentials or
   are unauthorized to access certain networks the procedures described
   in [7] may very well be aligned with such an approach.  Finally, it
   has to be noted that routing emergency calls through SIP proxies in
   the AIP closely matches the approaches favored by the 3GPP in their
   IMS emergency architecture.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 12]

Internet-Draft      Trustworthy Location Information           July 2008

6.  Conclusion

   Emergency services raise a number of architectural questions,
   see~\cite{draft-ietf-ecrit-framework}.  With the generalized
   emergency architecture considered within the ECRIT working group
   various security challenges need to be addressed, including the
   ability to report faked location and other attacks against the
   emergency services infrastructure.  These types of attacks also show
   that the attack characteristics play an important role when dealing
   with the problems and lower-layer solutions, as they have been
   proposed as solutions to generic Denial of Service prevention (for
   example using cryptographic puzzles), have limited applicability.

   Although it is important to ensure that location information cannot
   be faked there will be a larger number of GPS-enabled devices out
   there that make it difficult to utilize any of the security
   mechanisms described in Section 5.  It will be very unlikely that end
   users will upload their location information for "verification" to a
   nearby location server located in the access network.  When location
   is obtained from the network then there one mechanism, namely
   Location by Reference, is currently being specified already to offer
   a high degree of security protection.  In addition, it is extremely
   important to stress the need for a strong identity mechanism that
   allows user's to be traced back and to hold them responsible for
   their actions.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 13]

Internet-Draft      Trustworthy Location Information           July 2008

7.  IANA Considerations

   This document does not require actions by IANA.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 14]

Internet-Draft      Trustworthy Location Information           July 2008

8.  Acknowledgments

   We would like to thank the members of the IETF ECRIT and the IETF
   GEOPRIV working group for their input to the discussions related to
   this topic.  We would also like to thank Andrew Newton, Murugaraj
   Shanmugam, Richard Barnes and Matt Lepinski for their feedback to
   previous versions to this document.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 15]

Internet-Draft      Trustworthy Location Information           July 2008

9.  References

9.1.  Normative References

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

9.2.  Informative references

   [2]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
        and DHCPv6) Option for Civic Addresses Configuration
        Information", RFC 4776, November 2006.

   [3]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
        Configuration Protocol Option for Coordinate-based Location
        Configuration Information", RFC 3825, July 2004.

   [4]  Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP
        Enabled Location Delivery (HELD)",
        draft-ietf-geopriv-http-location-delivery-07 (work in progress),
        April 2008.

   [5]  Polk, J. and B. Rosen, "Location Conveyance for the Session
        Initiation Protocol", draft-ietf-sip-location-conveyance-10
        (work in progress), February 2008.

   [6]  Thomson, M. and J. Winterbottom, "Digital Signature Methods for
        Location Dependability",
        draft-thomson-geopriv-location-dependability-02 (work in
        progress), July 2008.

   [7]  Schulzrinne, H., McCann, S., Bajko, G., and H. Tschofenig,
        "Extensions to the Emergency Services Architecture for dealing
        with  Unauthenticated and Unauthorized Devices",
        draft-schulzrinne-ecrit-unauthenticated-access-02 (work in
        progress), February 2008.

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 16]

Internet-Draft      Trustworthy Location Information           July 2008

Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

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

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

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

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 17]

Internet-Draft      Trustworthy Location Information           July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Tschofenig & Schulzrinne  Expires January 8, 2009              [Page 18]

Html markup produced by rfcmarkup 1.119, available from https://tools.ietf.org/tools/rfcmarkup/