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@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf