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

"TSG" <tglassey@earthlink.net> Sat, 21 June 2008 02:07 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359E83A68C4; Fri, 20 Jun 2008 19:07:57 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B09E3A6899; Fri, 20 Jun 2008 19:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-mX9jOq68kg; Fri, 20 Jun 2008 19:07:54 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id AF4953A6874; Fri, 20 Jun 2008 19:07:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mKWXfVLg8POWFx1zcuk+JD++1pmiDCT/bRlErm2DfBkoknD2q4pW6bh2xj/jyYO7; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.23.176.93] (helo=tsg1) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <tglassey@earthlink.net>) id 1K9sWA-0000Sk-EZ; Fri, 20 Jun 2008 22:07:54 -0400
Message-ID: <001101c8d34c$009e2ac0$6401a8c0@tsg1>
From: "TSG" <tglassey@earthlink.net>
To: "Eric Rescorla" <ekr@networkresonance.com>, "Mary Barnes" <mary.barnes@nortel.com>
References: <20080525020040.4DE5A5081A@romeo.rtfm.com><F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com>
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07
Date: Fri, 20 Jun 2008 19:07:52 -0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79eebcf540220e9e53635ead041acbbf28350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.23.176.93
Cc: geopriv@ietf.org, draft-ietf-geopriv-http-location-delivery@tools.ietf.org, secdir@mit.edu, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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" <ekr@networkresonance.com>;
To: "Mary Barnes" <mary.barnes@nortel.com>;
Cc: <geopriv@ietf.org>;; <secdir@mit.edu>;; 
<draft-ietf-geopriv-http-location-delivery@tools.ietf.org>;; <iesg@ietf.org>;; 
<ietf@ietf.org>;
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:ekr@networkresonance.com]
>> Sent: Saturday, May 24, 2008 9:01 PM
>> To: secdir@mit.edu;
>> draft-ietf-geopriv-http-location-delivery@tools.ietf.org
>> Cc: ietf@ietf.org; iesg@ietf.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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf 

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf