Subject: Review of draft-ietf-geopriv-http-location-delivery

From: Bernard Aboba <[email-masked]>
Date: Sun, 7 Jun 2009 15:39:09 -0700

Review of "HTTP Enabled Location Delivery (HELD)"
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery

As stated in Section 1 of the document:

"This document describes a protocol that can be used to
acquire Location Information (LI) from a LIS within an access
network.

This specification identifies two types of location information that
may be retrieved from the LIS.  Location may be retrieved from the
LIS by value, that is, the Device may acquire a literal location
object describing the location of the Device.  The Device may also
request that the LIS provide a location reference in the form of a
location URI or set of location URIs, allowing the Device to
distribute its LI by reference.  Both of these methods can be
provided concurrently from the same LIS to accommodate application
requirements for different types of location information."

In the case of location by value, the object returned in the HELD
response (a PIDF-LO) is subsequently conveyed using a protocol
such as that defined in draft-ietf-sip-location-conveyance
In the case of location by reference, the reference will be to a
PIDF-LO object.

While this document does define the protocol by which the PIDF-LO
or reference is conveyed, it does not provide much in the way of
guidance as to how identity-related fields within the PIDF-LO
are filled in, or how those fields potentially relate to aspects
of the protocol identification and/or authentication mechanisms.

As a result, it seems difficult to analyze the protocol with respect
to its security properties, or even with respect to conformance to
requirements established in [RFC3693] and [RFC4119].

Specifically, Section 10 Examples does not include any examples
that utilize the identification fields supported by the PIDF-LO
object format as indicated by [RFC4119] and [RFC5491], such as
entity, device or deviceID.

Section 9 does not talk about the linkage between these parameters
and the security authentication mechanisms, leaving it unclear as to
whether it is possible to launch a cut and paste attack -- insertion of
a PIDF-LO returned to entity A into a message sent by another entity B.
Even if the returned PIDF-LO object or reference were to be signed
by the LIS and subsequently verified, such an attack would not appear to be
precluded unless the identity of requester A were to be bound to the
returned PIDF-LO in some way.

Identification and Authentication facilities

Section A.1 describes the use of the IP address as the primary source
of identity:

"  HELD uses the IP address of the location request message as the
   primary source of identity for the requesting device or target.  This
   identity can be used with other contextual network information to
   provide a physical location for the Target for many network
   deployments.  There may be network deployments where an IP address
   alone is insufficient to identify a Target in a network.  However,
   any necessary identity extensions for these networks is beyond the
   scope of this document."

Based on this, one might assume that the IP address would be placed into the
deviceID field of the PIDF-LO object, but the document does not say this
explicitly.

Section 8 of the document states:

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

The logic relating to the  prohibition on the use of HTTP authentication is not
explained.  Does this prohibition apply to all forms of identity that can be
used by HELD, or only to deployments utilizing IP address identification?
Is the prohibition related to the need to support unauthenticated
emergency calling?  If so, then it's worth noting some of the issues that
have arisen:
http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html

Requirements

"A Presence-based GEOPRIV Location Object Format" [RFC4119] Section 2.1 states:

"  The GEOPRIV requirements [10] (or REQ for short) specify the need for
   a name for the person, place or thing that location information
   describes (REQ 2.1).  PIDF has such an identifier already:  every
   PIDF document has an "entity" attribute of the 'presence' element
   that signifies the URI of the entity whose presence the document
   describes.  Consequently, if location information is contained in a
   PIDF document, the URI in the "entity" attribute of the 'presence'
   element indicates the target of that location information (the
   'presentity').  The URI in the "entity" attribute generally uses the
   "pres" URI scheme defined in [3].  Such URIs can serve as unlinkable
   pseudonyms (per REQ 12).

   PIDF optionally contains a 'contact' element that provides a URI
   where the presentity can be reached by some means of communication.
   Usually, the URI scheme in the value of the 'contact' element gives
   some sense of how the presentity can be reached; if it uses the SIP
   URI scheme, for example, SIP can be used, and so on.  Location
   information can be provided without any associated means of
   communication.  Thus, the 'contact' element may or may not be
   present, as desired by the creator of the PIDF document."

This left me wondering whether the entity or contact elements might be
filled in based on identification provided within the HELD exchange.
My guess was no, but I was not sure.  If a signed PIDF-LO were to be
returned and these elements were not filled in, would they be added
later, after the signature was applied?

"Geopriv Requirements" [RFC3693] Section 7.1 states:

"  Req. 2.  (Location Object fields) The Location Object definition MUST
      contain the following Fields, which MAY be optional to use:

      2.1) Target Identifier

      2.2) Location Recipient Identity
      This identity may be a multicast or group identity, used to
      include the Location Object in multicast-based using protocols.

      2.3) Location Recipient Credential

      2.4) Location Recipient Proof-of-Possession of the Credential"

Based on the document, I am not clear how these requirements are met by
HELD.

"Threat Analysis of the GEOPRIV Protocol" RFC 3694 Section 6.3.2 states:i

6.3.2.  Mutual End-Point Authentication

   Authentication is crucial to the security of LI during transmission.
   The Location Server must be capable of authenticating Location
   Recipients to prevent impersonation.  Location Generators must be
   capable of authenticating Location Servers to ensure that raw
   location information is not sent to improper entities.  Additionally,
   Location Servers must be able to authenticate Rule Makers to ensure
   that unauthorized entities cannot change Rules.

Based on the current document, I am presuming that IP address identification
is being used to meet this requirement.  However, it seems like somewhat
of a stretch to apply the term "authentication" to this.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Jun 2009 00:51:04 -0500

Hi Bernard,

From your email I can see that you’ve tried quite hard to understand how this fits together.  Unfortunately, I can see that there is a small omission in the document in this regard.  I don’t believe that it’s serious [1], but it would be good to avoid any potential confusion.

From your email and our other discussions I’ve identified three items that need addressing.

1.       The expectations placed on the relationship between the Device and the access network (or LIS) are not made explicit. The document relies on implication and referenced documents to establish this.  For such an important concept, this needs to be clearer.

2.       The role of identity in the request needs to be established.  More specifically, whether authentication of the device is permitted/required beyond the return reachability test.  The document mandates that HTTP authentication is not relied upon, does not provide justification.  Putting this in context (see #1) and providing rationale for this and should address this concern.

3.       Further to that, there is no guidance on how to populate the response with regards to the many possible identity parameters in PIDF.  PIDF-LO, as a PIDF extension, inherits a great many options.  Some recommendation would be helpful.  For privacy reasons, avoiding use of any of these identifiers would be best, leaving the binding of identity and location to the using protocol.  That means that identity is limited to the mandatory presentity identifier.  Using a unlinked pseudonym (c.f. RFC 3693) for this ensures that identity is not distributed by the LIS along with location information.

It would not be reasonable to expect a reader to come to these same conclusions.

I suggest that the following edits are made to address these shortcomings.  These changes reflect experience with implementation of the protocol.

To address #1, make the following statement in Section 3 (the first paragraph or just after seems suitable):

New:

   This document assumes that the Device and Access Provider have no
   prior relationship other than what is necessary for the Device to 
   obtain network access.

To address #2, the prohibition on authentication can be softened somewhat in Section 8.  I’ve changed the focus to what the device is required to support.  Better rationale for this prohibition should give policy makers better guidance:

Old:

   The LIS MUST NOT
   rely on device support for cookies [RFC2965 <http://tools.ietf.org/html/rfc2965> ] or use Basic or Digest
   authentication [RFC2617 <http://tools.ietf.org/html/rfc2617> ].

New:

   A Device that conforms to this specification is not required to 

   support HTTP authentication [RFC2617 <http://tools.ietf.org/html/rfc2617> ] or cookies [RFC2965 <http://tools.ietf.org/html/rfc2965> ].  Because

   the Device and LIS do not necessarily have a prior relationship and 

   this protocol is suited to a range of networks, there is no common 

   authentication mechanism that can be used for any access network.  

   A LIS MUST NOT deny access to location information based on the 

   absence of Device authentication, unless it can be guaranteed that

   all Devices in the access network are aware that authentication is

   required.

I could go on and say that local policy might state otherwise, but I’m sick of saying that at every turn.

To address #3, we extend Section 6.6:

New:

   The LIS MUST NOT include any means of identifying the Device in
   the PIDF-LO unless it is able to verify that the identifier is 
   correct and inclusion of identity is expressly permitted by a Rule
   Maker.  Therefore, PIDF parameters that contain identity are either
   omitted or contain unlinked pseudonyms [RFC3693].  A unique,
   unlinked presentity URI SHOULD be generated by the LIS for the
   mandatory presence “entity” attribute of the PIDF document.  
   Optional parameters such as the “contact” element and the
   “deviceID” element [RFC4479] are not used.

I hope that these changes address your concerns.

Of course, while I’ve done what I can to wordsmith these for clarity, I expect that there is room for improvement.

Regards,

Martin

[1] In the location configuration use case, identity is typically ignored.  Location by reference is where the complications arise.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Monday, 8 June 2009 8:39 AM
To: [email-masked]
Subject: Review of draft-ietf-geopriv-http-location-delivery

Requirements

      2.1) Target Identifier

 

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Tue, 16 Jun 2009 00:35:16 -0400

Martin:

Regarding #2, I would feel more comfortable with your text if it had the 
strength of a RECOMMENDATION.  Making a specific policy configuration a 
  MUST NOT doesn't make sense.  Also, this discussion is missing the 
possibility of client authentication in TLS, which falls under the same 
recommendation.  Suggested text follows:

> Old:
> 
> The LIS MUST NOT rely on device support for cookies [RFC2965] or use 
> Basic or Digest authentication [RFC2617].
> 
> 
> New (Thomson):
> 
> support HTTP authentication [RFC2617] or cookies [RFC2965].  Because

New (Barnes):

A Device that conforms to this specification MAY omit support for HTTP 
authentication [RFC2617] or cookies [RFC2965].  Because the Device and 
the LIS may not necessarily have a prior relationship, it is RECOMMENDED 
that that the LIS not require a Device to authenticate, either using the 
above HTTP authentication methods or TLS client authentication.

--Richard

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Jun 2009 23:19:34 -0700

> above HTTP authentication methods or TLS client authentication.

The previous text related to LIS behavior (e.g. not refusing authorization
based on lack of authentication).  This suggested text relates to the 
client (e.g. that it may omit support for HTTP authentication, TLS
client auth or cookies). 

In the previous text, the LIS could challenge the client, but was 
restricted in its options if the client failed authentication.  In this
text, the LIS is recommended not to even try to authenticate
the client. 

A compromise approach would be for the LIS to make the choice 
on whether to challenge the device based on the nature of the request. 
Devices only supporting requests that cannot be challenged (e.g. 
requests utilizing implicit IP address identification)
could omit support for HTTP authentication.  However, if
a device were to make a request of another type (e.g. utilizing
HELD extensions), the LIS could challenge it and therefore the device 
would need to support HTTP authentication.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 16 Jun 2009 01:45:09 -0500

That's not just a good compromise, I think it's necessary.

However, I should point out that this document only describes the former (implicit IP identification) and therefore I'm happy to defer dealing with the other in extension documents.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 16 Jun 2009 18:04:00 -0500

This is probably better than my phrasing, particularly the MAY piece.

I would like to make the consequences of ignoring the "SHOULD" clear though:

   A Device that conforms to this specification MAY choose not to
   support for HTTP authentication [RFC2617] or cookies [RFC2965].
   Because the Device and the LIS may not necessarily have a prior
   relationship, the LIS SHOULD NOT require a Device to authenticate,
   either using the above HTTP authentication methods or TLS client
   authentication.  Unless all Devices that access a LIS can be expected
   to be able to authenticate in a certain fashion, denying access to
   location information could prevent a Device from using
   location-dependent services, such as emergency calling.

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, 16 June 2009 2:35 PM
> To: Thomson, Martin
> Cc: Bernard Aboba; [email-masked]; Cullen Jennings;
> [email-masked]
> Subject: Re: Review of draft-ietf-geopriv-http-location-delivery
> 
> Martin:
>