That change looks fine to me! Thanks, --Richard
On Nov 8, 2011, at 11:33 PM, <[email protected]> wrote: > 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:[email protected]] >> Sent: Tuesday, November 08, 2011 9:43 PM >> To: Black, David >> Cc: [email protected]; [email protected]; >> [email protected]; gen- >> [email protected]; [email protected]; [email protected]; [email protected] >> 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
