Subject: [Geopriv] I-D Action: draft-ietf-geopriv-deref-protocol-06.txt

From: [email-masked]
Date: Wed, 11 Jul 2012 16:13:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title           : A Location Dereferencing Protocol Using HELD
	Author(s)       : James Winterbottom
                          Hannes Tschofenig
                          Henning Schulzrinne
                          Martin Thomson
	Filename        : draft-ietf-geopriv-deref-protocol-06.txt
	Pages           : 23
	Date            : 2012-07-11

Abstract:
   This document describes how to use the Hypertext Transfer Protocol
   (HTTP) over Transport Layer Security (TLS) as a dereferencing
   protocol to resolve a reference to a Presence Information Data Format
   Location Object (PIDF-LO).  The document assumes that a Location
   Recipient possesses a URI that can be used in conjunction with the
   HTTP-Enabled Location Delivery (HELD) protocol to request the
   location of the Target.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-geopriv-deref-protocol

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-06

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-deref-protocol-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Robert Sparks <[email-masked]>
Date: Thu, 12 Jul 2012 13:15:57 -0500

This revision addressed all the points from IESG review.

Notably, it contained a clarification to when TLS is required:

OLD:
   TLS SHOULD be used.

NEW:
    TLS MUST be used unless confidentiality and integrity are provided by
    some other mechanism, such as IPsec or a fully trusted network.
    Without a reliable assertion that a mechanism is in place, such as
    through configuration or user override, then TLS MUST be used.

If you have a concern with this change, please let me know ASAP.
If I haven't heard anything I'll approve the document towards the end of 
next week.

RjS
On 7/11/12 6:13 PM, [email-masked] wrote:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: tglassey <[email-masked]>
Date: Thu, 12 Jul 2012 12:02:29 -0700

>    through configuration or user override, then TLS MUST be used.
My concerns for this is that the use of the HELD over the TLS transport 
creates the infringement of the US6370629 patent(s) which is/are in 
court over the assignment fraud claim. The next court date is the middle 
of August and the case number is CV165643 in Santa Cruz CA Superior Court.

See the existing IPR filings with the IETF on this issue. Its the same 
one the Timestamp folks face, the DNSSec folks face and you folks face 
as well for all location based services.

Todd Glassey
> If I haven't heard anything I'll approve the document towards the end 
> of next week.
>
> RjS
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2195 / Virus Database: 2437/5127 - Release Date: 07/12/12
>

-- 
//Confidential Mailing - Please destroy this if you are not the intended recipient.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 12 Jul 2012 15:16:57 -0400

This sounds okay with me, not that I believe there is any practical way to do either of the alternatives.

Brian

On Jul 12, 2012, at 2:15 PM, Robert Sparks wrote:

> If I haven't heard anything I'll approve the document towards the end of next week.
> 
> RjS
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 15:26:53 -0400

Hi Todd,

If you believe there is IPR that relates to this document, please submit it to the IETF IPR tracker.  It does not appear that you have done so already:
<https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-geopriv-deref-protocol>

Thanks,
--Richard

On Jul 12, 2012, at 3:02 PM, tglassey wrote:

> My concerns for this is that the use of the HELD over the TLS transport creates the infringement of the US6370629 patent(s) which is/are in court over the assignment fraud claim. The next court date is the middle of August and the case number is CV165643 in Santa Cruz CA Superior Court.
> 
> See the existing IPR filings with the IETF on this issue. Its the same one the Timestamp folks face, the DNSSec folks face and you folks face as well for all location based services. 
> 
> Todd Glassey
>> Checked by AVG - www.avg.com

---

From: Richard L. Barnes <[email-masked]>
Date: Thu, 12 Jul 2012 15:35:50 -0400

<hat type="individual"/>

I would prefer that this text make a little clearer which entities in the protocol are required to do something and when.

OLD:
"
TLS SHOULD be used.
"

NEW: 
"
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue HTTPS URIs and respond to HTTPS dereference request, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel.  Dereference clients MUST support dereference of HTTPS URIs and SHOULD support dereference of HTTP URIs.
"

---

From: tglassey <[email-masked]>
Date: Thu, 12 Jul 2012 21:13:03 -0700

> <https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-geopriv-deref-protocol>

Done - and I included a link to the PATENT ASSIGNMENT STATEMENT for this 
patents assignment to Digital Delivery Inc a company later bought by Datum.

http://www.jdsupra.com/post/documentViewer.aspx?fid=9e6c52e3-a1b6-4274-bf68-ee14e3629153

What you will read in the link is that I assigned the patent so that 
they could perform pre-paid legal services in filing the patents for us. 
You understand there are special standings for Fiduciary Contracts???

I am dead serious about this - I am losing about a billion dollars a 
week in royalties.

Todd//

> -----

---

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Jul 2012 09:30:30 -0500

Hi Richard.

Where you say "be configure to" and "respond to", do you mean "be 
configured to only" and "respond only to"?

RjS

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 12:05:04 -0400

I don't think we want to preclude HTTP entirely.  For example, a LIS might want to use HTTP to redirect clients to HTTPS if they decide to try going non-secure.  But obviously, it shouldn't send location in HTTPS unless alternative protections are in place.

NEW:
"
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference request, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel.  Location Servers MAY respond to dereference requests over HTTP, but MUST NOT provide location information over HTTP unless alternative protections are in place.  HTTP should only be used for ancillary functions, such as redirecting clients toward HTTPS URIs.  Dereference clients MUST support dereference of HTTPS URIs and SHOULD support dereference of HTTP URIs.
"

On Jul 13, 2012, at 10:30 AM, Robert Sparks wrote:

> Hi Richard.
> 
> Where you say "be configure to" and "respond to", do you mean "be configured to only" and "respond only to"?
> 
> RjS
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jul 2012 09:16:02 -0700

This is more explicit text, which makes things a lot clearer.  In
particular, I like the point that it is the choice of the server to
choose an http: URI.

I don't see the need for your more recent additions, which implies
permission to do these things.  When redirects from HTTP are
encouraged (though I hardly think that is your intent, that's how it
appears to me), this offers an attacker the opportunity to change the
URI target.  I'd rather just drop any statements of that sort.  I
prefer your original suggestion, with the edits implied by Robert.

--Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 12:37:53 -0400

Thanks, Martin. 

The reason I'm cautious about the "only respond over HTTPS" suggested by Robert is that it seems to me to disallow the redirect case.  Even though the redirect case does have the vulnerability that you point out, it can be a fail-safe in case an HTTPS URI gets transposed to an HTTP URI.  

But if we don't say "only respond over HTTPS", then we need to clarify that you shouldn't actually do a dereference over HTTP, just ancillary stuff like redirects.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 17:47:30 +0100

So I don't see the use-case for re-directs really given
that anyone could then re-direct me to badguy.com.

Wouldn't it be better to just take the failure if
someone drops the "s" from an https URL and then not
have to worry so much?

S.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 13:01:54 -0400

> that anyone could then re-direct me to badguy.com.

It's not really "anyone".  The set of people who could redirect me (call this A for active) is a subset of the people who could sniff my traffic anyway (call this P for passive).  The redirect is secure in the face of only passive attackers.  So the incremental benefit is #(P-A). 

Things like routers, firewalls, and VPN endpoints are obviously in both A and P, but lots of other things aren't. For example, things like Cisco Source Guard and SAVI prevent passive attackers from being active because they prevent address spoofing.  

> someone drops the "s" from an https URL and then not

There are cases where failure can cause real problems.  I'm thinking mainly of emergency services, where you might have a SIP proxy doing a dereference.  HTTPS already causes some concern here, because of things like mismatching trust anchors.  

I'm not trying to argue that redirects are a great idea, just that they're useful enough that we shouldn't preclude them.

--RLB

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 18:30:27 +0100

Hiya,

> Things like routers, firewalls, and VPN endpoints are obviously in both A and P, but lots of other things aren't. For example, things like Cisco Source Guard and SAVI prevent passive attackers from…

But so is every compromised http proxy on the path right?

I'd have thought that you'd only benefit from a VPN or
source guard or (heaven forbid;-) SAVI in cases where
you're already in a situation where you don't need TLS
because you have IPsec or something else.

So I'm not getting the case where we MUST use TLS but
are ok to accept a 30x response to a request to port 80.

> I'm not trying to argue that redirects are a great idea, just that they're useful enough that we shouldn't preclude them.

So if network infrastructure components can't get that
right then aren't you hosed in any case since they
won't be able to successfully follow the 30x?

S.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jul 2012 11:24:30 -0700

The text that you propose contains the same escape clause, which is
either sufficient for this, or not.  That is, "unless confidentiality
and integrity protection are provided by some other mechanism".

If the "other mechanism" is unicorns and fairies, as long as the
people deploying are OK with that, then the letter and spirit of the
language is adhered to.  We all sleep soundly at night knowing that
the fairy princess and her noble unicorn mount are defending our
location privacy.

I think that you might need to provide a stronger case for the weaker
security you advocate.

--Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 14:33:47 -0400

Ok, it seems the winds are against me today.  I'll give Stephen his "only" :)

NEW:
"
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference requests, unless confidentiality and integrity protection are provided by some other mechanism.  For example, the server might only accept requests from clients within a trusted network, or via an IPsec-protected channel. 
"

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 21:45:19 +0300

The proposed text sounds good to me.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 22:59:28 +0100

> The scheme of a location URI determines whether or not TLS is used on a given dereference transaction.  Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS der…

Works for me.
Thanks,
S,

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jul 2012 15:06:05 -0700

Works for me too.  Expect an update shortly.