Simultaneous-Use and PEAP doesn't work correctly.

[Alan DeKok]

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.