Hi Anthony,
thanks for your timely review. Please find my comments inline:
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of Anthony Leibovitz
Sent: 08 April, 2009 22:12
To: IETF(_at_)IETF(_dot_)ORG
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf