Last Call Review of draft-ietf-geopriv-policy-uri-
review-ietf-geopriv-policy-uri-genart-lc-black-2011-11-30-00

Request Review of draft-ietf-geopriv-policy-uri
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2011-12-13
Requested 2011-11-29
Authors Richard Barnes, Martin Thomson, James Winterbottom, Hannes Tschofenig
Draft last updated 2011-11-30
Completed reviews Genart Telechat review of -?? by Suresh Krishnan
Genart Last Call review of -?? by David Black
Genart Last Call review of -?? by David Black
Genart Last Call review of -?? by David Black
Secdir Last Call review of -?? by Scott Kelly
Assignment Reviewer David Black
State Completed
Review review-ietf-geopriv-policy-uri-genart-lc-black-2011-11-30
Review completed: 2011-11-30

Review
review-ietf-geopriv-policy-uri-genart-lc-black-2011-11-30

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 receive.

Document: draft-ietf-geopriv-policy-uri-02
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 review.

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.

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 hence
presentation of the URI is sufficient authorization for its use, as an unauthorized
entity will not know and cannot guess the URI.

[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.

[2] 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 protocols
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
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.

[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.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------