Simultaneous-Use and PEAP doesn't work correctly.
tmarcott at enterasys.com
Thu Oct 11 21:11:40 CEST 2007
Thank you for the response, even if it was ridden with unnecessary
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.
> -----Original Message-----
> From: freeradius-users-bounces at lists.freeradius.org
> users-bounces at lists.freeradius.org] 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
> > Access-Reject is sent back (I just double-checked to verify).
> > what I don't understand is why not?
> Because it's an EAP method, *and* it's TLS. Go read the debug
> 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
> is often multiple round trips required to get all of that data to the
> 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
> > of RADIUS packets. It can also understand other Vendor Specific
> > attributes depending on the vendor, but I've yet to encounter one
> > 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
> which has no way to carry the Reply-Message.
> > If a End User isn't allowed onto the network because he's already
> > in, why wouldn't you want to send an Access-Reject?
> Because you're fixated on Access-Reject, and *not* on the user
> getting dropped. If the user session goes away, who cares about
> 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
> 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
> an Access-Reject. Why you ask? But doesn't the server need to send
> 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
> 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
> a misunderstanding of how the system works. Stop arguing. Stop
> thinking that something is going wrong. Start believing me that
> no problem. The user IS getting rejected, even if there is no
> Access-Reject being sent.
> Alan DeKok.
> List info/subscribe/unsubscribe? See
More information about the Freeradius-Users