Well, generally, conversion is a bad idea unless you know what is
happening
downstream. Having said that, I think we should be flexible. I
think we
should allow the user to specify one, and if the server has the
other kind
of data, and can convert, it should imply the conditions based on the
translation. We should definitely allow the user to specify
conditions in
both forms, and we should have error and warning mechanisms that
tell the
user what is happening:
Case 1: Server only has one kind of data, user specifies the same one
Result: no problem.
Case 2: Server only has one kind of data, user specifies the other one
Result: I think an error, regardless of whether the server can convert
Case 3: Server has both kinds of data, user specified both
Result: no problem
Case 4: Server has both kinds of data, user specifies one, server
can't
convert
Result: Error
Case 5: Server has both kinds of data, user specifies one, server can
convert
Result: Conversion occurs, no errors. Could have a warning.
Brian
-----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
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
