PEAP/MSCHAPv2 authentication problems
wu sheng
wushengws1001 at gmail.com
Fri Aug 25 10:53:43 CEST 2006
Hi Hoercher,
Thank you very much for your advice.
Using ethereal sniffing, I've captured the *packets in the wireless
supplicant interface and the related records are as follows:*
No. Time Source Destination Protocol
Info
65 40.298751 Colubris_f3:dc:20 192.168.1.3 EAP
Request,
Identity [RFC3748]
Frame 65 (27 bytes on wire, 27 bytes captured)
Ethernet II, Src: Colubris_f3:dc:20 (00:03:52:f3:dc:20), Dst:
192.168.1.3(00:0e:35:89:71:e0)
802.1X Authentication
No. Time Source Destination Protocol
Info
66 40.299193 192.168.1.3 Colubris_f3:dc:20 EAP
Response,
Identity [RFC3748]
Frame 66 (30 bytes on wire, 30 bytes captured)
Ethernet II, Src: 192.168.1.3 (00:0e:35:89:71:e0), Dst: Colubris_f3:dc:20
(00:03:52:f3:dc:20)
802.1X Authentication
No. Time Source Destination Protocol
Info
69 50.331149 Colubris_f3:dc:20 192.168.1.3 EAP
Request,
PEAP [Palekar]
Frame 69 (24 bytes on wire, 24 bytes captured)
Ethernet II, Src: Colubris_f3:dc:20 (00:03:52:f3:dc:20), Dst:
192.168.1.3(00:0e:35:89:71:e0)
802.1X Authentication
No. Time Source Destination Protocol
Info
70 50.332306 192.168.1.3 Colubris_f3:dc:20 TLSv1 Client
Hello
Frame 70 (98 bytes on wire, 98 bytes captured)
Ethernet II, Src: 192.168.1.3 (00:0e:35:89:71:e0), Dst: Colubris_f3:dc:20
(00:03:52:f3:dc:20)
802.1X Authentication
No. Time Source Destination Protocol
Info
71 50.355419 Colubris_f3:dc:20 192.168.1.3 TLSv1 Server
Hello, Certificate, Server Hello Done
Frame 71 (696 bytes on wire, 696 bytes captured)
Ethernet II, Src: Colubris_f3:dc:20 (00:03:52:f3:dc:20), Dst:
192.168.1.3(00:0e:35:89:71:e0)
802.1X Authentication
No. Time Source Destination Protocol
Info
72 50.371799 192.168.1.3 Colubris_f3:dc:20 EAP
Response,
PEAP [Palekar]
Frame 72 (24 bytes on wire, 24 bytes captured)
Ethernet II, Src: 192.168.1.3 (00:0e:35:89:71:e0), Dst: Colubris_f3:dc:20
(00:03:52:f3:dc:20)
802.1X Authentication
No. Time Source Destination Protocol
Info
73 50.392452 Colubris_f3:dc:20 192.168.1.3 EAP
Request,
PEAP [Palekar]
Frame 73 (24 bytes on wire, 24 bytes captured)
Ethernet II, Src: Colubris_f3:dc:20 (00:03:52:f3:dc:20), Dst:
192.168.1.3(00:0e:35:89:71:e0)
802.1X Authentication
No. Time Source Destination Protocol
Info
76 60.383628 Colubris_f3:dc:20 192.168.1.3 EAP
Request,
PEAP [Palekar]
Frame 76 (24 bytes on wire, 24 bytes captured)
Ethernet II, Src: Colubris_f3:dc:20 (00:03:52:f3:dc:20), Dst:
192.168.1.3(00:0e:35:89:71:e0)
802.1X Authentication
No. Time Source Destination Protocol
Info
79 70.376465 Colubris_f3:dc:20 192.168.1.3 EAP
Failure
Besides, * the related radius log is as follows:*
rad_recv: Access-Request packet from host 172.24.26.144:1025, id=186,
length=249
Acct-Session-Id = "2e578294"
NAS-Port = 1
NAS-Port-Type = Wireless-802.11
User-Name = "alcatel"
Calling-Station-Id = "00-0E-35-89-71-E0"
Called-Station-Id = "00-03-52-01-84-7D"
EAP-Message =
0x02f3005019800000004616030100410100003d030144ed53ef07a048b6fc29ca4e446ccb5d3fbfca4977bba0fee1d0212aacab134400001600040005000a000900640062000300060013001200630100
State = 0xd5fc64a31e807c1466886de9976ddb63
NAS-Identifier = "R014-00755"
NAS-IP-Address = 172.24.26.144
Framed-MTU = 1496
Connect-Info = "IEEE802.1X"
Service-Type = Framed-User
Message-Authenticator = 0xad27137f763a888a127758b4802d60bd
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 6
modcall[authorize]: module "preprocess" returns ok for request 6
radius_xlat:
'/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824'
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to
/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824
modcall[authorize]: module "auth_log" returns ok for request 6
modcall[authorize]: module "mschap" returns noop for request 6
rlm_realm: No '@' in User-Name = "alcatel", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 6
rlm_eap: EAP packet type response id 243 length 80
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 6
users: Matched entry DEFAULT at line 152
users: Matched entry DEFAULT at line 171
modcall[authorize]: module "files" returns ok for request 6
modcall: leaving group authorize (returns updated) for request 6
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 6
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
rlm_eap_tls: Length Included
eaptls_verify returned 11
(other): before/accept initialization
TLS_accept: before/accept initialization
rlm_eap_tls: <<< TLS 1.0 Handshake [length 0041], ClientHello
TLS_accept: SSLv3 read client hello A
rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello
TLS_accept: SSLv3 write server hello A
rlm_eap_tls: >>> TLS 1.0 Handshake [length 0243], Certificate
TLS_accept: SSLv3 write certificate A
rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone
TLS_accept: SSLv3 write server done A
TLS_accept: SSLv3 flush data
TLS_accept:error in SSLv3 read client certificate A
rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
In SSL Handshake Phase
In SSL Accept mode
eaptls_process returned 13
rlm_eap_peap: EAPTLS_HANDLED
modcall[authenticate]: module "eap" returns handled for request 6
modcall: leaving group authenticate (returns handled) for request 6
Sending Access-Challenge of id 186 to 172.24.26.144 port 1025
Framed-IP-Address = 255.255.255.254
Framed-MTU = 576
Service-Type = Framed-User
EAP-Message =
0x01f402a61900160301004a02000046030144ed52c7791dfb4db0d0bacf1f84744c2e7aa61d8990d0711343cfd7428edc4320d9fdf4f079954337b4c264c8a33c0b2ccca925f5119a4c314a5d25e612fca3aa00040016030102430b00023f00023c000239308202353082019ea003020102020101300d06092a864886f70d01010405003054310b3009060355040613024652310e300c060355040813055061726973310f300d0603550407130656656c697a793110300e060355040a1307416c636174656c31123010060355040313096c6f63616c686f7374301e170d3036303831373131343230355a170d3037303831373131343230355a3054310b
EAP-Message =
0x3009060355040613024652310e300c060355040813055061726973310f300d0603550407130656656c697a793110300e060355040a1307416c636174656c31123010060355040313096c6f63616c686f737430819f300d06092a864886f70d010101050003818d0030818902818100c0b68a2064159d8dc8b4067746ee82384bc71ac4efbf1132ffe1afabf49a207e3e3d553a6e27b1a7c3875c8892c8ebd91a09fd7709e354168e9a4a71e38a936c82e2b857eb5176eae445966adf28ce8f3a31c987aced4d774a9957de5b26bdc300fcee71c0f7139845ebd253c6f27945bbe70fd3501563e231ba1d52419508ed0203010001a31730153013060355
EAP-Message =
0x1d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181001a8366350e04eb86535cbf2b3c4a13c32f5c4455310aad4e23480d695cab9ea9dbdeed10885c1c483beb583e19adaf4e663bc41fe81c3a00a83dbcb86dbae0dd25653c2f2eea11f510cbc359e83589e6236a8456ae91bb0631c30c87172933e625ff3e2571d8781b5a3351179d0ebcd2955b235513684fcdcd288386eb612a8316030100040e000000
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xac69d287747a66f880697ba51187da63
Finished request 6
Going to the next request
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 172.24.26.144:1025, id=144,
length=175
Acct-Session-Id = "2e578294"
NAS-Port = 1
NAS-Port-Type = Wireless-802.11
User-Name = "alcatel"
Calling-Station-Id = "00-0E-35-89-71-E0"
Called-Station-Id = "00-03-52-01-84-7D"
EAP-Message = 0x02f400061900
State = 0xac69d287747a66f880697ba51187da63
NAS-Identifier = "R014-00755"
NAS-IP-Address = 172.24.26.144
Framed-MTU = 1496
Connect-Info = "IEEE802.1X"
Service-Type = Framed-User
Message-Authenticator = 0x96da8d8ab41d8a0d4d4fe964298b1d0f
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 7
modcall[authorize]: module "preprocess" returns ok for request 7
radius_xlat:
'/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824'
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to
/usr/local/var/log/radius/radacct/172.24.26.144/auth-detail-20060824
modcall[authorize]: module "auth_log" returns ok for request 7
modcall[authorize]: module "mschap" returns noop for request 7
rlm_realm: No '@' in User-Name = "alcatel", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 7
rlm_eap: EAP packet type response id 244 length 6
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 7
users: Matched entry DEFAULT at line 152
users: Matched entry DEFAULT at line 171
modcall[authorize]: module "files" returns ok for request 7
modcall: leaving group authorize (returns updated) for request 7
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
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/peap
rlm_eap: processing type peap
rlm_eap_peap: Authenticate
rlm_eap_tls: processing TLS
rlm_eap_tls: Received EAP-TLS ACK message
rlm_eap_tls: ack handshake fragment handler
eaptls_verify returned 1
eaptls_process returned 13
rlm_eap_peap: EAPTLS_HANDLED
modcall[authenticate]: module "eap" returns handled for request 7
modcall: leaving group authenticate (returns handled) for request 7
Sending Access-Challenge of id 144 to 172.24.26.144 port 1025
Framed-IP-Address = 255.255.255.254
Framed-MTU = 576
Service-Type = Framed-User
EAP-Message = 0x01f500061900
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xb2fb4146c8792b2e32313e63983fdbdd
Finished request 7
Going to the next request
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 5 ID 108 with timestamp 44ed52c7
Cleaning up request 7 ID 144 with timestamp 44ed52c7
Cleaning up request 6 ID 186 with timestamp 44ed52c7
Nothing to do. Sleeping until we see a request.
Anyone has some good suggestions? Thanks in advance.
2006/8/23, K. Hoercher <wbhoer at gmail.com>:
>
> On 8/22/06, sheng <wushengws1001 at gmail.com> wrote:
>
> > There's a strange problem: each time the client send a request, the
> server
> > tries to read the client certificate on the supplicant. I think it's
> very
> > strange considering that no client certificate is needed for
> peap/mschapv2.
> > This event is recorded in the handshake phase on the radius logfile(I've
> > listed it in the below). It seems the handshake phase fails because the
> > server cann't read the client certificate.
> [...]
> > TLS_accept:error in SSLv3 read client certificate A
> > rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
> > In SSL Handshake Phase
> > In SSL Accept mode
> > eaptls_process returned 13
> > rlm_eap_peap: EAPTLS_HANDLED
>
> Hi,
>
> if you are referring to the quoted part, that' not a problem. Roughly
> put: openssl just mentiones that it wasn't able to check the client
> cert (which is possible, but unneeded for eap-peap).
>
> > Finished request 3
> > Going to the next request
> > Waking up in 6 seconds...
> > --- Walking the entire request list ---
> > Cleaning up request 2 ID 19 with timestamp 44e9e42f
> > Cleaning up request 3 ID 138 with timestamp 44e9e42f
> > Nothing to do. Sleeping until we see a request.
> > rad_recv: Access-Request packet from host 172.24.26.144:1025, id=137,
> > length=249
> > Acct-Session-Id = "67671438"
> > NAS-Port = 1
> > NAS-Port-Type = Wireless-802.11
> > User-Name = "alcatel"
> > Calling-Station-Id = "00-0E-35-89-71-E0"
> > Called-Station-Id = "00-03-52-01-84-7D"
> > EAP-Message =
> 0x0280005019800000004616030100410100003d030144e9e54ee8bf5c390cecf9fa8b659b32ac0a7eb623919876fa26dd9dc220d75800001600040005000a000900640062000300060013001200630100
> > State = 0x091ad12235d4b0c91ca834c803d04ee0
> [...]
> > modcall: entering group authenticate for request 4
> > rlm_eap: Request not found in the list
> > rlm_eap: Either EAP-request timed out OR EAP-response to an unknown
> > EAP-request
> > rlm_eap: Failed in handler
>
> Which of the two cases mentioned in the debug output to your further
> requests might be happening I'm not sure of. There seems to elapse
> quite some time, before they come in after the challenge was sent out.
> That looks curious.
>
> As your included data got truncated on the list you might consider
> resending it as attachment or use a pastebot and provide the link.
>
> Maybe you could provide some sniffing on the wireless part (via
> wireshark et al). That might be instructive in sorting out when who
> did send what.
>
> regards
> K. Hoercher
> (Hopefully gmail really could not send this out, as it keept telling
> me. Otherwise this must be the 5th reply, if so please excuse me.)
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
--
Best Wishes,
Sheng Wu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20060825/09b40911/attachment.html>
More information about the Freeradius-Users
mailing list