One document matched: draft-ietf-ecrit-trustworthy-location-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-sip-location-conveyance PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-location-conveyance.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.thomson-geopriv-location-dependability PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-location-dependability.xml">
<!ENTITY RFC3825 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825.xml">
<!ENTITY RFC4776 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml">
<!ENTITY RFC5012 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml">
<!ENTITY I-D.schulzrinne-ecrit-unauthenticated-access PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schulzrinne-ecrit-unauthenticated-access.xml">
<!ENTITY I-D.ietf-ecrit-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml">
<!ENTITY RFC4293 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC3411 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC4188 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4188.xml">
<!ENTITY RFC4862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC3927 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml">
<!ENTITY RFC4474 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY RFC4479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4740 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4740.xml">
<!ENTITY I-D.tschofenig-ecrit-architecture-overview PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-ecrit-architecture-overview.xml">
<!ENTITY I-D.ietf-ecrit-mapping-arch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-mapping-arch.xml">
<!ENTITY I-D.winterbottom-geopriv-deref-protocol PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-deref-protocol.xml">
<!ENTITY I-D.ietf-ecrit-location-hiding-req PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-location-hiding-req.xml">
]>
<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-ecrit-trustworthy-location-00.txt">
<front>
<title abbrev="Trustworthy Location Information">Trustworthy Location Information</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<city>450 Computer Science Building</city>
<region>New York, NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>bernarda@microsoft.com</email>
</address>
</author>
<date year="2010"/>
<area>Real-Time Applications and Infrastructure</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>For some location-based applications, such as emergency calling or roadside assistance, it
appears that the identity of the requestor is less important than accurate and trustworthy
location information. To ensure adequate help location has to be left untouched by the end
point or by entities in transit.</t>
<t> This document lists different threats, an adversary model, outlines three frequentlly
discussed solutions and discusses operational considerations. Finally, the document
concludes with a suggestion on how to move forward.</t>
</abstract>
</front>
<middle>
<!-- *********************************************************************** -->
<section anchor="intro" title="Introduction">
<t> 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. </t>
<t> 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. </t>
<t> 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 <xref
target="LLDP-MED"/>, DHCP extensions (see <xref target="RFC4776"/>, <xref target="RFC3825"
/>), HELD <xref target="I-D.ietf-geopriv-http-location-delivery"/>, 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). More common with
high-quality cellular devices is the ability for the end host itself to determine its own
location using 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
HTTP, SIP or XMPP. </t>
<t> This document investigates the security threats in <xref target="threats"/>, and outlines
three solutions that are frequently mentioned in <xref target="solutions"/>. We use
emergency services an example to illustrate the security problems, 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 earlier. We also take a look at the operational considerations in
<xref target="ops"/> since there is a cost associated with the estbalishment of the
necessary infrastructure. With the pros of the available technology being described and the
cons of the operational complexity highlighted we offer a conclusion in <xref
target="conclusion"/>.</t>
</section>
<!-- *********************************************************************** -->
<section anchor="terminology" title="Terminology">
<t>This document re-uses a lot of the terminology defined in Section 3 of <xref
target="RFC5012"/>.</t>
</section>
<!-- *********************************************************************** -->
<section title="Emergency Services">
<t>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. </t>
<t> 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 public switched telephone network (PSTN) / public land mobile
network (PLMN) 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. </t>
</section>
<!-- *********************************************************************** -->
<section anchor="threats" title="Threats">
<t>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. </t>
<t> 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. </t>
<t>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. </t>
<t> 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'. </t>
<t> 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. </t>
<t> Attackers may want to modify, prevent or delay emergency calls. In 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 require the authenticated identity of the emergency caller, as is true
for PSTN-based emergency calls placed from payphones or SIM-less cell phones today.
Furthermore, if identities can easily be crafted (as it is the case with many VoIP offerings
today), then the value of emergency caller authentication itself might be limited. As a
consequence, an attacker can forge emergency call information without the chance of being
held accountable for its own actions.</t>
<t> 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
(see <xref target="I-D.ietf-ecrit-mapping-arch"/> or against the emergency services IP
network (including PSAPs), a larger region and a large number of potential emergency callers
are affected. The call takers themselves are a particularly scarce resource and if human
interaction by these call takers is required then this can very quickly have severe
consequences.</t>
<t>To provide a structured analysis we distinguish between three adversary models: </t>
<t>
<list style="hanging">
<t hangText="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. </t>
<t hangText="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. </t>
<t hangText="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.</t>
</list>
</t>
<t>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. </t>
<section title="Location Spoofing">
<t> 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. Another form of this attack is to fool a VSP (and indirectly a LIS) in using
a wrong identity (such as an IP address) for the location lookup. This type of attack can
be accomplished in the PSTN today with the help of caller-id spoofing. </t>
<t> The following list presents threats specific to location information handling: </t>
<t>
<list style="hanging">
<t hangText="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. </t>
<t hangText="Time shifting:">Trudy pretends to be at a location she was a while ago.</t>
<t hangText="Location theft:"> Trudy observes Alice's location and replays it as her
own.</t>
<t hangText="Location swapping:">Trudy and Malory, located in different locations, can
collude and swap location information and pretend to be in each other's location.</t>
</list>
</t>
</section>
<section title="Call Identity Spoofing">
<t> 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: (a) network access authentication (e.g., using the
Extensible Authentication Protocol (EAP) <xref target="RFC3748"/> and (b) authentication
of the emergency caller at the VoIP application layer. This differentiation is created by
the split between the AIP and the VSP. Note that different identities are involved and
that the are also managed by different parties and thus making the linkage between the two
quite difficult.</t>
<t> Trying to find an adversary that did not authenticate itself to the VSP is difficult
even though there is still a chance if network access authentication was executed. 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. </t>
<t> 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
dedicated certificates, increases costs, introduces a significant administrative overhead
and is only useful if widely used. </t>
</section>
</section>
<!-- *********************************************************************** -->
<section anchor="solutions" title="Solution Proposals">
<t> This section presents three solution approaches that have been discussed in order to
mitigate the threats discussed. </t>
<section title="Location Signing">
<t> 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. <xref target="fig1"/> 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 <xref target="I-D.ietf-sip-location-conveyance"/> are
applicable for location conveyance. </t>
<t>
<figure anchor="fig1" title="Location Signing">
<artwork><![CDATA[
+-----------+ +-----------+
| | | 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 +
| |
+-----------+
]]></artwork>
</figure>
</t>
<t>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. </t>
<t> 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 useful in placing calls. </t>
<t> 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 argued in <xref target="ops"/>
the operational considerations make a real-time verification difficult. A strawman
proposal for location signing is provided by <xref
target="I-D.thomson-geopriv-location-dependability"/>. </t>
<t> 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. </t>
<t> 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. </t>
</section>
<section title="Location by Reference">
<t> 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.</t>
<t>
<xref target="fig2"/> 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 <xref target="I-D.ietf-sip-location-conveyance"/> are applicable. </t>
<t>
<figure anchor="fig2" title="Location by Reference">
<artwork><![CDATA[
+-----------+ 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 +
| |
+-----------+
]]></artwork>
</figure>
</t>
<t> 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)
<xref target="I-D.ietf-geopriv-http-location-delivery"/> is an example of a protocol
that is able to return such references. </t>
<t> 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 server. </t>
<t> 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. </t>
<t> 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 information.
</t>
</section>
<section title="Proxy Adding Location">
<t> 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. </t>
<t> When the untrustworthy end host does not have the ability to access location
information, it cannot modify it either. Proxies can use various authentication security
techniques, including SIP Identity <xref target="RFC4474"/>, 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. </t>
<t> 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. This requires a
standardized VoIP profile to be deployed at every end device and at every AIP, for
example, based on SIP. This might impose a certain interoperability challenge.
Additionally, the AIP more or less takes the responsibility for emergency calls, even for
customers they have no direct or indirect relationship with. To provide identity
information about the emergency caller from the VSP it would be necessary to let the AIP
and the VSP to interact for authentication (see, for example, <xref target="RFC4740"/>).
This interaction along the Authentication, Authorization and Accounting infrastructure
(see ) is often based on business relationships between the involved entities. The AIP and
the VSP are very likely to have no such business relationship, particularly when talking
about an arbitrary VSP somewhere on the Internet. In case that the interaction between the
AIP and the VSP fails due to the lack of a business relationship then the procedures
described in <xref target="I-D.schulzrinne-ecrit-unauthenticated-access"/> are applicable
and typically a fall-back would be provided where no emergency caller identity information
is made available to the PSAP and the emergency call still has to be completed. </t>
</section>
</section>
<!-- *********************************************************************** -->
<section anchor="ops" title="Operations Considerations">
<section title="Attribution to a Specific Trusted Source">
<t>
<xref target="NENA-i2"/> Section 3.7 describes some of the aspects of attribution as
follows: <list style="empty">
<t> The i2 solution proposes a Location Information Server (LIS) be the source for
distributing location information within an access network. Furthermore the validity,
integrity and authenticity of this information are directly attributed to the LIS
operator. </t>
</list>
</t>
<t><xref target="validity"/> describes the issues that arise in ensuring the validity of
location information provided by the LIS operator. <xref target="signing"/> and <xref
target="reference"/> describe operational issues that arise in ensuring the integrity
and authenticity of location information provided by the LIS operator. </t>
<section anchor="validity" title="Validity">
<t> In existing networks where location information is both determined by the access/voice
service provider as well as communicated by the AIP/VSP, responsibility for location
validity can be attributed entirely to a single party, namely the AIP/VSP. </t>
<t> However, on the Internet, not only may the AIP and VSP represent different parties,
but location determination may depend on information contributed by parties trusted by
neither the AIP nor VSP, or even the operator of the Location Information Server (LIS).
In such circumstances, mechanisms for enhancing the integrity or authenticity of
location data contribute little toward ensuring the validity of that data. </t>
<t> It should be understood that the means by which location is determined may not
necessarily relate to the means by which the endpoint communicates with the LIS. Just
because a Location Configuration Protocol (LCP) operates at a particular layer does not
imply that the location data communicated by that protocol is derived solely based on
information obtained at that layer. In some circumstances, LCP implementations may base
their location determination on information gathered from a variety of sources which may
merit varying levels of trust, such as information obtained from the calling endpoint,
or wiremap information that is time consuming to verify or may rapidly go out of date. </t>
<t>For example, consider the case of a Location Information Server (LIS) that utilizes
LLDP-MED <xref target="LLDP-MED"/> endpoint move detection notifications in determining
calling endpoint location. Regardless of whether the LIS implementation utilizes an LCP
operating above the link layer (such as an application layer protocol such as HELD <xref
target="I-D.ietf-geopriv-http-location-delivery"/>), the validity of the location
information conveyed would be dependent on the security properties of LLDP-MED. </t>
<t>
<xref target="LLDP-MED"/> Section 13.3 defines the endpoint move detection notification
as follows: </t>
<t>
<figure anchor="overview" title="Interworking Architecture">
<artwork><![CDATA[
lldpXMedTopologyChangeDetected NOTIFICATION-TYPE
OBJECTS { lldpRemChassisIdSubtype,
lldpRemChassisId,
lldpXMedRemDeviceClass
}
STATUS current
DESCRIPTION
"A notification generated by the local device
sensing a change in the topology that
indicates a new remote device attached to a
local port, or a remote device disconnected
or moved from one port to another."
::= { lldpXMedNotifications 1 }
]]></artwork>
</figure>
</t>
<t> As noted in Section 7.4 of <xref target="LLDP-MED"/>, the lldpRemChassisIdSubtype,
lldpRemChassisId and lldpXMedRemDeviceClass variables are determined from the Chassis ID
(1) and LLDP-MED Device Type Type-Length-Value (TLV) tuples provided within the LLDP
advertisement of the calling device. As noted in <xref target="LLDP-MED"/> Section
9.2.3, all Endpoint Devices use the Network address ID subtype (5) by default. In order
to provide topology change notifications in a timely way, it cannot necessarily be
assumed that a Network Connectivity devices will validate the network address prior to
transmission of the move detection notification. As a result, there is no guarantee that
the network address reported by the endpoint will correspond to that utilized by the
device. </t>
<t> The discrepancy need not be due to nefarious reasons. For example, an IPv6-capable
endpoint may utilize multiple IPv6 addresses. Similarly, an IPv4-capable endpoint may
initially utilize a Link- Local IPv4 address <xref target="RFC3927"/> and then may
subsequently acquire a DHCP-assigned routable address. All addresses utilized by the
endpoint device may not be advertised in LLDP, or even if they are, endpoint move
detection notification may not be triggered, either because no LinkUp/LinkDown
notifications occur (e.g. the host adds or changes an address without rebooting) or
because these notifications were not detectable by the Network Connectivity device (the
endpoint device was connected to a hub rather than directly to a switch). </t>
<t>Similar issues may arise in situations where the LIS utilizes DHCP lease data to obtain
location information. Where the endpoint address was not obtained via DHCP (such as via
manual assignment, stateless autoconfiguration <xref target="RFC4862"/> or Link-Local
IPv4 self- assignment), no lease information will be available to enable determination
of device location. This situation should be expected to become increasingly common as
IPv6-capable endpoints are deployed, and Location Configuration Protocol (LCP)
interactions occur over IPv6. </t>
<t> Even in scenarios in which the LIS relies on location data obtained from the IP MIB
<xref target="RFC4293"/> and the Bridge MIB <xref target="RFC4188"/>, availability of
location determination information is not assured. In an enterprise scale network,
maintenance of current location information depends on the ability of the management
station to retrieve data via polling of network devices. As the number of devices
increases, constraints of network latency and packet loss may make it increasingly
difficult to ensure that all devices are polled on a sufficiently frequent interval. In
addition, in large networks, it is likely that tables will be large so that when UDP
transport is used, query responses will fragment, resulting in increasing packet loss or
even difficulties in firewall or NAT traversal. </t>
<t> Furthermore, even in situations where the location data can be presumed to exist and
be valid, there may be issues with the integrity of the retrieval process. For example,
where the LIS depends on location information obtained from a MIB notification or query,
unless SNMPv3 <xref target="RFC3411"/> is used, data integrity and authenticity is not
assured in transit between the network connectivity device and the LIS. </t>
<t> From these examples, it should be clear that the availability or validity of location
data is a property of the LIS system design and implementation rather than an inherent
property of the LCP. As a result, mechanisms utilized to protect the integrity and
authenticity of location data do not necessarily provide assurances relating to the
validity or provenance of that data. </t>
</section>
<section anchor="signing" title="Location Signing">
<t>
<xref target="NENA-i2"/> Section 3.7 includes recommendations relating to location
signing: <list style="empty">
<t> Location determination is out of scope for NENA, but we can offer guidance on what
should be considered when designing mechanisms to report location: </t>
<t> 1. The location object should be digitally signed. </t>
<t> 2. The certificate for the signer (LIS operator) should be rooted in VESA. For
this purpose, VPC and ERDB operators should issue certs to LIS operators. </t>
<t> 3. The signature should include a timestamp. </t>
<t> 4. Where possible, the Location Object should be refreshed periodically, with the
signature (and thus the timestamp) being refreshed as a consequence. </t>
<t> 5. Antispoofing mechanisms should be applied to the Location Reporting method.
</t>
</list> [Note: The term Valid Emergency Services Authority (VESA) refers to the root
certificate authority.] </t>
<t> Signing of location objects implies the development of a trust hierarchy that would
enable a certificate chain provided by the LIS operator to be verified by the PSAP.
Rooting the trust hierarchy in VESA can be accomplished either by having the VESA
directly sign the LIS certificates, or by the creation of intermediate CAs certified by
the VESA, which will then issue certificates to the LIS. In terms of the workload
imposed on the VESA, the latter approach is highly preferable. However, this raises the
question of who would operate the intermediate CAs and what the expectations would be.</t>
<t> In particular, the question arises as to the requirements for LIS certificate
issuance, and whether they are significantly different from say, requirements for
issuance of an SSL/TLS web certificate. </t>
</section>
<section anchor="reference" title="Location by Reference">
<t> Where location by reference is provided, the recipient needs to deference the LbyR in
order to obtain location. With the introduction of location by reference concept two
authorization models were developed, see <xref
target="I-D.winterbottom-geopriv-deref-protocol"/>, namely the "Authorization by
Possession" and "Authorization via Access Control Lists" model. With the "Authorization
by Possession" model everyone in possession of the reference is able to obtain the
corresponding location information. This might, however, be incompatible with other
requirements typically imposed by AIPs, such as location hiding (see <xref
target="I-D.ietf-ecrit-location-hiding-req"/>). As such, the "Authorization via Access
Control Lists" model is likely to be the preferred model for many AIPs and subject for
discussion in the subsequent paragraphs.</t>
<t> Just as with PIDF-LO signing, the operational considerations in managing credentials
for use in LbyR dereferencing can be considerable without the introduction of some kind
of hierarchy. It does not seem reasonable for a PSAP to manage client certificates or
Digest credentials for all the LISes in its coverage area, so as to enable it to
successfully dereference LbyRs. In some respects, this issue is even more formidable
than the validation of signed PIDF- LOs. While PIDF-LO signing credentials are provided
to the LIS operator, in the case of de-referencing, the PSAP needs to be obtain
credentials compatible with the LIS configuration, a potentially more complex
operational problem. </t>
<t> As with PIDF-LO signing, the operational issues of LbyR can be addressed to some
extent by introduction of hierarchy. Rather than requiring the PSAP to obtain
credentials for accessing each LIS, the local LIS could be required to upload location
information to location aggregation points who would in turn manage the relationships
with the PSAP. This would shift the management burden from the PSAPs to the location
aggregation points. </t>
</section>
</section>
<section title="Application to a Specific Point in Time">
<t> PIDF-LO objects contain a timestamp, which reflects the time at which the location was
determined. Even if the PIDF-LO is signed, the timestamp only represents an assertion by
the LIS, which may or may not be trustworthy. For example, the recipient of the signed
PIDF-LO may not know whether the LIS supports time synchronization, or whether it is
possible to reset the LIS clock manually without detection. Even if the timestamp was
valid at the time location was determined, a time period may elapse between when the
PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing
location information to renew the timestamp even though the location information itself is
unchanged puts additional load on LISs. As a result, recipients need to validate the
timestamp in order to determine whether it is credible.</t>
</section>
<section title="Linkage to a Specific Endpoint">
<t> As noted in the "HTTP Enabled Location Delivery (HELD)" <xref
target="I-D.ietf-geopriv-http-location-delivery"/> Section 6.6: <list style="empty">
<t> The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless
it is able to verify that the identifier is correct and inclusion of identity is
expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity
are either omitted or contain unlinked pseudonyms <xref target="RFC3693"/>. A unique,
unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence
"entity" attribute of the PIDF document. Optional parameters such as the "contact"
element and the "deviceID" element <xref target="RFC4479"/> are not used. </t>
</list>
</t>
<t> Given the restrictions on inclusion of identification information within the PIDF-LO, it
may not be possible for a recipient to verify that the entity on whose behalf location was
determined represents the same entity conveying location to the recipient. </t>
<t> Where "Enhancements for Authenticated Identity Management in the Session Initiation
Protocol (SIP)" <xref target="RFC4474"/> is used, it is possible for the recipient to
verify the identity assertion in the From: header. However, if PIDF parameters that
contain identity are omitted or contain an unlinked pseudonym, then it may not be possible
for the recipient to verify whether the conveyed location actually relates to the entity
identified in the From: header. </t>
<t> This lack of binding between the entity obtaining the PIDF-LO and the entity conveying
the PIDF-LO to the recipient enables cut and paste attacks which would enable an attacker
to assert a bogus location, even where both the SIP message and PIDF-LO are signed. As a
result, even implementation of both <xref target="RFC4474"/> and location signing does not
guarantee that location can be tied to a specific endpoint. </t>
</section>
</section>
<!-- *********************************************************************** -->
<section anchor="conclusion" title="Conclusion">
<t> Emergency services raise a number of architectural questions, see <xref
target="I-D.ietf-ecrit-framework"/>, <xref
target="I-D.schulzrinne-ecrit-unauthenticated-access"/>, <xref
target="I-D.ietf-ecrit-location-hiding-req"/>, and <xref
target="I-D.tschofenig-ecrit-architecture-overview"/>. 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 for Denial of Service prevention (for
example using cryptographic puzzles), have limited applicability. </t>
<t>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 <xref target="solutions"/>. 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.</t>
<t> Given the practical and operational limitations in the technology, it may be worthwhile to
consider whether the goals of trustworthy location, as for example defined by NENA i2 <xref
target="NENA-i2"/>, are attainable, or whether lesser goals (such as auditability) should
be substituted instead.</t>
<t> The goal of auditability is to enable an investigator to determine the source of a rogue
emergency call after the fact. Since such an investigation can rely on audit logs provided
under court order, the information available to the investigator could be considerably
greater than that present in messages conveyed in the emergency call. As a consequence the
emergency caller becomes accountable for his actions. For example, in such a situation,
information relating to the owner of the unlinked pseudonym could be provided to
investigators, enabling them to unravel the chain of events that lead to the attack.
Auditability is likely to be of most benefits in situations where attacks on the emergency
services system are likely to be relatively infrequent, since the resources required to
pursue an investigation are likely to be considerable. </t>
<t> Where attacks are frequent and continuous, a reliance on non-automated mechanisms is
unlikely to be satisfactory. As such, mechanisms to exchange audit trails information in a
standardized format between ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
potentially fraudulent emergency calls from real emergencies might be valuable for the
emergency services community. </t>
</section>
<!-- *********************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<t>This document does not require actions by IANA. </t>
</section>
<!-- *********************************************************************** -->
<section title="Acknowledgments">
<t> 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 of this document. Martin Thomson provided valuable input to version -02 of this
document. </t>
</section>
<!-- *********************************************************************** -->
</middle>
<back>
<references title="Normative References"> &RFC5012; </references>
<references title="Informative references"> &RFC4776; &RFC3825;
&I-D.ietf-geopriv-http-location-delivery; &I-D.ietf-sip-location-conveyance;
&I-D.thomson-geopriv-location-dependability;
&I-D.schulzrinne-ecrit-unauthenticated-access; &I-D.ietf-ecrit-framework;
&RFC3693; &RFC4293; &RFC3411; &RFC4188; &RFC4862; &RFC3927; &RFC4740; &I-D.winterbottom-geopriv-deref-protocol;
&RFC3748; &RFC4474; &RFC4479; &I-D.tschofenig-ecrit-architecture-overview; &I-D.ietf-ecrit-location-hiding-req;
&I-D.ietf-ecrit-mapping-arch; <reference anchor="LLDP-MED">
<front>
<title>Telecommunications: IP Telephony Infrastructure: Link Layer Discovery Protocol for
Media Endpoint Devices, ANSI/TIA-1057-2006</title>
<author initials="" surname="" fullname="TIA,">
<organization/>
</author>
<date month="April" year="2006"/>
</front>
</reference>
<reference anchor="NENA-i2">
<front>
<title>08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)</title>
<author initials="" surname="" fullname="NENA">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
</reference>
<!--
<reference anchor="IEEE-802.1AB-REV">
<front>
<title>IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control Connectivity Discovery, IEEE
802.1AB-REV D5.0</title>
<author initials="" surname="" fullname="IEEE">
<organization/>
</author>
<date month="February" year="2009"/>
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:50:06 |