Subject: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

From: Ben Campbell <[email-masked]>
Date: Thu, 4 Jun 2009 17:58:14 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-geopriv-http-location-delivery-14
Reviewer: Ben Campbell
Review Date: 2009-06-04
IETF LC End Date: 2009-06-09
IESG Telechat date: (if known)

Summary:

This draft is ready for publication as a proposed standard. I have a  
few editorial and clarity comments that might could slightly improve  
the draft, but can safely be ignored. Additionally, I have one comment  
highlighting a "feature" that is not necessarily a problem, but is  
architecturally important enough that I want to make sure the IESG  
thinks about it.

Major issues: None.

Minor issues:

-- There is one feature of HELD that the ADs should explicitly think  
about: The HTTP binding forbids LIS reliance on HTTP digest or basic  
authentication. If I understand correctly, this means effectively that  
the _only_ method for client authentication is the built in reverse  
routeability test. I am agnostic as to whether this is sufficient.

Nits/editorial comments:

-- section 4, paragraph 1:

Please expand (and reference) PIDF-LO on first mention.

-- Section 6.2, value list:

-- In my previous review, I was confused as to the relationship  
between the geodetic/civic and LoBV/LoBR choices. I think it's worth  
some clarification in this section that geodetic and civic imply LoBV.  

-- section 9.3, 5th paragraph: "A temporary spoofing of IP address  
could mean that a device could request a Location Object or Location  
URI that would result in another Device's location."

It might be worth clarifying that (if I understand correctly) that  
this is more than a spoofing attack, in that the attacker must not  
only spoof its source address, but must be able to receive packets  
sent to the spoofed address?

-- same paragraph: "... re-use of the Device's
    IP address could result in another Device receiving the original
    Device's location rather than its own location."

It seems like this problem is pretty unlikely to occur by _accident_  
when HELD is used over TCP (the only binding right now), right? And  
certain not to happen over TLS? Might be worth a "mitigating" mention.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 05 Jun 2009 09:43:58 -0400

Ben,

Thanks for your review.  With respect to the HTTP issue you raise, is 
your claim that the HTTP binding prevents the use of Digest or Basic 
based on this sentence from Section 6.3?

"
HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
"

If so, then I think that's a misinterpretation that calls for a 
clarification. The authors should feel free to correct me, but I think 
that HTTP-level errors (e.g., the need for authentication, or even a LIS 
not listening at a given path) can still generate other HTTP response 
codes (e.g., 401 or 404).  It's just that if the only thing that's gone 
wrong is at the HELD layer -- if it's the positioning that failed, not 
the communications -- then you have to use a 200.

Assuming that all the above is accurate, proposed text:
"
HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response. 
(Other response codes may still be generated at the HTTP layer, if the 
problem is with the HTTP part of the message, not the HELD part.  For 
instance, if the request needs to be authenticated with Basic or Digest 
authentication, the server may issue a 401 Unauthorized response as a 
challenge, or if the indicated path is not valid, then the server may 
issue a 404 Not Found.)
"

Cheers,
--Richard

Ben Campbell wrote:
> This draft is ready for publication as a proposed standard. I have a few 
> editorial and clarity comments that might could slightly improve the 
> draft, but can safely be ignored. Additionally, I have one comment 
> -- In my previous review, I was confused as to the relationship between 
> the geodetic/civic and LoBV/LoBR choices. I think it's worth some 
> clarification in this section that geodetic and civic imply LoBV.
> -- section 9.3, 5th paragraph: "A temporary spoofing of IP address could 
> mean that a device could request a Location Object or Location URI that 
> would result in another Device's location."
> 
> It might be worth clarifying that (if I understand correctly) that this 
> is more than a spoofing attack, in that the attacker must not only spoof 
> its source address, but must be able to receive packets sent to the 
> spoofed address?
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 5 Jun 2009 09:12:41 -0500

On Jun 5, 2009, at 8:43 AM, Richard Barnes wrote:

> Ben,
>
> Thanks for your review.  With respect to the HTTP issue you raise,  
> is your claim that the HTTP binding prevents the use of Digest or  
> Basic based on this sentence from Section 6.3?
>
> "

No, I based it on the last sentence, second paragraph in section 8:

"The LIS MUST NOT rely on device support for cookies [RFC2965] or use  
Basic or Digest authentication [RFC2617]."

It doesn't explicitly "forbid" the use of digest authn, but if it  
can't depend on client support, then it can't really base any decision  
on it.

> clarification. The authors should feel free to correct me, but I  
> think that HTTP-level errors (e.g., the need for authentication, or  
> even a LIS not listening at a given path) can still generate other  
> HTTP response codes (e.g., 401 or 404).  It's just that if the only  
> thing that's gone wrong is at the HELD layer -- if it's the  
> positioning that failed, not the communications -- then you have to  
> use a 200.
>
> (Other response codes may still be generated at the HTTP layer, if  
> the problem is with the HTTP part of the message, not the HELD  
> part.  For instance, if the request needs to be authenticated with  
> Basic or Digest authentication, the server may issue a 401  
> Unauthorized response as a challenge, or if the indicated path is  
> not valid, then the server may issue a 404 Not Found.)
> "
>
> Cheers,
> --Richard
>
>
>
>
> Ben Campbell wrote:
>> This draft is ready for publication as a proposed standard. I have  
>> a few editorial and clarity comments that might could slightly  
>> improve the draft, but can safely be ignored. Additionally, I have  
>> one comment highlighting a "feature" that is not necessarily a  
>> problem, but is architecturally important enough that I want to  
>> make sure the IESG thinks about it.
>> Major issues: None.
>> Minor issues:
>> -- There is one feature of HELD that the ADs should explicitly  
>> think about: The HTTP binding forbids LIS reliance on HTTP digest  
>> or basic authentication. If I understand correctly, this means  
>> effectively that the _only_ method for client authentication is the  
>> built in reverse routeability test. I am agnostic as to whether  
>> this is sufficient.
>> Nits/editorial comments:
>> between the geodetic/civic and LoBV/LoBR choices. I think it's  
>> worth some clarification in this section that geodetic and civic  
>> imply LoBV.
>> could mean that a device could request a Location Object or  
>> Location URI that would result in another Device's location."
>> It seems like this problem is pretty unlikely to occur by  
>> _accident_ when HELD is used over TCP (the only binding right now),  
>> right? And certain not to happen over TLS? Might be worth a  
>> "mitigating" mention.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 8 Jun 2009 13:35:28 -0500

The wording on this topic in this section and in the security section
(9.1) are not really as consistent as it should be in terms of normative
language - the security section describes the capabilities in terms of
what MUST be provided/implemented by a LIS and client implementation,
but not necessarily what MUST be used and the RECOMMENDED mechanism is
actually a "can", there are several lower case MUSTs, etc. Noting in
particular the MAY in terms of the client being able to use an external
mechanism. 
Also, note that the recommended mechanism is the authentication
mechanism as provided by TLS, so there's nothing unusual with this
approach (as I understand it since I'm not a security expert).   So, I
would propose to reword the text in section 9.1 as follows:

OLD:
   When the HELD transaction is
   conducted using TLS [RFC5246], 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 TLS [RFC2818].  If the client has
   external information as to the expected identity or credentials of
   the proper LIS (e.g., a certificate fingerprint), these checks MAY be
   omitted.  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.

NEW:

   When the HELD transaction is
   conducted using TLS [RFC5246], the LIS SHOULD 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 TLS [RFC2818]. 
   If the client has
   external information as to the expected identity or credentials of
   the proper LIS (e.g., a certificate fingerprint), these checks MAY be
   omitted.  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.

And the text that causes you concern in section 8 as:

OLD:
   The LIS MUST NOT
   rely on device support for cookies [RFC2965] or use Basic or Digest
   authentication [RFC2617].

NEW: 
   The LIS SHOULD NOT
   rely on device support for cookies [RFC2965] or use Basic or Digest
   authentication [RFC2617], but rather SHOULD use the mechanism
described 
   in section 9.1. 

I'll respond to your other comments separately.

Thanks,
Mary. 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 9:13 AM
To: Richard Barnes
Cc: General Area Review Team; Barnes, Mary (RICH2:AR00);
[email-masked]; [email-masked];
[email-masked]; [email-masked]; Cullen Jennings; [email-masked]
Subject: Re: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

It doesn't explicitly "forbid" the use of digest authn, but if it can't
depend on client support, then it can't really base any decision on it.

> that HTTP-level errors (e.g., the need for authentication, or even a 
> LIS not listening at a given path) can still generate other HTTP 
> response codes (e.g., 401 or 404).  It's just that if the only thing 
> that's gone wrong is at the HELD layer -- if it's the positioning that

> failed, not the communications -- then you have to use a 200.
>

> instance, if the request needs to be authenticated with Basic or 
> Digest authentication, the server may issue a 401 Unauthorized 
> response as a challenge, or if the indicated path is not valid, then 
> the server may issue a 404 Not Found.) "
>
> Cheers,
> --Richard
>
>
>
>
> Ben Campbell wrote:

>> the draft, but can safely be ignored. Additionally, I have one 
>> comment highlighting a "feature" that is not necessarily a problem, 
>> but is architecturally important enough that I want to make sure the 
>> IESG thinks about it.
>> Major issues: None.
>> Minor issues:
>> authentication. If I understand correctly, this means effectively 
>> that the _only_ method for client authentication is the built in 
>> reverse routeability test. I am agnostic as to whether this is 
>> sufficient.
>> Nits/editorial comments:

---

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Jun 2009 13:46:42 -0500

Hi Mary,

The part I was trying to highlight was the lack of client device  
authentication, not LIS authentication. If I read 9.1 right, it only  
covers authentication of the LIS. I assume there is no expectation  
that client devices present TLS certs to the LIS, right?

Again, I'm not saying that the lack of client device authentication is  
a problem. The reverse routeability aspect might be sufficient. I'm  
merely pointing it out to make sure people think about it.

On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:

> can't
>> think
>> the
>>> think

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 8 Jun 2009 13:55:16 -0500

Hi Ben,

Thanks for your third Gen-ART review of this document.  My responses are
inline below, with the exception of the Minor issue you highlight to
which I responded in a separate email.

Mary.  

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, June 04, 2009 5:58 PM
To: General Area Review Team; Barnes, Mary (RICH2:AR00);
[email-masked]; [email-masked];
[email-masked]
Cc: Richard Barnes; [email-masked]; Cullen Jennings; [email-masked]
Subject: Gen-ART LC Review of
draft-ietf-geopriv-http-location-delivery-14

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary:

Major issues: None.

Minor issues:

Nits/editorial comments:

[MB] Okay.

[MB] Okay, how about the following: 
OLD: 
   geodetic:  The LIS SHOULD return a geodetic location for the Target.
   civic:  The LIS SHOULD return a civic address for the Target.

NEW: 
   geodetic:  The LIS SHOULD return a location by value in the form of a

              geodetic location for the Target.
   civic:  The LIS SHOULD return a location by value in the form of
           a civic address for the Target.

[MB] That statement was intended to include both those items, I'd
propose to clarify as follows:
NEW: 
A temporary spoofing of IP address could mean that a device could
request a Location Object or Location URI that would result in receiving
another Device's location if the attacker is able to receive packets
sent to the spoofed address. 

It seems like this problem is pretty unlikely to occur by _accident_
when HELD is used over TCP (the only binding right now), right? And
certain not to happen over TLS? Might be worth a "mitigating" mention.
[MB] Certainly, it is fairly unlikely (if not impossible in most
situations), but the recommendations in the bullet points further reduce
the potential for problems in the off chance that this occurs.  It's not
entirely clear to me why you suggest this is certain not to happen over
TLS since this is talking about a device that has dropped and thus the
connection would drop and it would seem there's a window for another
device (although quite unlikely) to use that same IP address. But,
perhaps, qualifying the statement as follows would address your concern:
OLD:
  These exposures are limited by the following:

NEW: 
  While these situations are fairly unlikely to occur (in particular
with the use of TCP/TLS), the exposures can be further limited by the
following:

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 8 Jun 2009 14:12:21 -0500

Hi Ben,

So, you are talking about section 9.3 which does state that the LIS
ensures that the client is authenticated, per the following:

   "The LIS MUST
   verify that the client is the target of the returned location, i.e.,
   the LIS MUST NOT provide location to other entities than the target.

And the following: 
   A prerequisite for meeting this requirement is that the LIS must have
   some assurance of the identity of the client.  Since the target of
   the returned location is identified by an IP address, simply sending
   the response to this IP address will provide sufficient assurance in
   many cases.  This is the default mechanism in HELD for assuring that
   location is given only to authorized clients; LIS implementations
   MUST support a mode of operation in which this is the only client
   authentication.

And, then the text goes on to some of the other text in section 9.3 that
you had questions about that I responded to in a separate email.

So, I'm not certain I understand the problem IF I make the proposed
change to the sentence in section 8.

Mary. 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, June 08, 2009 1:47 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;

Hi Mary,

The part I was trying to highlight was the lack of client device
authentication, not LIS authentication. If I read 9.1 right, it only
covers authentication of the LIS. I assume there is no expectation that
client devices present TLS certs to the LIS, right?

Again, I'm not saying that the lack of client device authentication is a
problem. The reverse routeability aspect might be sufficient. I'm merely
pointing it out to make sure people think about it.

On Jun 8, 2009, at 1:35 PM, Mary Barnes wrote:

> (9.1) are not really as consistent as it should be in terms of 
> normative language - the security section describes the capabilities 
> in terms of what MUST be provided/implemented by a LIS and client 
> implementation, but not necessarily what MUST be used and the 
> RECOMMENDED mechanism is actually a "can", there are several lower 
> case MUSTs, etc. Noting in particular the MAY in terms of the client 
> being able to use an external mechanism.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Jun 2009 14:26:57 -0500

Again, my point was not to say that this was necessarily a problem--I  
highlighted it as something the IESG should think about, knowing that  
they have a big reading load. I guess my question is, is the statement  
that reverse routability provides "sufficient assurance in many  
cases", along with the fact that the HTTP binding explicitly  
discourages stronger client authentication mechanisms acceptable to  
them. If it is, I am fine with it, and the draft would not need a  
change. If on the other hand I have misunderstood something, that's  
different.

I am a little confused about the proposed change to section 8, though.  
It sounds like it is conflating LIS authentication with device  
authentication. To decompose your proposed language I read it as:

"The LIS SHOULD NOT ... use [device authentication mechanism], but  
rather SHOULD use [LIS authentication mechanism]"

Is it possible I am misunderstanding the direction of the client- 
server relationship in the HTTP binding? I was assuming the device to  
be the HTTP client and the LIS to be the HTTP server--do I have it  
backwards?

On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote:

> that
>>> is
>>>> worth
>>>> Location
>>>> _accident_

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 8 Jun 2009 16:21:05 -0500

I guess I'm still missing your original concern. But, one problem with
that sentence is that it's really out of context and would make more
sense if it were the first sentence in the last paragraph in section 8,
as that then leads to the text on the recommended mechanism (i.e., TLS).
The sentence in question was added in the -12 version when we added a
lot more text on HTTP guidelines and it likely should have been merged
then with the existing text related to security mechanisms. 

You are correct that the device is the HTTP client the the LIS the HTTP
server, so the reference should have been to section 9.3 - sorry.

Mary. 
 
-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, June 08, 2009 2:27 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Richard Barnes; General Area Review Team;

Again, my point was not to say that this was necessarily a problem--I
highlighted it as something the IESG should think about, knowing that
they have a big reading load. I guess my question is, is the statement
that reverse routability provides "sufficient assurance in many cases",
along with the fact that the HTTP binding explicitly discourages
stronger client authentication mechanisms acceptable to them. If it is,
I am fine with it, and the draft would not need a change. If on the
other hand I have misunderstood something, that's different.

Is it possible I am misunderstanding the direction of the client- server
relationship in the HTTP binding? I was assuming the device to be the
HTTP client and the LIS to be the HTTP server--do I have it backwards?

On Jun 8, 2009, at 2:12 PM, Mary Barnes wrote:

> And, then the text goes on to some of the other text in section 9.3 
> that you had questions about that I responded to in a separate email.
>

>>  conducted using TLS [RFC5246], 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  

>> identity,  either as a domain name or as an IP address, to the client

>> by  presenting a certificate containing that identifier as a  

>> described  in section 9.1.
>>
>>

>> can't depend on client support, then it can't really base any 
>> decision on it.
>>
>>>
>>> "
>>>

>>>> about: The HTTP binding forbids LIS reliance on HTTP digest or 
>>>> basic authentication. If I understand correctly, this means 

>>>> -- same paragraph: "... re-use of the Device's IP address could 
>>>> result in another Device receiving the original Device's location 
>>>> rather than its own location."

>>>> "mitigating"
>>>> mention.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Jun 2009 14:10:49 -0500

Hi Mary,

Responses inline. I've edited out sections that I think we have  
closure on.

On Jun 8, 2009, at 1:55 PM, Mary Barnes wrote:

[...]

> between

Thanks, that helps.

> could
> this

Thanks, that helps.

> with the use of TCP/TLS), the exposures can be further limited by the

On reflection, it's probably better to err on the side of caution  
here, rather than try to dilute the warning. I withdraw my comment,  
and think the original text is fine here. Sorry for the flip-flop.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Jun 2009 14:21:59 -0500

> then with the existing text related to security mechanisms.

Remember, my concern was not a question of clarity of text--rather it  
was an attempt to shine a light on what I think is an important  
architectural "feature" that some people may find controversial.  It's  
not that I thought it was buried or something--I just know the IESG  
has a really big reading load, and thought this feature deserved an  
"in case you didn't notice" sort of comment. Maybe I caused confusion  
by including this in the "minor issue" section--I did not mean it to  
be so much an "issue" as a "comment".

In particular, I read the text to fairly clearly say that, for the  
HTTP binding, the LIS cannot use digest or basic authentication, and  
that the only current device authentication mechanism is the inherent  
reverse routability check. Unless that was somehow _not_ the intent,  
then I don't think the text requires clarification per se. Some  
motivating text might be helpful, i.e. the part about having to work  
with clients with no previous relationship and therefore no shared  
secret.

OTOH, Martin, in a separate email, indicated that he read the text to  
say the LIS cannot _rely_ on digest or basic authentication, which is  
subtly different. If that was the intent, then I think the text _does_  
need clarification.

> cases",
> server