RE: freeradius not responding on machine specific IPs
Kevin, The relevant line is: rad_verify: Received Access-Reject packet from client 127.0.0.1 port 1812 with invalid signature (err=2)! (Shared secret is incorrect.) The shared secret to authenticate a client to the RADIUS server (for RADIUS, not EAP traffic) is either not set, or you're using the wrong secret. By default there is no shared secret set for localhost. Edit clients.conf, search for 127.0.0.1. You'll find a line that looks like: ipaddr = 127.0.0.1 Now, add this line beneath: secret = secret Restart freeradius and try again. The message should go away. Remember, you're still going to get an access-reject response unless you setup the user account and password your authenticating with in the users file. Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 jason.wittlin-co...@yale.edu - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Logging authentication attempts while TLS session resumption (caching) is enabled
When authenticating via PEAP or TTLS with an anonymous identity, the log shows both the anonymous identity and the real identity tunneled through the TLS tunnel. However, when TLS session resumption (caching) is enabled, only the anonymous identity is logged. This is presumably due to the fact that the user is not actually sending the real ID and password through the tunnel; rather the saved session is being used. However, being that the tunneled username is still available, and obtained from the cache, it should be available to log. Is this the intended behavior? It would seem that logging authentication attempts would be more useful if the real username was provided in addition to the anonymous identity. Caching disabled: Fri Dec 12 17:35:38 2008 : Auth: Login OK: [Jason Wittlin-Cohen] (from client Wireless port 0 via TLS tunnel) Fri Dec 12 17:35:38 2008 : Auth: Login OK: [Anonymous] (from client Wireless port 55 cli 0013e87d571d) Caching enabled: Fri Dec 12 17:35:56 2008 : Auth: Login OK: [Anonymous] (from client Wireless port 55 cli 0013e87d571d) However, the tunneled username does seem to be available. It's obtained from the cache and added to the Access-Accept message: [peap] Session established. Decoding tunneled attributes. [peap] Received EAP-TLV response. [peap] Success [peap] Adding cached attributes to the reply: User-Name = Jason Wittlin-Cohen Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 jason.wittlin-co...@yale.edu - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius configuration to support EAP-TLS, EAP-TTLS and EAP-PEAP
On Thu, Dec 11, 2008 at 9:16 AM, Attou eric gouroue...@yahoo.fr wrote: Hi Everybody. We are having some issues in setting up freeradius to support EAP-TLS, EAP-TTLS and EAP-PEAP. Our goal is to have our authentication server providing those three Auth-Type simultaneously. To support EAP-TLS, we generate our CA and certificates via TinyCA. You can use TinyCA, but you must add the proper extended key usage. Under Openssl-Configuration in TinyCA put the OID 1.3.6.1.5.5.7.3.1 for Server Certificates into Extended Key usage, and 1.3.6.1.5.5.7.3.2 into Client Certificate Extended Key Usage. Jason - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: (err=2)! (Shared secret is incorrect.)
The shared secret is the password that clients use to connect to the RADIUS server. It's located in the client.conf file in your freeradius configuration directory. Note, that this shared secret is used to secure RADIUS traffic. User names and passwords of users which are authenticating via EAP are stored in the users file. -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Does FreeRADIUS support PEAPv0/EAP-TLS?
On Tue, Dec 9, 2008 at 5:35 AM, Alan DeKok [EMAIL PROTECTED]wrote:
Jason Wittlin-Cohen wrote:
I already do that with the Juniper Access Client. The problem is that
the client certificate has the user's name as the Common Name and that
is sent in the clear. PEAP/EAP-TLS sends the user's certificate through
the tunnel obviating the issue. I admit this isn't a large problem but
it would be a nice feature to have.
FreeRADIUS doesn't support RFC 5216, it's too new.
It has been tested with PEAPv0/EAP-TLS in the past, but it's not a
common configuration. So it might not work now.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
Alan,
I installed FreeRADIUS 2.1.3 on my Ubuntu 8.10 server and encountered the
same failure with PEAPv0/EAP-TLS. I think I've discovered the problem.
FreeRADIUS expects the client certificate to be sent before the SSL tunnel
is established. When the client sends a response without a certificate, it
complains that the client did not return a certificate and rejects the user.
I've tested with the Juniper Access Client, Intel ProSet client, and XP's
own supplicant and got the same result each time, so I don't think this is a
client-side problem.
Log:
[peap] TLS 1.0 Handshake [length 0007], Certificate
[peap] TLS 1.0 Alert [length 0002], fatal handshake_failure
TLS Alert write:fatal:handshake failure
TLS_accept:error in SSLv3 read client certificate B
rlm_eap: SSL error error:140890C7:SSL
routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
SSL: SSL_read failed in a system call (-1), TLS session fails.
TLS receive handshake failed during operation
[peap] eaptls_process returned 4
[peap] EAPTLS_OTHERS
[eap] Handler failed in EAP/peap
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [Jason Wittlin-Cohen] (from client Wireless port 55 cli
0013e87d571d)
What's interesting is that if I send a certificate outside the tunnel
(Juniper allows you to send a certificate in addition to any authentication
method - which would in this case, lead to the certificate being sent once
outside the tunnel and again inside), authentication still fails, this time
with the No EAP session matching the State variable error.
rlm_eap: No EAP session matching the State variable.
[eap] Either EAP-request timed out OR EAP-response to an unknown EAP-request
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [Jason Wittlin-Cohen] (from client Wireless port 0 via TLS
tunnel)
eap.conf:
Module: Linked to module rlm_eap
Module: Instantiating eap
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048
}
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
CA_path = /etc/freeradius/certs/
pem_file_type = yes
private_key_file = /etc/freeradius/certs/server.key
certificate_file = /etc/freeradius/certs/server.crt
CA_file = /etc/freeradius/certs/ca.crt
dh_file = /etc/freeradius/certs/dh3072.pem
random_file = /dev/urandom
fragment_size = 1024
include_length = yes
check_crl = yes
cipher_list = HIGH
check_cert_issuer = /C=US/O=FreeRadius CA/CN=FreeRadius
CA/[EMAIL PROTECTED]
cache {
enable = no
lifetime = 24
max_entries = 255
}
}
Module: Linked to sub-module rlm_eap_peap
Module: Instantiating eap-peap
peap {
default_eap_type = tls
copy_request_to_tunnel = no
use_tunneled_reply = no
proxy_tunneled_request_as_eap = no
}
Module: Linked to sub-module rlm_eap_mschapv2
Module: Instantiating eap-mschapv2
mschapv2 {
with_ntdomain_hack = no
}
Jason Wittlin-Cohen
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
server certs seem fine but generated client cert in Windows shows Windows does not have enough information to verify and yes, I have loaded the 'ca.der' file generated by the instructions on the Windows client and that installs in 'Trusted Root Authorities'. The 'client' cert seems to install in 'Other People', and does include the XPextensions stuff. Craig Craig, You have to install the root certificate and client certificate to the correct certificate store. You have two options - the machine store or the personal certificate store of your current Windows user. The personal certificate store is probably what you want. Double click the client certificate, select install certificate and choose Place the certificate in the following store. Select the Personal certificate store. That should solve your problem. Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: client certs
Craig, Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts* * Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: client certs
Craig, Have you tried authenticating with the same certificate from a different computer, or using a different supplicant? The XP supplicant is pretty awful. If you have an Intel card, you can download the Intel PROset software for free which has more features than XP's supplicant, supports more authentication options, and tends to work better. My personal favorite is Juniper's Open Access client. Juniper has a 30-day trial if you want to test to see if that solves your problems. In addition, I find that if the sever is down while a client tries to connect, I have to refresh the settings on the AP, restarting the wireless, or the RADIUS server will show no activity at all. Restarting Windows or repairing the wireless connection doesn't help as it appears to be an issue with the AP. So, if you had the the RADIUS server down for even a short while, try restarting the AP. You can also see if there's a valid certificate chain. Start Run mmc. File Add Snap-In. Add Certificates. Choose My User. You should see a Certificates - Current User tree. Expand it, then open Personal Certificates. You should see your certificate in the list. Double click the certificate and check the Certificate Path tab. Certificate Status should be OK, and you should see both your client cert and the CA. If your certificate was signed by the server key and not the CA key, certificate verification will fail. Also, run freeradius with freeradius -X to check to see whether Windows is even communicating with the RADIUS server. I was having problems with my Ubuntu laptop and found it was timing out before even attempting to authenticate with the RADIUS server due to a driver issue. Jason On Wed, Dec 10, 2008 at 9:17 PM, Craig White [EMAIL PROTECTED] wrote: On Wed, 2008-12-10 at 19:51 -0500, Jason Wittlin-Cohen wrote: Craig, Apparently Windows automatically sends non-CA certificates in DER or PEM format to the Other People' certificate store. More importantly, the wireless supplicant in Windows XP \will not work with PEM or DER formatted client certificates. It'll complain that you have no certificate. You must convert to pkcs12 as the documentation states. openssl pkcs12 -export -in certname.pem \ -inkey keyname.key -out name.p12 -clcerts Jason Thanks for the help. Last week when I was generating certificates my own way, I was doing that and yes, as Ivan points out, the 'scripted' way that make client.pem does make the p12 cert for the client. My issue now - and obviously sh*t happens as I change things around is that with the certificates newly generated and radiusd restarted in 'debug' mode, the newly minted ca.der and client.p12 certificates installed in their proper homes in 'certificates' following the instructions here... http://wiki.freeradius.org/WPA_HOWTO#Step_4:_Configure_the_Client I 'repair' or 'refresh' Network Connection (obviously the repair is for the Wireless) and it hems/haws and finally says Authentication failed but the wireless AP never makes an effort to connect to the radius server. Just rebooted the laptop and checked for stale info in regedit HKCU\Software\Microsoft\EAPOL (none) This AP has been talking to the radius server for weeks now (and all day today) and authenticating Macintosh and iPhone clients but Windows is making me absolutely nuts. The radius server is also authenticating for my RRAS server on a Windows server on the LAN...my only issue has been Windows laptops ;-( At least earlier with my otherwise generated certificates, I could get through the AP and to the radius server but now...it's like no one is home. The Wireless AP does show my connection but that's it. I'm very frustrated Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRadius and Ubuntu 8.10
Note that the version of FreeRADIUS packaged by Ubuntu doesn't have SSL support (so no TLS, PEAP, TTLS). If you decide to install from source you should build a .deb package. It'll make it easier to administer and upgrade/uninstall in the future. tar -xvf freeradius* cd freeradius* apt-get build-dep freeradius dpatch dpkg-buildpackage -rfakeroot cd / dpkg -i freeradius_2.1.3-0_i386.deb On Thu, Dec 11, 2008 at 1:47 AM, Paul Bartell [EMAIL PROTECTED]wrote: Sudo apt-get install freeradius Its a bit of an older version if i remember correctly, so if you need virtual hosts (or whatever they are called) you should compile from source. First get the tar file tar -xvf freeradius* cd freeradius* ./configure (with whatever modules you need) make sudo make install pretty simple if i may say. On Wed, Dec 10, 2008 at 5:23 PM, Matthew Carriere [EMAIL PROTECTED] wrote: I am also about to install FreeRadius, anyone have experience with installing on Ubuntu 8.10 Server 32 Bit? -- Matthew Carriere [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Random quote of the week/month/whenever i get to updating it: Opportunity knocked. My doorman threw him out. - Adrienne Gusoff At school you don't get parole, good behavior only brings a longer sentence. - The History Boys - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRadius and Ubuntu 8.10
Sorry, that should be apt-get build-dep freeradius apt-get install dpatch dpatch is necessary to build the source package but isn't including as a build dependency. On Thu, Dec 11, 2008 at 2:09 AM, Jason Wittlin-Cohen [EMAIL PROTECTED] wrote: Note that the version of FreeRADIUS packaged by Ubuntu doesn't have SSL support (so no TLS, PEAP, TTLS). If you decide to install from source you should build a .deb package. It'll make it easier to administer and upgrade/uninstall in the future. tar -xvf freeradius* cd freeradius* apt-get build-dep freeradius dpatch dpkg-buildpackage -rfakeroot cd / dpkg -i freeradius_2.1.3-0_i386.deb On Thu, Dec 11, 2008 at 1:47 AM, Paul Bartell [EMAIL PROTECTED]wrote: Sudo apt-get install freeradius Its a bit of an older version if i remember correctly, so if you need virtual hosts (or whatever they are called) you should compile from source. First get the tar file tar -xvf freeradius* cd freeradius* ./configure (with whatever modules you need) make sudo make install pretty simple if i may say. On Wed, Dec 10, 2008 at 5:23 PM, Matthew Carriere [EMAIL PROTECTED] wrote: I am also about to install FreeRadius, anyone have experience with installing on Ubuntu 8.10 Server 32 Bit? -- Matthew Carriere [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Random quote of the week/month/whenever i get to updating it: Opportunity knocked. My doorman threw him out. - Adrienne Gusoff At school you don't get parole, good behavior only brings a longer sentence. - The History Boys - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Does FreeRADIUS support PEAPv0/EAP-TLS?
On Tue, Dec 9, 2008 at 5:35 AM, Alan DeKok [EMAIL PROTECTED]wrote: Jason Wittlin-Cohen wrote: I already do that with the Juniper Access Client. The problem is that the client certificate has the user's name as the Common Name and that is sent in the clear. PEAP/EAP-TLS sends the user's certificate through the tunnel obviating the issue. I admit this isn't a large problem but it would be a nice feature to have. FreeRADIUS doesn't support RFC 5216, it's too new. It has been tested with PEAPv0/EAP-TLS in the past, but it's not a common configuration. So it might not work now. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thanks for the quick response. I'll see if it works in 2.1.3 when I upgrade. Jason - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Does FreeRADIUS support PEAPv0/EAP-TLS?
Ivan,b
I already do that with the Juniper Access Client. The problem is that the
client certificate has the user's name as the Common Name and that is sent
in the clear. PEAP/EAP-TLS sends the user's certificate through the tunnel
obviating the issue. I admit this isn't a large problem but it would be a
nice feature to have.
Jason
2008/12/9 [EMAIL PROTECTED]b
http://wiki.freeradius.org/EAP
You should be able to set ananymous as user name for outer tunnel EAP-TLS
negotiation on the supplicant and use EAP-TLS with identity hidden.
Ivan Kalik
Kalik Informatika ISP
Dana 9/12/2008, Jason Wittlin-Cohen [EMAIL PROTECTED] piše:
I'm attempting to setup PEAPv0/EAP-TLS which uses EAP-TLS as the inner
authentication method within PEAP. Unlike EAP-TLS, PEAPv0/EAP-TLS sends
the
client certificate within the secure SSL tunnel, thus protecting the
user's
identity. While RFC-5216 suggests that EAP-TLS can optionally support a
privacy mode in which the client certificate is pushed through the SSL
tunnel, I've not found any way to enable this option. I have no particual
interest in using PEAPv0/EAP-TLS other than the fact that I know it does
what I want to accomplish. I would be perfectly happy to use EAP-TLS in
Privacy mode, or PEAPv0/MSCHAPv2 with a required client certificate.
However, both these modes pass the client certificate in the clear.
Here's what my testing has shown:
EAP-TLS: Works with both Windows XP Supplicant and Juniper Odyssey Access
Client 4.8
PEAPv0/EAP-MSCHAPv2- Works with both Windows XP Supplicant and Juniper
Odyssey Access Client 4.8
PEAPv0/EAP-MSCHAPv2 + Requierd Client Certificate- Works with Juniper
Odyssey Access Client 4.8 (XP Supplicant doesn't support MSCHAPv2 +
Certificate)
PEAPv0/EAP-TLS- Fails on both supplicants
I don't think my TLS settings are improper, as both EAP-TLS and
PEAPv0/MS-CHAPv2 + Client Certifciate work fine. The debug logs shows the
client certificate verified properly.
I've tried pretty much every combination of PEAP options, and after each
permutation I forced a reauthentication so that I could analyze the
packets
in Wireshark. No combination of settings forced the client certificate
through the SSL tunnel. I thought use_tunneled_reply = yes might
help, but it did not.
I have pasted the relevant configuration settings below as well as a full
log of the failure when I attempt to use PEAPv0/EAP-TLS.
The relevant settings: Other than default_eap_type = tls my settings
are
identical for PEAPv0/EAP-MSCHAPv2 which works fine.
The failure log seems to suggest that tls is not a supported
authentication mode within PEAP.
[files] users: Matched entry DEFAULT at line 200
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Found existing Auth-Type, not changing it.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
*rlm_eap: No EAP session matching the State variable.*
*[eap] Either EAP-request timed out OR EAP-response to an unknown
EAP-request*
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [Jason Wittlin-Cohen] (from client Wireless port 0 via
TLS
tunnel)
} # server inner-tunnel
[peap] Got tunneled reply code 3
[peap] Got tunneled reply RADIUS code 3
[peap] Tunneled authentication was rejected.
[peap] FAILURE
*PEAPv0/EAP-TLS Failure Log: *http://pastebin.com/m900e269
*PEAPv0/MSCHAPv2 Success Log:* http://pastebin.com/m16114697
*PEAPv.0/MSCHAPv2+Cert Success Log: *http://pastebin.com/m429d9c12
*EAP-TLS Success Log:* http://pastebin.com/m2b1c62f4
Relevant Settings:
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048
}
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 = 3072
verify_depth = 0
pem_file_type = yes
private_key_file = /etc/freeradius/certs/server_key.pem
certificate_file = /etc/freeradius/certs/server_cert.pem
CA_file = /etc/freeradius/certs/cacert.pem
dh_file = /etc/freeradius/certs/dh3072.pem
random_file = /etc/freeradius/certs/random
fragment_size = 1024
include_length = yes
check_crl = no
cipher_list = HIGH
make_cert_command = /etc/freeradius/certs/bootstrap
cache {
enable = no
peap {
default_eap_type = tls
copy_request_to_tunnel = no
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = no
virtual_server = inner-tunnel
}
Module: Linked to sub-module rlm_eap_mschapv2
Module: Instantiating eap-mschapv2
mschapv2 {
with_ntdomain_hack = no
modules mschap:
Module: Instantiating
Does FreeRADIUS support PEAPv0/EAP-TLS?
I'm attempting to setup PEAPv0/EAP-TLS which uses EAP-TLS as the inner
authentication method within PEAP. Unlike EAP-TLS, PEAPv0/EAP-TLS sends the
client certificate within the secure SSL tunnel, thus protecting the user's
identity. While RFC-5216 suggests that EAP-TLS can optionally support a
privacy mode in which the client certificate is pushed through the SSL
tunnel, I've not found any way to enable this option. I have no particual
interest in using PEAPv0/EAP-TLS other than the fact that I know it does
what I want to accomplish. I would be perfectly happy to use EAP-TLS in
Privacy mode, or PEAPv0/MSCHAPv2 with a required client certificate.
However, both these modes pass the client certificate in the clear.
Here's what my testing has shown:
EAP-TLS: Works with both Windows XP Supplicant and Juniper Odyssey Access
Client 4.8
PEAPv0/EAP-MSCHAPv2- Works with both Windows XP Supplicant and Juniper
Odyssey Access Client 4.8
PEAPv0/EAP-MSCHAPv2 + Requierd Client Certificate- Works with Juniper
Odyssey Access Client 4.8 (XP Supplicant doesn't support MSCHAPv2 +
Certificate)
PEAPv0/EAP-TLS- Fails on both supplicants
I don't think my TLS settings are improper, as both EAP-TLS and
PEAPv0/MS-CHAPv2 + Client Certifciate work fine. The debug logs shows the
client certificate verified properly.
I've tried pretty much every combination of PEAP options, and after each
permutation I forced a reauthentication so that I could analyze the packets
in Wireshark. No combination of settings forced the client certificate
through the SSL tunnel. I thought use_tunneled_reply = yes might
help, but it did not.
I have pasted the relevant configuration settings below as well as a full
log of the failure when I attempt to use PEAPv0/EAP-TLS.
The relevant settings: Other than default_eap_type = tls my settings are
identical for PEAPv0/EAP-MSCHAPv2 which works fine.
The failure log seems to suggest that tls is not a supported
authentication mode within PEAP.
[files] users: Matched entry DEFAULT at line 200
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Found existing Auth-Type, not changing it.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
*rlm_eap: No EAP session matching the State variable.*
*[eap] Either EAP-request timed out OR EAP-response to an unknown
EAP-request*
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [Jason Wittlin-Cohen] (from client Wireless port 0 via TLS
tunnel)
} # server inner-tunnel
[peap] Got tunneled reply code 3
[peap] Got tunneled reply RADIUS code 3
[peap] Tunneled authentication was rejected.
[peap] FAILURE
*PEAPv0/EAP-TLS Failure Log: *http://pastebin.com/m900e269
*PEAPv0/MSCHAPv2 Success Log:* http://pastebin.com/m16114697
*PEAPv.0/MSCHAPv2+Cert Success Log: *http://pastebin.com/m429d9c12
*EAP-TLS Success Log:* http://pastebin.com/m2b1c62f4
Relevant Settings:
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048
}
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 = 3072
verify_depth = 0
pem_file_type = yes
private_key_file = /etc/freeradius/certs/server_key.pem
certificate_file = /etc/freeradius/certs/server_cert.pem
CA_file = /etc/freeradius/certs/cacert.pem
dh_file = /etc/freeradius/certs/dh3072.pem
random_file = /etc/freeradius/certs/random
fragment_size = 1024
include_length = yes
check_crl = no
cipher_list = HIGH
make_cert_command = /etc/freeradius/certs/bootstrap
cache {
enable = no
peap {
default_eap_type = tls
copy_request_to_tunnel = no
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = no
virtual_server = inner-tunnel
}
Module: Linked to sub-module rlm_eap_mschapv2
Module: Instantiating eap-mschapv2
mschapv2 {
with_ntdomain_hack = no
modules mschap:
Module: Instantiating mschap
mschap {
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = no
}
Users:
DEFAULT Cleartext-Password := **,
EAP-TLS-Require-Client-Cert := Yes
Note: (*'s represent a 32 character randomly generated password)
Thanks in advance,
Jason
--
Jason Wittlin-Cohen
Yale Law School, Class of 2010
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Does FreeRADIUS support PEAPv0/EAP-TLS?
I forgot to mention that I'm running FreeRADIUS 2.1.0 on Ubuntu 8.10 (2.1.0+dfsg-0ubuntu2 to be exact). As the original binary didn't come with SSL support, I recompiled it using the Ubuntu source package. The client computer I have been testing run Windows XP SP3. Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] (908) 420-0861 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Question about the random file
I'm currently using EAP-TLS with 3072 bit RSA certificates and a 3072 bit DH paramters. Currently I'm using the random file produced by the bootstrap script which appears to take 10 bytes of data from /dev/urandom. Is this sufficient with the larger keysize I am using? In addition, many howtos suggest using /dev/urandom directly. Is this a good idea? Jason -- Jason Wittlin-Cohen Yale Law School, Class of 2010 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
WPA authentication works only with MacOS clients
Date: Mon, 16 Oct 2006 13:25:22 +0200 From: Josh Shamir [EMAIL PROTECTED] Subject: WPA authentication works only with MacOS clients To: freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hello all, I'm using WPA with EAP-TTLS and PEAP with a MacOS .Authentication works fine (even if enough slowly). The problem is that I can't authenticate WinXP client. I've readed that for using EAP-TTLS are required some other supplicant like SecureW2. Is SecureW2 required also for PEAP? You are correct. The Windows supplicant on XP SP2 supports PEAP-MSCHAPv2 otherwise known as PEAPv0 and EAP-TLS. If you want to use EAP-TTLS you have a few choices. You can use a commercial supplicant like Funk Odyssey Access Client (30 day free trial here: http://www.juniper.net/customers/support/products/oac.jsp. It's a great supplicant and supports EAP-TTLS, PEAPv0, PEAPv1, EAP-TLS, EAP-SIM, EAP-GTC etc. You also may want to check if your wireless card has its own supplicant that supports TTLS. Most new laptops come with an Intel Centrino chipset and Intel's Proset Wireless supplicant does support TTLS. It's also faster and has more features than the MS supplicant. If these aren't available options, why not just use PEAP-MSCHAPv2? If you're just doing username/password authentication this should work fine. PEAP and TTLS are very similar in nature and PEAP is supported in OS X and in the Windows supplicant. Thanks for attention Best Regards, Josh -- next part -- An HTML attachment was scrubbed... URL: https://list.xs4all.nl/pipermail/freeradius-users/attachments/20061016/aafb6aa7/attachment-0001.html -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WPA authentication works only with MacOS clients
Message: 5 Date: Mon, 16 Oct 2006 22:36:14 +0200 From: Josh Shamir [EMAIL PROTECTED] Subject: Re: WPA authentication works only with MacOS clients To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Jason, I want to use PEAP. So I can use PEAP on a WinXP SP2 client without any other supplicant, using his native supplicant. The problem is that with native WinXP supplicant the authentication process failed, and freeradius server give me an error regarding certificates. The strange thing is that with the same certificates, PEAP works fine with MacOSx. Could be a problem of certificates ? I generate certificates with CA.all. Any ideas about how generate certificates that works also with MS WixXP client? This is a common problem. Windows XP requires that the server and client certificates have specific attributes. This is useful as it prevents a main-in-the-middle attack where an authentic client masquerades as a server with his client cert. You need to use Microsoft's Extended Attributes: [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 See http://www.linuxjournal.com/node/8095/print for detailed instructions how to create a server certificate that will work with PEAP and MS clients. The HOWTO is for EAP-TLS which requires client and server certificates. Since you are using PEAP, you just need to create the server certificate. Good luck. In particular you'll want to do: openssl req -new -keyout server_key.pem -out server_req.pem -days 730 -config ./openssl.cnf openssl ca -config ./openssl.cnf \ -policy policy_anything -out server_cert.pem \ -extensions xpserver_ext -extfile ./xpextensions \ -infiles ./server_req.pem You'll now have server_cert.pem (Public Certificate) and server_key.pem (Private Key which has no password). The public certificate will have the Server extended key usage extensions set and now your XP client should authenticate. signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WPA authentication works only with MacOS clients
Message: 5 Date: Mon, 16 Oct 2006 22:36:14 +0200 From: Josh Shamir [EMAIL PROTECTED] Subject: Re: WPA authentication works only with MacOS clients To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Jason, I want to use PEAP. So I can use PEAP on a WinXP SP2 client without any other supplicant, using his native supplicant. The problem is that with native WinXP supplicant the authentication process failed, and freeradius server give me an error regarding certificates. The strange thing is that with the same certificates, PEAP works fine with MacOSx. Could be a problem of certificates ? I generate certificates with CA.all. Any ideas about how generate certificates that works also with MS WixXP client? This is a common problem. Windows XP requires that the server and client certificates have specific attributes. This is useful as it prevents a main-in-the-middle attack where an authentic client masquerades as a server with his client cert. You need to use Microsoft's Extended Attributes: [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 See http://www.linuxjournal.com/node/8095/print for detailed instructions how to create a server certificate that will work with PEAP and MS clients. The HOWTO is for EAP-TLS which requires client and server certificates. Since you are using PEAP, you just need to create the server certificate. Good luck. In particular you'll want to do: openssl req -new -keyout server_key.pem -out server_req.pem -days 730 -config ./openssl.cnf openssl ca -config ./openssl.cnf \ -policy policy_anything -out server_cert.pem \ -extensions xpserver_ext -extfile ./xpextensions \ -infiles ./server_req.pem You'll now have server_cert.pem (Public Certificate) and server_key.pem (Private Key which has no password). The public certificate will have the Server extended key usage extensions set and now your XP client should authenticate. Jason Wittlin-Cohen P.S: Sorry for the double post. My last message had flowed text making it very difficult to read so I decided to resend it. signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Freeradius is not restarting properly (fails to quit and becomes a zombie process)
Have you gotten a chance to take a look at this issue?
Message: 4
Date: Sun, 08 Oct 2006 15:24:33 -0400
From: "Alan DeKok" [EMAIL PROTECTED]
Subject: Re: Freeradius is not restarting properly (fails to quit and
becomes a zombie process)
To: FreeRadius users mailing list
freeradius-users@lists.freeradius.org
Message-ID: [EMAIL PROTECTED]
Jason Wittlin-Cohen [EMAIL PROTECTED] wrote:
I have discovered the root of the problem. When I enable the
"check_cert_cn = %{User-Name}" option in eap.conf and successfully
authenticate 1 user , a restart or stop of the radiusd service leads to
a zombie process which needs to be killed with "kill -9". If this option
is disabled, as is the default setting, radiusd can be restarted
normally without issue. This issue does not occur if either a) no users
have attempted to authenticate, or b) users have authenticated but were
rejected. Is this a known issue?
No. It's *very* weird. I'll try to take a look at it this week.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
WPA authentication works but take very log time
Message: 5 Date: Fri, 13 Oct 2006 23:38:54 +0200 From: Giuseppina Venezia [EMAIL PROTECTED] Subject: WPA authentication works but take very log time To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, I'm using freeradius 1.1.3 with PEAP and EAP-TTLS,the authentication using MacOS works but the time spent from when the client insert username and password until the moment when the user is authenticated (and obtains the IP address) is very long, about 2 minutes. Is normal that authentication using WPA takes all this time? The access point is configured for using WPA-Auto-Enterprise, *Auto* means that WPA1 and WPA2 are simultaneously supported. What could be the problem? I attach the log of the first 6 request reveiced by radius server: I've noticed that the time it takes to authenticate a client using EAP-TLS is heavily dependent on the Wireless Supplicant used. The best way to tell whether the RADIUS server is at fault is to simply run a packet sniffer in the background like Ethereal/Wireshark and see when EAP authentication starts and how long it takes. With the Windows XP SP2 MS supplicant login usually takes 5 OR 34 seconds. When I ran a packet sniffer I noticed that the client didn't initiate the EAP exchange until 33 seconds had gone by and the actual exchange took .55 seconds- basically instantaneous. However, when I use the Funk Odyssey Client authentication occurs in about 1 second. The Intel PROset wireless supplicant takes a few seconds- all are much faster than the MS Supplicant. The only way to tell what's holding things up is to run the packet sniffer and see what's going on. If you see nothing happening for 2 minutes, and at the last second the EAP exchange occurs, you know it's the supplicant. If the EAP exchange starts and stalls for a long period of time, it's likely your RADIUS setup. Jason - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TLS Certificate problems.
Message: 7 Date: Mon, 9 Oct 2006 11:26:51 -0400 From: Brian vb [EMAIL PROTECTED] Subject: RE: EAP-TLS Certificate problems. To: 'FreeRadius users mailing list' freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Recreated certs, same issue came with the Issuer field. XPExtensions are used. Password is the same in this file an what Freeradius has just changed to protect it. Here is the batch file I'm using to create the certs. I don't see anything amiss between it and the page you sent.. any ideas? PATH=C:\openssl\bin;C:\ssl1;%path% export LD_LIBRARY_PATH=C:\openssl\lib CD\SSL1 REM CA Creation C:\openssl\bin\openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -export -in newreq.pem -out root.p12 -cacerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in root.p12 -out root.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in root.pem -out root.der I'm not sure what you're doing here. First, C:\openssl\bin\openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved You're outputting the private key and public key to the same file. I'm not sure if this will include both in the same file, or only create one. Regardless, it's not what you want to do. Give the files unique names. The clients and server need the public key and only the certificate signing machine needs the private key. You don't want to combine the keys. To create a CA: openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 -config openssl.cnf Also, why are you creating a p12 file for the CA? You certainly don't want to hand out the private key to clients, and for certificate signing, you only need the private key which can be stored in cakey.pem for example. Clients should be given cacert.pem or cacert.der depending on the format you use. The p12 format should only be used for client certs because those need to combine private key + certificate (at least for the MS supplicant). REM Client cert Create C:\openssl\bin\openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved Again, -keyout is used to creaate the private key, and -out to create the certificate signing request which is then passed on to the CA later. You're using the same filename, so I have no idea what's happening. Either you have a certificate signing request and no key, or a key without a signing request. Either way, it won't work. You need to do something like this: openssl req -new -keyout client_key.pem \ -out client_req.pem -days 730 -config ./openssl.cnf Notice that the key and the signing request are given different names. C:\openssl\bin\openssl ca -policy policy_anything -out newcert.pem -passin pass:PassCodeRemoved -key PassCodeRemoved -extensions xpclient_ext -extfile xpexts -infiles newreq.pem C:\openssl\bin\openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-clt.p12 -clcerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in cert-clt.p12 -out cert-clt.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in cert-clt.pem -out cert-clt.der So, you convert from a PEM certificate and PEM key, to a P12 cert+key, to a PEM cert+key to DER cert+key. Why? The P12 cert+key will work fine. REM Server Cert Create C:\openssl\bin\openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved Again, the key and certificate signing request must be given different names or else your setup will fail. C:\openssl\bin\openssl ca -policy policy_anything -out newcert.pem -passin pass:PassCodeRemoved -key PassCodeRemoved -extensions xpserver_ext -extfile xpexts -infiles newreq.pem Do you need these steps? Freeradius will use a seperate certificate and key in PEM format. It works fine for me. It seems like your setup is overly complex. Keep it simple, and see if it works. Then you can change file formats- etc. For now, just make the changes I recommended and see if it gives you a working CA and client/server certificates. C:\openssl\bin\openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-srv.p12 -clcerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in cert-srv.p12 -out cert-srv.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in cert-srv.pem -out cert-srv.der Jason Wittlin-Cohen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TLS Certificate problems.
Date: Mon, 9 Oct 2006 11:26:51 -0400 From: Brian vb [EMAIL PROTECTED] Subject: RE: EAP-TLS Certificate problems. To: 'FreeRadius users mailing list' freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Recreated certs, same issue came with the Issuer field. XPExtensions are used. Password is the same in this file an what Freeradius has just changed to protect it. Here is the batch file I'm using to create the certs. I don't see anything amiss between it and the page you sent.. any ideas? PATH=C:\openssl\bin;C:\ssl1;%path% export LD_LIBRARY_PATH=C:\openssl\lib CD\SSL1 REM CA Creation C:\openssl\bin\openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -export -in newreq.pem -out root.p12 -cacerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in root.p12 -out root.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in root.pem -out root.der I'm not sure what you're doing here. First, C:\openssl\bin\openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved You're outputting the private key and public key to the same file. I'm not sure if this will include both in the same file, or only create one. Regardless, it's not what you want to do. Give the files unique names. The clients and server need the public key and only the certificate signing machine needs the private key. You don't want to combine the keys. To create a CA: openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 365 -config openssl.cnf Also, why are you creating a p12 file for the CA? You certainly don't want to hand out the private key to clients, and for certificate signing, you only need the private key which can be stored in cakey.pem for example. Clients should be given cacert.pem or cacert.der depending on the format you use. The p12 format should only be used for client certs because those need to combine private key + certificate (at least for the MS supplicant). REM Client cert Create C:\openssl\bin\openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved Again, -keyout is used to creaate the private key, and -out to create the certificate signing request which is then passed on to the CA later. You're using the same filename, so I have no idea what's happening. Either you have a certificate signing request and no key, or a key without a signing request. Either way, it won't work. You need to do something like this: openssl req -new -keyout client_key.pem \ -out client_req.pem -days 730 -config ./openssl.cnf Notice that the key and the signing request are given different names. C:\openssl\bin\openssl ca -policy policy_anything -out newcert.pem -passin pass:PassCodeRemoved -key PassCodeRemoved -extensions xpclient_ext -extfile xpexts -infiles newreq.pem C:\openssl\bin\openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-clt.p12 -clcerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in cert-clt.p12 -out cert-clt.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in cert-clt.pem -out cert-clt.der So, you convert from a PEM certificate and PEM key, to a P12 cert+key, to a PEM cert+key to DER cert+key. Why? The P12 cert+key will work fine. REM Server Cert Create C:\openssl\bin\openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved Again, the key and certificate signing request must be given different names or else your setup will fail. C:\openssl\bin\openssl ca -policy policy_anything -out newcert.pem -passin pass:PassCodeRemoved -key PassCodeRemoved -extensions xpserver_ext -extfile xpexts -infiles newreq.pem Do you need these steps? Freeradius will use a seperate certificate and key in PEM format. It works fine for me. It seems like your setup is overly complex. Keep it simple, and see if it works. Then you can change file formats- etc. For now, just make the changes I recommended and see if it gives you a working CA and client/server certificates. C:\openssl\bin\openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-srv.p12 -clcerts -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl pkcs12 -in cert-srv.p12 -out cert-srv.pem -passin pass:PassCodeRemoved -passout pass:PassCodeRemoved C:\openssl\bin\openssl x509 -inform PEM -outform DER -in cert-srv.pem -out cert-srv.der Jason Wittlin-Cohen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TLS Certificate problems.
Hi, I'm trying to get Freeradius up and running on a WinXP box (win haters. be nice ;) ) I have downloaded, installed, and configured the Freeradius version from www.freeradius.net. The server starts seemingly without errors. However when I try to connect with my XP laptop I get a certificate error on the radius systems log. I have created 3 certificates, Root, Client, Server. The Root and Client certificates were installed via the MMC snapin and Import wizard in XP. Any idea on what could be causing the errors? If I need to post file contents, let me know which ones. Using EAP-TLS(cert based) not EAP-TTLS(user-pass based). Xp laptop is stuck at Attempting to Authenticate. Welcome to the Freeradius mailing list, and thank you for providing debug log to help us sort out this issue. The debug information will tell you exactly why it's being rejected (i.e. no certificate was sent, certificate was signed by another CA). I believe I know what's going wrong. The CA public cert should be stored in the Trusted Root Certification Authorities certificate store. If it's anywhere else, Windows won't authenticate the server and it will look like it's failing- when it's doing what you asked it to do. In this scenario you won't see any error output from Freeradius because Windows has stopped attempting to connect. Your user public certificate must be stored in either your User or Machine Account Personal Certificate store (this is the first option in the snap-in). Also, if you have more than one certificate in your personal store, do not use simply certificate selection. Windows will choose the one highest in the list (It did for me). Manually select the certificate you want to use. Read this howto and follow the Configuring Windows XP Clients guide. It will tell you exactly what to do. See http://www.linuxjournal.com/node/8151/print Here is what's happening currently: Error 1 is seen if I have Validate Server Certificate check on the XP Laptop. --Error 1-- Sat Oct 7 19:35:58 2006 : Error: TLS_accept:error in SSLv3 read client certificate A -- When you enable Server verification, Windows checks to see if the server's certificate is signed by a trusted Root CA that you specify. Since you didn't install the CA to the Trusted Root Certificate Authorities certificate store, the Windows supplicant refuses to continue authenticating and Freeradius has nothing to do. This error doesn't actually mean anything. I see it when I have a successful login. You're not seeing an error- which means the problem is on the client side. This can be remedied by installing your Root CA in the Trusted Root Certification Authorities certificate store. Here's a successful authenticaiton from my radiusd.log. You'll notice the read client certificate A error. It can safely be ignored. Sun Oct 8 03:13:56 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Sun Oct 8 03:13:56 2006 : Error: rlm_eap: SSL error error::lib(0):func(0):reason(0) Sun Oct 8 03:13:56 2006 : Error: rlm_eap: SSL error error::lib(0):func(0):reason(0) Sun Oct 8 03:13:56 2006 : Auth: Login OK: [Jason Wittlin-Cohen] (from client WLAN port 8 cli 00095b93459e) Error 2 is seen if Validate is unchecked on the laptop --Error 2-- Sat Oct 7 19:34:35 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Sat Oct 7 19:34:35 2006 : Error: -- verify error:num=20:unable to get local issuer certificate Sat Oct 7 19:34:35 2006 : Error: TLS Alert write:fatal:unknown CA Sat Oct 7 19:34:35 2006 : Error: TLS_accept:error in SSLv3 read client certificate B Sat Oct 7 19:34:35 2006 : Error: rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. Sat Oct 7 19:34:35 2006 : Auth: Login incorrect: [shadowwolf/no User-Password attribute] (from client netnas port 11 cli 0014a5104864) - Error 2 tells us exactly what the problem is. Unable to get local issuer certificate AND Unknown CA. In other words, the certificate used is not the one it should be using as it's signed by another CA. This can be remedied by either installing the correct certificate in the Personal user certificate store and turning off simple certificate selection. I hope this resolves your problem. Jason Wittlin-Cohen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS Certificate problems.
Brian vb said: Ca is in trusted root stores under Current User, and client is in Personal under Current User. One thing I see when viewing the certs is the Root has Locker Systems (using a random name to keep the identity of my company out of the certs) as the issuer and the client has SSLeay Demoserver.. looks like OpenSSL didn't make the certs right for some odd reason.. its like it used its own CA root or something else happened. I will recreate the certs but I'm quite sure I entered the same data in all certs except commonname which I made the same as the machine the cert will reside on. Root ca common name didn't match any machine name. Where should the CA be? Machine or User? First, when you create the server and client certificates you need to use the Microsoft attributes for Server and Client authentication. [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 I would suggest following the instructions here: http://www.linuxjournal.com/node/8095/print The howto is for setup of Freeradius on Linux, but it should be similar on Windows because it's the OpenSSL commands that matter when creating the certs. In order to find out if the certificate is correct, you can double click the certifcate in the Personal store and go to Certification Path. You should see the certificate common name as well as the common name of your Root CA. If you don't something is wrong. You should also see This certificate is OK in the Certificate status box. If this isn't the case, either the certificate was signed by the wrong CA, or the Root CA wasn't properly loaded into the User Trusted Root Certificate Authorities store. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Can Session-Timeout be used to force users to re-authenticate?
Is it possible to use the Session-Timeout setting to force wireless clients to re-authenticate with the RADIUS server at a given interval? Unfortunately my Acesss Point does not provide this functionality, so I either have to do it via a supplicant such as the Funk Odyssey Client or on the Freeradius server. I am running Freeradius 1.1.3 on a Debian Sarge 3.1 system and I'm using EAP-TLS for authentication. I don't think it matters but I'm using a Buffalo WHR-G54S Wireless Router with the DD-WRT v23 SP2 firmware. I am trying to force my wireless clients to re-authenticate with the RADIUS server every 30 minutes (1800 seconds) with the Session-Timeout setting. Currently I am testing with just one user, and the Session-Timeout = 1800 setting is being sent with the Radius Access Accept message (I can see it in the Accept Accept message when I run in debug mode). However, this seems to have no affect. The user does not re-authenticate at the given interval. Here's my setting from the users file: Jason Wittlin-Cohen Session-Timeout = 1800 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius is not restarting properly (fails to quit and becomes a zombie process)
Alan DeKok wrote:
Jason Wittlin-Cohen [EMAIL PROTECTED] wrote:
Over the last few days I've been having a recurring problem. Whenever I
start Freeradius either with radiusd in a terminal or as a service in
Debian, I can not restart/kill radiusd properly if it's authenticated
any clients. Restarting the service says it's successful but the radius
log states that port 1812 is already in use. "top" shows 100% cpu usage
It looks like http://bugs.freeradius.org/show_bug.cgi?id=365
The solution is to not re-initialize the modules on HUP.
It works in *most* cases, because the code handling the HUP tries to
wait until all of the modules have stopped. But if your back-end DB's
are slow, it doesn't have much choice but to proceed with handling the
HUP.
Most people don't see it because the modules respond quickly. I'd
say the first step to a work-around is to make sure none of the
modules you're using are blocking the server.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I have discovered the root of the problem. When I enable the
"check_cert_cn = %{User-Name}" option in eap.conf and successfully
authenticate 1 user , a restart or stop of the radiusd service leads to
a zombie process which needs to be killed with "kill -9". If this
option is disabled, as is the default setting, radiusd can be restarted
normally without issue. This issue does not occur if either a) no users
have attempted to authenticate, or b) users have authenticated but were
rejected. Is this a known issue?
Jason Wittlin-Cohen
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Can Simultaneous-Use be used with EAP-TLS?
I am using EAP-TLS for authentication so I have no use for a backend db to check username/password credentials. However, I would still like to prevent simultaneous logins with the same certificate. Is this possible without having an sql database? I have Simultaneous-Users := 1 set in the users configuration file but it doesn't seem to do anything. Clients are being checked against this line in users DEFAULT Simultaneous-Use :=1 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Why is the default DH keysize only 512 bits?
Alan DeKok wrote:
Jason Wittlin-Cohen [EMAIL PROTECTED] wrote:
I noticed that the default DH keysize in FreeRadius 1.1.3 is 512 bits.
If you're talking about the key length in the EAP-TLS module, it
looks like those aren't being used for anything. See the source.
It does look like the EAP-TLS code is setting a 512-bit ephemeral
RSA key, but my reading of the OpenSSL docs indicates it won't be
used, because SSL_OP_EPHEMERAL_RSA isn't being set. So that code
could be deleted entirely.
I originally thought that the DH
keysize would be determined by the DH parameter file and only realized
that it was still using 512 bit keys when I ran freeradius in debug
mode.
Which prints out configuration entries that aren't being used.
$ cd src/modules/rlm_eap
$ grep -r key_length .
./libeap/mppe_keys.c: PRF(s-session-master_key, s-session-master_key_length,
./libeap/mppe_keys.c: PRF(s-session-master_key, s-session-master_key_length,
./types/rlm_eap_tls/rlm_eap_tls.c: { "rsa_key_length", PW_TYPE_INTEGER,
./types/rlm_eap_tls/rlm_eap_tls.c: offsetof(EAP_TLS_CONF, rsa_key_length), NULL, "512" },
./types/rlm_eap_tls/rlm_eap_tls.c: { "dh_key_length", PW_TYPE_INTEGER,
./types/rlm_eap_tls/rlm_eap_tls.c: offsetof(EAP_TLS_CONF, dh_key_length), NULL, "512" },
./types/rlm_eap_tls/rlm_eap_tls.h: int rsa_key_length;
./types/rlm_eap_tls/rlm_eap_tls.h: int dh_key_length;
See? They're config options that aren't used. They should be deleted.
So, if dh_key_length is being ignored, how is the DH key size
determined? By the DH parameter file?
Jason
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Freeradius is not restarting properly (fails to quit and becomes a zombie process)
Over the last few days I've been having a recurring problem. Whenever I
start Freeradius either with radiusd in a terminal or as a service in
Debian, I can not restart/kill radiusd properly if it's authenticated
any clients. Restarting the service says it's successful but the radius
log states that port 1812 is already in use. top shows 100% cpu usage
after I attempt to restart radiusd. In addition, kill will not work. I
need to use kill -9. No errors are thrown when I try to kill it in debug
mode either. It just says exiting and sits there but doesn't die.
The only change I have made to radiusd.conf was to set the user and
group to nobody and nogroup respectively. I've copied the contents of my
eap.conf configuration file below.
# -*- text -*-
#
# Whatever you do, do NOT set 'Auth-Type := EAP'. The server
# is smart enough to figure this out on its own. The most
# common side effect of setting 'Auth-Type := EAP' is that the
# users then cannot use ANY other authentication method.
#
#$Id: eap.conf,v 1.4.4.3 2006/04/28 18:25:03 aland Exp $
#
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received.
#
# The incoming EAP messages DO NOT specify which EAP
# type they will be using, so it MUST be set here.
#
# For now, only one default EAP type may be used at a time.
#
# If the EAP-Type attribute is set by another module,
# then that EAP type takes precedence over the
# default type configured here.
#
default_eap_type = tls
# A list is maintained to correlate EAP-Response
# packets with EAP-Request packets. After a
# configurable length of time, entries in the list
# expire, and are deleted.
#
timer_expire = 60
# There are many EAP types, but the server has support
# for only a limited subset. If the server receives
# a request for an EAP type it does not support, then
# it normally rejects the request. By setting this
# configuration to yes, you can tell the server to
# instead keep processing the request. Another module
# MUST then be configured to proxy the request to
# another RADIUS server which supports that EAP type.
#
# If another module is NOT configured to handle the
# request, then the request will still end up being
# rejected.
ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given
# a User-Name attribute in an Access-Accept, it copies one
# more byte than it should.
#
# We can work around it by configurably adding an extra
# zero byte.
cisco_accounting_username_bug = no
# Supported EAP-types
#
# We do NOT recommend using EAP-MD5 authentication
# for wireless connections. It is insecure, and does
# not provide for dynamic WEP keys.
#
md5 {
}
# Cisco LEAP
#
# We do not recommend using LEAP in new deployments. See:
# http://www.securiteam.com/tools/5TP012ACKE.html
#
# Cisco LEAP uses the MS-CHAP algorithm (but not
# the MS-CHAP attributes) to perform it's authentication.
#
# As a result, LEAP *requires* access to the plain-text
# User-Password, or the NT-Password attributes.
# 'System' authentication is impossible with LEAP.
#
leap {
}
# Generic Token Card.
#
# Currently, this is only permitted inside of EAP-TTLS,
# or EAP-PEAP. The module challenges the user with
# text, and the response from the user is taken to be
# the User-Password.
#
# Proxying the tunneled EAP-GTC session is a bad idea,
# the users password will go over the wire in plain-text,
# for anyone to see.
#
gtc {
# The default challenge, which many clients
# ignore..
#challenge = Password:
# The plain-text response which comes back
# is put into a User-Password attribute,
# and passed to another module for
# authentication. This allows the EAP-GTC
# response to be checked against plain-text,
# or crypt'd passwords.
#
# If you say Local instead of PAP, then
# the module will look for a User-Password
# configured for the request, and do the
# authentication itself.
#
auth_type = PAP
}
## EAP-TLS
#
# To generate ctest certificates, run the script
#
#../scripts/certs.sh
#
# The documents on http://www.freeradius.org/doc
# are old, but may be
Re: Freeradius is not restarting properly (fails to quit and becomes a zombie process)
select(5, [3 4], NULL, NULL, {6, 0})= 1 (in [3], left {5, 992000})
time(NULL) = 1159497421
recvfrom(3, \1\1\0\227\247\326\245\\\207\222(\352H\305\311\213\300...,
4096, 0, {sa_family=AF_INET, sin_port=htons(2054),
sin_addr=inet_addr(192.168.0.1)}, [16]) = 151
write(1, rad_recv: Access-Request packet ..., 77rad_recv:
Access-Request packet from host 192.168.0.1:2054, id=1, length=151
) = 77
time(NULL) = 1159497421
write(1, \tUser-Name = \Jason Wittlin-Cohe..., 35User-Name =
Jason Wittlin-Cohen
) = 35
write(1, \tNAS-IP-Address = 192.168.0.1\n, 30 NAS-IP-Address = 192.168.0.1
) = 30
write(1, \tCalled-Station-Id = \00160112eb..., 36
Called-Station-Id = 00160112ebda
) = 36
write(1, \tCalling-Station-Id = \00095b934..., 37
Calling-Station-Id = 00095b93459e
) = 37
write(1, \tNAS-Identifier = \00160112ebda\..., 33 NAS-Identifier =
00160112ebda
) = 33
write(1, \tNAS-Port = 8\n, 14 NAS-Port = 8
)= 14
write(1, \tFramed-MTU = 1400\n, 19Framed-MTU = 1400
) = 19
write(1, \tState = 0x8570d74429dcf8507949a..., 44 State =
0x8570d74429dcf8507949ae638bd52940
) = 44
write(1, \tNAS-Port-Type = Wireless-802.11..., 33 NAS-Port-Type =
Wireless-802.11
) = 33
write(1, \tEAP-Message = 0x020800060d00\n, 30 EAP-Message = 0x020800060d00
) = 30
write(1, \tMessage-Authenticator = 0xb781d..., 60
Message-Authenticator = 0xb781dd8563450fa51bff3ce9be35dac3
) = 60
time(NULL) = 1159497421
write(1, Processing the authorize secti..., 51 Processing the
authorize section of radiusd.conf
) = 51
time(NULL) = 1159497421
write(1, modcall: entering group authoriz..., 48modcall: entering
group authorize for request 8
) = 48
time(NULL) = 1159497421
write(1, modcall[authorize]: module \pr..., 67 modcall[authorize]:
module preprocess returns ok for request 8
) = 67
time(NULL) = 1159497421
write(1, modcall[authorize]: module \ch..., 63 modcall[authorize]:
module chap returns noop for request 8
) = 63
time(NULL) = 1159497421
write(1, modcall[authorize]: module \ms..., 65 modcall[authorize]:
module mschap returns noop for request 8
) = 65
time(NULL) = 1159497421
write(1, rlm_realm: No \'@\' in User-Na..., 82rlm_realm: No
'@' in User-Name = Jason Wittlin-Cohen, looking up realm NULL
) = 82
time(NULL) = 1159497421
time(NULL) = 1159497421
write(1, rlm_realm: No such realm \NU..., 36rlm_realm: No
such realm NULL
) = 36
time(NULL) = 1159497421
write(1, modcall[authorize]: module \su..., 65 modcall[authorize]:
module suffix returns noop for request 8
) = 65
time(NULL) = 1159497421
write(1, rlm_eap: EAP packet type respo..., 50 rlm_eap: EAP packet
type response id 8 length 6
) = 50
time(NULL) = 1159497421
write(1, rlm_eap: No EAP Start, assumin..., 68 rlm_eap: No EAP
Start, assuming it's an on-going EAP conversation
) = 68
time(NULL) = 1159497421
write(1, modcall[authorize]: module \ea..., 65 modcall[authorize]:
module eap returns updated for request 8
) = 65
time(NULL) = 1159497421
write(1, users: Matched entry Jason W..., 56users: Matched
entry Jason Wittlin-Cohen at line 96
) = 56
time(NULL) = 1159497421
write(1, modcall[authorize]: module \fi..., 62 modcall[authorize]:
module files returns ok for request 8
) = 62
time(NULL) = 1159497421
write(1, modcall: leaving group authorize..., 65modcall: leaving group
authorize (returns updated) for request 8
) = 65
time(NULL) = 1159497421
write(1, rad_check_password: Found Aut..., 43 rad_check_password:
Found Auth-Type EAP
) = 43
time(NULL) = 1159497421
write(1, auth: type \EAP\\n, 17auth: type EAP
)= 17
time(NULL) = 1159497421
write(1, Processing the authenticate se..., 54 Processing the
authenticate section of radiusd.conf
) = 54
time(NULL) = 1159497421
write(1, modcall: entering group authenti..., 51modcall: entering
group authenticate for request 8
) = 51
time(NULL) = 1159497421
write(1, rlm_eap: Request found, releas..., 49 rlm_eap: Request
found, released from the list
) = 49
time(NULL) = 1159497421
write(1, rlm_eap: EAP/tls\n, 19 rlm_eap: EAP/tls
)= 19
time(NULL) = 1159497421
write(1, rlm_eap: processing type tls\n, 31 rlm_eap: processing
type tls
) = 31
time(NULL) = 1159497421
write(1, rlm_eap_tls: Authenticate\n, 28 rlm_eap_tls: Authenticate
) = 28
time(NULL
Why is the default DH keysize only 512 bits?
I noticed that the default DH keysize in FreeRadius 1.1.3 is 512 bits. As DH keys have approximately the same strength as RSA keys, and 512 bit RSA keys have already been broken, wouldn't it be adviseable to use at least 1024 bit DH keys as the minimum size. 1024 bits is currently the minimum recommended size for a DSA/RSA certificate. It might also be a good idea to include the option commented out in eap.conf so users know that it's something they can change. I originally thought that the DH keysize would be determined by the DH parameter file and only realized that it was still using 512 bit keys when I ran freeradius in debug mode. As fas as performance goes, I've tested with 2048 bit and 3072 bit DH keys with no performance degredation. Authentication occurs in 1-2 seconds using the Funk Odyssey client on Windows XP SP2 with 3072 bit RSA certificates and 3072 bit DH key exchange. Also, it might be a good idea to put a comment in the TLS cipher suite comment section that the Microsoft Windows supplicant in Windows XP SP2 uses RC4-MD5 by default (TLS_RSA_WITH_RC4_128_MD5). First, MD5 is deprecated and weak. SHA-1 should be used in its place. Secondly, DH is preferable to RSA for key exchange because it provides perfect forward secrecy. If RSA is used for encryption, a compromise of the client private key would allow an attacker to gain access to the master keys used to encrypt all prior wireless sessions whereas fresh DH keys are produced on each authentication and deleted after use. OpenSSL's 'HIGH' setting is probably the best for a Windows XP user as it uses EDH-RSA-DES-CBC3-SHA (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA), so SHA1 is used for integrity, and DH is used for key exchange. Windows XP SP2 and earlier versions of Windows do not support AES for use in any of the EAP modes. Apparently, if you want to use AES you need to upgrade to Vista (See Security in Vista) or use a 3rd party supplicant like the Funk Odyssey Client which I use (uses TLS_DH_RSA_WITH_AES_256_CBC_SHA with default Freeradius setup). Jason Wittlin-Cohen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
