|
Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14
2009-06-08 15:29:10
Again, my point was not to say that this was necessarily a problem--I
highlighted it as something the IESG should think about, knowing that
they have a big reading load. I guess my question is, is the statement
that reverse routability provides "sufficient assurance in many
cases", along with the fact that the HTTP binding explicitly
discourages stronger client authentication mechanisms acceptable to
them. If it is, I am fine with it, and the draft would not need a
change. If on the other hand I have misunderstood something, that's
different.
I am a little confused about the proposed change to section 8, though.
It sounds like it is conflating LIS authentication with device
authentication. To decompose your proposed language I read it as:
"The LIS SHOULD NOT ... use [device authentication mechanism], but
rather SHOULD use [LIS authentication mechanism]"
Is it possible I am misunderstanding the direction of the client-
server relationship in the HTTP binding? I was assuming the device to
be the HTTP client and the LIS to be the HTTP server--do I have it
backwards?
On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote:
Hi Ben,
So, you are talking about section 9.3 which does state that the LIS
ensures that the client is authenticated, per the following:
"The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
And the following:
A prerequisite for meeting this requirement is that the LIS must
have
some assurance of the identity of the client. Since the target of
the returned location is identified by an IP address, simply sending
the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that
location is given only to authorized clients; LIS implementations
MUST support a mode of operation in which this is the only client
authentication.
And, then the text goes on to some of the other text in section 9.3
that
you had questions about that I responded to in a separate email.
So, I'm not certain I understand the problem IF I make the proposed
change to the sentence in section 8.
Mary.
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net]
Sent: Monday, June 08, 2009 1:47 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;
james(_dot_)winterbottom(_at_)andrew(_dot_)com;
martin(_dot_)thomson(_at_)andrew(_dot_)com;
barbara(_dot_)stark(_at_)att(_dot_)com; acooper(_at_)cdt(_dot_)org; Cullen
Jennings; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14
Hi Mary,
The part I was trying to highlight was the lack of client device
authentication, not LIS authentication. If I read 9.1 right, it only
covers authentication of the LIS. I assume there is no expectation
that
client devices present TLS certs to the LIS, right?
Again, I'm not saying that the lack of client device authentication
is a
problem. The reverse routeability aspect might be sufficient. I'm
merely
pointing it out to make sure people think about it.
On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:
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(_at_)estacado(_dot_)net]
Sent: Friday, June 05, 2009 9:13 AM
To: Richard Barnes
Cc: General Area Review Team; Barnes, Mary (RICH2:AR00);
james(_dot_)winterbottom(_at_)andrew(_dot_)com;
martin(_dot_)thomson(_at_)andrew(_dot_)com;
barbara(_dot_)stark(_at_)att(_dot_)com; acooper(_at_)cdt(_dot_)org; Cullen Jennings;
ietf(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|