Skip to main content

Last Call Review of draft-ietf-geopriv-policy-uri-
review-ietf-geopriv-policy-uri-secdir-lc-kelly-2011-11-08-00

Request Review of draft-ietf-geopriv-policy-uri
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-10-25
Requested 2011-10-14
Authors Richard Barnes , Martin Thomson , James Winterbottom , Hannes Tschofenig
I-D last updated 2011-11-08
Completed reviews Genart Telechat review of -?? by Suresh Krishnan
Genart Last Call review of -?? by David L. Black
Genart Last Call review of -?? by David L. Black
Genart Last Call review of -?? by David L. Black
Secdir Last Call review of -?? by Scott G. Kelly
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-geopriv-policy-uri by Security Area Directorate Assigned
Completed 2011-11-08
review-ietf-geopriv-policy-uri-secdir-lc-kelly-2011-11-08-00
I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security 


area directors. Document editors and WG chairs should treat these 


comments just like any other last call comments.






This review is a little late -- sorry for the delay. From the abstract, 


"This document extends the current location configuration protocols to 


provide hosts with a reference to the rules that are applied to a URI, 


so that the host can view or set these rules." Specifically, it allows 


the host to view, set, or change privacy rules associated with its 


location URIs.






The document is well-written, and contains a security considerations 


section that addresses associated protocol threats. That section 


references two "classes of risks": risk of unauthorized disclosure of 


the protected resource, and risk of disclosure of the policy information 


itself.






Why isn't unauthorized manipulation of the policy information also 


listed as a risk? Actually, the second paragraph of the security 


considerations addresses this, ("The mechanism also needs to ensure that 


only authorized entities are able to acquire or alter policy."), but 


subsequent text seems to indicate that if the policy URI is not kept 


secret, there are no further protections.






Am I missing something here, or is secrecy of the URI really the only 


protection against unauthorized policy manipulation? I have to admit 


that I have no experience with these protocols, and it may be that this 


is addressed elsewhere (or truly doesn't matter), but it does feel a bit 


off.




--Scott