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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, 8 June 2009 8:39 AM
To: ietf@ietf.org
Subject: Review of draft-ietf-geopriv-http-location-delivery

 

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.

	

 

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