Hi, i get the listet log. The freeradius server identify the request as EAP. But why it startet rlm_eap_tls? I thought he gots the message, notice its EAP and take the password from users (file). But it start tls handshake, and fails. (Where i can see how rlm_eap, rlm_eap_tls is configured?) Second queston, why no decision occurs, i found no reject or accept!? Thx for your help Michael LOG: rad_recv: Access-Request packet from host 192.168.1.3:1812, id=39, length=98 NAS-IP-Address = 192.168.1.3 NAS-Port = 50010 NAS-Port-Type = Ethernet User-Name = "test" Calling-Station-Id = "00-04-75-DA-4C-C8" Service-Type = Framed-User EAP-Message = 0x020100090174657374 Message-Authenticator = 0xe6b2e1c93f52004f14bc268c7894ecfd Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 1 length 9 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 users: Matched entry test at line 54 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns updated for request 0 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 0 modcall: group authenticate returns handled for request 0 Sending Access-Challenge of id 39 to 192.168.1.3:1812 EAP-Message = 0x010200061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x163120a63f7aadd336b0e76ac31c0c17 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 192.168.1.3:1812, id=40, length=187 NAS-IP-Address = 192.168.1.3 NAS-Port = 50010 NAS-Port-Type = Ethernet User-Name = "test" Calling-Station-Id = "00-04-75-DA-4C-C8" Service-Type = Framed-User State = 0x163120a63f7aadd336b0e76ac31c0c17 EAP-Message = 0x0202005019800000004616030100410100003d030142d27e6d475fe32bebed7ae37075c341 be0fadba80a11c04f8c468ea02ff68cf00001600040005000a00090064006200030006001300 1200630100 Message-Authenticator = 0x4b27203775b97e4a9a3d543a7cba95ea Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 2 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1 users: Matched entry test at line 54 modcall[authorize]: module "files" returns ok for request 1 modcall: group authorize returns updated for request 1 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 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 05ae], 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 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 1 modcall: group authenticate returns handled for request 1 Sending Access-Challenge of id 40 to 192.168.1.3:1812 EAP-Message = 0x0103040a19c00000060b160301004a02000046030142d28da92d2e3dce36fa41299b41b3fc eb9337e0419cc9955f8b503ad12741e7200a3d67a894ec4885fa5638a70585a57dd1bbd308a7 e196f4321a4bedc481a1ea00040016030105ae0b0005aa0005a70002723082026e308201d7a0 03020102020900c54a18eee8c82a38300d06092a864886f70d0101040500306d310b30090603 55040613024445311630140603550408130d4e69656465727361636873656e3111300f060355 0407130848616e6e6f766572310c300a060355040a130346484831133011060355040b130a49 6e666f726d6174696b3110300e06035504031307696473526f6f EAP-Message = 0x74301e170d3035303632343130323030315a170d3036303632343130323030315a306c310b 3009060355040613024445311630140603550408130d4e69656465727361636873656e311130 0f0603550407130848616e6e6f766572310c300a060355040a13034648483113301106035504 0b130a496e666f726d6174696b310f300d0603550403130669647353727630819f300d06092a 864886f70d010101050003818d0030818902818100c41bbdefa0e18b7a86822e40a288bde770 208e2d664594692a0f29d6e17136c8bbcd069ff636f713d199bdf76fbda405cd94f2dfefd2fa 32d4b6cc7b54858519b304e911fbcf2441e1a4ba3b3e43413198 EAP-Message = 0xbd985b957133ad10246bf90575d1dc33d20c06720f4cb6f6fe2e3ab749bac6ca0cc182d144 d38945377be15bb03f510203010001a317301530130603551d25040c300a06082b0601050507 0301300d06092a864886f70d0101040500038181004a500df63d64c6068e07e6114f7b2b317b 998ecf50b5e4493087776e204c59f6e8ea54150c473d694ccf6892a07f497de3c8b19668ba1a ccc40d9c6a56141de74fe7613e30979eb17f3ffdd52a6ddab7c3858eda356fe7c0fc7de24f61 637c7bfe98d71a5e949609574cdaa3d9cd0453bf09c5c57df30dc7ff1827baf4a1dbeb00032f 3082032b30820294a003020102020900c54a18eee8c82a36300d EAP-Message = 0x06092a864886f70d0101040500306d310b3009060355040613024445311630140603550408 130d4e69656465727361636873656e3111300f0603550407130848616e6e6f766572310c300a 060355040a130346484831133011060355040b130a496e666f726d6174696b3110300e060355 04031307696473526f6f74301e170d3035303632343130313834395a170d3037303632343130 313834395a306d310b3009060355040613024445311630140603550408130d4e696564657273 61636873656e3111300f0603550407130848616e6e6f766572310c300a060355040a13034648 4831133011060355040b130a496e666f726d6174696b3110300e EAP-Message = 0x06035504031307696473526f6f7430819f300d06092a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x6d3082dd717b8f84c8e57ba72651e779 Finished request 1 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 39 with timestamp 42d28da9 Cleaning up request 1 ID 40 with timestamp 42d28da9 Nothing to do. Sleeping until we see a request. -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
"Michael Langer" <mphantom@gmx.net> wrote:
i get the listet log. The freeradius server identify the request as EAP. But why it startet rlm_eap_tls?
Because PEAP uses TLS.
I thought he gots the message, notice its EAP and take the password from users (file). But it start tls handshake, and fails. (Where i can see how rlm_eap, rlm_eap_tls is configured?)
The debug log does now show a failure.
Second queston, why no decision occurs, i found no reject or accept!?
The client stops talking to the server in the middle of the EAP conversation. As a result, there is no accept or reject, because the client stopped asking to be authenticated. Alan DeKok.
Thx for response!!!
i get the listet log. The freeradius server identify the request as EAP. But why it startet rlm_eap_tls?
Because PEAP uses TLS.
TLS is used between windows 2000 and freeradius, or freeradius and cisco switch? I thought windows talk to cisco by ms-chapv2? Sorry now im confused. Can one say me shortly who is speaking over what protocol?
I thought he gots the message, notice its EAP and take the password from users (file). But it start tls handshake, and fails. (Where i can see how rlm_eap, rlm_eap_tls is configured?)
The debug log does now show a failure.
but both, the client and the root, certificates are installed on windows 2000 client. best regards Michael Langer
"Michael Langer" <mphantom@gmx.net> wrote:
TLS is used between windows 2000 and freeradius, or freeradius and cisco switch? I thought windows talk to cisco by ms-chapv2?
PEAP is EAP-TLS with EAP-MSCHAPv2 inside of the TLS tunnel.
but both, the client and the root, certificates are installed on windows 2000 client.
That doesn't matter. The debug log you posted does NOT show a reject. Alan DeKok.
TLS is used between windows 2000 and freeradius, or freeradius and cisco switch? I thought windows talk to cisco by ms-chapv2?
PEAP is EAP-TLS with EAP-MSCHAPv2 inside of the TLS tunnel.
but both, the client and the root, certificates are installed on windows 2000 client.
That doesn't matter.
The debug log you posted does NOT show a reject.
Ok now thats clear, but at what point the challenge stop? For me it seems, that the first step (TLS Chanel) is done!? Michael Langer LOG again: rad_recv: Access-Request packet from host 192.168.1.3:1812, id=39, length=98 NAS-IP-Address = 192.168.1.3 NAS-Port = 50010 NAS-Port-Type = Ethernet User-Name = "test" Calling-Station-Id = "00-04-75-DA-4C-C8" Service-Type = Framed-User EAP-Message = 0x020100090174657374 Message-Authenticator = 0xe6b2e1c93f52004f14bc268c7894ecfd Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 1 length 9 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 users: Matched entry test at line 54 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns updated for request 0 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 0 modcall: group authenticate returns handled for request 0 Sending Access-Challenge of id 39 to 192.168.1.3:1812 EAP-Message = 0x010200061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x163120a63f7aadd336b0e76ac31c0c17 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 192.168.1.3:1812, id=40, length=187 NAS-IP-Address = 192.168.1.3 NAS-Port = 50010 NAS-Port-Type = Ethernet User-Name = "test" Calling-Station-Id = "00-04-75-DA-4C-C8" Service-Type = Framed-User State = 0x163120a63f7aadd336b0e76ac31c0c17 EAP-Message = 0x0202005019800000004616030100410100003d030142d27e6d475fe32bebed7ae37075c341 be0fadba80a11c04f8c468ea02ff68cf00001600040005000a00090064006200030006001300 1200630100 Message-Authenticator = 0x4b27203775b97e4a9a3d543a7cba95ea Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 2 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1 users: Matched entry test at line 54 modcall[authorize]: module "files" returns ok for request 1 modcall: group authorize returns updated for request 1 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 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 05ae], 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 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 1 modcall: group authenticate returns handled for request 1 Sending Access-Challenge of id 40 to 192.168.1.3:1812 EAP-Message = 0x0103040a19c00000060b160301004a02000046030142d28da92d2e3dce36fa41299b41b3fc eb9337e0419cc9955f8b503ad12741e7200a3d67a894ec4885fa5638a70585a57dd1bbd308a7 e196f4321a4bedc481a1ea00040016030105ae0b0005aa0005a70002723082026e308201d7a0 03020102020900c54a18eee8c82a38300d06092a864886f70d0101040500306d310b30090603 55040613024445311630140603550408130d4e69656465727361636873656e3111300f060355 0407130848616e6e6f766572310c300a060355040a130346484831133011060355040b130a49 6e666f726d6174696b3110300e06035504031307696473526f6f EAP-Message = 0x74301e170d3035303632343130323030315a170d3036303632343130323030315a306c310b 3009060355040613024445311630140603550408130d4e69656465727361636873656e311130 0f0603550407130848616e6e6f766572310c300a060355040a13034648483113301106035504 0b130a496e666f726d6174696b310f300d0603550403130669647353727630819f300d06092a 864886f70d010101050003818d0030818902818100c41bbdefa0e18b7a86822e40a288bde770 208e2d664594692a0f29d6e17136c8bbcd069ff636f713d199bdf76fbda405cd94f2dfefd2fa 32d4b6cc7b54858519b304e911fbcf2441e1a4ba3b3e43413198 EAP-Message = 0xbd985b957133ad10246bf90575d1dc33d20c06720f4cb6f6fe2e3ab749bac6ca0cc182d144 d38945377be15bb03f510203010001a317301530130603551d25040c300a06082b0601050507 0301300d06092a864886f70d0101040500038181004a500df63d64c6068e07e6114f7b2b317b 998ecf50b5e4493087776e204c59f6e8ea54150c473d694ccf6892a07f497de3c8b19668ba1a ccc40d9c6a56141de74fe7613e30979eb17f3ffdd52a6ddab7c3858eda356fe7c0fc7de24f61 637c7bfe98d71a5e949609574cdaa3d9cd0453bf09c5c57df30dc7ff1827baf4a1dbeb00032f 3082032b30820294a003020102020900c54a18eee8c82a36300d EAP-Message = 0x06092a864886f70d0101040500306d310b3009060355040613024445311630140603550408 130d4e69656465727361636873656e3111300f0603550407130848616e6e6f766572310c300a 060355040a130346484831133011060355040b130a496e666f726d6174696b3110300e060355 04031307696473526f6f74301e170d3035303632343130313834395a170d3037303632343130 313834395a306d310b3009060355040613024445311630140603550408130d4e696564657273 61636873656e3111300f0603550407130848616e6e6f766572310c300a060355040a13034648 4831133011060355040b130a496e666f726d6174696b3110300e EAP-Message = 0x06035504031307696473526f6f7430819f300d06092a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x6d3082dd717b8f84c8e57ba72651e779 Finished request 1 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 39 with timestamp 42d28da9 Cleaning up request 1 ID 40 with timestamp 42d28da9 Nothing to do. Sleeping until we see a request. -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
"Michael Langer" <mphantom@gmx.net> wrote:
The debug log you posted does NOT show a reject.
Ok now thats clear, but at what point the challenge stop? For me it seems, that the first step (TLS Chanel) is done!?
Perhaps, but that's not the end of the conversation. The challenges stop when the server sends an Access-Accept or Access-Reject. If you want a more detailed explanation, it would involve explaining the internals of the protocol, which is best done by reading the specifications. Alan DeKok.
participants (2)
-
Alan DeKok -
Michael Langer