Problems using EAP-TLS with freeradius version 2
Hello again, @Alan DeKok
But I would first suggest trying to use the test certificates that come with 2.0.1. If those work, then the issue isn't 2.0.0 versus 1.1.7, it's that there is something special about the certificates you're using. I tried to generate some test certificates using the README file provided in the source-code under "freeradius-server-2.0.1/raddb/certs/" Therefore the Makefile is used in the same directory. I'm not really sure, but in Line 93 where the "client.pem" is created it must be -passin pass:$(PASSWORD_CLIENT) instead of -passin pass:$(PASSWORD_SERVER)
Most of the time you will not recognize, because in server.cnf and client.cnf all the passwords are set to "whatever" so they are identical, but when you set them, you will get an error (like me). It would also be helpful to integrate the following command into the ca section, when generating a self-signed CA certificate, because using Windows you need the CA in DER-format: openssl x509 -inform PEM -outform DER -in ca.pem -out ca.der This evening I will try to test if this certificates are working. @Reimer Karlsen-Masur
We know of problems with EE certificates in PDAs containing the "non-repudiation" flag.
Additionally Windows build-in supplicants don't like EE certificates with the extendedKeyUsage "Microsoft Smartcard Logon" (1.3.6.1.4.1.311.20.2.2) when doing EAP-TLS.
Apparently the latter issue can also be solved by just disabling the valid certificate usage of Microsoft Smartcard Logon in the issuing CAs trusted usages properties on the system. I'm not sure if understand correctly what you want to say to me (I'm stupid :-)) First I've used TinyCA to generate my certificates, now I will try the Makefile provided in the source-code of freeradius. I think the extendedKeyUsage "Microsoft Smartcard Logon" should not be set in both variants. Or do you mean that the extendedKeyUsage "Microsoft Smartcard Logon" must be disabled on the PDA?
Best regards and thanks in advance Stefan Puch
Stefan Puch wrote on 31.01.2008 17:05:
Hello again, ... @Reimer Karlsen-Masur
We know of problems with EE certificates in PDAs containing the "non-repudiation" flag.
If the "non-repudiation" keyUsage *is part* of your client certificates they might not work with some PDAs build-in supplicants. We found this out by try and error...
Additionally Windows build-in supplicants don't like EE certificates with the extendedKeyUsage "Microsoft Smartcard Logon" (1.3.6.1.4.1.311.20.2.2) when doing EAP-TLS.
Apparently the latter issue can also be solved by just disabling the valid certificate usage of Microsoft Smartcard Logon in the issuing CAs trusted usages properties on the system. I'm not sure if understand correctly what you want to say to me (I'm stupid :-)) First I've used TinyCA to generate my certificates, now I will try the Makefile provided in the source-code of freeradius. I think the extendedKeyUsage "Microsoft Smartcard Logon" should not be set in both variants.
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant. If the "Microsoft Smartcard Logon" extendedKeyUsage *is not part* of your client certificates this causes less problems with Windows build-in supplicant.
Or do you mean that the extendedKeyUsage "Microsoft Smartcard Logon" must be disabled on the PDA?
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates you could work around this by disabling the trust setting of valid certificate usage "Microsoft Smartcard Logon" in the CAs properties in Windows build-in certificate store on the PDA. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
@Reimer Karlsen-Masur
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates you could work around this by disabling the trust setting of valid certificate usage "Microsoft Smartcard Logon" in the CAs properties in Windows build-in certificate store on the PDA. As the "Microsoft Smartcard Logon" extendedKeyUsage *is NOT part* of the client certificates there should be no problem. Something different seems to be not correct.
Did you get a PDA using Windows Mobile working with EAP-TLS with Windows build-in supplicant and freeradius? If yes, can you tell me which freeradius version? I did one get a Windows Mobile working using the build-in supplicant and EAP-PEAP using mschapv2 and freeradius 1.1.7 @Alan DeKok I didn't find any test certificates that come with 2.0.1. I think you talk about the "bootstrap" script which can create some test certificates, don't you? If so, here are the results: - running "bootstrap" creates ca.pem, server.pem, dh and random which are used with the radius server (server.pem is signed with ca.pem) - running make client.pem creates a client certificate which is signed by the server certificate (in my opinion that cannot work but I did). I used that certificate and ca.pem (according to the README) with wpa_supplicant on my linux laptop - when trying to connect to the radius server the validation fails with following output from "radiusd -X" (because the the client cert is not signed with ca.pem): ... ... +- entering group authenticate 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake rlm_eap_tls: <<< TLS 1.0 Handshake [length 038d], Certificate --> verify error:num=20:unable to get local issuer certificate rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert write:fatal:unknown CA TLS_accept:error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. eaptls_process returned 13 rlm_eap: Freeing handler ++[eap] returns reject auth: Failed to validate the user. Login incorrect: [user@example.com/<via Auth-Type = EAP>] (from client AP-Tower port 1 cli 00095BC95B52) Found Post-Auth-Type Reject +- entering group REJECT ++- group REJECT returns noop ------------------------------------------------------------------------------------------ - Then I changed the Makefile, so that the client cert is signed with the ca.pem like the server certificate is (wouldn't be that the correct way?) - when trying to connect to the radius server the validation success with following output from "radiusd -X": ... ... +- entering group authenticate 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake rlm_eap_tls: <<< TLS 1.0 Handshake [length 0750], Certificate chain-depth=1, error=0 --> User-Name = user@example.com --> BUF-Name = Example Certificate Authority --> subject = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> issuer = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> verify return:1 chain-depth=0, error=0 --> User-Name = user@example.com --> BUF-Name = user@example.com --> subject = /C=FR/ST=Radius/O=Example Inc./CN=user@example.com/emailAddress=user@example.com --> issuer = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> verify return:1 TLS_accept: SSLv3 read client certificate A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0106], CertificateVerify TLS_accept: SSLv3 read certificate verify A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 23 to 192.168.0.8 port 1140 EAP-Message = 0x010800450d800000003b140301000101160301003031e600309274b2c95b4c91d60b518c86b678535f6f72e1ea9786b7ff77f6f405392a8 b9ddcd13285e0683603d2669f42 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x80a5541786ad5978313d7a01a03396c4 Finished request 6. Going to the next request Waking up in 0.2 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1140, id=24, length=198 Message-Authenticator = 0xd8bec720128818f3ea6b29158e3a0cae Service-Type = Framed-User User-Name = "user@example.com" Framed-MTU = 1488 State = 0x80a5541786ad5978313d7a01a03396c4 Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00095BC95B52" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x020800060d00 NAS-IP-Address = 192.168.0.8 NAS-Port = 1 NAS-Port-Id = "STA port # 1" +- entering group authorize ... ... +- entering group authenticate 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 is finished eaptls_verify returned 3 eaptls_process returned 3 rlm_eap: Freeing handler ++[eap] returns ok Login OK: [user@example.com/<via Auth-Type = EAP>] (from client AP-Tower port 1 cli 00095BC95B52) +- entering group post-auth ------------------------------------------------------------------------------------------ The problem is, that after the "Login OK" nothing futher happens, e.g. the clients cannot carry using dhcp. The dhcp-client is started, but the request doesn't reach the dhcp-server. So I downgraded again from 2.0.1 to freeradius 1.1.7 and tested everything again: The first client certificate, which was signed with der server certificate didn't work, the second one worked fine AND the when after "Login OK" the dhcp-client is started, the dhcp-server gets the requests and can answer. The first question I would like to get an answer for is: Which certificate is needed to sign the client certificate, the CA certificate or the server certificate? The second question is: Are there any further suggestions or do I have to make an ethereal trace? Perhaps you can send me some test certs that should really work, so that I can exclude the certs when debugging/analyzing the rest? Best regards Stefan Puch
Stefan Puch wrote on 01.02.2008 09:57:
@Reimer Karlsen-Masur
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates you could work around this by disabling the trust setting of valid certificate usage "Microsoft Smartcard Logon" in the CAs properties in Windows build-in certificate store on the PDA. As the "Microsoft Smartcard Logon" extendedKeyUsage *is NOT part* of the client certificates there should be no problem. Something different seems to be not correct.
Did you get a PDA using Windows Mobile working with EAP-TLS with Windows build-in supplicant and freeradius?
I am afraid, we do not have a Win Mob PDA to test things available. Problems with the non-repudiation keyUsage occured with a SymbianOS based PDA. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Stefan Puch wrote:
- running "bootstrap" creates ca.pem, server.pem, dh and random which are used with the radius server (server.pem is signed with ca.pem)
- running make client.pem creates a client certificate which is signed by the server certificate (in my opinion that cannot work
I guess all of the people using that exact scenario are deluding themselves.
- when trying to connect to the radius server the validation fails with following output from "radiusd -X" (because the the client cert is not signed with ca.pem):
No. It's failing because the server hasn't been told that it's server certificate is a known CA. SSL is weird that way.
- Then I changed the Makefile, so that the client cert is signed with the ca.pem like the server certificate is (wouldn't be that the correct way?)
No. But it *will* work, too. It may take less effort to get it to work.
The problem is, that after the "Login OK" nothing futher happens, e.g. the clients cannot carry using dhcp. The dhcp-client is started, but the request doesn't reach the dhcp-server.
The "login OK" message is nothing more than a suggestion in the radius logs. What is *important* is: - was an Access-Accept sent back? The rest of the debug log that you deleted should show that - was the Access-Accept understood and processed by the NAS? See the NAS for details. If the server sent an Access-Accept, and the user still doesn't have network access, then the NAS chose to disconnect the user. This is basic RADIUS knowledge.
So I downgraded again from 2.0.1 to freeradius 1.1.7 and tested everything again: The first client certificate, which was signed with der server certificate didn't work, the second one worked fine AND the when after "Login OK" the dhcp-client is started, the dhcp-server gets the requests and can answer.
You're stuck on the wrong pieces of information. The certificates are irrelevant. What is actually happening is that you've configured 2.0.1 and 1.1.7 *differently*. The contents of the final Access-Accept sent by 2.0.1 are different from the contents sent by 1.1.7. Since you configured the contents, you are responsible for making sure that the contents are identical, and that the NAS accepts them. The NAS doesn't look at the certificates. It doesn't care. It *does* care if it isn't told the right information in the Access-Accept. I'll bet that if you posted the final Access-Accept from 1.1.7 and from 2.0.1, that they would be *different*. If you make them the same, I'll also bet that the NAS will accept the user.
The first question I would like to get an answer for is: Which certificate is needed to sign the client certificate, the CA certificate or the server certificate?
Either. It depends on how you want to do it.
The second question is: Are there any further suggestions or do I have to make an ethereal trace? Perhaps you can send me some test certs that should really work, so that I can exclude the certs when debugging/analyzing the rest?
The certificates are fine. Don't claim that the certificates don't work. Many people have them working in real-world and test environments. Stop fighting with the certificates. You're wasting your time, and confusing yourself. Start looking at the contents of the Access-Accept, which is the only thing that really matters. Alan DeKok.
@Alan DeKok
I'll bet that if you posted the final Access-Accept from 1.1.7 and from 2.0.1, that they would be *different*. If you make them the same, I'll also bet that the NAS will accept the user. You were right (you win the bet), I accidentally commented out an entry in the "default"-file, which setting were included in radiusd.conf in previous version of freeradius
Stop fighting with the certificates. You're wasting your time, and confusing yourself. Start looking at the contents of the Access-Accept, which is the only thing that really matters. With that hint I was able to get Windows and Linux Laptops working again using EAP-TLS and freeradius 2.0.1. I also managed to get a WM2003 and a WM6 PDA connecting using EAP-PEAP. For using EAP-TLS with the Windows Mobile devices I still have to solve one problem, which I think would be no problem for you, the problem with the username of the devices.
If I disable the option "check_cert_cn = %{User-Name}" in eap.conf I get a working configuration, but finally it should work also with that Option enabled. The problem of the Windows Mobile devices is, that they always submit as username "DOMAIN\user". If you leave the DOMAINNAME blank still "\user" is used. Since the radiusd.conf hints say, that I should NOT use the option "with_ntdomain_hack" (and when I tested it still didn't work for me) I wanted to use the "Realm module". But at the moment I didn't fully understand how realms work, although I did read the Posting on this mailinglist (from 2004) and the manpage. I Know that I will have to use the realm module # 'domain\user' realm ntdomain { format = prefix delimiter = "\\" } therefore, but what else do I have to configure when I want to use a "blank" domain? First I tried with a domain called "bla" which is configured in proxy.conf: realm bla { authhost = LOCAL accthost = LOCAL } The attached logfile shows, that the username is stripped correctly, but obviously the stripped username in not passed correctly to the eap module. Can anyone tell me, what else I have to configure? My goal is simply to strip the "empty" domain from the username, so that eap-tls work with the option "check_cert_cn = %{User-Name}" enabled in eap.conf In short: How do I specify an empty domain (realm "" {authhost = LOCAL, accthost = LOCAL} doesn't work)? What else do I have to configure, when the realm ntdomain is set in radiusd.conf (I have also set ntdomain in "authorize" and "preacct" section) Best regards and thanks in advance Stefan Puch PS: When I've got a working configuration for the Windows Mobile devices, I'm going to write a little HOWTO like the one "EAP/TLS Setup for FreeRADIUS and Windows XP Supplicant" just for Mobile PDA's FreeRADIUS Version 2.0.1, for host i586-mandriva-linux-gnu, built on Jan 24 2008 at 21:20:10 Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. Starting - reading configuration files ... including configuration file /etc/raddb/radiusd.conf including configuration file /etc/raddb/proxy.conf including configuration file /etc/raddb/clients.conf including configuration file /etc/raddb/snmp.conf including configuration file /etc/raddb/eap.conf including configuration file /etc/raddb/policy.conf including files in directory /etc/raddb/sites-enabled/ including configuration file /etc/raddb/sites-enabled/default including dictionary file /etc/raddb/dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "/var/log/radius" libdir = "/usr/lib/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 allow_core_dumps = no pidfile = "/var/run/radiusd/radiusd.pid" user = "radius" group = "radius" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes security { max_attributes = 200 reject_delay = 1 status_server = no } } client 127.0.0.1 { require_message_authenticator = no secret = "test" shortname = "localhost" } client 192.168.0.8 { require_message_authenticator = no secret = "test" shortname = "AP-Tower" } radiusd: #### Loading Realms and Home Servers #### proxy server { retry_delay = 5 retry_count = 3 default_fallback = no dead_time = 120 wake_all_if_all_dead = no } home_server localhost { ipaddr = 127.0.0.1 port = 1812 type = "auth" secret = "testing123" response_window = 20 max_outstanding = 65536 zombie_period = 40 status_check = "status-server" ping_check = "none" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 num_pings_to_alive = 3 revive_interval = 120 status_check_timeout = 4 } home_server_pool my_auth_failover { type = fail-over home_server = localhost } realm example.com { auth_pool = my_auth_failover } realm bla { authhost = LOCAL accthost = LOCAL } realm LOCAL { } radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating exec exec { wait = yes input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating expr Module: Linked to module rlm_expiration Module: Instantiating expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server { modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_eap Module: Instantiating eap eap { default_eap_type = "tls" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no } Module: Linked to sub-module rlm_eap_tls Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes rsa_key_length = 512 dh_key_length = 512 verify_depth = 0 pem_file_type = yes private_key_file = "/etc/pki/tls/private/server.pem" certificate_file = "/etc/pki/tls/private/server.pem" CA_file = "/etc/pki/tls/certs/ca.pem" private_key_password = "whatever" dh_file = "/etc/raddb/certs/dh" random_file = "/etc/raddb/certs/random" fragment_size = 1024 include_length = yes check_crl = no check_cert_cn = "%{User-Name}" } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating preprocess preprocess { huntgroups = "/etc/raddb/huntgroups" hints = "/etc/raddb/hints" with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no with_alvarion_vsa_hack = no } Module: Linked to module rlm_detail Module: Instantiating auth_log detail auth_log { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_realm Module: Instantiating ntdomain realm ntdomain { format = "prefix" delimiter = "\" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating files files { usersfile = "/etc/raddb/users" compat = "no" } Module: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating acct_unique acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } Module: Checking accounting {...} for more modules to load Module: Instantiating detail detail { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_radutmp Module: Instantiating radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Checking session {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Instantiating reply_log detail reply_log { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } } } radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 } listen { type = "acct" ipaddr = * port = 0 } Listening on authentication address * port 1812 Listening on accounting address * port 1813 Ready to process requests. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=143, length=203 Message-Authenticator = 0x6a9456153eae379a334abd83a66943de Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0200001901626c615c75736572406578616d706c652e636f6d NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:02 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 0 length 25 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Requiring client certificate rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 143 to 192.168.0.8 port 1128 EAP-Message = 0x010100060d20 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd855ce66d854c3db82f4be0093fad79e Finished request 0. Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=144, length=270 Message-Authenticator = 0xc3e9820d65ceacf0da25985d0491a9dc Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 State = 0xd855ce66d854c3db82f4be0093fad79e Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0201004a0d8000000040160301003b010000370301a7e723f972662a0dd9f47bf100b53967eacf0169d5d1cbf872f42a65f2a3113200001000040005000a000900640062000300060100 NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:02 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 1 length 74 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 TLS Length 64 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 003b], 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 075b], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 00a6], CertificateRequest TLS_accept: SSLv3 write certificate request A TLS_accept: SSLv3 flush data TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 144 to 192.168.0.8 port 1128 EAP-Message = 0x010204000dc00000085a160301004a02000046030147a8db36f7de79b222c826c344ccc50f4f28f2212f49eabd6563cfcb42a342e720fe29e3f6c35a60dbc948048c57e83889209d7fcb00d060074f31f3a50dc5cd3c000400160301075b0b0007570007540003a6308203a23082028aa003020102020101300d06092a864886f70d0101040500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d3126302406035504 EAP-Message = 0x03131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3038303133313230313030345a170d3039303133303230313030345a307c310b3009060355040613024652310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e312330210603550403131a4578616d706c65205365727665722043657274696669636174653120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100cd0aae93d135cfa6de4ef564f3c3ea6afd2fda9ba67ed5e20c3aa7594026 EAP-Message = 0x426df1c094085e62d90d1ecf1eb16473b90db8cd8aa73c8ab1ceab1b0b13d65f5e707e10cc384f80d28b977cb16177968b7cbd7d4dd25be2434ef1728f7b00cb47ef030641549a1fb49fbfdab2232b34cd6de986ac053a54f63cdde4e553d40f193f62e73125ad718b8cd6b8867b29691b642752e65406a3261ded9c988c7e98d2d4dc62e2c86dab8eada9ecfbb407edb8d6e05ca07abe73d8c718966be7e36161f48f1c5efa9567173759e81f479311380d0e411e946e78ba4fe343d0ad2a2e239c2baeb3a49ae39760e25fc49203cafbd6d063bcdede04dfd583f62b3ffe5d37e70203010001a317301530130603551d25040c300a06082b06010505 EAP-Message = 0x070301300d06092a864886f70d010104050003820101009c0a02fee42eef2b4470120ef49920c5ba74597993b054a639c7934ed86883f98ac77748ecc490f9ce22eac7df58b64a6ce0d7a880e883610393f168f8aa9b1da7265fe73402d6715663a959281014e3eaa827c30a73c9226e9fc47d0380a156afcb456c78176330c44a0c2de71441d9f26f73121524fd913d3eda66f4335117c35f963019bc30dd2991ae9a6f87d3f797f3ff3be21736d1c1a033f8eff0f08a6c77838171c53e694b0b077451ccff66deae511d1e89d9f51c96d67302bba8f569a9bcfa7a2b5c147294ae1bf3a104a0de7f7c5b2903e19140b5e3a2012f71bee6c5e7694a8a EAP-Message = 0x274e032acd43a5bca611d725 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd855ce66d957c3db82f4be0093fad79e Finished request 1. Going to the next request Waking up in 0.8 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=145, length=202 Message-Authenticator = 0x9ad3446768f6a2edfaac1bf4bc2fb1c0 Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 State = 0xd855ce66d957c3db82f4be0093fad79e Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x020200060d00 NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:03 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 2 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 eaptls_verify returned 1 eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 145 to 192.168.0.8 port 1128 EAP-Message = 0x010304000dc00000085a23355921a1747a34c197603352550003a8308203a43082028c020900927807f7241a80a4300d06092a864886f70d0101050500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3038303133313230313030335a170d3038303330313230313030335a308193310b3009060355 EAP-Message = 0x040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f7269747930820122300d06092a864886f70d01010105000382010f003082010a0282010100b2fb6cf91fecd4c4d86dc1d33479c39ef0273adf98d5c61f705c29b0592b853cbf48e5bdbf8b53207b800a96008b776b04f49983761c78abd187a95861fc4f2c7b7aee015662b554f1d9aa64b8906687 EAP-Message = 0x9e4246aaa8b63c2541fb75adbd395380d34e0756c542eafa4572f0f64e3a78ac5050bffad57f7b63e896a336930763ba2861a10bb1a8637241e025e113e828854558345183472766e6de33a80cedc10fe5f540db3212581ff6546118326a59cedce4927c6d10e7ea359251cdbdb95c2c122a9cd9afeca66ae97b852542ec21a93d85adbc606fc3ec37d646d0533ffdaae7a06869247eac8ae81009a0a1041f25486a7ff4e629fd2aae9287dfd47cd3010203010001300d06092a864886f70d01010505000382010100a1c65ea3a93de293e98fea2031bc47643bf9a1ae4d0b379c9f1b0652c6bd7f3ba4ea448285ce80187ff086f9a32b1701773e356c EAP-Message = 0xa5c646bc7fa4ed896a60c1942735277d4a9d6d18505c5e53b20655eb76077701b0bf7072a055172b622ad8304d6eaa13ea3c16b6da96fc2ea827b808a9ca383513979115156b2b01610dc2f2802b618d91f95ca1672fd131eda6aa5a5cf442bb6ad97b19717208dd4197bbe219b551fc3af61b331a4de9f03720139913754ad2a7d0781a374b3633a24944fefe3aaef1e3be7d6fd5d59b3a1a28c13917636c50fd47371fee39d607f0d52e0752614f0dd1565e97d042ec689cec47fe6149df970e70d35bac9785fc846df05816030100a60d00009e0301024000980096308193310b3009060355040613024652310f300d060355040813065261646975 EAP-Message = 0x733112301006035504071309 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd855ce66da56c3db82f4be0093fad79e Finished request 2. Going to the next request Waking up in 0.7 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=146, length=202 Message-Authenticator = 0x0835adbae1c68d7427e1db3683525dcb Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 State = 0xd855ce66da56c3db82f4be0093fad79e Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x020300060d00 NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:03 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 3 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 eaptls_verify returned 1 eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 146 to 192.168.0.8 port 1128 EAP-Message = 0x010400780d800000085a536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f726974790e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd855ce66db51c3db82f4be0093fad79e Finished request 3. Going to the next request Waking up in 0.6 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=147, length=1702 Message-Authenticator = 0x30b4960c3f45725d88c1be80642953a8 Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 State = 0xd855ce66db51c3db82f4be0093fad79e Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x020405d80dc0000005e116030105b10b0003a100039e00039b308203973082027fa003020102020106300d06092a864886f70d0101040500308193310b3009060355040613024652310f300d060355040813065261646975733112301006035504071309536f6d65776865726531153013060355040a130c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e636f6d312630240603550403131d4578616d706c6520436572746966696361746520417574686f72697479301e170d3038303133313231323235315a170d3039303133303231323235315a3071310b3009060355040613024652 EAP-Message = 0x310f300d0603550408130652616469757331153013060355040a130c4578616d706c6520496e632e311930170603550403141075736572406578616d706c652e636f6d311f301d06092a864886f70d010901161075736572406578616d706c652e636f6d30820122300d06092a864886f70d01010105000382010f003082010a0282010100a6355bf3db416288af94b9b6375d7791c2a78185d1168801d013bb8717721fc107d68204d80b9103f28f0999cf24534151ac16c99ca1a3a00ff4562754c52e2dde5a08567b61a125723b925992eaa5df170c8a8137ac68a2ecafc998b1a2d78bd32c2d535cfa9e97876ef92f21ce253c62f1e2a5501e99c1 EAP-Message = 0x3a45bcc2bf792d390cedb563f79f7d92f2eb0fd6d7327436c65ef574460156a9e70c7d5b96153b6ad2400459e98aa6ba56db512b266453b5756a92974558a16fc95add4bd975dc68205d327a477608ceaff7d25d113b2e044e0ffaa818cb4a62530b28150b36e8e1803ba0c60d428f9f2c4ca3af14755f98fe083ec58f096c9c89945835c822bd030203010001a317301530130603551d25040c300a06082b06010505070302300d06092a864886f70d010104050003820101003bcfbd82cc96ff2b12e95e357b06cba909d9c677f918f735cbbed8b78259d82278e45f9f46356fb3cfa871a2addb70ab14058904b7b5c84703b033f1840da82d0260aa EAP-Message = 0xe136ec1ac9b49af0b9b7ea03ac567c14ea3d47bacfe0de5ec78c554193c23c92da5457274e2f4756b7ccd73a238948633d644beb265b5a7f4eb86b76d39656a7cb808a435c4f63131d8e4a255f7609544b1553a8bcb938ef7ceb9141d4b02f7643f9bb170a337b3a5d2f57270b812778609611403f45321d6be7b547344e1a16be8abfb732f2048639341199d04084237a11e93aed58f4f21158fc8dca167ce364f3eae8c3492a55f2fc77455aa3f5a94d0106887e4b806298db8455941000010201009e940c0cf49fe68f41d945974197b6196cd147fc8c307625f9f63545c57625dd9c3c733a5c3d05b079bfaa64a0ebf57f84a1372a1463605a6008 EAP-Message = 0x341f3f77bb13b8074b90451cdc7bd5e243eee60f9c22cd4b9ebfd53e790cda90c191f8fdbb15352d2ec8c06e7894dd776883379bf13d82c95e9d52daefbe0c9ff7d32d229788ca9429c3c588f6608448aa6d9319c3b31f92208e24cc64c261e957d30b6cdf7daa45c7389616cfdefc9a29b385df03606381360f62b14dd7e48f6a9531ddcae7f65e725fd0fa105d52d8bc90b55bfa8181f3ad06b0a065b88c022380ab860eee226283b409231f205c7e7a96f1ba4d62ea2fbfad3d26ccfd02c91b93ba074da60f00010201006a77de0f83c67284ddff00ab404dfcddf9e4de8dde95a51c78dca72a374a5138430cadf79937cb74309dd2de2821f2f087 EAP-Message = 0x0ee9a8a0d152fe9edc973681c0fa148c0cbd2c6a2715302fcba3134535799733ead78d716ae7364cf5fe143fae73ea8f85e9138550dba12ec5e161a6628d93315cfa37547b72a06367555e44c99a0cda5e9ba91f1c6578754ede32a9669296fd337d5bd0ee8b5cfab0af80e22cbb56b72c6ab82031788de8e70295f62e33e68ce1e15af30c23df21b0b0b0becacdd0ace66d03c2b6885cf7005da481239422896fb58f0ac32e90792412d5eefeef9040de8ca4992be275c0e6436adfc93616ad57e46c66d3a64b70990a068ef62392140301000101160301002068d801790f68bf809a2e1f0bf5 NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:03 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 4 length 253 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 TLS Length 1505 rlm_eap_tls: Received EAP-TLS First Fragment of the message eaptls_verify returned 9 eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 147 to 192.168.0.8 port 1128 EAP-Message = 0x010500060d00 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd855ce66dc50c3db82f4be0093fad79e Finished request 4. Going to the next request Waking up in 0.3 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=148, length=221 Message-Authenticator = 0x7d627a7897faed5ff31c3dd65eb009b5 Service-Type = Framed-User User-Name = "bla\\user@example.com" Framed-MTU = 1488 State = 0xd855ce66dc50c3db82f4be0093fad79e Called-Station-Id = "000FB5BA4F59:Flugplatz" Calling-Station-Id = "00127946D8F2" NAS-Identifier = "AP-Tower" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x020500190d00112d679a5282e10a85aafb50657bc8b89651c0 NAS-IP-Address = 192.168.0.8 NAS-Port = 2 NAS-Port-Id = "STA port # 2" +- entering group authorize ++[preprocess] returns ok expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.0.8/auth-detail-20080205 expand: %t -> Tue Feb 5 22:55:03 2008 ++[auth_log] returns ok rlm_realm: Looking up realm "bla" for User-Name = "bla\user@example.com" rlm_realm: Found realm "bla" rlm_realm: Adding Stripped-User-Name = "user@example.com" rlm_realm: Proxying request from user user@example.com to realm bla rlm_realm: Adding Realm = "bla" rlm_realm: Authentication realm is LOCAL. ++[ntdomain] returns noop rlm_eap: EAP packet type response id 5 length 25 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated users: Matched entry DEFAULT at line 226 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake rlm_eap_tls: <<< TLS 1.0 Handshake [length 03a5], Certificate chain-depth=1, error=0 --> User-Name = bla\user@example.com --> BUF-Name = Example Certificate Authority --> subject = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> issuer = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> verify return:1 expand: %{User-Name} -> bla\user@example.com rlm_eap_tls: checking certificate CN (user@example.com) with xlat'ed value (bla\user@example.com) rlm_eap_tls: Certificate CN (user@example.com) does not match specified value (bla\user@example.com)! chain-depth=0, error=0 --> User-Name = bla\user@example.com --> BUF-Name = user@example.com --> subject = /C=FR/ST=Radius/O=Example Inc./CN=user@example.com/emailAddress=user@example.com --> issuer = /C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority --> verify return:0 rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal certificate_unknown TLS Alert write:fatal:certificate unknown TLS_accept:error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. eaptls_process returned 13 rlm_eap: Freeing handler ++[eap] returns reject auth: Failed to validate the user. Login incorrect: [bla\\user@example.com/<via Auth-Type = EAP>] (from client AP-Tower port 2 cli 00127946D8F2) Found Post-Auth-Type Reject +- entering group REJECT ++- group REJECT returns noop Delaying reject of request 5 for 1 seconds Going to the next request Waking up in 0.3 seconds. Waking up in 0.1 seconds. Waking up in 0.1 seconds. Waking up in 0.2 seconds. rad_recv: Access-Request packet from host 192.168.0.8 port 1128, id=148, length=221 Waiting to send Access-Reject to client AP-Tower port 1128 - ID: 148 Sending delayed reject for request 5 Sending Access-Reject of id 148 to 192.168.0.8 port 1128 EAP-Message = 0x04050004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.3 seconds. Cleaning up request 0 ID 143 with timestamp +25 Waking up in 0.1 seconds. Cleaning up request 1 ID 144 with timestamp +25 Cleaning up request 2 ID 145 with timestamp +26 Waking up in 0.1 seconds. Cleaning up request 3 ID 146 with timestamp +26 Waking up in 0.2 seconds. Cleaning up request 4 ID 147 with timestamp +26 Waking up in 1.0 seconds. Cleaning up request 5 ID 148 with timestamp +26 Ready to process requests.
Stefan Puch wrote:
@Alan DeKok
I'll bet that if you posted the final Access-Accept from 1.1.7 and from 2.0.1, that they would be *different*. If you make them the same, I'll also bet that the NAS will accept the user.
You were right (you win the bet), I accidentally commented out an entry in the "default"-file, which setting were included in radiusd.conf in previous version of freeradius
Stop fighting with the certificates. You're wasting your time, and confusing yourself. Start looking at the contents of the Access-Accept, which is the only thing that really matters.
With that hint I was able to get Windows and Linux Laptops working again using EAP-TLS and freeradius 2.0.1. I also managed to get a WM2003 and a WM6 PDA connecting using EAP-PEAP. For using EAP-TLS with the Windows Mobile devices I still have to solve one problem, which I think would be no problem for you, the problem with the username of the devices.
If I disable the option "check_cert_cn = %{User-Name}" in eap.conf I get a working configuration, but finally it should work also with that Option enabled. The problem of the Windows Mobile devices is, that they always submit as username "DOMAIN\user". If you leave the DOMAINNAME blank still "\user" is used. Since the radiusd.conf hints say, that I should NOT use the option "with_ntdomain_hack" (and when I tested it still didn't work for me) I wanted to use the "Realm module". But at the moment I didn't fully understand how realms work, although I did read the Posting on this mailinglist (from 2004) and the manpage.
I Know that I will have to use the realm module
You dont... your using 2.01 ? Write a regular expression to strip off the proceeding \ Heres one I did earlier.... If I remember correctly it's \\\\ to escape to one \ in the username ... \\ To escape it in the RegExp string, \\ to make \ literal in the regular expression... authorize { # USERNAME FORMATTING # User-Name Formatting, extracts Realm, User. Ignores NT domain # This will accept # * user # * user@domain # * ntdomain\\user # * ntdomain\\user@domain if("%{User-Name}" =~ /\\\\?([^@\\\\]+)@?([-[:alnum:]._]*)?$/) { update request { Stripped-User-Name = "%{1}" } } ... } You then use: check_cert_cn = %{Stripped-User-Name}
PS: When I've got a working configuration for the Windows Mobile devices, I'm going to write a little HOWTO like the one "EAP/TLS Setup for FreeRADIUS and Windows XP Supplicant" just for Mobile PDA's
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
@Arran Cudbard-Bell
Write a regular expression to strip off the proceeding \ Heres one I did earlier.... If I remember correctly it's \\\\ to escape to one \ in the username ... \\ To escape it in the RegExp string, \\ to make \ literal in the regular expression... I'm not so familiar with regular expressions, but your example works" Thank you very much! :-)
To make the test certificate being accepted I only hat to remove the leading "@", beacuse the username in there is "user@example.com" and if stripped to only "user" not accepted by the radius server. # This one work with the test certificate, too if("%{User-Name}" =~ /\\\\?([^\\\\]+)@?([-[:alnum:]._]*)?$/) { update request { Stripped-User-Name = "%{1}" } }
if("%{User-Name}" =~ /\\\\?([^@\\\\]+)@?([-[:alnum:]._]*)?$/) { update request { Stripped-User-Name = "%{1}" } } Is there anywhere a more detailed HOWTO for understanding this regular expression? I would like to understand "fully" what this example does... Probably I just have to do some "googling"
Now where the test certificates are working (on Win XP AND Windows Mobile) I will have to investigate again in my old certificates, because my one are only working with Windows XP supplicant and wpa_supplicant using Linux. The Windows Mobile supplicant cannot use them correctly although the certificates are the same one. Very strange! Finally I can start writing the HOWTO for Windows Mobile devices ;-)
Stefan Puch wrote:
@Arran Cudbard-Bell
Write a regular expression to strip off the proceeding \
Heres one I did earlier.... If I remember correctly it's \\\\ to escape to one \ in the username ... \\ To escape it in the RegExp string, \\ to make \ literal in the regular expression...
I'm not so familiar with regular expressions, but your example works" Thank you very much! :-)
To make the test certificate being accepted I only hat to remove the leading "@", beacuse the username in there is "user@example.com" and if stripped to only "user" not accepted by the radius server.
http://www.regular-expressions.info/ This is the best reference for regular expressions, depending on the libraries the servers are built against, the RegExp flavour is usually PCRE (Perl Compatible Regular Expressions).
# This one work with the test certificate, too if("%{User-Name}" =~ /\\\\?([^\\\\]+)@?([-[:alnum:]._]*)?$/) { update request { Stripped-User-Name = "%{1}" } }
/ Is the prefix and suffix to the regular expression string. Any characters after the / suffix are used as modifiers. FreeRadius only supports the i modifier to make matches case insensitive. \\\\ resolves to a literal back-slash. Regular expressions use the \ char as an escape char so it needs to be escaped with itself. FR also uses \ as an escape char so it has to be escaped with itself too. Hence the \\\\\ -> \\ -> \ This regular expression was written to stop *stupid* *stupid* *stupid* students from breaking authentication by entering something in the domain field. They kept entering sussex.ac.uk and user@sussex.ac.uk in the User Box in the windows supplicant, which resulted in. sussex.ac.uk\user@domain or sussex.ac.uk\user The regexp parses these as : "%{1}" = user "%{2}" = domain or "%{1}" = user "%{2}" =
if("%{User-Name}" =~ /\\\\?([^\\\\]+)$/) { update request { Stripped-User-Name = "%{1}" } }
If you don't need the domain information separately, the above expression might work better for you. The \\\\? will always try to match the first '\' but will actually match the last '\' because of the greedy capture. Then the greedy capture which will capture anything but \ . Should also work for just straight user@domain as the '\' prefix is optional.
We use the domain part of the user identifier for proxying.
Is there anywhere a more detailed HOWTO for understanding this regular expression? I would like to understand "fully" what this example does... Probably I just have to do some "googling"
Now where the test certificates are working (on Win XP AND Windows Mobile) I will have to investigate again in my old certificates, because my one are only working with Windows XP supplicant and wpa_supplicant using Linux. The Windows Mobile supplicant cannot use them correctly although the certificates are the same one. Very strange! Finally I can start writing the HOWTO for Windows Mobile devices ;-)
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
@Arran Cudbard-Bell
/ Is the prefix and suffix to the regular expression string. Any characters after the / suffix are used as modifiers. FreeRadius only supports the i modifier to make matches case insensitive.
\\\\ resolves to a literal back-slash. Regular expressions use the \ char as an escape char so it needs to be escaped with itself. FR also uses \ as an escape char so it has to be escaped with itself too. Hence the \\\\\ -> \\ -> \
This regular expression was written to stop *stupid* *stupid* *stupid* students from breaking authentication by entering something in the domain field. They kept entering sussex.ac.uk and user@sussex.ac.uk in the User Box in the windows supplicant, which resulted in. ... The regexp parses these as :
"%{1}" = user "%{2}" = domain
or
"%{1}" = user "%{2}" = Thanks again for the detailed comment, it saved me a lot of time and I will try to get more familiar with that kind of regular expressions. I will take your first solution, the domain was only excluded to see that the test certificates work which could bee generated with the Makefile provided in the FreeRadius Source.
Now where the test certificates are working (on Win XP AND Windows Mobile) I will have to investigate again in my old certificates, because my one are only working with Windows XP supplicant and wpa_supplicant using Linux. The Windows Mobile supplicant cannot use them correctly although the certificates are the same one. Very strange! Yesterday evening I found the solution, why my certificates doesn't work with the Windows Mobile supplicant although the Windows XP supplicant does: I'm using TinyCA to create and mange my certificates. By default the certificates are generates with a Keylength of 4096 using RSA encryption and SHA-1 as Signature Algorithm. When I took a look into the Makefile which generates the test certificates in the freeradius source a Keylength of only 2048 is used and MD5 as Signature Algorithm, so the devil must be in there somewhere. And indeed, it doesn't matter, which Algorithm you are using for signing (MD5 or SHA-1) but the Keylength seems to be very important for Windows Mobile devices. All certificates I generated with a Keylength of 2048 are working fine, all certificates wit a Keylength of 4096 doesn't work on the Mobile device (although they work fine on a Windows XP system).
In short: The build in supplicant of the Windows Mobile devices (I tested one with Windows Mobile 2003SE and one with Windows Mobile 6 Professional) doesn't like certificates with a Keylength of 4096!!! Thanks again for all help I got here on the mailing list, the next days/weeks I'm going to write some HOWTO for Mobile Devices in order to give something back to you :-) @Alan DeKok Wont it be better, to change the signing process in te provided Makefile so that a client certificate is signed by the ca certificate instead from the server certificate? When using TinyCA every certificate is signed from the ca certificate, too. I know both will work, if you specify the correct ca-cert in eap.conf, but changing that point would make the process (in my opinion) more consistent: You have to install the ca certificate and the client certificate on the client-computer, why should client cert by signed from the server cert? When I looked around in Web previous to find some god HOWTO's about setting up Freeradius using EAP-TLS I always found it that way, that the ca cert signs all other certs and by the way, the HOWTO in the freeradius Wiki (EAPTLS.pdf) explains it that way, too ;-) Best regards Stefan Puch
You have to install the ca certificate and the client certificate on the client-computer, why should client cert by signed from the server cert?
Because the idea is to authenticate those users to *that* server, not to *every* server that got the certificate from that CA. With your approach the user would be admitted to some other network if their server was issued a certificate by the same CA. If you are using commercial certificates there might be thousands of servers with certificates issued by the same CA. And the user will be able to get onto all of them (if they use EAP-TLS). Ivan Kalik Kalik Informatika ISP
You have to install the ca certificate and the client certificate on the client-computer, why should client cert by signed from the server cert?
Because the idea is to authenticate those users to *that* server, not to *every* server that got the certificate from that CA. With your approach the user would be admitted to some other network if their server was issued a certificate by the same CA. If you are using commercial certificates there might be thousands of servers with certificates issued by the same CA. And the user will be able to get onto all of them (if they use EAP-TLS). Thanks for the clarification, this is a good argument! In my case there is (and will be) only one server with uses the CA so it makes no difference, but in many other cases, you are right, signing with the CA is not what you really want.
Thanks again and best wishes Stefan Puch
For using EAP-TLS with the Windows Mobile devices I still have to solve one problem, which I think would be no problem for you, the problem with the username of the devices.
If I disable the option "check_cert_cn = %{User-Name}" in eap.conf I get a working configuration, but finally it should work also with that Option enabled. The problem of the Windows Mobile devices is, that they always submit as username "DOMAIN\user". If you leave the DOMAINNAME blank still "\user" is used.
Hi, in version 1.1.7 i used following configuration to cut off the "host/" in front of the username. in users-file: DEFAULT Prefix == "host/" the new value will be written in the attribute "stripped-user-name". so i had to change the value in eap.conf to the following setting: check_cert_cn = %{Stripped-User-Name} Maybe that will work in your configuration... Sebastian -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
The first question I would like to get an answer for is: Which certificate is needed to sign the client certificate, the CA certificate or the server certificate?
It's nonsense, that the server certificate signs the client certificate... it must be signed by the ca certificate. Sebastian -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
--On Thursday, January 31, 2008 05:42:50 PM +0100 "Reimer Karlsen-Masur, DFN-CERT" <karlsen-masur@dfn-cert.de> wrote:
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant.
This is not surprising, if that is the only EKU in the cert. In fact, in that situation, no correct server should accept the certificate for EAP-TLS, because the presence of any EKU means the certificate may _only_ be used for listed usages, and EAP-TLS is not smartcard-based logon. If you want to use a certificate for both purposes, then it must have both id-kp-ms-sc-logon and one of anyExtendedKeyUsage (2.5.29.37.0) or [sigh] id-kp-clientAuth (1.3.6.1.5.5.7.3.2). Unfortunately, RFC2716 does not discuss the details of certificate validation, but the rules for handling extended key usages are the same for all uses of PKIX; for details, see RFC3280 section 4.2.1.13. The replacement for RFC2716 is draft-simon-emu-rfc2716bis-13.txt, which was just approved as a Proposed Standard in the past week. It does discuss the details of certificate validation for EAP-TLS, in section 5.3. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Carnegie Mellon University - Pittsburgh, PA
Jeffrey Hutzelman wrote on 04.02.2008 00:43:
--On Thursday, January 31, 2008 05:42:50 PM +0100 "Reimer Karlsen-Masur, DFN-CERT" <karlsen-masur@dfn-cert.de> wrote:
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your client certificates they might not work with Windows build-in supplicant.
This is not surprising, if that is the only EKU in the cert.
I was talking about a set of EKUs like MS Smartcard Logon in combination with clientAuth and eg. e-mail protection...even if I did not state that clearly enough. Windows does not like to use EE-certs containing EKUs clientAuth and MS Smartcard Logon for EAP-TLS with its build-in supplicant. -- Beste Gruesse / Kind Regards Reimer Karlsen-Masur DFN-PKI FAQ: https://www.pki.dfn.de/faqpki 15 Jahre DFN-CERT + 15. DFN-Workshop "Sicherheit in vernetzten Systemen" am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ -- Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), Phone +49 40 808077-615 DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstr. 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski
Stefan Puch wrote:
Therefore the Makefile is used in the same directory. I'm not really sure, but in Line 93 where the "client.pem" is created it must be -passin pass:$(PASSWORD_CLIENT) instead of -passin pass:$(PASSWORD_SERVER)
Thanks. I've fixed that.
It would also be helpful to integrate the following command into the ca section, when generating a self-signed CA certificate, because using Windows you need the CA in DER-format: openssl x509 -inform PEM -outform DER -in ca.pem -out ca.der
Thanks. I've added that, too. Alan DeKok.
participants (7)
-
Alan DeKok -
Arran Cudbard-Bell -
Ivan Kalik -
Jeffrey Hutzelman -
Reimer Karlsen-Masur, DFN-CERT -
Sebastian Heil -
Stefan Puch