Re: [Geopriv] Gen-ART review of draft-ietf-geopriv-policy-uri-02

[<[e-mail]>]

Hi Richard,

Thanks for the quick response.  Two of the three proposed changes are fine with me:

- The additional text in section 3.1 stating that the policy URI is a shared
	secret with a forward reference to the security considerations section
	removes the surprise factor.
- The additional text on URI unpredictability in section 7.2 recommending a
	combination of 32 bits of entropy with rate limiting provides concrete
	guidance to implementers.

That leaves the issue of confidentiality and integrity requirements in section 7.2:

> > 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.
> 
> I like this phrasing.  I'm not sure it's quite REQUIRED (following the "MUST implement / MAY use"
> pattern of BCP 61), but I would go for a strong SHOULD.  The underlying LCP protocols already
> guarantee the "MUST implement".   Suggested text:
> 
> Section 7.2
> OLD:
> "
> 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.
> "
> NEW:
> "
> Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location
> configuration protocol, and in the requests that are used to inspect, change or delete the policy
> resource.
> "

The reason for going beyond BCP 61 is that BCP 61 concerns protocols in general, but this
is a specific case with additional security requirements because a policy URI is a shared
secret.  If a policy URI is sent without confidentiality, a likely result is that the
policy URI is still shared, but is no longer sufficiently secret (oops).

This is particularly dangerous if there are no additional authorization checks on the
PUT or DELETE methods for the policy URI, but it's probably ok in some situations if only
the GET method is allowed (e.g., policy creation and update are handled via some other means
such as a secure web portal).

For that reason, the proposed SHOULD requirement would be ok with me if a couple of things
were added:
 (i) If an LCP sends a policy URI without confidentiality protection, then the
	LIS or LS MUST reject the PUT and DELETE methods for that URI.
 (ii) The PUT and DELETE methods SHOULD NOT be supported for policy URIs that
	use the "http:" URI scheme (in contrast to the "https:" URI scheme).

For (i) it'd also be useful to note that the current LCPs never send a policy URI
without confidentiality protection in connection with this (already stated in 7.1,
but ought to be connected to (i) if that text winds up in a different section).

For (ii), I'm not sure what is envisioned by the final sentence in section 7.1:

	If other means of protection are available, an "http:" URI MAY be used.

What sorts of "other means of protection" were the underlying motivation?  Those "other
means of protection" would be the reason for (ii) being a "SHOULD" instead of a "MUST".

Thanks,
--David

> -----Original Message-----
> From: Richard L. Barnes [mailto:[e-mail]]
> Sent: Saturday, October 22, 2011 11:19 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]; gen-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02
> 
> Hi David,
> 
> Thanks for your review.  Glad to provide clarification on these points.  Responses inline below.  Let
> me know if these address your concerns.
> 
> --Richard
> 
> 
> > 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.
> 
> Thanks!
> 
> 
> > [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.
> 
> I definitely appreciate that this could be surprising in Section 3, but since this section is mainly
> dealing with how the server makes access control decisions, I'm inclined to address this mainly with a
> forward reference to the Security Considerations. Suggested text:
> 
> Section 3.1
> OLD:
> "
> Knowledge of the policy URI can be considered adequate evidence of authorization.
> "
> NEW:
> "
> Knowledge of the policy URI can be considered adequate evidence of authorization; a policy URI
> functions as a shared secret between the client and the server (see Section 7).
> "
> 
> 
> > 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.
> 
> I like this phrasing.  I'm not sure it's quite REQUIRED (following the "MUST implement / MAY use"
> pattern of BCP 61), but I would go for a strong SHOULD.  The underlying LCP protocols already
> guarantee the "MUST implement".   Suggested text:
> 
> Section 7.2
> OLD:
> "
> 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.
> "
> NEW:
> "
> Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a 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 ;-) ).
> 
> I actually don't think the entropy requirements are huge here.  Because the number of legitimate
> requests from any client should be quite small (are you going to update your policy 2^16 times?), the
> server can apply rate limits to prevent brute force attacks.  Suggested text:
> 
> Section 7.2
> OLD:
> "
> 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.
> "
> NEW:
> "
> 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 32 bits or more of random entropy is RECOMMENDED to make it infeasible for a
> third party to guess a policy URI.
> o Servers SHOULD apply rate limits in order to make brute-force guessing infeasible.  If a server
> allocates policy URIs that include N bits of entropy with a default lifetime of T seconds, then the
> server should limit clients to 2^(N/2)/T queries per second.
> "
> 
> 
> 
> > Nits: I found a number of acronyms that should be expanded on first use,
> > e.g., LIS, LS, and HELD.
> 
> Section 1:
> OLD: "(acting for the Location Server)"
> NEW: "(acting for the Location Server (LS) or Location Information Server (LIS))"
> 
> Section 1:
> OLD: "extensions to the HELD protocol"
> NEW: "extensions to the HTTP-Enabled Location Delivery (HELD) protocol"
>