I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may
Reviewer: David L. Black
Review Date: October 21, 2011
IETF LC End Date: October 25, 2011
Summary: This draft is on the right track but has open issues, described in the
information obtained and maintained by Location Configuration Protocols (LCPs).
The draft is clear and well written.
The open issues concern the security consequences of the shared secret nature of
policy URIs - the authorization model is that a policy URI is a shared secret
between the location provider and the client whose location is involved, and
presentation of the URI is sufficient authorization for its use, as an
entity will not know and cannot guess the URI.
 This first turns up as an editorial issue in Section 3:
Knowledge of the policy URI can be considered adequate evidence of
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.
 The first paragraph of section 7.1 is descriptive:
Each LCP ensures integrity and confidentiality through different
means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
These measures ensure that a policy URI is conveyed to the client
without modification or interception.
The paragraph ought to also be prescriptive and include possible future
that may use policy URIs - adding a sentence like the following would help:
All LCPs that use policy URIs MUST provide confidentiality and integrity
for policy URIs sufficient to ensure that a policy URI is conveyed to
the client without modification or interception.
Alternatively, changing "required" to "REQUIRED" in the following sentence
in Section 7.2 may suffice, although integrity is not mentioned in this
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.
[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 ;-) ).
Nits: I found a number of acronyms that should be expanded on first use,
e.g., LIS, LS, and HELD.
idnits 2.12.2 did not find anything that needs attention.
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
Ietf mailing list