[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Radius-Geopriv: Whose location?
hi all,
this mail tries to resolve the issue raised by joel:
[Joel M. Halpern]
Rationale/Explanation of issue: The location of a user is very different
from the location of an access device.
Length description of problem:
The document states that it provides the location of the access device
providing network service. The document then goes on to describe this as
"the users location". The document even describes this location as being
useful for services other than charging (cf section 4.2). However, what is
needed for accounting is very different from the location for service
delivery. The correlation between the two depends many factors outside of
the scope of this draft. Mixing the two is not helpful.
The information format in fact seems designed to provide not the access
device location, but the location of the subscriber.
It is also likely that if access identification is desired, geographic
location will often not be the correct mechanism.
Requested change:
Decide whether this document is intended to provide subscriber location
(which is rarely directly useful for AAA), or access device / network
location information. In either case, remove the inappropriate material.
If access device identification is desired, please indicate why
operator defined tokens are not sufficient. And reference where such
tokens are when they are needed.
[hannes] to clarify this issue i have added some text to the terminology
section:
"
Based on the availability of today's protocols we assume that the
location information is provided by the access network where the end
host is attached. As part of the network attachment, which includes
the execution of an authentication and authorization protocol
exchange, authentication is accomplished. The authenticated identity
can refer to a user, a device or something else. Although there
might often be a user associated with the authentication process
(either directly or indirectly; indirectly when a one-to-one
relationship between a device and a user exists) there is no
assurance that a particular real-world entity (such as a person)
triggered this process. Since location based authorization is
executed based on the network access authentication of a particular
"user" it might be reasonable to talk about user's privacy within
this document even though scenarios exist where this might not be
true (and device or network privacy might be the correct term).
Furthermore, the authors believe that there is a relationship between
the location of the network and the location of the entity that
triggered the network access authentication. Knowing the location of
a network (where the user or end host is attached to) might in many
networks also reveal the location of the user or end host. In some
networks it is even possible to provide a more fine-grain granular
location of the user or end host. A similar assumption is also made
with regard to the location information obtained via DHCP (see for
example [4]). This information might be used by applications in
other protocols (such as SIP) to indicate the location of a
particular user even though the location "only" refers to the
location of the network or equipment within the network. The
assumption here is also that the location of the network has some
relationship to the location of the end host (and subsequently to a
user). This assumption might not hold in all scenarios but seems to
be a good approximation.
Please note that the authors use the term end host or user
interchangable with respect to the used identities as part of the
network access authentication. To cover the worst case the term
'user' is used whenever the privacy of the user could potentially be
compromised.
"
do you think that this would work for you?
ciao
hannes
--
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/>