Hi Anthony, thanks for your timely review. Please find my comments inline: ________________________________ From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Anthony Leibovitz Sent: 08 April, 2009 22:12 To: IETF@xxxxxxxx Subject: DRAFT-IETF-GEOPRIV-RADIUS-LO-23 TO WHOM IT MAY CONCERN: I have read draft-ietf-geopriv-radius-lo-23 and have the following concerns about it: a. Confusion with existing functionality. As defined in RFC 2865, the RADIUS protocol REQUIRES that NAS identification attributes be present in a RADIUS Access-Request. When combined with a wiremap, these attributes (such as NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address) provide information on the NAS location, which can be used to infer the user location in a number of common scenarios (e.g. IEEE 802 network access as envisaged in RFC 3580). Given this pre-existing support for location, it was surprising for me to read Section 1, which presents the functionality of this document as though it were new (e.g. "This document defines attributes. that can be used to convey location-related information."). At a minimum, Section 1 needs to describe the existing RADIUS location functionality, and clearly delineate the additional value provided by the attributes described in the document. [hannes] This document defines location attributes that allow location information to explicitly describe the location of the end point (or if this information is not available then the location of the entity closest to the end point). Like with any other field in computer science there are different solution approaches and that's just fine. This document does not claim to be the only way to provide this functionality in certain deployment scenarios and it is not a literature survey either. b. Confusion about privacy requirements. Given that RADIUS has always supported transmission of information relating to user location, and indeed, the transmission of this information is REQUIRED in every access request, there are a number of statements in the document which appear to represent major changes to RFC 2865, even though this document does not indicate that it updates RFC 2865. As an example, Section 1 states that "location information needs to be protected against unauthorized access and distribution", yet nowhere in the document are the implications of this statement for the RADIUS protocol laid out. Does this statement apply only to the attributes defined in the document, or does it apply to the NAS Identification attributes defined in RFC 2865? Do the security requirements outlined in Section 7 apply to any use of RADIUS, or just to the attributes in this document? The document is unclear on this point; it needs to state clearly whether the privacy requirements and rules functionality applies only to uses of the attributes defined in this document, or to any use of RADIUS. [hannes] This document does not provide a generic investigation of what privacy risks there are with RADIUS (or the AAA architecture in general) when information is shared without the user's consent. This document focuses only on location information and tries the best it can do to ensure that the user's privacy preferences are preserved. It does this in a way that is not contracting with RFC 2865. The requirements in Section 7 of the draft refer to the rather generic security and privacy requirements defined in RFC 3693. We tried to map and apply them to the attributes defined in this document. The document does not discuss privacy and security aspects of other RADIUS attributes defined elsewhere. We do refer to identity information that may be available to some AAA entities as it is relevant for the security considerations of the attributes being defined in this document. c. Confusion about the meaning of "retransmission allowed". As noted in draft-ietf-geopriv-sip-lo-retransmission as well as in recent discussions on the GEOPRIV WG mailing list, there is confusion about the meaning of "retransmission allowed". Since RFC 2865 requires the inclusion of NAS identification in a RADIUS Access-Request, re-transmission of information related to user-location is an integral part of the network access authentication and authorization process. As a result, restrictions on the ability of a RADIUS proxy to retransmit location information to a RADIUS server are inherently non-deployable. In addition, many RADIUS proxies will treat attributes they do not understand as opaque blobs, and so are inherently unable to parse or act upon privacy policies. However, on reading this document, I had many of the same questions as were raised in draft-ietf-geopriv-lo-retransmission with respect to SIP conveyance, as to whether privacy policies applied to RADIUS conveyance. Some of this confusion was enhanced by Section A.2, entitled "Distribution of location information at the Visited Network". Is the issue really distribution of location information within the RADIUS realms on the roaming relationship path, or is it retransmission of location information outside those entities? This is a critical point - but one that the document leaves unclear. [hannes] The discussions about the re-transmission privacy policy in the GEOPRIV working group are related to the functionality in SIP regarding location based routing. A single binary flag was insufficient to express all the different cases that appeared based on this functionality in SIP. A separate document was written to clarify this aspect (and I hope it in fact did). RADIUS does not have a notion of location based routing, i.e., routing of AAA messages based on the location carried in RADIUS attributes. As such, the issue does not arise. Hence, these privacy policies refer to the distribution of location information outside the RADIUS realm. d. Consistency with RADIUS architecture. With respect to privacy policies, it is unclear whether draft-ietf-geopriv-radius-lo-23 requires RADIUS proxies to inspect RADIUS attributes prior to re-transmission, to understand that certain RADIUS attributes contain location information and to implement policies encoded within those attributes. If so, this would be an ominous and undesirable requirement to place on RADIUS implementations because RADIUS servers need not have explicit knowledge of the all attributes they transmit or re-transmit. Such a requirement would be even more undesirable in multi-vendor deployments where RADIUS interoperability is required. [hannes] A AAA server that does not understand location will not run a location server either to distribute location information to outside entities. If it wants to distribute location information (for whatever reason) then it acts in the role of a location server and has to respect the privacy rules. I use the Diameter terminology since it is better developed: "Relay Agent or Relays: Relays forward requests and responses based on routing-related AVPs and routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs." Demanding such Diameter Relay to suddenly look at location and privacy attributes even though they never look at any attribute is a bit unrealistic. Diameter Proxies, per definition, do more: "In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning." We couldn't find cases what these entities could do with location information that would require them to look at the location/privacy attributes other than distributing the information outside the AAA realm. As mentioned, there is no such thing as location based routing in AAA. Imagine, however, that location information is distributed to third parties outside the AAA realm then the AAA entity would act in the role of a location server. We want to make sure that the good guys are able to have added value from the privacy mechanisms (in this case privacy policies). The privacy flags and fields cannot help against the bad guys since they would just ignore them anyway. This is something for law enforcement to deal with. The limitations of the basic privacy policies are documented in the referenced GEOPRIV documents. e. Implications for RADIUS accounting and billing. RADIUS accounting data - which includes location-related information - is commonly made available to RADIUS proxies and servers today. In some cases, RADIUS accounting data is stored on the visited network proxy and in other cases, the RADIUS accounting data is forwarded to an intermediate or home realm for storage in a database. When 're-transmission allowed' is set to 0 (the default), does this mean that RADIUS accounting data that includes location information cannot be re-transmitted to another realm? If so, then this document would disrupt the transmission of accounting data which is legally required to be maintained by statues such as Sarbanes Oxley. [hannes] This is a good point and a frequent question we hear around the privacy policies. You might be interested to hear that we are working on an update of RFC 3693, namely http://tools.ietf.org/id/draft-barnes-geopriv-lo-sec-05.txt, that aims to describe some of these aspects in a different (hopefully more readable) fashion. The privacy policies, when set, restrict the distribution of location for a specific usage context. The usage context itself is not encoded in the policies itself (as this would be somewhat hard todo). As such, the context needs to be obtained from the mode of operation of the protocol. In your example, if the AAA server stores all the stuff it gets in a log file then the retransmission-allowed flag set to 'no' means that it is still allowed to store the data in a log file since it is required in order to get the entire network access authentication procedure to work. Selling the data to some third party company for marketing purposes would, however, not be acceptable with the retransmission-allowed flag set to 'no'. You can compare this with another frequently used policy language, namely Creative Commons (http://creativecommons.org/). CC has a focus on applying conditions to your work (e.g., images, music, documents). The concept is, however, similar and often helps to understand the basic idea of the Geopriv privacy policies. I hope I was able to clarify your questions. If you believe that text needs to be added here and there I am happy to work with you on text improvements. Ciao Hannes Thanks, Anthony Leibovitz Principal Program Manager Microsoft Corporation _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf