At Thu, 29 May 2008 07:51:02 -0500,
Mary Barnes wrote:
Hi Eric,
Thanks for you review and comments. My responses are embedded below
[MB].
Mary.
-----Original Message-----
From: Eric Rescorla [mailto:ekr(_at_)networkresonance(_dot_)com]
Sent: Saturday, May 24, 2008 9:01 PM
To: secdir(_at_)mit(_dot_)edu;
draft-ietf-geopriv-http-location-delivery(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: Review of draft-ietf-geopriv-http-location-delivery-07
$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1
2008/05/24 15:03:19 ekr Exp $
TECHNICAL
S 4.2.
which a Location Recipient (LR) can use to retrieve LI. A location
URI provided by a LIS can be assumed to be globally-addressable; that
is, anyone in possession of the URI can access the LIS. However,
this does not in any way suggest that the LIS is bound to reveal the
location associated with the location URI. This issue is deemed out
I don't understand this point. anyone in possession of the URI can
access the URI but the LIS isn't required to reveal it? Those seem kind
of contradictory.
[MB] Your comment is similar to a point made by Ben Campbell's gen-art
review.
The text is unclear, in particular the "However," clause. The changes
agreed as a result of the gen-art thread
http://www.ietf.org/mail-archive/web/gen-art/current/msg02995.html
are reflected below (also incorporating another issue Ben raised, as
well, by adding a new paragraph to that section):
NEW:
However, this does not in any way suggest that the LIS
indiscriminately reveals the location associated with the location
URI.
The specific requirements associated with the dereference of the
location are specified in [I-D.ietf-geopriv-lbyr-requirements].
The location dereference protocol details are out of scope of
this document and are specified in
[I-D.winterbottom-geopriv-location-deref].
It should also be noted that while the lybr requirements document
specifies a requirement that a client SHOULD be able to cancel
location references, the protocol specified in this document
does not provide that functionality. The mechanism to
provide this support in the protocol requires explicit management
of Target state on the LIS. It is anticipated that extensions to HELD
may support that requirement.
Does the revised text help to alleviate your concern?
Well, it alleviates my concern about the security question, but it
reinforces my concern about the completeness of this specification.
Unless I'm missing something, this is a major normative dependency
on draft-winterbottom-geopriv-location-deref? I'm not sure we can
assess this protocoal with that reference unbound.
It could also be useful for a VPN device to serve as a LIS for other
location configuration options such as Dynamic Host Configuration
Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [27]. VPN devices that serve as a LIS may
acquire their own location using HELD.
Yes, I think this is an improvement.
S 5.1.
o The HELD protocol must provide authentication, confidentiality and
protection against modification per Section 10.3.
Are you talking about HELD, which doesn't seem to have these features,
or about the transport protocol? Also, authentication for who? Based on
what model?
[MB] Per your subsequent response to Hannes on this point, I will change
that bullet to read:
o The HELD protocol REQUIRES that the underlying transport provide
authentication, confidentiality and
protection against modification per Section 10.3.
Agreed.
S 6.5.
I'm having trouble keeping straight two kinds of URIs:
- URIs that a Device uses to get its own LI.
- LbyR references that the LIS hands out.
This text seems to imply that an LIS can hand out a helds:
URI. Is that *also* the URI that a Device derferences?
[MB] Yes, the helds: URI that a device receives in a locationResponse is
the URI that a device would dereference. But, it's important to note
that the LIS does not have to return a helds: URI - other URIs may also
be used per the text in section 6.5. [/MB]
Hmm... Then I think this needs some explanation in the main text.
S 6.5.1.
A "locationURI" SHOULD NOT contain any information that could be used
to identify the Device or Target. Thus, it is RECOMMENDED that the
"locationURI" element contain a public address for the LIS and an
anonymous identifier, such as a local identifier or unlinked
pseudonym.
1. This seems like it should be clearer about what is desired.
In particular it's not just "identify" but also "link".
Also this needs to be clarified to indicate the implications
of idetntifiction by position.
2. Shouldn't this be MUST strength?
[MB] This isn't a MUST strength because we had WG discussion/consensus
that we can't mandate LIS behavior. We can make recommendations, but a
LIS may not necessarily follow them. I'm not entirely clear on your
first point as far as "identification by position". [/MB]
I mean that knowing where someone is with high enough resolution gives
a lot of information about their identity. For instance, if you know
that someone is at the AP associated with my house, it seems pretty
likely it's me.
Does this say somewhere what "helds" actually means? I see the
definitition of the URI, but it doesn't say what the underlying
transport is, as far as I can tell. Given a "helds:" URI, what am I
supposed to do with it?
[MB] I will add something like the following to section 8. Also, we have
discussion on the WG mailing list and we will be adding the basic held:
URI schema, as well:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05567.html
OLD:
This section defines the schema for a helds: URI.
NEW:
This section defines the schema for a helds: URI for TLS connections.
The concern I have is more fundamental. This section doesn't say
that helds: uses HTTP at all? I assume this is the protocol
in S 9, but this doesn't say so, nor does the next section.
S 9.
OK and here's how I get confusied about the two types of URI,
since this is an HTTP binding, but there's no corresponding
URI.
[MB] The thread above relates to this point and your next.
On this specific point, we will be defining a held: URI along with the
helds: URI. [/MB]
The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [RFC2818].
I'm having a lot of trouble visualizing this. If you want to
send a more complete section, I'll try to tell you if I think
this addresses my concerns.
Is this MUST implement or MUST use? Don't the next two sentences
imply MUST use?
[MB] Per the thread above, that text does need some clarification for
consistency. It should be
MUST "implement" and not MUST "use", so I would propose the
following change:
OLD:
The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [RFC2818]. TLS provides message integrity and
privacy between Device and LIS. The LIS MUST use the server
authentication method described in [RFC2818]; the Device MUST fail a
request if server authentication fails, except in the event of an
emergency.
NEW:
The implementation of HTTP as a transport mechanism MUST implement
TLS as described in [RFC2818]. TLS provides message integrity and
privacy between Device and LIS.
privacy->confidentiality. Also, only if the right cipher suiotes
are used.
The LIS MUST implement the server
authentication method described in [RFC2818]. When TLS is used,
the Device SHOULD fail a request if server authentication fails,
except in the event of an emergency.
Does that address your concerns?
Why did this become a SHOULD when it was a MUST?
[MB] Yep. [/MB]
between Device and LIS. The LIS MUST use the server
authentication method described in [RFC2818]; the Device MUST fail a
request if server authentication fails, except in the event of an
emergency.
This is incomplete, because 2818 assumes the presence of a URI to
compare against. Where does that come from?
How is client authentication supposed to work here?
[MB] Per Hannes response, the device (client) gets the URI of the LIS
(server) using LIS discovery procedures.
Sure, but what are the contents of that URI? Where is it defined?
S 10.3.
o The network SHOULD have mechanisms that protect against IP address
spoofing, such as those defined in [RFC3704].
Is this WG really in a position to levy a SHOULD level requirement
for network ingress filtering? Recall that this is really a global level
technology. Or do you mean something else?
[MB] Per Richard's response on this thread, the IP address spoofing
recommendation is due to HELD using the devices IP address as the
identifier for the device. In this case it is important to have a
recommendation for IP address spoofing. I think the paragraph prior to
those bullets appropriately qualifies the context of that
recommendation.
[/MB]
I can't say I really agree with this assertion about the qualification.
This still looks to me like a general levy on the access network.
-Ekr
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf