RE: rlm_eap_tls not built because OpenSSL not found

[Tim Winders]

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