Issue: Capability Attribute rationale and scenarios unclear

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Capability Attribute rationale and scenarios unclear

Submitter name: Emile van Bergen
Submitter email address: openradius-radextwg@e-advies.nl
Date first submitted: September 10, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00824.html
Document: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt
Comment type: T
Priority: S
Section: 8
Rationale/Explanation of issue:

From the text:

  "8. Capability Attribute
  
   The capability attribute allows the RADIUS client to indicate whether
   civic and/or geospatial location information can be provided to the
   RADIUS server.  This is useful to avoid sending location information
   with every request if no further out-of-band arrangements are made
   with regard to the transport of location information.  

   The AAA server uses the capability attribute to indicate that the AAA
   client has to provide civic and/or geospatial location information as
   part of this particular protocol exchange.  If the AAA server does
   not send a capability attribute then the AAA client MUST NOT return
   location information.  The user's authorization policies MUST be
   consulted by the AAA server before requesting location information
   delivery from the AAA client.  If the AAA server encounters that the
   AAA client does not support the desired location information it might
   respond with an Access-Reject with the corresponding error cause
   attribute (with the Location-Info-Required error code)."

The reason to avoid sending location information is not clear. From the
rest of the document, it would appear that the sending of location
information is entirely conditional on the user's policy, not on any
other consideration.

In RADIUS, the RADIUS client can only learn about the user's policy from
RADIUS responses to an access request. So I would suggest to put the
following text somewhere:

  "Without prior knowledge of the user's policy, the RADIUS client MUST
  NOT send Location attributes in an Access Request.

  If the home RADIUS server requires location information for
  authentication and has permission from the user, it sends an Access-
  Challenge containing Location-Info-Required to request the
  information, upon which the RADIUS client will reissue its Access
  Request, including the Location attributes (and echoing the State
  attribute as per RFC 2865).

  If the home RADIUS server does not require location information to
  perform its authentication, but the user's policy allows location
  information to be transmitted by the RADIUS client, the RADIUS server
  informs the RADIUS client of that policy in the Access Accept packet."

It seems there's no capability negotiation needed, and as RADIUS servers
are currently not required to keep any dynamic per-client data, leave
alone per-NAS data, that should only be added when absolutely required.

Kind regards,


Emile van Bergen.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>