Hi Bernard, I received your review. I need more time to process given its length. In fact the length of your review surprised me a bit given the long (>16 months) discussion we already had about the document. Ciao Hannes > -----Ursprüngliche Nachricht----- > Von: Bernard Aboba [mailto:bernard_aboba@xxxxxxxxxxx] > Gesendet: Donnerstag, 1. März 2007 06:45 > An: ietf@xxxxxxxx > Betreff: Re: Last Call: draft-ietf-geopriv-radius-lo > (Carrying LocationObjects in RADIUS > > This is a repost of 2 messages previously sent to the > ietf@xxxxxxxx list > which did not make it to the list. They are being re-sent > here at the > request of the RAI ADs. > > ======================================== > To: ietf@xxxxxxxx > Subject: Re: Last Call: draft-ietf-geopriv-radius-lo > (Carrying Location > Objects in RADIUS > From: "Bernard Aboba" <bernard_aboba@xxxxxxxxxxx> > Date: Sat, 17 Feb 2007 16:13:44 -0800 > Cc: radiusext@xxxxxxxxxxxx, secdir@xxxxxxx > > 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@xxxxxxxxxxx> > Subject: Re: Last Call: draft-ietf-geopriv-radius-lo > (Carrying Location > Objects in RADIUS > From: Peter Nixon <listuser@xxxxxxxxxxxxxx> > Date: Sun, 18 Feb 2007 13:18:57 +0200 > Cc: ietf@xxxxxxxx, radiusext@xxxxxxxxxxxx, sec-dir@xxxxxxx > In-reply-to: <BAY117-F234F10A1C03CDC0AEEFF44938B0@xxxxxxx> > References: <BAY117-F234F10A1C03CDC0AEEFF44938B0@xxxxxxx> > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf