RE: AW: Capabilities: Summary

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...

> The problem with this is that it violates a MUST of RFC 2865.  
> If the server is ok without location in the Access-Request,
> then it can send an Access-Accept instead of a Challenge.

Yes, I think it is appropriate for the server to make the decision to
provide limited access or full access, using one of the existing or
proposed attributes, such as including a Filter-ID attribute in the
Access-Accept.

The problem with this, however, is if the only way that the server can
find out if a NAS has or supports location information is to send an
Access-Challenge, there is no way for the server to make this informed
decision in some scenarios, as the NAS will automatically treat an
un-expected Access-Challenge as an Access-Reject.  The server cannot
know, from the initial Access-Request, whether to send an
Access-Challenge or send an Access-Accept (possibly with a Filter-ID).

This discussion presumes two facts: (a) the NAS never includes location
information in its initial Access-Request and (b) RADIUS authentication
mechanisms that do not already support Access-Challenge need to be use
in conjunction with GEOPRIV.  I think (a) is a requirement of GEOPRIV
and (b) is something that needs to be validated.


--
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/>