Subject: [Ecrit] [ecrit] #13: Location Trust Assessment

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 22:35:37 -0000

#13: Location Trust Assessment

 Regardless of whether location is conveyed in a secure and reliable
 manner, questions will persist about the reliability of the location data.
 Therefore the document does need to provide guidance about how location
 trustworthiness can be assessed.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  drat-ietf-ecrit-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  trustworthy-location     |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/ecrit/trac/ticket/13>
ecrit <http://tools.ietf.org/ecrit/>

---

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 28 Feb 2013 22:36:49 -0000

Comment (by [email-masked]):

 Here is a proposal for a Section 3.4 on Trust Assessment:

 3.4.  Location Trust Assessment

    The ability to assess the level of trustworthiness of conveyed
    location information is important, since this makes it possible to
    understand how much value should be placed on location information,
    as part of the decision making process.  As an example, if automated
    location information is understood to be highly suspect, a call taker
    can put more effort into obtaining location information from the
    caller.

    Caller accountability is another important aspect of trust
    assessment.  Can the individual purchasing the device or activating
    service be identified or did the call originate from a non-service
    initialized (NSI) device whose owner cannot be determined?  Prior to
    the call, was the caller authenticated at the network or application
    layer?  In the event of a prank call, can audit logs be made
    available to an investigator, or can information relating to the
    owner of an unlinked pseudonym be provided, enabling investigators to
    unravel the chain of events that lead to the attack?  In practice,
    the ability to identify a caller may decrease the likelihood of
    caller misbehavior.  For example, where emergency calls have been
    allowed from handsets lacking a SIM card, or where ownership of the
    SIM card cannot be determined, the frequency of nuisance calls has
    often been unacceptably high [TASMANIA][UK][SA].

    Note that location trust assessment has value regardless of whether
    the location has been conveyed securely (via signed location,
    location-by-reference or proxy-added location) or not (via location-
    by-value without location signing), since secure conveyance does not
    provide assurance relating to the validity or provenance of location
    data.

    In practice, the source of the location data is important for
    location trust assessment.  For example, location provided by a
    Location Information Server (LIS) whose administrator has an
    established history of meeting emergency location accuracy
    requirements (e.g. Phase II) may be considered more reliable than
    location information provided by a third party Location Service
    Provider (LSP) that disclaims use of location information for
    emergency purposes.

    However, even where an LSP does not attempt to meet the accuracy
    requirements for emergency location, it still may be able to provide
    information useful in assessing about how reliable location
    information is likely to be.  For example,  was location determined
    based on the nearest cell tower or 802.11 Access Point (AP), or was a
    triangulation method used?  If based on cell tower or AP location
    data, was the information obtained from an authoritative source (e.g.
    the tower or AP owner) and when was the last time that the location
    of the tower or access point was verified?

    For real-time validation, information in the signaling and media
    packets can be cross checked against location information.  For
    example, it may be possible to determine the region associated with
    the IP address included within SIP Via: or Contact: headers, or the
    media source address, and compare this against the location
    information reported by the caller or conveyed in the PIDF-LO.  While
    a a CAPTCHA-style test may be applied to suspicious calls to lower
    the risk from bot-nets, this is quite controversial for emergency
    services, due to the risk of delaying or rejecting valid calls.

    By design, PIDF-LO objects limit the information available for real-
    time attribution,.  As noted in [RFC5985] Section 6.6:

       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 [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" and "deviceID" elements
       [RFC4479] are not used.

    As a result, typically the location recipient will be unable to
    verify in real-time whether the entity on whose behalf location was
    determined represents the same entity conveying location to the
    recipient.  This is true even where "Enhancements for Authenticated
    Identity Management in the Session Initiation Protocol (SIP)"
    [RFC4474] is used, allowing the recipient to verify the identity
    assertion in the From: header.

    The 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 "Enhancements for Authenticated Identity
    Management in the Session Initiation Protocol (SIP)" [RFC4474] and
    location signing does not guarantee that location can be tied to a
    specific endpoint in real-time.  As noted in [RFC6442] Section 1:

       In no way does this document assume that the SIP user agent client
       that sends a request containing a location object is necessarily
       the Target.  The location of a Target conveyed within SIP
       typically corresponds to that of a device controlled by the
       Target, for example, a mobile phone, but such devices can be
       separated from their owners, and moreover, in some cases, the user
       agent may not know its own location.

    However, although real-time validation based on PIDF-LO elements is
    challenging, where LIS audit logs are available (such as where a law
    enforcement agency can present a subpoena), linking of a pseudonym to
    the device obtaining location can be accomplished in a post-mortem.

    Similarly, real-time validation of the timestamp contained within
    PIDF-LO objects (reflecting the time at which the location was
    determined) is challenging.  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
    LISes.  As a result, recipients need to validate the timestamp in
    order to determine whether it is credible.

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <https://svn.tools.ietf.org/wg/ecrit/trac/ticket/13#comment:1>
ecrit <http://tools.ietf.org/ecrit/>