EAP-PEAP-MSCHAPv2: use_tunneled_reply = yes
Hi all, I'm using FreeRADIUS with Cisco 1200 Series Access points for dynamic VLAN assignment. When i set use_tunneled_reply = yes for PEAP i get an Access-Challenge with the correct attributes but the final Access-Accept has no attributes and the User-Name is the anonymous one from the outer tunnel. This username is then used by the AP for accounting. Is this by design or is my configuration wrong? Partial debug, Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 24 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 24 modcall: group authenticate returns ok for request 24 PEAP: Got tunneled reply RADIUS code 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Processing from tunneled session code 0x818f508 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS modcall[authenticate]: module "eap" returns handled for request 24 modcall: group authenticate returns handled for request 24 Sending Access-Challenge of id 8 to 127.0.0.1:33229 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Message-Authenticator = 0x00000000000000000000000000000000 EAP-Message = 0x010900501900170301002079fdf7026cf88ffd8c978e4fb62290b4d4f4a1596c767f557ada bdaf51b7437d17030100209a1de8e9b88b4654d03b0754d4f5a04887b57b329c94a6494ef84d 2bf74f294c State = 0x3c86d1f16a6312263ae7a01dbfc81a28 Finished request 24 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 127.0.0.1:33229, id=9, length=205 User-Name = "anon" NAS-IP-Address = 127.0.0.1 Calling-Station-Id = "00-00-00-00-00-02" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0209005019001703010020f8f585176e2220ba00055d66cd73494a9539cce8d52da81ff067 f5835fd4de1117030100207461f938bb9af8c154f926ab2eb5653392cb1ebb02782ac58c3b6c ca8566fbdd State = 0x3c86d1f16a6312263ae7a01dbfc81a28 Message-Authenticator = 0x830975610af464574e583a2a9240068d Processing the authorize section of radiusd.conf modcall: entering group authorize for request 25 modcall[authorize]: module "preprocess" returns ok for request 25 radius_xlat: '/var/log/radiusd/radiusd-20050930' rlm_detail: /var/log/radiusd/radiusd-%Y%m%d expands to /var/log/radiusd/radiusd-20050930 modcall[authorize]: module "auth_log" returns ok for request 25 modcall[authorize]: module "chap" returns noop for request 25 modcall[authorize]: module "mschap" returns noop for request 25 rlm_realm: No '@' in User-Name = "anon", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 25 rlm_eap: EAP packet type response id 9 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 25 modcall[authorize]: module "files" returns notfound for request 25 modcall: group authorize returns updated for request 25 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 25 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: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 25 modcall: group authenticate returns ok for request 25 Sending Access-Accept of id 9 to 127.0.0.1:33229 MS-MPPE-Recv-Key = 0x73f9e4f3cc50836d0d52db55ddceb6afb7fea6e50313380873101fe245e6532d MS-MPPE-Send-Key = 0xcbf30f484d74cc947dcd0ea4fb49f7d94adb6be677e23d4edae3a22d136ad3b9 EAP-Message = 0x03090004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "anon" Finished request 25 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 16 ID 0 with timestamp 433d25b6 Cleaning up request 17 ID 1 with timestamp 433d25b6 Cleaning up request 18 ID 2 with timestamp 433d25b6 Cleaning up request 19 ID 3 with timestamp 433d25b6 Cleaning up request 20 ID 4 with timestamp 433d25b6 Cleaning up request 21 ID 5 with timestamp 433d25b6 Cleaning up request 22 ID 6 with timestamp 433d25b6 Cleaning up request 23 ID 7 with timestamp 433d25b6 Cleaning up request 24 ID 8 with timestamp 433d25b6 Cleaning up request 25 ID 9 with timestamp 433d25b6 Nothing to do. Sleeping until we see a request. --------------------------------------------------- When i use TTLS everything works perfectly. If i set use_tunneled_reply = no for TTLS the outer tunnel identity is used in the Access-Accept and no attributes are returned. Partial debug, Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 7 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 7 modcall: group authenticate returns ok for request 7 TTLS: Got tunneled reply RADIUS code 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03070004 Message-Authenticator = 0x00000000000000000000000000000000 TTLS: Got tunneled Access-Accept rlm_eap: Freeing handler TTLS: Freeing handler for user radtes modcall[authenticate]: module "eap" returns ok for request 7 modcall: group authenticate returns ok for request 7 Sending Access-Accept of id 7 to 127.0.0.1:33227 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Message-Authenticator = 0x00000000000000000000000000000000 MS-MPPE-Recv-Key = 0xf250fa51ea382aef2f2ea5ebaab8596fa822cf6788ccd2782fe2e7df98cd06aa MS-MPPE-Send-Key = 0xca164c1041c8b439c99b13505ba04aaf48cabf6802df8c92738a2c12349b4be2 EAP-Message = 0x03070004 Finished request 7 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 0 with timestamp 433d1f58 Cleaning up request 1 ID 1 with timestamp 433d1f58 Cleaning up request 2 ID 2 with timestamp 433d1f58 Cleaning up request 3 ID 3 with timestamp 433d1f58 Cleaning up request 4 ID 4 with timestamp 433d1f58 Cleaning up request 5 ID 5 with timestamp 433d1f58 Cleaning up request 6 ID 6 with timestamp 433d1f58 Cleaning up request 7 ID 7 with timestamp 433d1f58 Nothing to do. Sleeping until we see a request. raddb/eap.conf eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no tls { private_key_password = ******** private_key_file = ${raddbdir}/certs/srv_key.pem certificate_file = ${raddbdir}/certs/srv_cert.pem CA_file = ${raddbdir}/certs/demoCA/prv.pem dh_file = ${raddbdir}/certs/dh random_file = /dev/urandom } ttls { default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = yes } mschapv2 { } peap { default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = yes } mschapv2 { } } raddb/users DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1 User-Name = "%{User-Name}", Fall-Through = Yes DEFAULT Huntgroup-name == "LAN", FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := LAN DEFAULT Huntgroup-name == "AIR", FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := AIR
"Bjarni Hardarson" <freeradius@hardarson.se> wrote:
the correct attributes but the final Access-Accept has no attributes and the User-Name is the anonymous one from the outer tunnel. This username is then used by the AP for accounting. Is this by design or is my configuration wrong?
Looks like it's a bug. The PEAP protocol gets the tunneled "ack", and then continues the PEAP conversation for another packet or so, before sneding the final Access-Accept. The server *should* keep the tunneled reply attributes around, and add them to the final Access-Accept. I'm not sure how best to fix it. Alan DeKok.
"Bjarni Hardarson" <freeradius@hardarson.se> wrote:
When i set use_tunneled_reply = yes for PEAP i get an Access-Challenge with the correct attributes but the final Access-Accept has no attributes and the User-Name is the anonymous one from the outer tunnel. This username is then used by the AP for accounting. Is this by design or is my configuration wrong?
Oh, and please file a bug on bugs.freeradius.org, pointing to these messages from the list, so it isn't lost. Alan DeKok.
participants (2)
-
Alan DeKok -
Bjarni Hardarson