ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS

2007-03-01 07:09:28
This is a repost of 2 messages previously sent to the ietf(_at_)ietf(_dot_)org list which did not make it to the list. They are being re-sent here at the request of the RAI ADs.

========================================
To: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS
From: "Bernard Aboba" <bernard_aboba(_at_)hotmail(_dot_)com>
Date: Sat, 17 Feb 2007 16:13:44 -0800
Cc: radiusext(_at_)ops(_dot_)ietf(_dot_)org, secdir(_at_)mit(_dot_)edu

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]).

The DHCP case might be analagous to WLAN/LAN, but it is not analagous
to the case of VPN or dialup access where the NAS and user could be
separated by thousands of miles.

 This
 information might be used by applications in other protocols (such as
 SIP [11] with extensions [12]) 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.  This
 assumption might not hold in all scenarios but seems to be reasonable
 and practicable.

I think you need to say that the assumption can be presumed to hold
for certain values of the NAS-Port-Type attribute (e.g. LAN or
WLAN access).  In others it may not hold.

Section 3

 Location Objects, which consist of location information and privacy
 rules, are transported via the RADIUS protocol from the AAA client to
 the AAA server.  A few attributes are introduced for this purpose, as
 listed in Section 5, whereby delivery to the RADIUS server can happen
 during the authentication/authorization phase (described in
 Section 3.1), or in the mid-session using the dynamic authorization
 protocol framework (described in Section 3.2).  This section
 describes messages flows for both delivery methods.

To me, it makes more sense to talk about what packets the location
information can be delivered in, rather than "phases".  For example,
location is delivered in Access-Request or Accounting-Request packets.
Whether the Access-Request was triggered by dynamic authorization or
a new user login is not important.  Also, this paragraph seems to suggest
that dynamic authorization is required to obtain mid-session location
information.  Since location can be provided interim accounting packets,
this is not really true.  Perhaps the point is that dynamic authorization
allows the information to be provided on demand.

Section 3.1

 Figure 1 shows an example message flow for delivering location
 information during the network access authentication and
 authorization procedure.  Upon a network authentication request from
 an access network client, the NAS submits a RADIUS Access-Request
 message that contains location information attributes among other
 required attributes.  These attributes are added based on various
 criteria (such as local policy, business relationship with
 subscriber's home network provider and in case of location
 information also by considering privacy policies).

Even though Figure 1 mentions "out of band agreement" the text doesn't
elaborate on what this means.

Since Figure 1 shows location information provided in
an Accounting-Request, the first sentence isn't quite right.
Given the privacy issues, I think you need to qualify what
"location information" means in the second sentence. Do you
mean that the user location is being supplied by the NAS?
I think you need to say something about the default settings
(e.g. location provided, or not?)  Backward compatiblity issues
also probably deserve some discussion here. You might say
a few words about when this flow might occur (e.g. challenge-incapable
NAS).

Figure 1 uses the term "Network Access Client" which isn't
defined in terminology or used in other RADIUS RFCs.  I would change
all uses of this term to "User".

 If the AAA server needs to obtain location information also in
 accounting messages then it needs to include a Requested-Info
 attribute to the Access-Accept to express that is desired (if privacy
 policy allow it) and the Network Access Server SHOULD then include
 location information to the RADIUS accounting messages .

I think you should say something about the packets within which the
location information can be delivered in Section 1.  Something like:
"This document enables a RADIUS server to request the delivery of
location information within Access-Request packets, or additionally,
within Accounting-Request packets."

Section 3.2

This section is problematic since it specifies RADIUS attribute
usage prohibited by RFC 3576 Section 3, which states:

 Where a Service-Type Attribute with value "Authorize Only" is
 included within a CoA-Request or Disconnect-Request, attributes
 representing an authorization change MUST NOT be included; only
 identification attributes are permitted.

If the desire is to change the location information being provided
(e.g. to turn on location in accounting packets, or deliver different
types of location) why couldn't a CoA-Request be sent without an
"Authorization-Only" Service-Type?  If the desire is to request
location immediately, couldn't this be encoded in the Request-Info
attribute?  There seem to be ways to achieve the goal without
violating RFC 3576.

Later on in the section, it is stated:

 Since location information can be sent in accounting records
 (including accounting interim records), RFC 3576 [5] is only needed
 for authorization changes.

Given this, it would appear that the need to obtain location mid-session
is best met by another technique, and that use of CoA-Request packets
is only a corner case.  Given that RFC 3576 is not widely implemented,
I'd expect the accounting approach to be more applicable, at least
without an explanation about why this isn't a good idea (e.g. might
not need location info with each interim accounting update).

Also, this section doesn't talk about when a RADIUS server can
send a CoA-Request containing a Request-Info attribute.  Wouldn't
this be restricted to cases where the NAS has previously included
a Location-Information or Challenge-Capable attribute?

Section 4

I'm not clear this section should exist as a standalone entity. It might
be best to delete Section 4.2 entirely and integrate Section 4.1 with
Sections 1 or 2.

Section 4.1

 The home network operator requires location information for
 authorization and billing purposes.  The operator may deny service if
 location information is not available, or it may offer limited
 service only.  The NAS delivers location information to the home AAA
 server.

 The location of the AAA client and/or the end host is transferred
 from the NAS to the RADIUS server (based on a pre-established
 agreement or if the RADIUS server asks for it under consideration of
 privacy policies).  The NAS and intermediaries (if any) are not
 allowed to use that information other than to forward it to the home
 network.

Are the terms "NAS" and "AAA client" used interchangeably here?  If so,
can we primarily use one term (NAS seems best)?

 The NAS and intermediaries (if any) are not
 allowed to use that information other than to forward it to the home
 network.

Intermediaries (e.g. AAA proxies) sometimes log Accounting-Request
packets, since they may need them for billing purposes.  Since billing is
one of the uses of location information, I don't think you can prohibit
that.  Also, what does it mean for the NAS to "use" location information?
Some NASes have stable storage, so they might write Accounting-Request
packets to stable storage prior to delivery.  Or they might retain
location information in memory.  Do you mean that that the NAS or proxies
can't provide the location information to unauthorized parties?  Or do you
mean that proxies MUST respect the privacy policies they receive from the
RADIUS server?

 The RADIUS server authenticates and authorizes the user requesting
 access to the network.  If the user's location policies are available
 to the RADIUS server, the RADIUS server MUST deliver those policies
 in an Access Accept to the RADIUS client.  This information MAY be
 needed if intermediaries or other elements want to act as Location
 Servers (see Section 4.2).  If the NAS or intermediaries do not
 receive policies from the RADIUS server (or the end host itself) then
 they MUST NOT make any use of the location information other than
 forwarding it to the user's home network.

I would name the specific attributes rather than just saying "location
policies".  You are essentially saying that some attributes MUST be
included in an Access-Accept packet.  The last sentence is somewhat
more specific than just saying "allowed to use that information".

 Location Information may also be reported in accounting messages.
 Accounting messages are generated when the session starts, stops and
 periodically.  Accounting messages may also be generated when the
 user roams during handoff.  This information may be needed by the
 billing system to calculate the user's bill.  For example, there may
 be different tariffs or tax rates applied based on the location.
 Unless otherwise specified by authorization rules, location
 information in the accounting stream MUST NOT be transmitted to third
 parties.

Most of this paragraph probably belongs in Section 1 of the document.
I'm unsure what the last sentence means.  I think that the part of
the last sentence from "location..." should probably be combined with
the next sentence, to clarify it:

 Location information in the accounting stream MUST only be sent in
 the proxy chain to the home network (unless specified otherwise).

For example, you might say "Location attributes contained within
Accounting-Request packets MUST only be made available to entities
on the proxy chain between the NAS and the home accounting
server."

Section 4.2

 Location Servers are entities that receive the user's location
 information and transmit it to other entities.  In this second
 scenario, Location Servers comprise also the NAS and the RADIUS
 server.  The RADIUS servers are in the home network, in the visited
 network, or in broker networks.

 Unless explicitly authorized by the user's location policy, location
 information MUST NOT be transmitted to other parties outside the
 proxy chain between the NAS and the Home RADIUS server.

 Upon authentication and authorization, the home RADIUS server MUST
 transmit the ruleset (if available) in an Access-Accept.  The RADIUS
 client, intermediate proxies are allowed to share location
 information if they received ruleset indicates that it is allowed.

Is a "Location Server" somehow different from an entity eligible
to receive location information as described in the previous section?
I'm unclear whether this section is saying anything different from
Section 4.1 with respect to handling of user location information.

Section 5.1

 The Operator-Name attribute SHOULD be sent in Access-Request, and
 Accounting-Request records where the Acc-Status-Type is set to Start,
 Interim, or Stop.

Is this attribute only sent in these packets?  If so, I would say:
"MAY only be sent in Access-Request and Accounting-Request..."

The Value type is restricted to use with Integers.  I think that we
are talking about a String here, no?

Section 5.2

 The Location-Information attribute SHOULD be sent in Access-Request
 and in Accounting-Request messages.  For the Accounting-Request
 message the Acc-Status-Type may be set to Start, Interim or Stop.

Is the intent that these attributes are only sent in Access-Request
and Accounting-Request messages?  If so, say "MAY only be sent in..."

I think you are talking about a String type attribute, not an integer,
right?

     The 16-bit unsigned integer value allows to associate
     the Location-Information attribute with
     Location-Info-Civic and Location-Info-Geo
     attributes.

This is not a complete sentence. I think you need to explain that
this attribute is used to provide information relating to the
information included in the Location-Info-Civic and
Location-Info-Geo attributes to which it refers (via the Index).

You should probably also state that this attribute is largely treated
as an opaque blob, like the Location-Info-Civic and Location-Info-Geo
attributes to which it refers.  As a result, it is not expected that
RADIUS servers will need to change code to receive this attribute
(although location applications would have to parse it).

Section 5.3

 Location-Info-Civic attribute SHOULD be sent in Access-Request and in
 Accounting-Request messages.  For the Accounting-Request message the
 Acc-Status-Type may be set to Start, Interim or Stop.

Change to "MAY only be sent..." if that is the intent.

Please change "Value" to "String".

     The 16-bit unsigned integer value allows to associate
     the Location-Info-Civic attribute with the
     Location-Information attributes.

Is there an implication that multiple Location-Information attributes
will have the same Index value?  That doesn't make sense to me.

Section 5.4

 Location-Info-Geo attribute SHOULD be sent in Access-Request, and
 Accounting-Request records where the Acc-Status-Type is set to Start,
 Interim or Stop if available.

Change to "MAY only be sent" if that is the intent.

Change "Value" to "String"

Section 5.5

Should the title be "Basic-Policy-Rules Attribute"?

 Policy rules control the distribution of location location
 information.  In some environments the the AAA client might know the
 privacy preferences of the user based on pre-configuration or the
 user communicated them as part of the network attachment.

This seems somewhat unlikely.  Do any existing access protocols support
user-provided privacy policies?  Or are we talking about generic
NAS privacy settings here?


 Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request,
 Access-Accept, an Access-Challenge, an Access-Reject and an
 Accounting-Request message.

I think you mean "MAY be sent in an Access-Request..."

 o  The AAA client SHOULD NOT attach location information in the
    initial Access-Request message but should rather wait for the AAA
    server to receive a challenge for location information.

I think you mean "for the AAA server to send an Access-Challenge..."

I think you are instead saying that "absent NAS settings
to the contrary, the default is..."  This probably should be clarified.

 o  If a roamig agreement or legal circumstances require the AAA

roamig -> roaming

    client to transfer location information in the initial Access-
    Request message to the AAA server (even though user specific
    policies are not available to the AAA client) then the access
    network attaches default authorization policies.

Are you saying that a Basic Policy Rules attribute MUST accompany
a Location-Information, Location-Info-Geo or Location-Info-Civic
attribute?

    The 'retransmission-allowed' flag MUST be set to '0' meaning
    that the location must not be shared with other parties (other than
    forarding them to the user's home network).

Are we saying that sharing of location information is controlled by the
're-transmission-allowed' flag and that parties MUST respect the flag?
This seems to contradict earlier MUST statements (which seem to imply
that sharing is not permitted, regardless of the flag value).

    In case the home
    network knows the user's privacy policies then these policies
    SHOULD be sent from the RADIUS server to the RADIUS client in a
    subsequent response message and these policies will be applied to
    further location dissemination and in subsequent RADIUS
    interactions (e.g., when attaching location information to
    Accounting messages).

What kind of response message?  Do you mean Access-Challenge here
or Access-Accept? Is there a reason why a RADIUS server would refuse
to disclose the user's privacy policies?  Should those policies
ever be considered private?

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags                        | Retention Expires            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Retention Expires                                            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Retention Expires             | Note Well                    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Note Well                                                    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The design of this attribute is problematic.  It is different from
other complex attributes in that it is sent by the RADIUS server,
and the inclusion of timestamps implies that it needs to be computed
dynamically, rather than treated as an opaque blob.

Also, there is an implication elsewhere in the document that the
retransmission bit needs to be respected by RADIUS proxies.  Most
existing RADIUS proxies cannot be configured to look at a specific
octet in an attribute, so this will not be possible.

Is there a reason that this could not be split into separate
unitary attributes, say, one for Retransmission, one for
Retention-Expires and another for Privacy-Policy?  The "Retention Expires"
attribute would a 64-bit
Long Integer, the Flags would be a 32-bit integer
and the Note Well would be a string.

This would be much more compatible with the design of existing
RADIUS servers and proxies and would enable privacy policies to
be respected.

Section 5.6

 The Extended-Policy-Rules attribute SHOULD be sent in an Access-
 Request, an Access-Accept, an Access-Challenge, an Access-Reject and
 in an Accounting-Request message whenever location information is
 transmitted.

Do we mean "MAY be sent" here?

I think "String" should be used here instead of "Value"

Why is Length >=4 (rather than 3)?

Section 5.7

Why is the Challenge-Capable attribute defined if it is always
set to 0?  Is the presence of the attribute sufficient to indicate
that the NAS is capable of being challenged so that the value
is irrelevant?

It would make more sense for this to be a 32-bit integer value
that only has a single value defined (1) indicating that the
NAS is capable of being challenged.

Section 5.8

 The Requested-Info attribute allows the RADIUS server to indicate
 whether it needs civic and/or geospatial location information of the
 NAS or the end host (i.e., the entities that are indicated in the
 Entity field of the Location-Information attribute).

Can't the RADIUS server ask for both NAS and end host information?

    2.  If the RADIUS server does not receive the requested
        information in response to the Access-Challenge (including the
        Requested-Info attribute) then the RADIUS server responds with
        an Access-Reject with an Error-Cause attribute (including the
        "Location-Info-Required" value).  Note that an Access-Reject
        message SHOULD only be sent if the RADIUS server MUST use
        location information for returning a positive access control
        decision.

The combination of SHOULD and MUST is confusing.  I think you mean to
say that an Access-Reject MUST only be sent if the RADIUS server
requires location information, but does not receive it, right?

    This is typically the case when location
    information is used for inclusion to the user's bill only.

Rephrase to "is used only for billing".

 If the RADIUS server does not send a Requested-Info attribute then
 the RADIUS client MUST NOT attach location information to messages to
 the RADIUS server.  The user's authorization policies, if available,
 MUST be consulted by the RADIUS server before requesting location
 information delivery from the RADIUS client.

But earlier it is said that the NAS may send location information by
default,
correct?  Or is an exception being made?

Figure 11 probably belongs earlier in the document.

 The Requested-Info attribute MUST be sent by the RADIUS server if it
 wants the RADIUS client to return civic and/or geospatial
 information.  This Requested-Info attribute MAY appear in the Access-
 Accept or in the Access-Challenge message.

Earlier it seems to imply that the NAS could sent location information
by out-of-band agreement.  So do you mean to say "in the absence of
an out-of-band agreement..."?

   Requested-Info (64 bits):

     This text field contains an integer value that encodes the
     requested information attributes.
     Each capability value represents a bit position.

It would be clearer to just say that the Requested-Info attribute
defines a bit field, where the information on CIVIC_LOCATION,
GEO_LOCATION, USERS_LOCATION, and NAS_LOCATION can be requested.

BTW, why is a 64-bit value required?  wouldn't 32-bits do as well?

Section 6

 If multiple
 Location-Information attributes are sent then they MUST NOT contain
 the same information.

Does this mean "must not have the same Index field?" Or does it mean
that they must not be identical in all respects?

Section 8.2

 o  The visited network is able to learn the user's identity.

I think you need a reference to NAI privacy (e.g. RFC 4282 or 4372) here.

Section 8.3

This section interrupts the document flow; it would better belong in
an Appendix.

Section 9

 Two entities might act as Location Servers as shown in Section 4, in
 Figure 16 and in Figure 17:

I think the sentence should end with a period, not a colon, right?

Section 9.1

 In this scenario it is difficult to obtain authorization policies
 from the end host (or user) immediately when the user attaches to the
 network.  In this case we have to assume that the visited network
 does not allow unrestricted distribution of location information to
 other than the intended recipients (e.g., to third party entities).
 When the AAA messages traverses one or more broker networks, the
 broker network is bound by the same guidelines as the visited network
 with respect to the distribution of location information.

Are you just saying that proxies need to respect the 'retransmission' bit?
In practice, they won't be able to do that because their policy engines
operate at the attribute, not bit level.  You'll need to have an
individual attribute for retransmission if you want this to work.

 The visited network MUST behave according to the following
 guidelines:

 o  Per default only the home network is allowed to receive location
    information.  The visited network MUST NOT distribute location
    information to third parties without seeing the user's privacy
    rule set.

Are you saying that the lack of distribution is the default, absent
receipt of privacy policies to the contrary?  I'd suggest that this
be stated earlier on.

 o  If the RADIUS client in the visited network learns the basic rule
    set or a reference to the extended rule set by means outside the
    RADIUS protocol (e.g., provided by the end host) then it MUST
    include the Basic-Policy-Rules and the Extended-Policy-Rules
    attribute in the Access-Request message towards the home AAA
    server.  Furthermore, the visited network MUST evaluate these
    rules prior to the transmission of location information either to
    the home network or a third party.  The visited network MUST
    follow the guidance given with these rules.

This seems quite unlikely.  Is there a reference to a specification
where this is proposed?

 o  If the RADIUS client in the visited network receives the Basic-
    Policy-Rules attribute with Access-Accept or the Access-Challenge
    message then the Basic-Policy-Rules MUST be attach in subsequent
    RADIUS messages which contain the Location-Information attribute
    (such as interim accounting messages).

attach -> attached
You need to include this statement in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a visited network?

 o  If the RADIUS client in the visited network receives the Extended-
    Policy-Rules attribute with Access-Accept or the Access-Challenge
    message then the Basic-Policy-Rules attribute MUST be attach in
    subsequent RADIUS messages which contain the Location-Information
    attribute (such as interim accounting messages).

attach -> attached

I think this needs to be included in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a Visited network?

Section 10

 If no authorization information is provided by the user
 then the visited network MUST set the authorization policies to only
 allow the home AAA server to use the provided location information.

This seems to contradict Figure 1 which shows location
information sent by out-of-band agreement without any policy attributes.

 It is necessary to use authorization policies to limit the
 unauthorized distribution of location information.  The security
 requirements which are created based on [10] are inline with threats
 which appear in the relationship with disclosure of location
 information as described in [33].  PIDF-LO [21] proposes S/MIME to
 protect the Location Object against modifications.  S/SIME relies on
 public key cryptography which raises performance, deployment and size
 considerations.  Encryption would require that the local AAA server
 or the NAS knows the recipient's public key (e.g., the public key of
 the home AAA server).

So are we saying that the location information attributes can be encrypted
in some cases, so that the privacy concerns are not applicable? But the
attributes don't support this, right?

 Knowing the final recipient of the location
 information is in many cases difficult for RADIUS entities.

Specifically, RADIUS clients only deal with RADIUS servers that are one
hop away.

=============================================
To: "Bernard Aboba" <bernard_aboba(_at_)hotmail(_dot_)com>
Subject: Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS
From: Peter Nixon <listuser(_at_)peternixon(_dot_)net>
Date: Sun, 18 Feb 2007 13:18:57 +0200
Cc: ietf(_at_)ietf(_dot_)org, radiusext(_at_)ops(_dot_)ietf(_dot_)org, 
sec-dir(_at_)mit(_dot_)edu
In-reply-to: <BAY117-F234F10A1C03CDC0AEEFF44938B0(_at_)phx(_dot_)gbl>
References: <BAY117-F234F10A1C03CDC0AEEFF44938B0(_at_)phx(_dot_)gbl>
User-agent: KMail/1.9.5

--------------------------------------------------------------------------------

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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>