[Geopriv] [Fwd: [secdir] Security Directorate review of draft-ietf-geopriv-policy-12]

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

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