[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
review of the geopriv radius location attributes draft
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
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>