accepting clients with expired certificates
I have setup authentication against AD according to: http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO This works as expected. If the client's certificate is expired, eap/tls will, of course, fail. In this case a guest vlan shall be assigned to the client. Having a module, that adds the needed radius-attributes seems to work, if an additional Auth-Type += Accept is added. Doing this, the eap-tls is short-circuited and may result in a: Incoming RADIUS packet did not have correct Message-Authenticator - dropped message on the client side. Is this acceptable? What would be the best way to handle a situation like that? Norbert Wegener
Norbert Wegener wrote:
If the client's certificate is expired, eap/tls will, of course, fail. In this case a guest vlan shall be assigned to the client.
I'm not sure that's good enough. The client may not believe it was successfully authenticated until the TLS session is properly finished.
Having a module, that adds the needed radius-attributes seems to work, if an additional Auth-Type += Accept is added. Doing this, the eap-tls is short-circuited and may result in a:
Incoming RADIUS packet did not have correct Message-Authenticator - dropped message on the client side.
Try adding a Message-Authenticator to the reply. Any value will do, as it will be re-calculated when the packet is sent. Alan DeKok.
Alan DeKok wrote:
...
Incoming RADIUS packet did not have correct Message-Authenticator - dropped message on the client side.
Try adding a Message-Authenticator to the reply. Any value will do, as it will be re-calculated when the packet is sent.
freeradius now sends a Message-Authenticator with value 0x00: rad_check_password: Auth-Type = Accept, accepting the user Sending Access-Accept of id 0 to 156.215.207.190 port 58366 Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Tunnel-Private-Group-Id:0 = "VL-G-DE-GU14-0001" Message-Authenticator <BARE-WORD> 0x00000000000000000000000000000000 Finished request 0 but there seems to be a problem on the other end, as eapol_test shows: STA 00:00:00:00:00:02: Received RADIUS packet matched with a pending request, round trip time 0.05 sec RADIUS packet matching with station could not extract EAP-Message from RADIUS message EAPOL: startWhen --> 0 EAPOL test timed out MPPE keys OK: 0 mismatch: 1 FAILURE freeradius version is 1.1.6 Norbert Wegener -- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Norbert Wegener Siemens AG Siemens IT Solutions and Services SBS GO GIO NW PSU2 Kruppstr. 16 D-46128 Essen, Germany Phone : +49 (0) 201 816-3116 Fax. : +49 (0) 201 816-5581284 mailto:norbert.wegener@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme Vorstand: Peter Löscher, Vorsitzender; Johannes Feldmayer, Heinrich Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus Wucherer Sitz der Gesellschaft: Berlin und München; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 WEEE-Reg.-Nr. DE 23691322
Norbert Wegener wrote:
freeradius now sends a Message-Authenticator with value 0x00: ... but there seems to be a problem on the other end, as eapol_test shows:
STA 00:00:00:00:00:02: Received RADIUS packet matched with a pending request, round trip time 0.05 sec RADIUS packet matching with station could not extract EAP-Message from RADIUS message
Yes. As I said, the supplicant may not like it if you don't complete the whole TLS conversation. At the minimum, you'll need to send an EAP Success packet inside of the EAP-Message attribute. But don't expect that to work. If the client certificate has expired, the odds are that the client *cannot* be authenticated, even with the sacrifice of small animals, and the sprinkling of their leavings in graveyards at midnight... Alan DeKok.
participants (2)
-
Alan DeKok -
Norbert Wegener