Subject: [secdir] draft-ietf-geopriv-policy-uri-02

From: "Scott G. Kelly" <[email-masked]>
Date: Sun, 30 Oct 2011 06:41:01 -0700

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 30 Oct 2011 21:19:40 +0100

Hi Scott,

Thanks for the review.  Couple of comments inline.

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

Since we're talking about access control policy here, the effect of "manipulation of the policy information" is precisely "unauthorized disclosure of the protected resource".  Does that clear thing sup?

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

You're exactly right in that understanding.  The idea is that a policy URI is already controlling access control policy on something, so we didn't want to have access control policies for who can access policy URIs (turtles all the way down).  That's the reason for all the text about keeping the policy URI secret.

Thanks for the review,
--Richard

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 31 Oct 2011 05:17:41 -0700

Hi Richard,

On 10/30/11 1:19 PM, Richard Barnes wrote:
> <trimmed...>

I see your point, but manipulation of policy information could also be 
used to prevent/deny disclosure too. As I noted below, I have no 
experience with these protocols, and this may not matter, but as a 
reviewer, I think I should mention it.

> You're exactly right in that understanding.  The idea is that a policy URI is already controlling access control policy on something, so we didn't want to have access control policies for who can a…

I didn't see any language suggesting that if one wishes to mitigate the 
resulting exposure, these URIs should probably be short-lived. Is that 
covered in one of the related docs?  Again, not sure if this matters, 
but as the boilerplate suggests, the purpose of these secdir reviews is 
to let the security ADs (who presumably have much more context) know if 
there's anything they should be aware of, so I pointed it out. Lacking 
background and protocol expertise, I don't have any strong position of 
my own on this.

--Scott

---

From: Richard Barnes <[email-masked]>
Date: Mon, 31 Oct 2011 15:02:56 +0100

> I see your point, but manipulation of policy information could also be used to prevent/deny disclosure too. As I noted below, I have no experience with these protocols, and this may not matter, but as a reviewer, I think I should mention it.

That's a fair point.  How about this change to the text:

OLD: "The risk of unauthorized disclosure of the protected resource" 
NEW: "The risk of unauthorized grants or denial of access to the protected resource" 

> I didn't see any language suggesting that if one wishes to mitigate the resulting exposure, these URIs should probably be short-lived. Is that covered in one of the related docs?  Again, not sure if this matters, but as the boilerplate suggests, the purpose of these secdir reviews is to let the security ADs (who presumably have much more context) know if there's anything they should be aware of, so I pointed it out. Lacking background and protocol expertise, I don't have any strong position of my own on this.

It's sort of covered in that policy URIs have the same lifetime as the underlying location URI, but there's not anything like a "key roll-over" mechanism.  It seems to me like the current limitations are sufficient, but if the ADs feel differently, we can make changes.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 31 Oct 2011 10:39:50 -0700 (PDT)

Hi Richard,

I think your proposed change is fine.

--Scott

On Monday, October 31, 2011 7:02am, "Richard Barnes" <[email-masked]> said:

>>> <trimmed...>
>>> 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.
>>> Since we're talking about access control policy here, the effect of
>>> "manipulation of the policy information" is precisely "unauthorized disclosure
>>> of the protected resource".  Does that clear thing sup?
>>
>> I see your point, but manipulation of policy information could also be used to
>> prevent/deny disclosure too. As I noted below, I have no experience with these
>> protocols, and this may not matter, but as a reviewer, I think I should mention
>> it.
> 
>>>> 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.
>>>
>>> You're exactly right in that understanding.  The idea is that a policy URI is
>>> already controlling access control policy on something, so we didn't want to
>>> have access control policies for who can access policy URIs (turtles all the way
>>> down).  That's the reason for all the text about keeping the policy URI secret.
>>
>> I didn't see any language suggesting that if one wishes to mitigate the resulting
>> exposure, these URIs should probably be short-lived. Is that covered in one of
>> the related docs?  Again, not sure if this matters, but as the boilerplate
>> suggests, the purpose of these secdir reviews is to let the security ADs (who
>> presumably have much more context) know if there's anything they should be aware
>> of, so I pointed it out. Lacking background and protocol expertise, I don't have
>> any strong position of my own on this.
> 
> It's sort of covered in that policy URIs have the same lifetime as the underlying
> location URI, but there's not anything like a "key roll-over" mechanism.  It seems
> to me like the current limitations are sufficient, but if the ADs feel
> differently, we can make changes.