The wording on this topic in this section and in the security section (9.1) are not really as consistent as it should be in terms of normative language - the security section describes the capabilities in terms of what MUST be provided/implemented by a LIS and client implementation, but not necessarily what MUST be used and the RECOMMENDED mechanism is actually a "can", there are several lower case MUSTs, etc. Noting in particular the MAY in terms of the client being able to use an external mechanism. Also, note that the recommended mechanism is the authentication mechanism as provided by TLS, so there's nothing unusual with this approach (as I understand it since I'm not a security expert). So, I would propose to reword the text in section 9.1 as follows: OLD: When the HELD transaction is conducted using TLS [RFC5246], the LIS can authenticate its identity, either as a domain name or as an IP address, to the client by presenting a certificate containing that identifier as a subjectAltName (i.e., as an iPAddress or dNSName, respectively)." In the case of the HTTP binding described above, this is exactly the authentication described by TLS [RFC2818]. If the client has external information as to the expected identity or credentials of the proper LIS (e.g., a certificate fingerprint), these checks MAY be omitted. Any binding of HELD MUST be capable of being transacted over TLS so that the client can request the above authentication, and a LIS implementation for a binding MUST include this feature. Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the LIS certificate itself. NEW: When the HELD transaction is conducted using TLS [RFC5246], the LIS SHOULD authenticate its identity, either as a domain name or as an IP address, to the client by presenting a certificate containing that identifier as a subjectAltName (i.e., as an iPAddress or dNSName, respectively). In the case of the HTTP binding described above, this is exactly the authentication described by TLS [RFC2818]. If the client has external information as to the expected identity or credentials of the proper LIS (e.g., a certificate fingerprint), these checks MAY be omitted. Any binding of HELD MUST be capable of being transacted over TLS so that the client can request the above authentication, and a LIS implementation for a binding MUST include this feature. Note that in order for the presented certificate to be valid at the client, the client MUST be able to validate the certificate. In particular, the validation path of the certificate MUST end in one of the client's trust anchors, even if that trust anchor is the LIS certificate itself. And the text that causes you concern in section 8 as: OLD: The LIS MUST NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617]. NEW: The LIS SHOULD NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617], but rather SHOULD use the mechanism described in section 9.1. I'll respond to your other comments separately. Thanks, Mary. -----Original Message----- From: Ben Campbell [mailto:ben@xxxxxxxxxxxx] Sent: Friday, June 05, 2009 9:13 AM To: Richard Barnes Cc: General Area Review Team; Barnes, Mary (RICH2:AR00); james.winterbottom@xxxxxxxxxx; martin.thomson@xxxxxxxxxx; barbara.stark@xxxxxxx; acooper@xxxxxxx; Cullen Jennings; ietf@xxxxxxxx Subject: Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14 On Jun 5, 2009, at 8:43 AM, Richard Barnes wrote: > Ben, > > Thanks for your review. With respect to the HTTP issue you raise, is > your claim that the HTTP binding prevents the use of Digest or Basic > based on this sentence from Section 6.3? > > " > HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. No, I based it on the last sentence, second paragraph in section 8: "The LIS MUST NOT rely on device support for cookies [RFC2965] or use Basic or Digest authentication [RFC2617]." It doesn't explicitly "forbid" the use of digest authn, but if it can't depend on client support, then it can't really base any decision on it. > > " > > If so, then I think that's a misinterpretation that calls for a > clarification. The authors should feel free to correct me, but I think > that HTTP-level errors (e.g., the need for authentication, or even a > LIS not listening at a given path) can still generate other HTTP > response codes (e.g., 401 or 404). It's just that if the only thing > that's gone wrong is at the HELD layer -- if it's the positioning that > failed, not the communications -- then you have to use a 200. > > Assuming that all the above is accurate, proposed text: > " > HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. > (Other response codes may still be generated at the HTTP layer, if the > problem is with the HTTP part of the message, not the HELD part. For > instance, if the request needs to be authenticated with Basic or > Digest authentication, the server may issue a 401 Unauthorized > response as a challenge, or if the indicated path is not valid, then > the server may issue a 404 Not Found.) " > > Cheers, > --Richard > > > > > Ben Campbell wrote: >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> Please resolve these comments along with any other Last Call comments >> you may receive. >> Document: draft-ietf-geopriv-http-location-delivery-14 >> Reviewer: Ben Campbell >> Review Date: 2009-06-04 >> IETF LC End Date: 2009-06-09 >> IESG Telechat date: (if known) >> Summary: >> This draft is ready for publication as a proposed standard. I have a >> few editorial and clarity comments that might could slightly improve >> the draft, but can safely be ignored. Additionally, I have one >> comment highlighting a "feature" that is not necessarily a problem, >> but is architecturally important enough that I want to make sure the >> IESG thinks about it. >> Major issues: None. >> Minor issues: >> -- There is one feature of HELD that the ADs should explicitly think >> about: The HTTP binding forbids LIS reliance on HTTP digest or basic >> authentication. If I understand correctly, this means effectively >> that the _only_ method for client authentication is the built in >> reverse routeability test. I am agnostic as to whether this is >> sufficient. >> Nits/editorial comments: >> -- section 4, paragraph 1: >> Please expand (and reference) PIDF-LO on first mention. >> -- Section 6.2, value list: >> -- In my previous review, I was confused as to the relationship >> between the geodetic/civic and LoBV/LoBR choices. I think it's worth >> some clarification in this section that geodetic and civic imply >> LoBV. >> -- section 9.3, 5th paragraph: "A temporary spoofing of IP address >> could mean that a device could request a Location Object or Location >> URI that would result in another Device's location." >> It might be worth clarifying that (if I understand correctly) that >> this is more than a spoofing attack, in that the attacker must not >> only spoof its source address, but must be able to receive packets >> sent to the spoofed address? >> -- same paragraph: "... re-use of the Device's >> IP address could result in another Device receiving the original >> Device's location rather than its own location." >> It seems like this problem is pretty unlikely to occur by _accident_ >> when HELD is used over TCP (the only binding right now), right? And >> certain not to happen over TLS? Might be worth a "mitigating" >> mention. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf