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. Again, thank you for your explanation; it was very insightful, even if it was condescending and rude. Regards, -Tyler > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:freeradius- > [EMAIL PROTECTED] On Behalf Of Alan DeKok > Sent: Thursday, October 11, 2007 3:35 AM > To: FreeRadius users mailing list > Subject: Re: Simultaneous-Use and PEAP doesn't work correctly. > > Marcotte, Tyler wrote: > > I can understand that nowhere in any documentation does it say that an > > Access-Reject is sent back (I just double-checked to verify). However, > > what I don't understand is why not? > > Because it's an EAP method, *and* it's TLS. Go read the debug output > again: the inner tunnel MS-CHAP authentication has to send an MS-CHAP > "authentication failed" response to the supplicant. Since this has to > go in the TLS tunnel, it has to go in an Access-Challenge, because there > is often multiple round trips required to get all of that data to the > supplicant. > > Further, the EAP specifications say that the server CANNOT > short-circuit the EAP conversation, by sending an EAP-Failure in the > middle of a conversation. > > > If you're using this with 802.1X (which I'm trying to do) the radius > > client most likely does not understand reply-messages. It only > > understands Access-Challenges, Requests, Accepts, and Rejects for types > > of RADIUS packets. It can also understand other Vendor Specific > > attributes depending on the vendor, but I've yet to encounter one that > > can understand a Reply-Message. > > You're thinking about the problem entirely wrong. The RADIUS client > *does* understand Reply-Message. It just can't do anything with it. > The protocol used between the RADIUS client and the supplicant is EAPoL, > which has no way to carry the Reply-Message. > > > If a End User isn't allowed onto the network because he's already logged > > in, why wouldn't you want to send an Access-Reject? > > Because you're fixated on Access-Reject, and *not* on the user session > getting dropped. If the user session goes away, who cares about sending > an Access-Reject? > > Let me guess what's happening, because you did NOT say what happens > after the Access-Challenge is sent. > > What happens is this: > The server sends the Access-Challenge. > NOTHING MORE HAPPENS. > The client doesn't send another Access-Request. > Therefore, the server doesn't send an Access-Reject. > You then see no Access-Reject > You then conclude "OH NO! THE USER WASN'T REJECTED". > > Here's a simple proof of the illogic of that argument: > The client doesn't send another Access-Reject. > i.e. the client is NO LONGER REQUESTING ACCESS. > i.e. the client has GONE AWAY. It is NO MORE. > (Insert further "parrot sketch" lines here.) > > What happening is that the inner tunnel MS-CHAP session tells the > supplicant that the user has been rejected. At that point, there is no > need for the supplicant to continue the conversation. So it doesn't. > > Since EAP is driven 100% by the client, the server has no need to send > an Access-Reject. Why you ask? But doesn't the server need to send an > Access-Reject to kick the user off? Isn't something going terribly, > horrible, wrong? > > No. The server doesn't have to reject users if they're not requesting > access. If the user goes away part way through an EAP conversation, > then the NAS will AUTOMATICALLY reject their session. > > There is NO NEED for the server to send an Access-Reject. Your > insistence that it's a problem when there's no Access-Reject is based on > a misunderstanding of how the system works. Stop arguing. Stop > thinking that something is going wrong. Start believing me that there's > no problem. The user IS getting rejected, even if there is no > Access-Reject being sent. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html