Marcotte, Tyler wrote:

...

Hi, You said it's a bug in 1.x. I just tried the latest code in the cvs repository (2.0 I believe) and I still get the same problem. After the PEAP failure, it sends an Access-Challenge rather than an Access- Reject.

That's completely different from what you said before.

...

Am I missing anything else here?

$ radiusd -X

Alan DeKok.

I had it attached to my first email. Here it is again inline though. Thanks, -Tyler Waking up in 6 seconds... rad_recv: Access-Request packet from host 192.168.3.88:1812, id=223, length=185 NAS-IP-Address = 192.168.3.88 NAS-Port = 192 Cisco-NAS-Port = "FastEthernet0/6" NAS-Port-Type = Ethernet User-Name = "user1" Called-Station-Id = "00-0D-29-53-6D-46" Calling-Station-Id = "00-09-6B-7C-1F-78" Service-Type = Framed-User Framed-MTU = 1500 State = 0x45d6de6646898817fedcc83eb8325436 EAP-Message = 0x0207001d1900170301001255c450b5120aec60b77bb555c8b9e89b6026 Message-Authenticator = 0x48d3b363a7a39d3120d016ea8ee0ef55 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 17 modcall[authorize]: module "preprocess" returns ok for request 17 modcall[authorize]: module "chap" returns noop for request 17 modcall[authorize]: module "mschap" returns noop for request 17 rlm_realm: No '\' in User-Name = "user1", skipping NULL due to config. modcall[authorize]: module "ntdomain" returns noop for request 17 users: Matched entry DEFAULT at line 158 users: Matched entry DEFAULT at line 177 users: Matched entry user1 at line 223 modcall[authorize]: module "files" returns ok for request 17 rlm_eap: EAP packet type response id 7 length 29 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 17 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 17 modcall: leaving group authorize (returns updated) for request 17 rad_check_password: Found Auth-Type System rad_check_password: Found Auth-Type EAP Warning: Found 2 auth-types on request for user 'user1' auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 17 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 rlm_eap_peap: Tunneled data is valid. PEAP: Got tunneled EAP-Message EAP-Message = 0x020700061a03 PEAP: Setting User-Name to user1 PEAP: Adding old state with 21 a6 PEAP: Sending tunneled request EAP-Message = 0x020700061a03 FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "user1" State = 0x21a6b01dca8c206387e07f1b6ed3d5e2 NAS-IP-Address = 192.168.3.88 NAS-Port = 192 Cisco-NAS-Port = "FastEthernet0/6" NAS-Port-Type = Ethernet Called-Station-Id = "00-0D-29-53-6D-46" Calling-Station-Id = "00-09-6B-7C-1F-78" Service-Type = Framed-User Framed-MTU = 1500 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 17 modcall[authorize]: module "preprocess" returns ok for request 17 modcall[authorize]: module "chap" returns noop for request 17 modcall[authorize]: module "mschap" returns noop for request 17 rlm_realm: No '\' in User-Name = "user1", skipping NULL due to config. modcall[authorize]: module "ntdomain" returns noop for request 17 users: Matched entry DEFAULT at line 158 users: Matched entry DEFAULT at line 177 users: Matched entry user1 at line 223 modcall[authorize]: module "files" returns ok for request 17 rlm_eap: EAP packet type response id 7 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 17 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 17 modcall: leaving group authorize (returns updated) for request 17 rad_check_password: Found Auth-Type System rad_check_password: Found Auth-Type EAP Warning: Found 2 auth-types on request for user 'user1' auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 17 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 17 modcall: leaving group authenticate (returns ok) for request 17 Processing the session section of radiusd.conf modcall: entering group session for request 17 radius_xlat: '/var/log/radius/radutmp' radius_xlat: 'user1' modcall[session]: module "radutmp" returns ok for request 17 modcall: leaving group session (returns ok) for request 17 PEAP: Got tunneled reply RADIUS code 3 Reply-Message := "\r\nYou are already logged in - access denied\r\n\n" PEAP: Processing from tunneled session code 0x81667248 3 Reply-Message := "\r\nYou are already logged in - access denied\r\n\n" PEAP: Tunneled authentication was rejected. rlm_eap_peap: FAILURE modcall[authenticate]: module "eap" returns handled for request 17 modcall: leaving group authenticate (returns handled) for request 17 Sending Access-Challenge of id 223 to 192.168.3.88 port 1812 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x010800261900170301001b1450162d7978bb0a346febf7acf7b4182469bacd418814fa e7c575 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x5e309299e4e51fb5676d6d6b3e369b85 Finished request 17 Going to the next request Waking up in 6 seconds...

So? Why would you expect it to send an Access-Reject? If you watch what happens next in the conversation, you should see the side effects of the Simultaneous-Use.

I'm not surprised at this behavior. It's what is *supposed* to happen.

Alan DeKok.

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? 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. 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?

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

Marcotte, Tyler wrote:

Thank you for the response, even if it was ridden with unnecessary sarcasm.

<shrug> After nearly a decade on this list, I've found that the best way to convince certain people to READ my messages, and to THINK about the problem they have is to be blunt. Those people then get upset, even after their questions have been answered. For some psychological reason, it's considered polite for people like you to argue with the experts, and to tell the experts that they're wrong. It's considered rude for the experts to explain how things work. I don't understand it, but I've learned to deal with it.

While I don't necessarily agree with your logic,

<sigh> Once again, we've run into the conflict. If you don't agree with my logic, it's because you don't understand how things work. Since you say you don't agree with my logic, it means you're arguing with me. Yet you said earlier that you weren't trying to argue with me. Can you see where my frustration comes from? "I'm not arguing, but I think you're wrong." If you're so all-fired knowledgable, why are you asking questions on this list?

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.

Once again, it's clear you don't understand how RADIUS works. When a user is rejected, their session is GONE. You CANNOT put them into a different VLAN, because they have no session where that VLAN can be assigned!

If the reject never comes, or waits for the user to log out, issues can arise.

"issues"... like what? Please clarify. The reality is that there are no issues. If the reject never comes, the user never obtains network access. There are no issues with that, because the user is not trying to obtain network access. What issues could there possible be? You want to assign the user a VLAN when they're not requesting access... How are you going to do that?

Again, thank you for your explanation; it was very insightful, even if it was condescending and rude.

It might have opened a small crack of enlightenment. If so, it was productive, even if the process was painful for you. Alan DeKok.