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

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> In my own review of RFC 2869, it would appear that there is a distinction
> made between "no service" and "disconnection". 

  It's not clear to me.  The text is ambiguous, and I could interpret
it in many ways, but the examples in 2.3.4 show "client disconnected"
as a result of RADIUS Access-Reject.

  I agree it's reasonable to say that "no service" != "disconnection".
My only concern then is to clearly scope what kind of service is
permitted after an Access-Reject, if the client isn't disconnected.
Where the semantics or decisions are ambiguous, a simple client
disconnection makes implementation and security analysis easier.

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

  That's reasonable, which means one more issue to address in RFC
2869, Section 7.2.5 page 43, which says:

   If EAP is negotiated but is not supported by the RADIUS proxy or
   server, then the server or proxy MUST respond with an Access-Reject.
   In these cases, the NAS MUST send an LCP-Terminate and disconnect the
   user.

  In that case, the difference in RADIUS client behaviour between
Access-Reject due to authentication failure, and Access-Reject due to
implementations not supporting the requested authentication becomes
problematic.  Again, if an implementor isn't sure, disconnection is
always a safe bet.

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

  While I'm not familiar with the details of 802.11i, I'm not sure
what it means to be in an "authenticated" state after the session was
rejected.  Maybe this is just a terminology difference between 802.11i
and RADIUS.

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

  I agree.  Though the Password-Retry attribute of RFC 2869 is in a
grey area.  I could see an equivalent design be to use Password-Retry
in Access-Challenge.

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