Watching the latest review comments, I wasn't sure whether the issue relating to request for location data had been resolved. The draft states that the RADIUS server can request location-data if the client indicated that it was location capable. However, since the location data provided was to be considered opaque, it can't check whether the actual data corresponded to the requested info without code modifications.
There was also the question of the meaning of "retransmission allowed" in this context; this issue has also arisen in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-sip-lo-retransmission-01.txt. For example, that document states:
Bear in mind, however, that <retransmission-allowed> is not intended
to provide any protocol-level mechanism to prevent unauthorized
parties from learning location through means like eavesdropping. It
is merely a way to express the preferences of the Rule Maker to the
LR. If the LR were, for example, legally bound to follow the privacy
preferences expressed by Rule Makers, then they might incur liability
of they ignored the <retransmission-allowed> parameter. No further
privacy protection is assumed to be provided by <retransmission-
allowed>....
In this architecture, the question of who is an "authorized
recipient" from the point of view of the Rule Maker has been muddy.
The ... elements along the path are authorized to receive and forward
the ... message; does that make them automatically authorized
recipients of the LI it contains? The final target of the ...
message will receive the LI along with other information, but it may
be different than the initial target in a variety of scenarios; is it
authorized to read the LI?
These questions and concerns are particularly problematic when
<retransmission-allowed> is set to "no" (the default case). This
core concern might be put as "to whom does <retransmission-allowed>
apply in location-based routing?"
These issues also arise in RADIUS since standard RADIUS attributes like NAS-IP-Address,
NAS-IPv6-Address, NAS-Identifier are required by [RFC2865] to be sent in an Access-Request and
also can be used for the purposes of location determination. RADIUS proxies will forward these
attributes along the path to the the RADIUS server regardless of whether the rules allow
retransmission or not. Since the RADIUS protocol doesn't provide confidentiality,
user location is sent in the clear. Are any of these existing practices affected by
the carriage of rules within RADIUS packets?
|