[Ecrit] [ecrit] #17: Rewrite of Section 4

"ecrit issue tracker" <trac+ecrit@trac.tools.ietf.org> Mon, 15 July 2013 18:42 UTC

Return-Path: <trac+ecrit@trac.tools.ietf.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72111E8179 for <ecrit@ietfa.amsl.com>; Mon, 15 Jul 2013 11:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwhca7kNQlIs for <ecrit@ietfa.amsl.com>; Mon, 15 Jul 2013 11:42:49 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7211B11E817C for <ecrit@ietf.org>; Mon, 15 Jul 2013 11:42:49 -0700 (PDT)
Received: from localhost ([127.0.0.1]:37576 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+ecrit@trac.tools.ietf.org>) id 1UynjN-0003Fr-76; Mon, 15 Jul 2013 20:42:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: ecrit issue tracker <trac+ecrit@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: ecrit
Date: Mon, 15 Jul 2013 18:42:41 -0000
X-URL: http://tools.ietf.org/ecrit/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/17
Message-ID: <065.3817af94c27189bfb7e27cf718565131@trac.tools.ietf.org>
X-Trac-Ticket-ID: 17
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org
X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu
Resent-Message-Id: <20130715184249.7211B11E817C@ietfa.amsl.com>
Resent-Date: Mon, 15 Jul 2013 11:42:49 -0700
Resent-From: trac+ecrit@trac.tools.ietf.org
Cc: ecrit@ietf.org
Subject: [Ecrit] [ecrit] #17: Rewrite of Section 4
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: ecrit@ietf.org
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 18:42:50 -0000

#17: Rewrite of Section 4

 As part of the reorganization of Section 3.1, some of the material from
 Section 4 has been moved there, so that Section 4 is now proposed to read
 as follows:

 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.

    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.

    To prevent location-swapping attacks, the "entity" element of the
    PIDF-LO is of limited value if an unlinked pseudonym is provided in
    this field.  However, if the LIS authenticates the target, then the
    linkage between the pseudonym and the target identity can be
    recovered post-mortem.

    As noted in [I.D.thomson-geopriv-location-dependability], if the
    location object was signed, the location recipient has additional
    information on which to base their trust assessment, such as the
    validity of the signature, the identity of the target, the identity
    of the LIS, whether the LIS authenticated the target, and the
    identifier included in the "entity" field.

    Caller accountability is also an 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].

    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 city, state, country or
    continent 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.  However, in some situations only entities close to
    the caller may be able to verify the correctness of location
    information.

    Real-time validation of the timestamp contained within PIDF-LO
    objects (reflecting the time at which the location was determined) is
    also challenging.  To address time-shifting attacks, the "timestamp"
    element of the PIDF-LO, defined in [RFC3863], can be examined and
    compared against timestamps included within the enclosing SIP
    message, to determine whether the location data is sufficiently
    fresh.  However, 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.  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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-ecrit-
  bernard_aboba@hotmail.com          |  trustworthy-location@tools.ietf.org
     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/17>
ecrit <http://tools.ietf.org/ecrit/>