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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 13:17:38 +0200

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 <[email-masked]>
To: 	[email-masked] <[email-masked]>
CC: 	[email-masked]

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
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 08:56:50 -0400

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:[email-masked]]
> 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,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 16:17:10 +0200

Hi Brian,

I like this approach.

If the user specifies only the civic condition and the server cannot 
create the corresponding geodetic location condition then a request by 
an LR (where the Target's location is only available as geodetic and 
cannot be related) wouldn't match. Hence, the rule would not fire. No 
actions and transformations would be executed -- privacy safe failing.

I need to think about the error procedures you mentioned...

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Sep 2007 19:11:19 +0200

Note that conditions are additive in the framework, so if both are  
specified, they both have to match. (This doesn't contradict what  
you're saying, I think.)