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 <tnt@kalik.net>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" <jwittlincohen@gmail.com> 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 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 jason.wittlin-cohen@yale.edu

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Jason Wittlin-Cohen Yale Law School, Class of 2010 jason.wittlin-cohen@yale.edu

On Tue, Dec 9, 2008 at 5:35 AM, Alan DeKok <aland@deployingradius.com>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