Subject: RE: New Version Notification - draft-ietf-geopriv-radius-lo-22.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 23:31:43 -0800

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?