Subject: Re-auth failure

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Mar 2008 17:48:20 +0200

RFC 3579 says:

   Reception of a RADIUS Access-Reject packet MUST result in the NAS denying
   access to the authenticating peer.

Consider a host that is already authenticated and authorized for network
access. If it performs re-authentication say 1 hour before the session
timeout and fails authentication (EAP-Failure), should the NAS disconnect
the host from the network immediately? According to the RFC 3579 text, it
MUST eject the host immediately. 

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?

Thanks.

Alper 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 7 Mar 2008 11:00:31 -0500

Alper Yegin writes...

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

I suppose that depends on whether one considers the responses of the RADIUS
Server to be authoritative or merely advisory.  One can construct reasonable
use cases to support either notion, although historically we have considered
the responses of the RADIUS Server to be authoritative.

If the Access-Reject was caused by a transient failure somewhere in the
system, including the back-end authentication service, one might want to
allow a customer to finish out his pre-allocated session time.  If the
Access-Reject was caused by a system administrator's action to de-authorize
a user (maybe an employee who is about to be fired), one would almost
certainly want the session to be terminated upon a failed re-authentication.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 07 Mar 2008 17:27:25 +0100

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

  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.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Mar 2008 18:54:11 +0200

Thank you for the response.

> use cases to support either notion, 

For example, if the user is on a pre-paid account and his credit has reached
0 yet still has 1 more hour to go with the current session, that left-over
time shall not be taken away from him just because his "request to extend"
the session was not granted. [I don't know pre-paid support well enough to
say whether this is already taken care of by some means.]

> although historically we have
> considered

That makes sense. AAA server can have its own reasons for expecting
different outcomes from issuing Access-Reject. But how does the NAS know how
to react to receiving an Access-Reject? Unless some auxiliary info is
provided to the NAS, it cannot know the real intention of the AAA when
issuing the reject. I wonder if there are such cases where a RADIUS
attribute is used for helping NAS make the right decision.

Thank you.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Mar 2008 19:02:40 +0200

Hi Alan,

> until

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

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 7 Mar 2008 10:26:26 -0800

[email-masked] <> scribbled on Friday, March 07, 2008 8:54
AM:

>> I suppose that depends on whether one considers the responses of the
>> RADIUS Server to be authoritative or merely advisory.  One can
>> construct reasonable use cases to support either notion,
> 
> For example, if the user is on a pre-paid account and his
> credit has reached 0 yet still has 1 more hour to go with the
> current session, that left-over time shall not be taken away
> from him just because his "request to extend"
> the session was not granted. [I don't know pre-paid support
> well enough to say whether this is already taken care of by some
> means.] 

I think that in this case the problem arises from trying to overload the
Access-Request & Access-Accept/Reject messages a little too much: the
semantics of the question being asked don't match those of the messages
used.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 7 Mar 2008 10:33:48 -0800

[email-masked] <> 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?
>> 
>>   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.
> 
> 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

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?

> 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
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 7 Mar 2008 14:16:00 -0500

Alper Yegin writes...

> specification's role to dictate what a NAS should be doing with
> the output of this protocol's execution.

Since RADIUS is all about authorization and service provisioning, you would
not be able to get multi-vendor interoperability at a behavioral level if
every NAS interpreted the standardized RADIUS messages in an implementation
dependent fashion.

The *semantics* of the messages, in terms of what they dictate for NAS
behavior is all part of the RADIUS specification.

> I think the reaction to a RADIUS state is an "architectural" decision,
> and belongs to the users of this protocol.

If you want to re-use RADIUS messaging formats in an implementation
featuring user customized actions for each message, then feel free to do so,
but please don't call it RADIUS.  :-)

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Mar 2008 11:37:53 -0800

If we are talking about EAP, then Re-authentication is driven by the 
authenticator.
RFC 3579 states that this occurs on expiration of the Session-Timeout value,
so that the maximum session time has already been utilized by the time it 
occurs.

Therefore if the user fails authentication, they have no remaining time left 
on
the session.

--------------------------------------------------
From: "Alper Yegin" <[email-masked]>
Sent: Friday, March 07, 2008 7:48 AM
To: <[email-masked]>
Subject: Re-auth failure

---

From: Avi Lior <[email-masked]>
Date: Sat, 8 Mar 2008 16:37:55 -0500

> well enough to say whether this is already taken care of by
> some means.]

In this case we dont send a reject but rather an accept indicating that there is no more quota allowing the NAS to let the user finish off his quota.

---

From: Avi Lior <[email-masked]>
Date: Sat, 8 Mar 2008 16:49:02 -0500

This is exactly true in the case you specify.
But consider the case where the NAS or the Device itself decides to reauthenticate OR for that matter in Diameter where we do have an Authorization LifeTime and a Session time.

NASREQ has text that covers this scenario and IMO is correct:

2.2.  Diameter Session Reauthentication or Reauthorization

Snip

   A Diameter server informs the NAS of the maximum time allowed before
   reauthentication or reauthorization via the Authorization-Lifetime
   AVP [BASE].  A NAS MAY reauthenticate and/or reauthorize before the
   end, but A NAS MUST reauthenticate and/or reauthorize at the end of
   the period provided by the Authorization-Lifetime AVP.  The failure
   of a reauthentication exchange will terminate the service.

Cant be clearer then this.

The business reasons are clearer.

A HAAA server authorizes a service and by doing so is willing to pay the NAS to deliver that service.  If reauthentication fails, then the HAAA can not be on the hook for paying for service.  OR from the user's perspective, if reauthentication fails you cant expect the user to pay for the service since upon presntation of a bill the user will claim it wasn't him.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, March 07, 2008 2:38 PM
> To: Alper Yegin; [email-masked]
> Subject: Re: Re-auth failure
>
> If we are talking about EAP, then Re-authentication is driven
> by the authenticator.
> RFC 3579 states that this occurs on expiration of the
> Session-Timeout value, so that the maximum session time has
> already been utilized by the time it occurs.
>
> Therefore if the user fails authentication, they have no
> remaining time left on the session.
>
> > Consider a host that is already authenticated and authorized for
> > network access. If it performs re-authentication say 1 hour
> before the
> > session timeout and fails authentication (EAP-Failure),
> should the NAS
> > disconnect the host from the network immediately? According
> to the RFC
> > 3579 text, it MUST eject the host immediately.
> >
> connected
> > to? If so, is there a different interpretation of the above
> text, or a
> > different message (Access-Accept with EAP-Failure?) recommended?
> >
> > Thanks.
> >
> > Alper
> >
> >
> >
> > --
> [email-masked] with