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

From: "ecrit issue tracker" <[email-masked]>
Date: Tue, 12 Mar 2013 20:02:46 -0000

#13: Location Trust Assessment

Comment (by [email-masked]):

 Here is revision to the text (now in its own Section 4):

 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 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.

    Although privacy-preserving procedures may be disabled for emergency
    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.

    Also, the device referred to in the PIDF-LO may not necessarily be
    the same entity conveying the PIDF-LO to the PSAP.  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.

    Due to these design choices, it is possible for an attacker to cut
    and paste a PIDF-LO obtained by a different device or user into a SIP
    INVITE and send this to the PSAP.  While PIDF-LO signing would
    prevent modification of a PIDF-LO or invention of one out of whole
    cloth, it would not prevent this cut and paste attack.  Neither would
    implementation of "Enhancements for Authenticated Identity Management
    in the Session Initiation Protocol (SIP)" [RFC4474], allowing the
    recipient to verify the identity assertion in the From: header.
    However, while it might not be possible to detect the cut and paste
    in real-time, examination of the audit logs might provide enough
    information to enable events to be reconstructed.

    Real-time validation of the timestamp contained within PIDF-LO
    objects (reflecting the time at which the location was determined) is
    also 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.

    While this document focuses on the discussion of real-time
    determination of suspicious emergency calls, the use of audit logs
    may help in enforcing accountability among emergency callers.  For
    example, in the event of a prank call, 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.
    However, while auditability is an important deterrent, it is likely
    to be of most benefit 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.  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.

    Where attacks are frequent and continuous, automated mechanisms are
    required.  For example, it might be valuable to develop 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.

-- 
-------------------------------------+-------------------------------------
 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       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

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