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