[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
> The radius server might also understand either civic, geospatial or both.
We need to distinguish between the RADIUS Accounting Server and the RADIUS
Authentication Server. The RADIUS Accounting Server can be assumed to
"understand" anything (e.g. it just writes AVPs to stable storage). The
RADIUS Server should be thought of as either REQUIRING or NOT REQUIRING an
attribute. If an attribute is REQUIRED the RADIUS Server will request it
in an Access-Challenge.
> whether the desire to support this functionality justifies the introduction of an avp is subject for discussion.
I think there is a need for an attribute to be sent from the RADIUS Server
to the NAS to describe what it wants (e.g. Geospatial, Civil), what
location is to be sent (user or NAS)), and how it
wants it. Presumably this attribute can be sent in an Access-Challenge.
There is also a need for location attributes, to be sent from the NAS to
the RADIUS server.
However, I don't see a need for "Capabilities Announcement" by the NAS.
> this was the approach that was suggested to us in previous discussions.
> sounds good to me.
The Access-Challenge approach is ok only if it is made clear that a NAS
that is not expecting an Access-Challenge MUST treat it as a Reject, as
mandated in RFC 2865. And of course, a RADIUS Server MAY send a Reject if
the Challenge isn't answered correctly, so you need to support that case
or the NAS/RADIUS server exchange could go on indefinitely.
> i guess you would suggest to return an access reject if the nas is
> unable to understand the returned location information format.
The NAS can't send an Access-Reject. It can only treat the Challenge as
an Access-Reject.
> this requirement hasn't been presented to me yet.
Given that it's the RADIUS server that is determining what is needed,
there needs to be a way for the server to actually request what it needs. A
given RADIUS server may require user location (there are installations
today that do locatoin-based authorization) in geospatial or civil format.
Or it just may need NAS location.
> i hope it is simple.
From the RADEXT WG discussion so far, it does appear to be quite simple.
--
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/>