Simultaneous-Use and PEAP doesn't work correctly.

[Marcotte, Tyler]

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: freeradius-users-bounces at lists.freeradius.org
[mailto:freeradius-
> 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
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