[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/>