here are a few review comments.
In the document we do not use Target but instead host. Is this intentional?
We also use the term LS rather than LIS. Is this intentional?
A few minor comments inline:
FROM:
"
From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide the Device (the client
in an LCP) with a way to inform the Location Server with policy for
how his location information should be handled. This document
addresses this gap by defining a simple mechanism for referring to
and manipulating policy, and by extending current LCPs to carry
policy references. Using the mechanisms defined in this document, an
LCP server (acting for the Location Server) can inform a client as to
which policy document controls a given location resource, and the LCP
client (in its Rule Maker role) can inspect this document and modify
it as necessary.
"
TO:
"
From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide hosts (the clients
in an LCP) with a way to inform the Location Server with
policy for how his location information should be handled. This document
addresses this gap by defining a simple mechanism for referring to
and manipulating policy, and by extending current LCPs to carry these
policy references. Using the mechanisms defined in this document, an
LCP server (acting for the LIS) can inform a host as to
which policy document controls a given location resource, and the LCP
client (in its Rule Maker role) can inspect this document and modify
it as necessary.
"
The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (d) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(b)| |Protocol |Protocol
| |(a) |(c)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead.
The text in Section 3.2 says:
"
A Location Server creates a policy URI for a specific location
resource at the time that the location resource is created; that is,
a policy URI is created at the same time as the location URI that it
controls. The URI of the policy resource MUST be different to the
location URI.
"
The current text gives the impression that the policy URI is bound to location itself. Location, however, is an always changing element in the architecture. Instead, the policy URI follows the lifecycle of it the location URI: when all the location URI are destroyed the policy URI becomes invalid as well.
As the text later says each location URI is associated with zero or one policy URIs. This is not correct given the example in Section 5.1 where a single policy URI is associated with two location URIs.
So, I suggest to add a picture to illustrate the case. Here is a proposal:
+----------+
| Actual |
| Location |
+----+-----+
|
+----+-----+
| Device |
| Identity | +-----------+
+----+-----+ | Policy |
| | Reference |
| +-----+-----+
| |
+----+-----+ +-----+-------+
| Context | | Policy |
| Handler |----------+ Information |
+----=+----+ +-------------+
,-' '-.
,-' `-.
_.-' `..
,,' `._
+------'---------+ +---------+------+
| Location URI-1 | ... | Location URI-n |
+----------------+ +----------------+
A few words about the picture:
- There is some progressing engine in the location server that maps the input identifiers to some location. This figure is about the location URIs being provided as input to the entire process.
- There is an implementation internal data structure that glues everything together - the context handler. The policy information is bound to this handler since it is not bound to a specific identifier per se (at least not in the way how the document is written).
Now, the only question is how the lifetime of each of these objects relate to each other.
For example, a policy may contain a validity element. For example, do you expert the location URI to be invalid when the validity time expires?
In particular, the following statement needs to be strong:
FROM:
"
A DELETE request to a policy URI is a request to delete the
referenced policy document and terminate access to the protected
resource.
"
TO:
"
A DELETE request to a policy URI is a request to delete the
referenced policy document. The LS MUST also terminate access to
location information referenced by any of the location URIs
previously distributed.
"
We have to describe the followingI believe it should instead say:
"
A Location Server creates a policy URI at the same time as the location URI
that it controls. Internally to the Location Server the policy URI refers to
the location URIs. The URI of the policy resource MUST be different to the
location URI since they refer to different information elements.
"
There is a small typo in the following sentence:
A policy URI MUST NOT be provided to an entity that is not
authorized to view or set policy. This document does not describe
how policy might be provided to entities other than for location
configuration. in responses to dereferencing requests
ˆˆˆˆ
[I-D.ietf-geopriv-deref-protocol] or requests from third parties
[I-D.ietf-geopriv-held-identity-extensions].
FROM:
"
A policy URI is a shared secret between Location Server and its
clients. Knowledge of a policy URI is all that is required to
perform any operations allowed on the policy. Thus, a policy URI is
constructed so that it is hard to predict (see Section 8).
"
TO:
"
From a security point of view a policy URI has to be treated like a
secret shared between Location Server and each of its
clients. Knowledge of a policy URI is all that is required to
perform any operations allowed on the policy. Thus, a policy URI is
constructed so that it is hard to predict (see Section 8) and
confidentiality protected while in transit.
"
s/5.3. Basic access control policy/5.3. Basic Access Control Policy
Section 5.3 says:
"
Consider a user that gets the policy URI
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
above LCP example. The first thing this allows the user to do is
inspect the default policy that the LS has assigned to this URI:
"
I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this.
From:
"
Finally, after using the URI for a period, the user wishes to
permanently invalidate the URI.
"
Section 7.1:
The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy".
Security considerations: Wouldn't it be more useful to always require HTTPS to be used? Are there really cases where it wouldn't be used? Do we feel OK with the requirement that every LCP has to confidentiality protect the transmission of the policy URI to the host given that DHCP does not meet this confidentiality requirement?
Regarding the policy capabilities: In HELD context we had the functionality for limited use URIs and Snapshot URIs. A limited use URI can only be accessed a fixed number of times to yield the location of the Target. A snapshot URI points to the location of the Target at a specific point in time, and no matter how many times the URI is accessed it will always yield the same location.
Did we loose this functionality?
Ciao
We also use the term LS rather than LIS. Is this intentional?
A few minor comments inline:
FROM:
"
From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide the Device (the client
in an LCP) with a way to inform the Location Server with policy for
how his location information should be handled. This document
addresses this gap by defining a simple mechanism for referring to
and manipulating policy, and by extending current LCPs to carry
policy references. Using the mechanisms defined in this document, an
LCP server (acting for the Location Server) can inform a client as to
which policy document controls a given location resource, and the LCP
client (in its Rule Maker role) can inspect this document and modify
it as necessary.
"
TO:
"
From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide hosts (the clients
in an LCP) with a way to inform the Location Server with
policy for how his location information should be handled. This document
addresses this gap by defining a simple mechanism for referring to
and manipulating policy, and by extending current LCPs to carry these
policy references. Using the mechanisms defined in this document, an
LCP server (acting for the LIS) can inform a host as to
which policy document controls a given location resource, and the LCP
client (in its Rule Maker role) can inspect this document and modify
it as necessary.
"
The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (d) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(b)| |Protocol |Protocol
| |(a) |(c)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead.
The text in Section 3.2 says:
"
A Location Server creates a policy URI for a specific location
resource at the time that the location resource is created; that is,
a policy URI is created at the same time as the location URI that it
controls. The URI of the policy resource MUST be different to the
location URI.
"
The current text gives the impression that the policy URI is bound to location itself. Location, however, is an always changing element in the architecture. Instead, the policy URI follows the lifecycle of it the location URI: when all the location URI are destroyed the policy URI becomes invalid as well.
As the text later says each location URI is associated with zero or one policy URIs. This is not correct given the example in Section 5.1 where a single policy URI is associated with two location URIs.
So, I suggest to add a picture to illustrate the case. Here is a proposal:
+----------+
| Actual |
| Location |
+----+-----+
|
+----+-----+
| Device |
| Identity | +-----------+
+----+-----+ | Policy |
| | Reference |
| +-----+-----+
| |
+----+-----+ +-----+-------+
| Context | | Policy |
| Handler |----------+ Information |
+----=+----+ +-------------+
,-' '-.
,-' `-.
_.-' `..
,,' `._
+------'---------+ +---------+------+
| Location URI-1 | ... | Location URI-n |
+----------------+ +----------------+
A few words about the picture:
- There is some progressing engine in the location server that maps the input identifiers to some location. This figure is about the location URIs being provided as input to the entire process.
- There is an implementation internal data structure that glues everything together - the context handler. The policy information is bound to this handler since it is not bound to a specific identifier per se (at least not in the way how the document is written).
Now, the only question is how the lifetime of each of these objects relate to each other.
For example, a policy may contain a validity element. For example, do you expert the location URI to be invalid when the validity time expires?
In particular, the following statement needs to be strong:
FROM:
"
A DELETE request to a policy URI is a request to delete the
referenced policy document and terminate access to the protected
resource.
"
TO:
"
A DELETE request to a policy URI is a request to delete the
referenced policy document. The LS MUST also terminate access to
location information referenced by any of the location URIs
previously distributed.
"
We have to describe the followingI believe it should instead say:
"
A Location Server creates a policy URI at the same time as the location URI
that it controls. Internally to the Location Server the policy URI refers to
the location URIs. The URI of the policy resource MUST be different to the
location URI since they refer to different information elements.
"
There is a small typo in the following sentence:
A policy URI MUST NOT be provided to an entity that is not
authorized to view or set policy. This document does not describe
how policy might be provided to entities other than for location
configuration. in responses to dereferencing requests
ˆˆˆˆ
[I-D.ietf-geopriv-deref-protocol] or requests from third parties
[I-D.ietf-geopriv-held-identity-extensions].
FROM:
"
A policy URI is a shared secret between Location Server and its
clients. Knowledge of a policy URI is all that is required to
perform any operations allowed on the policy. Thus, a policy URI is
constructed so that it is hard to predict (see Section 8).
"
TO:
"
From a security point of view a policy URI has to be treated like a
secret shared between Location Server and each of its
clients. Knowledge of a policy URI is all that is required to
perform any operations allowed on the policy. Thus, a policy URI is
constructed so that it is hard to predict (see Section 8) and
confidentiality protected while in transit.
"
s/5.3. Basic access control policy/5.3. Basic Access Control Policy
Section 5.3 says:
"
Consider a user that gets the policy URI
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
above LCP example. The first thing this allows the user to do is
inspect the default policy that the LS has assigned to this URI:
"
I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this.
From:
"
Finally, after using the URI for a period, the user wishes to
permanently invalidate the URI.
"
Section 7.1:
The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy".
Security considerations: Wouldn't it be more useful to always require HTTPS to be used? Are there really cases where it wouldn't be used? Do we feel OK with the requirement that every LCP has to confidentiality protect the transmission of the policy URI to the host given that DHCP does not meet this confidentiality requirement?
Regarding the policy capabilities: In HELD context we had the functionality for limited use URIs and Snapshot URIs. A limited use URI can only be accessed a fixed number of times to yield the location of the Target. A snapshot URI points to the location of the Target at a specific point in time, and no matter how many times the URI is accessed it will always yield the same location.
Did we loose this functionality?
Ciao
Hannes
On Mar 29, 2011, at 10:20 AM, Alissa Cooper wrote:
This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-policy-uri-00
Please send your comments to the list by 12 April 2011. As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
