[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS
On Sun 18 Feb 2007 02:13, Bernard Aboba wrote:
> Review of draft-ietf-geopriv-radius-lo-10.txt
>
> Overview comments:
>
> Overall, this document includes many normative statements relating
> to privacy in a number of sections. As it stands, this makes it very
> difficult to understand exactly what privacy support will be provided
> in various scenarios. I would strongly urge that these statements
> be consolidated into a single section.
>
> In terms of RADIUS protocol usage, there are a few problems
> (violation of a MUST NOT provision in RFC 3576, use of non-standard
> RADIUS data types, inappropriate use of complex attributes)
>
> There are also a lot of editorial issues that need to be cleaned up.
>
> Given everything, this document requires substantial work before
> it would be suitable for publication as an RFC.
>
> Section 1
>
> Wireless LAN (WLAN) access networks are being deployed in public
> places such as airports, hotels, shopping malls, and coffee shops by
> a diverse set of operators such as cellular network operators (GSM
> and CDMA), Wireless Internet Service Providers (WISPs), and fixed
> broadband operators.
>
> As noted later on, these attributes are not limited to use with WLAN
> networks, but the relationship to user location is probably stronger
> with WLAN or LAN access than other access types. I think you need
> to talk about this.
>
> When a user executes the network access authentication procedure to
> such a network, information about the location and ownership of this
> network needs to be conveyed to the user's home network to which the
> user has a contractual relationship.
>
> The use of the term "need" seems wrong here, since
> one of the goals of the document is to guard the privacy of location
> information, only providing it where there is "need to know".
>
> This document describes AAA attributes, which are used by a AAA
> client or a AAA proxy in an access network, to convey location-
> related information to the user's home AAA server.
>
> The use of the term "AAA" here is a bit confusing. If the attributes
> are applicable to both RADIUS and Diameter, this should be explicitly
> stated.
>
> Although the proposed attributes in this draft are intended for
> wireless LAN deployments, they can also be used in other types of
> wireless and wired networks whenever location information is
> required.
>
> I'd suggest this paragraph be combined with the first paragraph.
>
> Location information needs to be protected against unauthorized
> access and distribution to preserve the user's privacy. [10] defines
> requirements for a protocol-independent model for the access to
> geographic location information. The model includes a Location
> Generator (LG) that creates location information, a Location Server
> (LS) that authorizes access to location information, a Location
> Recipient (LR) that requests and receives information, and a Rule
> Maker (RM) that provides authorization policies to the LS which
> enforces access control policies on requests to location information.
>
> I would talk a bit more about the privacy model in general terms, such
> as what protections it is designed to provide.
>
> Section 2
>
> Based on 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 authentication to the AAA server
> location information is sent from the AAA client to the AAA server.
>
> Earlier, the document refers to use by a AAA proxy. Could you say
> a few words about where the information originates (e.g. may originate
> on the NAS, or may be added a proxy). Somewhere it is also worth
> stating that existing RADIUS attributes may also provide location
> information (e.g. NAS-Identifier).
>
> The authenticated identity might 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 binding between a device and a user exists) there is no
> assurance that a particular real-world entity (such as a person)
> triggered this process.
>
> Is the distinction between a user, device or machine identity
> relevant for the purposes of a privacy discussion? This paragraph
> leaves me wondering whether there is a legal distinction that
> is relevant to the protocol design.
>
> 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 apply
> (and device or network privacy might be the better term).
>
> Maybe you need to define the term "user" in the document as being
> either a user, device or machine identity in order to clarify this.
>
> Furthermore, the authors believe that there is a relationship between
> the NAS (or other nodes in the access network) and the location of
> the entity that triggered the network access authentication, such as
> the user.
>
> Why? If the NAS is a VPN server, then the user might be located halfway
> around the world. Might make more sense to say "depending on the
> type of access being provided, there may be a close relationship...."
> You might give examples:
>
> 1) WLAN has limited range when deployed with an omni-directional
> antenna, so user is probably close to the NAS in geospatial
> (but not necessarily civil) terms. Also, some WLAN
> access points can use "time of arrival" or other processing
> techniques to determine user location accurately;
> 2) In LAN access, the user can't be further away from the switch
> than cable length will permit.
> 3) Dialup or VPN user could be very far away from the NAS;
>
> If you talk about this a bit, it might help clarify why the document
> is mostly for WLAN/LAN access.
>
> The NAS might in many cases know the location of the end
> host through various techniques (e.g., wire databases, wireless
> triangulation). Knowing the location of a network (where the user or
> end host is attached) might in many networks also reveal enough
> information about the location of the user or the end host. A
> similar assumption is also made with regard to the location
> information obtained via DHCP (see for example [4]).
Also, If you consider 3G/GPRS networks, the NAS that a user connects to is
typically located in the main operations center of the operator which means
that the users location if most likely somewhere inside that country,
however when the user roams (A large and growing number of operator have
GPRS/3G roaming agreements) they could in-fact be connecting via an operator
on the other side of the world, yet the NAS at most will know the IP address
of the SGSN (another device on GSM networks is involved in the whole GPRS
process, of which each operator has at least one) and will not have an real
idea where the user is at all...
Other devices in the network (Billing systems etc) may have an "better" idea
of where the user is (the country for example..) but they also may not know
this information until several weeks or months later (when billing
information is exchanged between operators)
Cheers
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
--
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/>