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

"Thomson, Martin" <Martin.Thomson@xxxxxxxxxx> · 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] or use Basic or Digest
   authentication [RFC2617].

New:

   A
Device that conforms to this specification is not required to 

   support
HTTP authentication [RFC2617]
or cookies [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@xxxxxxxx
[mailto:ietf-bounces@xxxxxxxx] On Behalf Of Bernard Aboba

Sent: Monday, 8 June 2009 8:39 AM

To: ietf@xxxxxxxx

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]

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf