-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net]
Sent: Friday, September 21, 2007 7:18 AM
To: GEOPRIV
Cc: Tim Polk
Subject: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft-
ietf-geopriv-policy-12]
Hi all,
Tim has also provided a good review of the draft-ietf-geopriv-policy-12
document.
There was one issue he raised that deserves attention.
A rule is constructed in a way that there is the capability to allow
conditions to be formulated with civic and geodetic information.
Now, Tim raised whether it is our expectation to have a user always to
provide location information for a specific location-specific condition
element in both geo- and civic location format or whether we expect the
server todo the translation step.
What does the group think about?
Ciao
Hannes
-------- Original Message --------
Subject: [secdir] Security Directorate review of
draft-ietf-geopriv-policy-12
Date: Wed, 19 Sep 2007 13:34:19 -0400
From: Tim Polk <tim.polk at nist.gov>
To: secdir at MIT.EDU <secdir at mit.edu>
CC: draft-ietf-geopriv-policy at tools.ietf.org
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors but document editors and WG chairs should treat
these comments just like any other last call comments.
Background:
RFC 4745 defines a framework "for creating authorization
policies for access to application specific data". The framework was
designed with location and presence data in mind, but is not restricted
to any particular type of application data. Authorization policies
are defined
as sets of rules. Rules are structured as conditions, actions, and
transformations. RFC 4745 specifies three types of conditions and
general
procedures for combining results when multiple rules are satisfied in
the
authorization policy. The types of conditions specified are identity,
sphere, and a validity period for the rule (starting and ending time).
Definition of actions and transformations is deferred to application
specific documents.
This specification defines an authorization policy language (in XML)
extending RFC 4745 to provide location-specific access control. Two
radically different location descriptions are supported: "civic
location"
and "geodetic location". Civic locations are specified in terms of
country,
region, city, etc. At its most specific, civic locations can specify
a location
even more specific than building and room. Geodetic locations are given
as locations in the World Geodetic System 84 (essentially, GPS
coordinates).
Geodetic locations may include or exclude altitude. The granularity of
location information may be restricted in either case, based on location
recipient or the location itself.
From the Introduction:
The rule set allows the entity that uses the rules defined in this
document to restrict the retention and to enforce access
restrictions
on location data, including prohibiting any dissemination to
particular individuals, during particular times or when the
Target is
located in a specific region. The [Rule Maker] can also
stipulate that only
certain parts of the Location Object are to be distributed to
recipients or that the resolution of parts of the Location Object is
reduced.
Comments:
I have no issues with the mechanisms described in the document. The
mechanisms are very rich, and clearly specified. It should be
possible to build
independent interoperable implementations from this specification.
(I am assuming that base specifications like the WGS 84 and the OpenGIS
Markup Language are sufficiently specified, given their general
utility in
other applications and products.)
However, the opening statements in the Security Considerations are a bit
of an oversimplification:
This document aims to make it simple for users to prevent the
unintended disclosure of private information to third parties. This
is accomplished through the usage of authorization policies.
The authorization policies supported by geopriv-policy are rich but are
not simple. The two different but interdependent location classes
introduce
considerable complexities that need to be highlighted. Civic and
geodetic
location as are not independent; given accurate geodetic locations
one can
determine the civic location as well, or vice versa. In addition,
the location
types may be mixed between rulesets and transformations. However,
specifying consistent rulesets and precision levels is not
straightforward.
For example, I could imagine specifying a ruleset that stated "within
a 30
mile radius of Washington DC provide my civic location with a
granularity of
the building" but elsewhere region only. If the user does not
restrict the
resolution of the geodetic location as well, a location recipient that
requested geodetic location rather than civic location could obtain the
private information I had intended to protect.
It is also unclear if a user needs to specify the ruleset in terms of
both
civic and geodetic conditions. Specifying the same geographic area as
a civic-condition or a geodetic condition seems tricky. Are we
likely to have
denial of service problems if conditions aren't specified in both
location
descriptions, or are policy servers expected to translate between
coordinates
and civi locations?
The security considerations section should include a discussion of the
dependencies between the location types and provide guidance to users
developing authorization policies in light of these dependencies.
_______________________________________________
secdir mailing list
secdir at mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
