[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: Capability Attribute rationale and scenarios unclear
Capability Attribute rationale and scenarios unclear
Submitter name: Emile van Bergen
Submitter email address: email@example.com
Date first submitted: September 10, 2005
Comment type: T
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
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.
Emile van Bergen.
E-Advies - Emile van Bergen firstname.lastname@example.org
tel. +31 (0)78 6136282 http://www.e-advies.nl
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.