RE: Re-auth failure

["Alper Yegin" <alper.yegin@yegin.org>]

Hi Alan,

> > Shouldn't the network have the option to let the host stay connected
> until
> > the expiration of the currently granted session, if it chooses to? If
> so, is
> > there a different interpretation of the above text, or a different
> message
> > (Access-Accept with EAP-Failure?) recommended?
> 
>   I tend to agree with David here.  RADIUS servers have traditionally
> been authoritative, so the user has to be rejected here.
> 
>   Much of the confusion comes about because RADIUS has traditionally had
> no definition of what a "session" is.  In this case, the server *is*
> authoritative for a session.  However, it's unclear whether or not the
> second session is related to the first, if at all.

For that reason and others, I think it's not RADIUS "protocol"
specification's role to dictate what a NAS should be doing with the output
of this protocol's execution. I think the reaction to a RADIUS state is an
"architectural" decision, and belongs to the users of this protocol. An
architecture spec can determine when and how to use the protocol, and how to
react to this protocol's output.

I wonder if this view is shared and ever used in
deployments/implementations, or if practically everybody is following the
interpretation described by Alan/David.

Alper




> 
>   NASes have traditionally made fail-safe decisions: If they receive an
> Access-Reject for a authentication tied to one MAC address, that MAC
> address is denied access.  This happens even if there are other
> "sessions" tied to that MAC which may still have access rights.
> 
>   Alan DeKok.
> 
> --
> 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/>