RE: rlm_eap_tls not built because OpenSSL not found

Tim Winders Mon, 13 Dec 2004 13:36:19 -0800

Thank you Guy!  The SecureW2 free plugin works perfectly!

--

Tim Winders
Associate Dean of Information Technology
South Plains College
Levelland, TX 79336

On Mon, 13 Dec 2004, Guy Davies wrote:

Hi Tim,

EAP-TTLS is not supported by default by the MS 802.1x supplicant.
*However*, you can get a copy of SecureW2 at http://www.securew2.com/,
which behaves as a plugin to the MS 802.1x supplicant to provide support
for EAP-TTLS.  If you want to use a third party complete supplicant, I'd
recommend Funk's Odyssey client.  It's not free, but you can download a
30 day free trial from http://www.funk.com/.

Regards,

Guy

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Tim Winders
Sent: 13 December 2004 18:32
To: [EMAIL PROTECTED]
Subject: RE: rlm_eap_tls not built because OpenSSL not found


Grrrr.  It's always something.

Is there a way to configure a WinXP SP2 client to use EAP-TTLS/PAP?

When I enable TTLS, what default_eap_type do I specify?  I
would guess
PAP.

I have tried searching through the FAQ and the list archives,
but am still
confused.  Much of what is there doesn't seem to be relevant
anymore with
current freeradius versions.  (I am using the 20041210 snapshot)

--

Tim Winders
Associate Dean of Information Technology
South Plains College
Levelland, TX 79336

On Mon, 13 Dec 2004, Guy Davies wrote:

Hi Tim,
You can't authenticate to the /etc/passwd file using

PEAP/MS-CHAPv2.

Any CHAP based authentication mechanism requires the server to have
access to the *clear text* passwords.

If you want to use PEAP/MS-CHAPv2, then you'll need to create
definitions of your users either in a local (or other)

database with

clear text (or trivially reversible) passwords.

If you want to use /etc/passwd, you could switch to EAP-TTLS/PAP.
Since PAP sends the password in clear text (don't worry,

it's inside

the outer TTLS tunnel so it's not visible in the air), your server
doesn't need the clear text held locally.  It simply

applies the same

crypt algorithm to the received password and checks the

result against

your /etc/passwd file.

Regards,

Guy

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On

Behalf Of Tim

Winders
Sent: 13 December 2004 15:55
To: [EMAIL PROTECTED]
Subject: Re: rlm_eap_tls not built because OpenSSL not found

Mon Dec 13 07:02:02 2004 : Info: rlm_eap_tls:  Length Included
Mon Dec 13 07:02:02 2004 : Error:     TLS_accept:error in

SSLv3 read client

certificate A Mon Dec 13 07:02:02 2004 : Info:

rlm_eap_tls: Received

EAP-TLS ACK message


That is not a show stopper. TLS is complaining about the client
certificate you don't need for PEAP, but should process

the request

anyway. Examine the debug output to see if there is any
other failure.
I am trying to connect to a Cisco AP1200 from a Windows XP SP2
client. The client has Network Authentication Open, Data
Encryption
WEP, EAP Type Protected EAP (PEAP), Authentication

Method: Secured

password (EAP-MSCHAP v2).
Why open and WEP? Why not WPA TKIP? The AP and supplicant should
support this.
No reason. I have changed the configuration to WPA/TKIP.

Here is the

degub output from radiusd after I have applied the MS hotfix
as referenced
in a previous message and have changed the AP and client
configuration to
WPA/TKIP.

--- Walking the entire request list ---
Cleaning up request 22 ID 236 with timestamp 41bdb896

Nothing to do.

Sleeping until we see a request.
rad_recv: Access-Request packet from host

10.0.1.231:21646, id=237,

length=134
         User-Name = "twinders"
         Framed-MTU = 1400
         Called-Station-Id = "0012.7f75.d940"
         Calling-Station-Id = "0090.4b65.34a5"
         Service-Type = Login-User
         Message-Authenticator = 0xdc3d497356c2a583f2eaf7954c684d3a
         EAP-Message = 0x0201000d017477696e64657273
         NAS-Port-Type = Wireless-802.11
         NAS-Port = 512
         NAS-IP-Address = 10.0.1.231
         NAS-Identifier = "sub-ap1"
   Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 23
   modcall[authorize]: module "preprocess" returns ok for

request 23

   modcall[authorize]: module "chap" returns noop for request 23
   modcall[authorize]: module "mschap" returns noop for request 23
   modcall[authorize]: module "digest" returns noop for request 23
     rlm_realm: No '@' in User-Name = "twinders", looking up realm
NULL
     rlm_realm: No such realm "NULL"
   modcall[authorize]: module "suffix" returns noop for request 23
   rlm_eap: EAP packet type response id 1 length 13
   rlm_eap: No EAP Start, assuming it's an on-going EAP

conversation

   modcall[authorize]: module "eap" returns updated for request 23
     users: Matched entry DEFAULT at line 152
   modcall[authorize]: module "files" returns ok for request 23
modcall: group authorize returns updated for request 23
   rad_check_password:  Found Auth-Type EAP
auth: type "EAP"
   Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 23
   rlm_eap: EAP Identity
   rlm_eap: processing type tls
   rlm_eap_tls: Initiate
   rlm_eap_tls: Start returned 1
   modcall[authenticate]: module "eap" returns handled for

request 23

modcall: group authenticate returns handled for request 23 Sending
Access-Challenge of id 237 to 10.0.1.231:21646
         EAP-Message = 0x010200061920
         Message-Authenticator = 0x00000000000000000000000000000000
         State = 0xe2c50ab039bff81ff87783b7c4dc1736
Finished request 23
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 23 ID 237 with timestamp 41bdb8b7

Nothing to do.

Sleeping until we see a request.


I see where it matches the DEFALT entry in the users file.  This is
simply:

DEFAULT Auth-Type = System
         Fall-Through = 1

I am trying to authenticate to the /etc/passwd file on the

system.

Dial up PPP users are able to connect and authenticate OK using
the default
Framed-User service type:

DEFAULT Service-Type == Framed-User
         Framed-IP-Address = 255.255.255.254,
         Framed-MTU = 576,
         Service-Type = Framed-User,
         Fall-Through = Yes


Perhaps the problem is here?  I am new to freeradius and may have
missed something here.

--

Tim Winders
Associate Dean of Information Technology
South Plains College
Levelland, TX 79336

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

This e-mail is private and may be confidential and is for

the intended

recipient only.  If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed.  If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or
disseminating this e-mail or any information contained in

it. We use

reasonable endeavours to virus scan all e-mails leaving the Company
but no warranty is given that this e-mail and any attachments are
virus free.  You should undertake your own virus checking.

The right

to monitor e-mail communications through our network is reserved by
us.

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


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


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

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

RE: rlm_eap_tls not built because OpenSSL not found

Reply via email to