Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-http-location-delivery-05.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Mar 2008 11:17:58 -0400

Reminder: This LC ends this Friday.

RjS

On Feb 27, 2008, at 4:57 PM, Robert Sparks wrote:

> Folks -
>
> This is a Last Call for comments on draft-ietf-geopriv-http- 
> location-delivery-05.txt
>
> As Mary notes below, the http-location-delivery draft had some  
> fairly big touches in response to
> the WGLC on -04, so we need to ask everyone to read _this_ version  
> and make sure we're ready
> to request publication.
>
> Because of the timing of the impending IETF meeting, I'm setting  
> the call for a little over 3 weeks.
>
> Please have your comments in no later than March 21.
>
> If at all possible, have your comments in before we get to the IETF  
> meeting. Please put your primary focus
> on making sure we've resolved the issues identified to date.
>
> Do remember to send a note in if you've read the document and have  
> no other comments other than
> "its ready to go" - we need those as much as we need "I found a  
> problem".
>
> Mary notes a couple of issues that we will close in parallel with  
> this review. Lets see if we can
> reach closure on those this week.
>
> Thanks!
>
> RjS
>
> Begin forwarded message:
>
>> From: "Mary Barnes" <[email-masked]>
>> Date: February 22, 2008 5:01:57 PM CST
>> To: "GEOPRIV" <[email-masked]>
>> Subject: [Geopriv] Updated:draft-ietf-geopriv-http-location- 
>> delivery-05.txt
>>
>> Hi all,
>>
>> Here's a summary of the changes in the -05 version reflecting WGLC
>> comments and subsequent mailing list discussion. In addition, Richard
>> Barnes sent a marked up version of the document with many editorial
>> changes and clarifications that have been made. It may be easiest to
>> review the diff. If you do see any issues or have additional  
>> suggestions
>> for changes, sending explicit text to the list makes the editting  
>> task
>> easier.  We are also reaching the point where we've tweaked the same
>> text many times over (onlist and then in the document revisions),  
>> so I'd
>> rather leave some things like whether extra commas are  
>> appropriate, etc.
>> to the RFC editor, unless the text actually conveys the wrong  
>> concept.
>>
>> 1) Totally replaced the security section with the details provided by
>> Richard Barnes so that we don't need a reference to the location
>> security document.
>>
>> 2) Fixed error codes in schema to allow extensibility. Change the  
>> IANA
>> registration to be "specification required".
>>
>> 3) Cleaned up the HELD: URI description, per comments from Martin and
>> James and partially addressing HELD-04 Issue 1.  Put the  
>> definition in a
>> separate section and clarified the applicability (to also include  
>> being
>> a results of the discovery process) and fixed examples.
>>
>> 4) Updated the LocationURI section to be more accurate, address  
>> HELD-04
>> Issue 3, and include the reference to the new HELD:URI section. Also,
>> fixed an error in the doc in that the top level parm in the
>> locationResponse is actually locationUriSet, which contains any  
>> number
>> of locationURI elements and the "expires" parameter.  So, Table 1 was
>> also updated and a new section for the LocationURISet was added that
>> includes the subsections for the "locationURI" and "expires".   And,
>> then clarified  that "expires" applies to "locationURISet" and not  
>> per
>> "locationURI".
>>
>> 5) Editorial nits:  pointed out offline by Richard (e.g., by-value  
>> -> by
>> value, by-reference -> by reference, etc.) and onlist by James and
>> Martin. Please refer to the diff for a complete view of editorial
>> changes.
>>
>> 6) Added text in HTTP binding section to disable HTTP caching  
>> (HELD-04
>> Issue 5 on the list).
>>
>> There remain a couple of open issues based on past discussions and  
>> I'll
>> post separate items to address those (or respond to those past list
>> items).
>>
>> Mary.
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of [email-masked]
>> Sent: Friday, February 22, 2008 3:45 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [Geopriv] I-D
>> Action:draft-ietf-geopriv-http-location-delivery-05.txt
>>
>> 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           : HTTP Enabled Location Delivery (HELD)
>> 	Author(s)       : M. Barnes, et al.
>> 	Filename        :
>> draft-ietf-geopriv-http-location-delivery-05.txt
>> 	Pages           : 43
>> 	Date            : 2008-02-22
>>
>> A Layer 7 Location Configuration Protocol (L7 LCP) is described  
>> that is
>> used for retrieving location information from a server within an  
>> access
>> network.  The protocol includes options for retrieving location
>> information in two forms: by value and by reference.  The protocol  
>> is an
>> extensible application-layer protocol that is independent of
>> session-layer.  This document describes the use of Hypertext Transfer
>> Protocol (HTTP) as a transport for the protocol.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http- 
>> location-del
>> ivery-05.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the  
>> body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> 	"get draft-ietf-geopriv-http-location-delivery-05.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE
>> /internet-drafts/draft-ietf-geopriv-http-location-delivery-05.txt".
>>
>> NOTE:   The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail
>> readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/geopriv
>

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

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 18 Mar 2008 10:31:26 +0100

I read through the HELD draft, and I got a bit confused in the examples section:

11.1 HTTP Example Messages shows a GET request and the identical
minimal POST request <locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held"/>

The text says:

   "The successful response to either of these requests is a PIDF-LO
   document. "

Below, in Section 11.2 another example with the same request
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> is
explained, but a locationURI is returned.

I would suggest to add a note that all these 3 requests at the
beginning of the examples section do not specify any location types
and therefore one possible response is shown. And instead of "is a
PIDF-LO" it should be "contains a PIDF-LO".

Otherwise one could assume (like I did), that a GET request would
always return a PIDF-LO. Actually, the text above the GET example is:

"This example shows the most basic request for a LO."

But the response might also contain a locationURI, so the sentence may
be misunderstood.

Another question: I wonder why there is no way to say location by
value only in a location request? if I request the locationtypes civic
and geo with exact="true", the server needs to have both, when I say
exact="false", I might end up with just an URI instead. Is this
correct? Is there a way to say civic OR geo but no URI (without doing
separate requests for civic and geo) I have overlooked?

The rest of the draft seems to be good.

cheers
karl heinz

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 18 Mar 2008 08:50:19 -0500

Hi Karl,

I think your comments on the examples are correct, if you issue a basic
GET or POST then you may get back anything. If it is a location or a
locationURISet then it will come back in a locationResponse message. The
text should be corrected to reflect this.

I am a bit nervous about adding an additional locationType of anyValue,
as I could see end-point implementers always sending a location request
with a type of anyValue with the exact attribute set to true, and in
some circumstances, say where location hiding were enabled, the
end-point would never get anything but an error.

In the current semantics, it is true you may get a location URI, but you
have the option to try and dereference it, if that fails then you know
you are not entitled to get your location.

I am not fundamentally opposed to the new locationType, but I am nervous
about it.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Karl Heinz Wolf
> Sent: Tuesday, 18 March 2008 8:31 PM
> To: Robert Sparks
> Cc: GEOPRIV; Mary Barnes
> Subject: Re: [Geopriv] WGLC:
draft-ietf-geopriv-http-location-delivery-
> 05.txt
> 
> I read through the HELD draft, and I got a bit confused in the
examples
> section:

------------------------------------------------------------------------------------------------
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]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 15:21:03 -0700

All of these comments sent purely as an individual contributor.

Section 6.1: I may be behind in my following the conversation on this  
but did we agree to put "emergecnyRouting" and "emergencyDispatch" as  
possible values for responseTime? They are in the schema and for some  
reason I thought we had decided to add them. I don't mean to reopen  
the previous debate on this, it just seems that either section 6.1 or  
the schema needs to be updated to reflect the outcome of that  
discussion.

Section 10.1.1, 3rd para. I find all this pretty hand wavy to  
understand how reverse DNS lookups to to find a host name then hope  
the server certificate matches the hostname will actually achieve the  
security goals. In scenarios that I have heard about  where people  
don't want to use a DNS name for the LIS, it is because they want it  
to work without DNS. I would think a better solution for LIS that  
don't want to have a DNS name would be to say that if the LIS was  
identified by a IP address and TLS was used, then the certificate  
needed to have the servers IP address as one of the entries of type  
ipAddress in the SubjectAltName. If we did this, servers with IP  
addresses would work petty much like servers with DNS names and for  
the cases where the LIS was identified with an IP address, and no DNS  
would be used.

Section 10.1.1, 3rd para, last sentence and last point in section  
10.3: The IP Spoofing issues. This doc normatively references and  
suggests domains SHOULD do the things in [5] and [9] (RFC 2827 and  
3704). This worried me because it is pretty clear that lots of  
networks will not follow this advice and I started thinking about how  
much worse does the security of LOST get if you don't do either of  
these. I'm not actually convinced that it makes much difference. If an  
attacker can only spoof a source address but can't change the routing  
such that the responses to that address come back to them, as the  
document discuss, there is no big deal because a request is not routed  
to them. To be more specific, the attacker does not even manage to set  
up a TCP connection. Now clearly 2827 is a general good idea but not  
sure it actually is relevant to this document. I think it would be  
worth considering if this makes sense or not and if this could just be  
removed.

Section 12.4 IANA. I think you want to rephrase "allocated on a first- 
come/first-serve basis with specification required".  These terms are  
defined in draft-narten-iana-considerations-rfc2434bis to mean  
different things. I think what you are trying to say here is  
"allocated by ' Specification required' as defined in draft-narten- 
iana-considerations-rfc2434bis". Anyways, my advice would be to have a  
read of  2334bis and pick one of the terms in it and reference 2434bis.

Trivial NIT.

Section 7 - Given the problems W3C is having with people fetching URLs  
that they should not, do we really need to put the URL to the RFC in  
the annotation in the schema.  Could this instead say "RFC XXXX".

It seems weird to make normative references to the requirements  
documents [13] and [17]. In cases where the requirements are actually  
frameworks and you can not implement the protocol without reading  
these, they should be normative (Midcom was an example of this). Give  
some thought to if you can move these to informative references.

Cullen

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 21 Mar 2008 17:40:58 -0500

Hi Cullen

I will answer the first part now and quickly, the others I will get to over the weekend.

The responseTime is EITHER and integer in ms, OR it is expressed as one of two enumerated types (emergencyRouting or emergencyDispatch). I believe that the schema reflects this:

    <!-- responseTime Type -->
    <xs:simpleType name="responseTimeType">
      <xs:union>
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="emergencyRouting"/>
            <xs:enumeration value="emergencyDispatch"/>
          </xs:restriction>
        </xs:simpleType>
        <xs:simpleType>
          <xs:restriction base="xs:nonNegativeInteger">
            <xs:minInclusive value="0"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:union>
    </xs:simpleType>

Am I missing what you are trying to say?

Cheers
James

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 16:39:47 -0700

Never mind this one- I had just missed the text that says
   The values defined for the purpose, emergencyRouting and
    emergencyDispatch, will likely be governed by jurisdictional
    policies, and should be configurable on the LIS.

On Mar 21, 2008, at 3:40 PM, Winterbottom, James wrote:

> The responseTime is EITHER and integer in ms, OR it is expressed as  
> one of two enumerated types (emergencyRouting or emergencyDispatch).  
> I believe that the schema reflects this:
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 24 Mar 2008 13:37:37 -0500

Cullen,

Thanks for the review. My responses are embedded below [MB]. 

Mary.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Friday, March 21, 2008 5:21 PM
To: Barnes, Mary (RICH2:AR00)
Cc: GEOPRIV
Subject: WGLC: draft-ietf-geopriv-http-location-delivery-05.txt - cullen
comments

Section 6.1: I may be behind in my following the conversation on this
but did we agree to put "emergecnyRouting" and "emergencyDispatch" as
possible values for responseTime? They are in the schema and for some
reason I thought we had decided to add them. I don't mean to reopen the
previous debate on this, it just seems that either section 6.1 or the
schema needs to be updated to reflect the outcome of that discussion.

[MB] Yes, we agreed to add the values emergencyRouting and
emergencyDispatch as options for the responseTime value.  They are in
the schema and they are described in section 6.1.  There had been a past
comment that the "and/or" in section 6.1 that describes having a time
value "and/or" a purpose needs to be changed to an "or". That change
will be reflected in the -06. There is text in that first paragraph in
6.1 describing the purposes of emergencyRouting and emergencyDispatch.
They are not quoted, which may be why they were missed. So, I can also
make that change in the -06. [/MB]

Section 10.1.1, 3rd para. I find all this pretty hand wavy to understand
how reverse DNS lookups to to find a host name then hope the server
certificate matches the hostname will actually achieve the security
goals. In scenarios that I have heard about  where people don't want to
use a DNS name for the LIS, it is because they want it to work without
DNS. I would think a better solution for LIS that don't want to have a
DNS name would be to say that if the LIS was identified by a IP address
and TLS was used, then the certificate needed to have the servers IP
address as one of the entries of type ipAddress in the SubjectAltName.
If we did this, servers with IP addresses would work petty much like
servers with DNS names and for the cases where the LIS was identified
with an IP address, and no DNS would be used.
[MB]  This is a good point and I welcome feedback from others (Richard
in particular, whom I've cc'ed) on this topic. We did not have the
reverse DNS lookups as part of the security solution until this version,
so this is all new text, with some new concepts. [/MB]

Section 10.1.1, 3rd para, last sentence and last point in section
10.3: The IP Spoofing issues. This doc normatively references and
suggests domains SHOULD do the things in [5] and [9] (RFC 2827 and
3704). This worried me because it is pretty clear that lots of networks
will not follow this advice and I started thinking about how much worse
does the security of LOST get if you don't do either of these. I'm not
actually convinced that it makes much difference. If an attacker can
only spoof a source address but can't change the routing such that the
responses to that address come back to them, as the document discuss,
there is no big deal because a request is not routed to them. To be more
specific, the attacker does not even manage to set up a TCP connection.
Now clearly 2827 is a general good idea but not sure it actually is
relevant to this document. I think it would be worth considering if this
makes sense or not and if this could just be removed.

[MB] I'm slightly confused by your reference to LOST above, but see your
point about considering whether this concept is useful for HELD. And,
per the point above, would appreciate feedback from others as to whether
this should be removed. [/MB]

Section 12.4 IANA. I think you want to rephrase "allocated on a first-
come/first-serve basis with specification required".  These terms are
defined in draft-narten-iana-considerations-rfc2434bis to mean different
things. I think what you are trying to say here is "allocated by '
Specification required' as defined in draft-narten-
iana-considerations-rfc2434bis". Anyways, my advice would be to have a
read of  2334bis and pick one of the terms in it and reference 2434bis.
[MB] Good point. I'll change to specification required (the other text
was a holdover from the -04, which had the specification recommended and
not required). [/MB]

Trivial NIT.

Section 7 - Given the problems W3C is having with people fetching URLs
that they should not, do we really need to put the URL to the RFC in the
annotation in the schema.  Could this instead say "RFC XXXX".
[MB] Yes, I'll change that just to RFC XXXX. [/MB]

It seems weird to make normative references to the requirements
documents [13] and [17]. In cases where the requirements are actually
frameworks and you can not implement the protocol without reading these,
they should be normative (Midcom was an example of this). Give some
thought to if you can move these to informative references.
[MB] I will move those to informative to avoid the MIDCOM problem (I
don't want to go through that again). [/MB]

Cullen

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 24 Mar 2008 13:53:44 -0500

Hi Karl,

Thanks for reviewing the document. My responses are embedded below [MB].

Mary. 

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 4:31 AM
To: Robert Sparks
Cc: GEOPRIV; Barnes, Mary (RICH2:AR00)
Subject: Re: [Geopriv] WGLC:

I read through the HELD draft, and I got a bit confused in the examples
section:

11.1 HTTP Example Messages shows a GET request and the identical minimal
POST request <locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held"/>

The text says:

I would suggest to add a note that all these 3 requests at the beginning
of the examples section do not specify any location types and therefore
one possible response is shown. And instead of "is a PIDF-LO" it should
be "contains a PIDF-LO".

Otherwise one could assume (like I did), that a GET request would always
return a PIDF-LO. Actually, the text above the GET example is:

[MB] Good points. I will clarify the text for the examples in the -06.
[MB].

Another question: I wonder why there is no way to say location by value
only in a location request? if I request the locationtypes civic and geo
with exact="true", the server needs to have both, when I say
exact="false", I might end up with just an URI instead. Is this correct?
Is there a way to say civic OR geo but no URI (without doing separate
requests for civic and geo) I have overlooked?

[MB] You are correct, there is no way to exclude the return of a
locationURI if one were available when you set exact="false".  Just as
there would be no way to say that you want either a locationURI or civic
and NOT geodetic. I would think it would be easier to just ignore the
locationURI that could possibly be returned if you just want the civic
or geo.  And, it would actually give you additional information if you
were to receive a locationURI and NOT receive either the civic or geo
that is preferred (i.e., wouldn't this save messaging if an
implementation had a preference for civic or geo, but could use the
locationURI as a backup.?)[/MB]

cheers
karl heinz

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Mar 2008 16:50:18 -0400

Cullen, Mary,

When I suggested the text for 10.1.1, para 3, I had momentarily 
forgotten about RFC 2818 and the iPAddress subjectAltName.  We do need 
slightly more than "Use RFC 2818", since RFC 2818 only applies to the 
HTTP binding, and we also want to say that the same checks should be 
available for other bindings.  I suggest that section 10.1.1 be 
condensed to the following:

"
This document assumes that the LIS to be contacted is identified either 
by an IP address or a domain name, as is the case for a LIS discovered 
via [ID.ietf-geopriv-lis-discovery].  When the HELD transaction is 
conducted using TLS [RFC2246], the LIS can authenticate its identity 
(either as a domain name or as an IP address) to the client by 
presenting a certificate containing that identifier as a subjectAltName 
(i.e., as an iPAddress or dNSName, respectively).  (In the case of the 
HTTP binding described above, this is exactly the authentication 
described by [RFC2818])  Any binding of HELD MUST be capable of being 
transacted over TLS so that the client can request the above 
authentication, and a LIS implementation for a binding MUST include this 
feature.  Note that in order for the presented certificate to be valid 
at the client, the client must be able to validate the certificate; in 
particular, the validation path of the certificate must end in one of 
the client's trust anchors, even if that trust anchor is the LIS 
certificate itself.
"

Good catch, Cullen, thanks.
--RB

> so this is all new text, with some new concepts. [/MB]

[RLB]
Cullen: Good point.  I had momentarily forgotten about RFC 2818 when I 
suggested this mechanisms, and in fact, your suggestion is what's 
actually in RFC 2818.  This part should just say "Use RFC 2818 
mechanisms to authenticate that the LIS you're talking to corresponds to 
the DNS name or IP address you used to contact it".
[/RLB]