RE: Re-auth failure

["Glen Zorn" <glenzorn@comcast.net>]

owner-radiusext@ops.ietf.org <> scribbled on Friday, March 07, 2008 9:03
AM:

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

So the semantics of RADIUS messages are not in the scope of the protocol
definition?  Sounds like COPS ;-)

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

How would different "architectures" interoperate?  How would the rules
be expressed?  How could multiple architectures be reasonably supported
in a single network?  It seems like this idea is fine for walled gardens
(WiMAX?), not so good for the Internet.  OTOH, if you have a walled
garden you can make up any rules you like anyway, so why worry about it?

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

AFAIK, your viewpoint is unique :-).

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



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