Re: Review of draft-ietf-geopriv-http-location-delivery-07

["TSG" <[e-mail]>]

FYI - the IETF IPR disclosure process doesn't work very well since GEOPRIV 
directly violates our patent - see IPR notice #201.

Todd Glassey
----- Original Message ----- 
From: "Eric Rescorla" <[e-mail]>
To: "Mary Barnes" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; 
<[e-mail]>
Sent: Friday, June 20, 2008 11:59 AM
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07


> 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:[e-mail]]
>> Sent: Saturday, May 24, 2008 9:01 PM
>> To: [e-mail];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf 

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf