hi
Anyway I have tested even without any User-Password entry against XP's "Administrator" login. And surprisingly got same result (that "Success" message before client certificate verification). Am I doing someting wrong?
well, imho, it should not behave in a wrong way even if there is a user...
i wanted to ask you which supplicant you are using or generally how you managed not to send the client certificate (if this is really the case) since the most supplicants would do so automatically.
ok, so the interesting part of the log starts here:
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 0694], Certificate
TLS_accept: SSLv3 write certificate A
rlm_eap_tls: >>> TLS 1.0 Handshake [length 00b1], CertificateRequest
TLS_accept: SSLv3 write certificate request A
TLS_accept: SSLv3 flush data
TLS_accept:error in SSLv3 read client certificate A
In SSL Handshake Phase
In SSL Accept mode
eaptls_process returned 13
ok, if i understand it correctly, it could not read the client certificate (which is quite normal here because it is just requesting the certificate). so in the next message the requested certificate should appear.
but: i could be VERY wrong in these wild assumptions. what you can do, is to compare this log to the log of Ken Roser out of his PDF-howto (it's on the freeradius website).
modcall[authenticate]: module "eap" returns handled for request 1
modcall: group authenticate returns handled for request 1
Sending Access-Challenge of id 4 to 10.0.0.1:21645
EAP-Message =
0x0104040a0dc00000079e160301004a02000046030140c5b760373179a906f712e477ff2addbba152897af7bb796e864f74fa5e447b20a773c1f550b1bef0d013e9c9e35e5ab375bb1f1524a27d276199b2342fccd7bc00040016030106940b00069000068d0002cd308202c930820232a003020102020102300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e74206365
EAP-Message =
0x7274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d301e170d3034303132353133323631305a170d3035303132343133323631305a30819b310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f73743119301706035504031310526f6f74206365727469666963617465311f301d06092a864886f70d0109011610726f6f74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003
EAP-Message =
0x818d0030818902818100dac525422bfedb082629a2cba44b3449c90d0ab462fb72c8434a782098863d7eb7d7e70028c2b7ad555a51cc756cf4fa1d7091615ab450d5289553ae6616aff014a55085d6b8fb4aee98638e426175cdd36c665c63cda177d34920eb30585edc8773999c2980f81ad4638bbbea1c82d054023db7ef24a3ec1c3f6241a903d7f30203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181007a2d921b1cf13bf2982a9178ec9ede6d88edc178a2e8bd40a0a06fb6f0769957884cd7084537083496fd184165293f583c8e8240eb68e042c94b15752e4c07e80d09
EAP-Message =
0x779afa3dd55c24fa54ac292d77205d1c2477ed30d59f57caf9bd21ff2a8d16cc0911c50e4f295763fcb60efa3c3d2d0e43850f6e6fbe284902f6e83503650003ba308203b63082031fa003020102020100300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c
EAP-Message = 0x652e636f6d301e170d3034303132353133323630375a
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x2852b1a60ade88586b0a538bdc340943
ok, so it's sent the request.
Finished request 1
Going to the next request
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 10.0.0.1:21645, id=5, length=150
User-Name = "Administrator"
Framed-MTU = 1400
Called-Station-Id = "000f.24a0.9ee0"
Calling-Station-Id = "0004.e280.fb7b"
Message-Authenticator = 0x6a14a6b264e5a205e622d32e29904386
EAP-Message = 0x020400060d00
NAS-Port-Type = Wireless-802.11
NAS-Port = 260
State = 0x2852b1a60ade88586b0a538bdc340943
Service-Type = Framed-User
NAS-IP-Address = 10.0.0.1
NAS-Identifier = "IXIA-AP"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 2
modcall[authorize]: module "preprocess" returns ok for request 2
rlm_eap: EAP packet type response id 4 length 6
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 2
users: Matched Administrator at 153
modcall[authorize]: module "files" returns ok for request 2
modcall: group authorize returns updated for request 2
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 2
rlm_eap: Request found, released from the list
rlm_eap: EAP/tls
rlm_eap: processing type tls
rlm_eap_tls: Authenticate
rlm_eap_tls: processing TLS
rlm_eap_tls: Received EAP-TLS ACK message
rlm_eap_tls: ack handshake fragment handler
ok, so it received the TLS ACK and nothing more. it's because the server is fragmenting its packet. the second fragment follows.
eaptls_verify returned 1
eaptls_process returned 13
modcall[authenticate]: module "eap" returns handled for request 2
modcall: group authenticate returns handled for request 2
Sending Access-Challenge of id 5 to 10.0.0.1:21645
EAP-Message =
0x010503a80d800000079e170d3036303132343133323630375a30819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003818d0030818902818100d4c5b19724f164acf1ffb189db1c8fbff4f14396ea7cb1e90f78d69451725377895dfe52cc
EAP-Message =
0xb99b41e80ddeb58b127a943f4f58cbc562878192fbdc6fece9f871e7c130d35cf5188817e9b133249edd2a1c75d31043ae87553cec7a77ef26aa7d74281db9b77e17c6446c5dd9b188b43250ca0229963722a123a726b00b4027fd0203010001a381ff3081fc301d0603551d0e0416041468d36d3e1ee7bc9d5a057021c363da1365d1ade33081cc0603551d230481c43081c1801468d36d3e1ee7bc9d5a057021c363da1365d1ade3a181a5a481a230819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e
EAP-Message =
0x31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d820100300c0603551d13040530030101ff300d06092a864886f70d01010405000381810033c00b66b1e579ef73a06798252dab8d5e5511fc00fd276d80d12f834777c6743fdc2743fca1507704e4bc0979e4f60ac3ad9ee83e6f347369229d1f77229ba2e982359da563024a00163dba6d6c986c0bad28af85132ff8f0d76501bf1b7c2dff658ce1e62c01997b6e64e3e8d4373354ce9912847651539063b85bbc5485c516030100b1
EAP-Message =
0x0d0000a902010200a400a230819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d0e000000
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x82732ea43ffc08d382ef30e52e29a64f
Finished request 2
that was the last fragment of server's data + cient cert request.
Going to the next request
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 10.0.0.1:21645, id=6, length=150
User-Name = "Administrator"
Framed-MTU = 1400
Called-Station-Id = "000f.24a0.9ee0"
Calling-Station-Id = "0004.e280.fb7b"
Message-Authenticator = 0x5f7cff95457c0a4ea00fe4a99a352976
EAP-Message = 0x020500060d00
NAS-Port-Type = Wireless-802.11
NAS-Port = 260
State = 0x82732ea43ffc08d382ef30e52e29a64f
Service-Type = Framed-User
NAS-IP-Address = 10.0.0.1
NAS-Identifier = "IXIA-AP"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 3
modcall[authorize]: module "preprocess" returns ok for request 3
rlm_eap: EAP packet type response id 5 length 6
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 3
users: Matched Administrator at 153
modcall[authorize]: module "files" returns ok for request 3
modcall: group authorize returns updated for request 3
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 3
rlm_eap: Request found, released from the list
rlm_eap: EAP/tls
rlm_eap: processing type tls
rlm_eap_tls: Authenticate
rlm_eap_tls: processing TLS
rlm_eap_tls: Received EAP-TLS ACK message
eaptls_verify returned 3
eaptls_process returned 3
rlm_eap: Freeing handler
modcall[authenticate]: module "eap" returns ok for request 3
modcall: group authenticate returns ok for request 3
so the server gets one more ACK for its last fragment.
that's strange:
Sending Access-Accept of id 6 to 10.0.0.1:21645
MS-MPPE-Recv-Key =
0x1a03837426e097d46c69798b4b5a79a0385b36302056aa5619bbb0a3f84e289b
MS-MPPE-Send-Key =
0x09ee49ef3de2120a353bc14e678a49cfb6db41a14fa20ae12d7ceea87bc22b6f
EAP-Message = 0x03050004
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "Administrator"
Finished request 3
Going to the next request
Waking up in 6 seconds...
since it still has not received the requested client certificate.
Alan??? am i wrong or is something wrong here?
ciao artur
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
