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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf