RE: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft-ietf-geopriv-policy-12]

["Brian Rosen" <br at brianrosen.net>]

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