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 | |
| Draft 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 | |
| Review |
review-ietf-geopriv-policy-uri-secdir-lc-kelly-2011-11-08
|
|
| 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