Subject: Re: [Geopriv] [secdir] Review of draft-ietf-geopriv-http-location-delivery-07

From: "TSG" <[email-masked]>
Date: Tue, 17 Jun 2008 13:25:44 -0800

FYI
Portions of the GeoPriv model seem to violate a couple of the controls in 
our "controlling access to stored information" patent and that is already on 
file with the IETF's IP Group formally.

Todd Glassey
----- Original Message ----- 
From: "Richard Barnes" <[email-masked]>
To: "Eric Rescorla" <[email-masked]>
Cc: "GEOPRIV" <>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Sunday, May 25, 2008 4:49 PM
Subject: Re: [secdir] 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 $
>>>>>>
>>>>>> S 4.3.1.
>>>>>>    Devices that establish VPN connections for use by other devices
>>>>>>    inside a LAN or other closed network could serve as a LIS, that
>>>>>>    implements the HELD protocol, for those other Devices.  Devices
>>>>>>    within the closed network are not necessarily able to detect the
>>>>>>    presence of the VPN and rely on the VPN device.  To this end, a 
>>>>>> VPN
>>>>>>    device should provide the address of the LIS server it provides, 
>>>>>> in
>>>>>>    response to discovery queries, rather than passing such queries
>>>>>>    through the VPN tunnel.
>>>>>>
>>>>>> How do you envision this happening? Isn't this going to require
>>>>>> changing every VPN protocol? I think some more text would be
>>>>>> appropriate here...
>>>>>>
>>>>>>
>>>>>>
>>>>> It requires location information to be obtained before the tunnel is 
>>>>> setup.
>>>>>
>>>> OK, but I still don't understand how this is going to work. Say that
>>>> I'm on a local network with a DHCP server and the VPN server is a 
>>>> couple
>>>> of hops away. How does the VPN device "provide the address of the LIS
>>>> server" to me?
>>>>
>>>>
>>>>
>>> When you operate a network and you want this stuff to work then you have
>>> to consider this aspect.
>>> In the past a few folks have suggested to write a BCP about how
>>> different deployments may deal with this aspect but I believe it is far
>>> too early todo so for a BCP.
>>
>> The problem is that I'm not sure that this is an issue that can be solved
>> by the network operator. In the example I described, it sounds to
>> me like new protocol work may be required.
>
> The current document specifies the use of HELD as a protocol between an
> endpoint and its local network (i.e., as a location configuration
> protocol).  In that sense, the use case you mention doesn't arise, or
> rather, the use case can be worked around by appropriate configuration
> of the LIS by the access network operator (to know how network segments
> are connected on the VPN).  I think this issue merits more of an
> applicability statement than new protocol work.
>
>
>>>> Well, lots of protocols would benefit from not having IP address
>>>> spoofing, but again, you're making a levy on network operations
>>>> on a global scale, no?
>>>>
>>>>
>>> If you want to deal with certain attacks then you may want todo
>>> something about it.
>>
>> Sorry, I don't think I get what you're saying here.
>
> What the document is trying to say is that because HELD uses the
> requestor's IP address as a location identifier, if the LIS is trying to
> assure that location is actually only provided to the host that
> originates a request, then it must have assurance that the source IP
> address of the request is that of the originator, i.e., that the source
> address of the request has not been spoofed.  If there is no requirement
> for that level of assurance, then there is no requirement for 
> anti-spoofing.
>
> On the other hand, given that the LIS is notionally operated by the
> access network operator, this is actually a local requirement: If you,
> the network/LIS operator, require this degree of assurance then you MUST
> implement measures to prevent IP address spoofing.  (Note, however, the
> conditionality.)
>
> --Richard
>
>
>
> _______________________________________________
> IETF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Jun 2008 16:30:30 -0400

Todd,

Could you please provide a link to the relevant IPR disclosure(s)?

Thanks,
--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2008 12:59:47 -0700

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:[email-masked]] 
> Sent: Saturday, May 24, 2008 9:01 PM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Review of draft-ietf-geopriv-http-location-delivery-07
> 
> 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

---

From: "TSG" <[email-masked]>
Date: Fri, 20 Jun 2008 19:07:52 -0800

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" <[email-masked]>
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Friday, June 20, 2008 11:59 AM
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 21 Jun 2008 06:03:29 -0500

Hi Todd,

Can you be a bit more helpful?

There is no disclosure #201 on the IPR page -
https://datatracker.ietf.org/ipr/ that I can find.

A search for "earthlink" does not yield anything either.

Could you provide a link to the information and an explanation of what
GEOPRIV is actually doing that "violates" a patent?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of TSG
Sent: Saturday, 21 June 2008 1:08 PM
To: Eric Rescorla; Mary Barnes
Cc: [email-masked];
[email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Review of
draft-ietf-geopriv-http-location-delivery-07

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" <[email-masked]>
To: "Mary Barnes" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>;
<[email-masked]>; 
<[email-masked]>
Sent: Friday, June 20, 2008 11:59 AM
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]