[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: [Pana] RADIUS Access-Reject and NAP/ISP authz



In my own review of RFC 2869, it would appear that there is a distinction
made between "no service" and "disconnection".  In the case of AppleTalk
it appears that the user can reauthenticate after an Access-Reject,
although their AppleTalk packets will not be forwarded.  So they have "no
service" but are not "disconnected".

In the case of PPP, it therefore seems to me that "Access Reject" really
means that the user does not get to NCP, not necessarily that an
LCP-Terminate MUST be sent (although that is typically what happens).

In 802.1X for example, Access-Reject means that packets cannot be
forwarded by the switch; it doesn't necessarily mean that all link state
is torn down.  For example, in 802.11i the STA would still be in State 3
(Authenticated, Associated) even after 802.1X fails.  However, the 802.1X
controlled port would not allow packets through.

So far, attributes in an Access-Reject have only been allowed to inform
the user that service isn't being provided (Reply-Message,
EAP-Message/EAP-Failure, etc.) or to control retry behavior.

On Mon, 21 Mar 2005, Nelson, David wrote:

> > Well, a first step might be for the WG Chairs to express the
> > historic semantics of the Access-Reject message and even, perhaps,
> > the WG consensus regarding it (determining that as necessary).
>
> Bernard may see this differently, but my own observation from the
> discussion to date on the list is that the RADEXT WG does not have a
> clear consensus on the semantics of the Access-Reject message and the
> permissible attributes that may appear therein.
>
> I think, historically speaking, that the RADIUS WG probably *did* have a
> clear consensus on what they thought Access-Reject meant, but that was
> then and this is now.  Access-Reject has classically meant "no service".
> I think that some of the RFCs published between the closing of the
> RADIUS WG and the chartering of the RADEXT WG may have blurred the
> classical semantics of Access-Reject.  There is currently a debate over
> what "service" means, although I hope that "no" still means "no".  :-)
>
> It seems to me that the pertinent question is what the RADEXT WG thinks
> is the correct semantics for Access-Reject for current and future RADIUS
> work.
>
>
> --
> 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/>
>

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