Hi Richard,
I think we're close:
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. Note that in some protocols (such as DHCP), these protections may
arise from limiting the
use of the protocol to the local network, thus relying on lower-layer
security mechanisms. When
neither application-layer or network-layer security is provided, location
servers MUST reject requests
using the PUT and DELETE methods, and SHOULD reject PUT and DELETE requests
for policy URIs that use
the "http:" URI scheme.
This text looks good to me, except that the structure of the final sentence
inadvertently neuters the final "SHOULD" requirement. Can we move that
requirement into Section 7.1? The change in Section 7.2 would then be:
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. Note that in some
protocols (such as DHCP), these protections may arise from limiting the use of
the protocol to the local network, thus relying on lower-layer security
mechanisms. When neither application-layer or network-layer security is
provided, location servers MUST reject requests using the PUT and DELETE
methods.
"
This change in Section 7.1 would pick up the moved requirement:
OLD
If other means of protection are available, an "http:" URI MAY be used.
NEW
If other means of protection are available, an "http:" URI MAY be used,
but
location servers SHOULD reject all PUT and DELETE requests for policy
URIs
that use the "http:" URI scheme.
END
One of my concerns behind wanting this general "SHOULD" is that there's no
assurance that an "http:" URI will stay confined to the local network that is
being relied upon to secure it.
Thanks,
--David
-----Original Message-----
From: Richard Barnes [mailto:rbarnes(_at_)bbn(_dot_)com]
Sent: Tuesday, November 08, 2011 9:43 PM
To: Black, David
Cc: martin(_dot_)thomson(_at_)andrew(_dot_)com;
james(_dot_)winterbottom(_at_)andrew(_dot_)com;
Hannes(_dot_)Tschofenig(_at_)gmx(_dot_)net; gen-
art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
rjsparks(_at_)nostrum(_dot_)com; geopriv(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-geopriv-policy-uri-02
Hi David,
The penalty for getting a quick response for the first time is that the
second response takes longer
:) Inline.
- 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.
Thanks, we'll note those changes for the RFC editor (or for a new revision,
if our AD prefers).
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".
I think the general countervailing idea here is that location servers are
generally expected to be a
local network function (see, for example, RFC 5986). In this context, you
benefit some from "other
protection" in that in order to capture information, an attacker has to be
fairly close to the victim.
There's a strong tie to DHCP security here. On one level, by analogy; DHCP,
after all, provides no
confidentiality protection, which is acceptable largely because its use is so
constrained. At another
level, though, we have to keep in mind that one of the goals of this
document is to enable policy
URIs to be distributed through DHCP. So even if we place stronger controls
on policy URIs, DHCP will
still be a "weaker link". Or, said the other way around, if we require
stronger controls for policy
URIs (as in your text), then we might as well remove the DHCP transport from
the document.
Nonetheless, your two caveats look fine to me if we make some accommodation
for this constrained case.
Proposed text:
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. Note that in some protocols (such as DHCP), these protections may
arise from limiting the
use of the protocol to the local network, thus relying on lower-layer
security mechanisms. When
neither application-layer or network-layer security is provided, location
servers MUST reject requests
using the PUT and DELETE methods, and SHOULD reject PUT and DELETE requests
for policy URIs that use
the "http:" URI scheme.
"
Thanks,
--Richard
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf