Subject: [Geopriv] review of the geopriv radius location attributes draft

From: Jari Arkko <[email-masked]>
Date: Sun, 07 Nov 2004 17:19:05 +0200

Hannes et al,

I read your document on the way here and I think it
looks overall pretty good. I did have a couple of issues
that I wanted to raise, however. Here they are:

Substantial:

>    During a protocol run it is possible to return Location-Information
>    attributes which provide both location information elements.  If only
>    one location information element is provided then civil location MUST
>    be included in the request.  Additionally, geospatial location MAY be
>    provided.

Why is the civil location the one that needs to be always provided?
What if the access device is a mobile router that has a GPS attached
to it? Then it would have easy access to geospatial location but
the street address would require a huge database... Suggestion:
s/MUST/SHOULD/.

>        0 Reserved
>        1 Coffee Shop
>        2 Hotel
>        3 Airport
>        4 Mall
>        5 Restaurant
>        6 Bus
>        7 Library
>        8 Convention Center
>        9 School
>       10 Office
>       11 Airplane
>       12 Train
>       13 Ship
>       14 Educational Institute
>       15 Public Place
>       16 Other

This list feels a bit restrictive. What about "Car"
or "Healt Institute" or a coffee shop in an airport?
Suggestion: use the value set (and IANA process) from
draft-ietf-simple-rpid-04.txt section 3.5.

>      Time-to-Live (64 bits):
>        NTP timestamp for the 'time-to-live' field.

It is not clear to me if this field contains the "time
of death" of this information, or if this is some sort
of a duration value.

>      Method (8 bits):
>        Describes the way that the location information was
>        derived or discovered. The following values are currently
>        defined:
>        (0) Global Positioning System (GPS)
>        (1) GPS with assistance (A-GPS)
>        (2) Manual configured information
>        (3) Provided by DHCP
>        (4) Triangulation: triangulated from time-of-arrival,
>            signal strength or similar measurements
>        (5) Cell: location of the cellular radio antenna
>        (6) IEEE 802.11 WLAN access point

I'd like to make this list a bit more technology independent.
Or, its OK to give the location information determination
method (such as A-GPS), but I don't think you should tie it
to the access technology. Suggest changing the last 2 items
to "(5) Cell: location of the network's antenna". Or use
a macro/microcell distinction if that feels better.

>        0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Type        |  Length       | Code          |  Precision    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Sighting Time                                                 ~
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Sighting Time                                                 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Time-to-Live                                                  ~
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Time-to-Live                                                  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Method      |    Location-Info                             ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
>    time-to-live: This field gives a hint until when it should be
>       considered current.  Note that the time-to-live field is different
>       than the 'retention-expires' rule.  The data type of this field is
>       a string and the format is a 64 bit NTP timestamp [14].

The format, the talk about 64 bits, and "string" appear inconsistent.
I think you mean that the value is a 64 bit integer, not a string.

>      Note Well (variable):
>        This field contains a URI with human readable
>        privacy instructions.

Putting human readable strings about "policy" into max 253
byte fields sounds like a bad idea. Do we really need this?
Suggestion: remove or replace with a URL reference.

>    One way to ensure that the visited network and intermediate networks
>    are incapable to learn the user identity is to use EAP methods that
>    hide the user's identity either actively or passively.  Some EAP
>    methods (such as [16]) protect the user's identity against passive
>    adversaries by utilizing temporal identities.  In some cases the
>    visited network is still able to retrieve the plaintext identity of
>    the user and user identity confidentiality is only provided against
>    eavesdroppers at the wireless link.  Depending on the movement
>    patters of the user, the network topology and available roaming
>    agreements it is possible that a AAA broker is able to see both the
>    plaintext user identity and subsequent temporal identities.
>    Associating location information and the user identity is possible in
>    these cases.
> 
>    It is assumed that the true username is not carried within the
>    initial EAP-Identity Request/Response message exchange.  Support for
>    username privacy is supported with [17].
> 
>    For stronger security and privacy protection active user identity
>    confidentiality is highly suggested.  EAP methods such as [18] or
>    [19] provide such a protection.
> 
>    Unfortunately, most users are not educated about the importance of
>    user identity confidentiality and many EAP methods do not provide
>    active user identity confidentiality.  User identity confidentiality
>    is often treated as an exotic feature which mainly aims to prevent
>    eavesdroppers on the wireless link to learn the user identity of the
>    attached users.  Awareness for this threat type does often not exist.
>    In many cases it is even not possible for users to freely select
>    their favorite authentication and key exchange protocol (based on
>    their security requirements).  Instead the choice is often
>    predetermined by a given architecture.

There seems to be several problems with the above text. First of
all, I do not necessarily agree that [18] and [19] provide better
identity privacy than [16] and [17]. The privacy results depend
highly on configuration in all of the cases. For instance, [16]
says that clients can refuse to give a cleartext identity. Depending
on configuration and back-end side implementation, this is possible
in some networks and not possible in some others. Similarly, [18]
depends highly on the configuration of the trusted public key/CA.
If it is the single server's key then you are very safe. If its
the Verisign general purpose CA, anyone with a web side cert can
get you to reveal your identity.

The second issue is that this is IMHO the wrong document to
talk about identity privacy. You should talk about location
privacy, but identity privacy is a larger subject than
something that EAP methods can do. For instance, we have
identity privacy problems at the MAC, EAP, PPP, IP, ND,
and application layers.

Suggestion: remove the above text and associated references.

>    Knowing
>    the final recipient of the location information is in fact impossible
>    for RADIUS entities.

I'd like the document to talk a little bit about the use of
Diameter Redirect functionality and how that affects the issues
talked about in the security considerations section.

Editorial:

>       rule se.

s/se./set./

>    Location Information may also be reported in accouning messages.

s/accouning/accounting/

>       change their policies using the authroization framework defined in

s/authroization/authorization/

>    network to which the user has a contractal relationship.  The main

s/contractal/contractual/

>    F. Adrangi
>    Intel Corporatation

s/Corporatation/Corporation/

>    network to the home AAA server.  To embedd a Location Object into

s/embedd/embed/

>    location information.  The location infomration may refer to network

s/infomration/information/

>    The home network operator requires location informaion for

s/informaion/information/

>          is useable on constrained devices.

s/useable/usable/

>       issues in more details.

s/details/detail/

>    defined in Section 4.6 of [12] which is reused by [5] we define our

I think its 3.5 of [12], if you look at rev -04.

--Jari

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Nov 2004 13:53:49 -0500

Jari Arkko wrote:

...
> draft-ietf-simple-rpid-04.txt section 3.5.

I believe there was agreement on that earlier.

> a macro/microcell distinction if that feels better.

See also 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt, 
Section 2.2.3. While the two are the same, there is no reference to the 
PIDF-LO registry. Since it seems silly to have two different ones, this 
should be called out.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 07 Nov 2004 22:27:15 +0200

> I believe there was agreement on that earlier.

Great!

> PIDF-LO registry. Since it seems silly to have two different ones, this 

OK, I didn't realize that. Yes, it should be the same.

--Jari