[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/>
- [Ecrit] [ecrit] #17: Rewrite of Section 4 ecrit issue tracker
- Re: [Ecrit] [ecrit] #17: Rewrite of Section 4 ecrit issue tracker