[Geopriv] Comment for draft-thomson-geopriv-location-dependability-00.txt

[Hannes Tschofenig <[e-mail]>]

I have read this interesting draft and I have a few high-level comments.

Section 2: Goals

FYI, the reference to I-D.ietf-geopriv-l7-lcp-ps needs to be updated to 
[I-D.barnes-geopriv-lo-sec] since we moved the terms and the security 
related context.

Section 2.1: Non-Goals

This section has not helped me to understand what you do not want todo.

Section 5.1: 'entity' Attribute

"
 If the LIS is able to authenticate the Target, and the Target grants
   permission to the LIS to use this field, the LIS can include this
   information in the "entity" field.
"

Does HELD provide such a capability to authenticate the end host?

"
  Presentity identifiers can be reused for the same Target, provided
   that the LIS is able to verify that the Target is the same.  This
   depends on the means by which location is acquired from the LIS; if
   session data that links subsequent requests exists, the LIS MAY reuse
   the presentity identifier.  Note that the the Target can initiate a
   new session to ensure that a new identifier is generated and thereby
   ensure that their previous and current positions cannot be correlated
   using the presentity identifier.
"

Is it correct to assume that the "session" concept in HELD refers to the 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-00.txt
?

Whatever mechanism you use I believe that you have to allow the end host 
to indicate that it does not want to utilize the capability of 
correlating identifiers. 

"
  This does not prevent the use of a "real" presentity in this field.
   If the LIS is able to authenticate the Target, and the Target grants
   permission to the LIS to use this field, the LIS can include this
   information in the "entity" field.  These conditions are hard to
   meet, which leads to two alternative means of including Target
   identity, described in the following sections.
"

This seems to be focused on HELD, right? If that's the case then there 
is no way for the LIS to authenticate my real presence identity. How 
does the Target grant a permission to the LIS to use a "real" identity?


"
  To achieve this linkage between location object and the Target's
   identity, the Target sends its identity to the LIS.  The LIS includes
   this identifier in the signed location object, effectively linking
   the identity to the location information.
"
"
   The LIS is not expected to authenticate this identity information,
   although it MAY do so.  This means that an attacker within the
   network could request a signed location object with any identity they
   choose.  However, the location object could only be used by an entity
   that can prove that they have the chosen identity, which limits the
   number of potential attackers.
"

I suspect that these paragraphs are not really applicable given that 
Section 5.3 says that you provide the hash of the user identity rather 
than the plaintext identity itself.

I like Section 5.3. It obviously requires a deep application knowledge 
since you need to put the correct address in there that will be later 
seen and authenticated by the Location Recipient.
The problem is that the hash of the identity is always the same (unless 
you change your identity). That obviously provides a good opportunity 
for linkability.

I am not sure what you want to say with Section 5.4. "Authenticated 
Identity".
The same is true for Section 5.5 "Multiple Identity Attack".

Section 6:

"
 This element is used in
   addition to a randomized "entity" attribute for several reasons: a
   randomized "entity" attribute can be used to detect replays; the
   identity is not necessarily authenticated; and the content can be
   other than a presentity identifier.
"
I would put the hashed identifier into the entity field but add a new 
"replay protection" element to store a randomized value.

Section 6.1: I am not sure to what this info refers.

Section 6.3: I think that this is problematic. Does the client has a 
chance to control the inclusion of this attribute? What identities are 
actually authenticated?

I cannot speak too much about the XPATH usage.

I believe there is a chance to shorten the draft considerably and make a 
couple of things more precise.

Ciao
Hannes



_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv