Hi David,
Thanks for your review. Glad to provide clarification on these points.
Responses inline below. Let me know if these address your concerns.
--Richard
This draft specifies policy URIs for management of privacy policy for location
information obtained and maintained by Location Configuration Protocols
(LCPs).
The draft is clear and well written.
Thanks!
[1] This first turns up as an editorial issue in Section 3:
Knowledge of the policy URI can be considered adequate evidence of
authorization.
That sentence should be expanded to explain why, because this is not the case
for URIs in general. The explanation is that a policy URI is constructed
to be very hard to predict, and functions as a shared secret (e.g.,
confidentiality protection is required in all protocols that transmit
a policy URI).
There are a couple of Security Considerations (Section 7) aspects that should
be strengthened because a policy URI is a shared secret.
I definitely appreciate that this could be surprising in Section 3, but since
this section is mainly dealing with how the server makes access control
decisions, I'm inclined to address this mainly with a forward reference to the
Security Considerations. Suggested text:
Section 3.1
OLD:
"
Knowledge of the policy URI can be considered adequate evidence of
authorization.
"
NEW:
"
Knowledge of the policy URI can be considered adequate evidence of
authorization; a policy URI functions as a shared secret between the client and
the server (see Section 7).
"
Alternatively, changing "required" to "REQUIRED" in the following sentence
in Section 7.2 may suffice, although integrity is not mentioned in this
sentence:
Confidentiality is required for its conveyance in the
location configuration protocol, and in the requests that are used
to inspect, change or delete the policy resource.
I like this phrasing. I'm not sure it's quite REQUIRED (following the "MUST
implement / MAY use" pattern of BCP 61), but I would go for a strong SHOULD.
The underlying LCP protocols already guarantee the "MUST implement".
Suggested text:
Section 7.2
OLD:
"
Confidentiality is required for its conveyance in the location configuration
protocol, and in the requests that are used to inspect, change or delete the
policy resource.
"
NEW:
"
Confidentiality and integrity protections SHOULD be used when policy URIs are
conveyed in a location configuration protocol, and in the requests that are
used to inspect, change or delete the policy resource.
"
[3} The unpredictability requirements are vague:
o The Location Server MUST ensure that the URI cannot be easily
predicted. The policy URI MUST NOT be derived solely from
information that might be public, including the Target identity or
any location URI. The addition of random entropy increases the
difficulty of guessing a policy URI.
Something needs to be stated about how much random entropy is required
(e.g., 8 bits is probably not enough ;-) ).
I actually don't think the entropy requirements are huge here. Because the
number of legitimate requests from any client should be quite small (are you
going to update your policy 2^16 times?), the server can apply rate limits to
prevent brute force attacks. Suggested text:
Section 7.2
OLD:
"
o The Location Server MUST ensure that the URI cannot be easily predicted.
The policy URI MUST NOT be derived solely from information that might be
public, including the Target identity or any location URI. The addition of
random entropy increases the difficulty of guessing a policy URI.
"
NEW:
"
o The Location Server MUST ensure that the URI cannot be easily predicted.
The policy URI MUST NOT be derived solely from information that might be
public, including the Target identity or any location URI. The addition of 32
bits or more of random entropy is RECOMMENDED to make it infeasible for a third
party to guess a policy URI.
o Servers SHOULD apply rate limits in order to make brute-force guessing
infeasible. If a server allocates policy URIs that include N bits of entropy
with a default lifetime of T seconds, then the server should limit clients to
2^(N/2)/T queries per second.
"
Nits: I found a number of acronyms that should be expanded on first use,
e.g., LIS, LS, and HELD.
Section 1:
OLD: "(acting for the Location Server)"
NEW: "(acting for the Location Server (LS) or Location Information Server
(LIS))"
Section 1:
OLD: "extensions to the HELD protocol"
NEW: "extensions to the HTTP-Enabled Location Delivery (HELD) protocol"
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf