On Thu, 2007-10-11 at 15:11 -0400, Marcotte, Tyler wrote:
Thank you for the response, even if it was ridden with unnecessary sarcasm.
I wasn't trying to argue, I was trying to understand why an Access-Reject wasn't sent back. Thank you for explaining that.
While I don't necessarily agree with your logic, I can see why you would think this is sufficient for normal 802.1X authentication and denial. The problem comes when you try to do something with a rejected user, for example, throw them in a different vlan. If the reject never comes, or waits for the user to log out, issues can arise.
You proceed from a false assumption. It's not possible in general to put someone into a vlan on reject (at least, using radius - see later) for two reasons: First, in general, attributes are not allowed in an access-reject. RFC2865 says: If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes (except Proxy-State) are permitted in an Access-Reject. See also for example, see section 3 of RFC4675, which specifically says the vlan and filter attributes are not permitted in a Reject. Other RFCs update this list slightly - Message-Authenticator in 3579, for example. FreeRadius enforces this (but does permit VSAs). Secondly, a correctly designed 802.1x supplicant will NOT enable the network link if the 802.1x conversation fails. The reasons for this should be obvious. Similarly, a correctly designed NAS (switch or AP) MUST (see section 2.1 of RFC3579) deny access on Reject - not permit it. I am aware of the reasons for wanting to do this (show someone a webpage to tell them their supplicant is mis-configured, or to get a temporary local guest account). But it cannot be done reliably. Some switch vendors implement a "fail vlan" feature. Since they've bothered to do this, I presume that the common supplicants (winXP, MacOS) *will* eventually give up and just try DHCP.