I used OpenSSL, what are the special attributes that you mention? is it OID? Thanks. Hamid. Guy Davies wrote:
Hi Hamid,
What CA did you use to create the client certs? If it was OpenSSL, did you ensure that you included the special attributes that the MS supplicant expects? There are a few HOWTO's around and they pretty much all reference this special value.
If you used the M$ Certificate Services, it is automatically added.
Rgds,
Guy
-----Original Message----- From: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Brian A. Seklecki Sent: 16 November 2005 17:02 To: Hamid Salim Cc: freeradius-users@lists.freeradius.org Subject: Re: FreeRadius EAP-TLS issue
If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 -cacert /blah".
Are you sure that you have imported and "trusted" your CA's cetificate on both the client and the server?
This is when I let the other guys make suggestions.
I was just curious of EAP-TLS with client certificates was simply a way of delivering the username to the client, letting the client authenticate the server and the server authenticate the identity of the client, and then providing for another password based mechanism.
Or if certificate TLS handshake was sufficient for authorization and authentication...
For example, Apache SSL can be told to verify client certificates, but htaccess would still be required.
With SMTP, client and server SSL verification can be compelled, but for SMTP AUTH for relay, username/password authentication would still be required.
~BAS
On Wed, 16 Nov 2005, Hamid Salim wrote:
It should not be asking/expecting any userid/password pair. I have installed the certificates on the supplicant machine which should be sufficient to authenticate without any password requirements. I am not
sure why the certs are not working???
Brian A. Seklecki wrote:
rlm_eap_tls: Received unexpected tunneled data after successful handshake.
...that's what I get when I try an invalid password in my EAP + Cisco
1200
+ LDAP + PEAP/MS-CHAPv2 configuration.
Let me ask...how is the client certificate method supposed to work?
Is the username embeded the CN/CommonName attribute of the certificate and the user is prompted for a password which you setup in authenticate {} ?
Is that any more secure than using PEAP/MS-CHAPv2 ?
~BAS
On Wed, 16 Nov 2005, Hamid Salim wrote:
Hi, I am just wondering if anyone has encountered the same issue. I have
set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. For some reason I am getting:
auth: Failed to validate the user. Login incorrect: [radiustst/<no User-Password attribute>] (from client testradius-ap-1 port 0 cli 00-10-c6-38-af-7b)
complete listing is attached. I am using certificates and SSL session is created successfully, then why FreeRadius is expecting a userid/password?
Any help will be appreciated.
Thanks Hamid.
============= Complete Listing ================= Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, length=1247 User-Name = "radiustst" NAS-IP-Address = 129.10.56.156 Called-Station-Id = "00-20-a6-4a-12-21" Calling-Station-Id = "00-10-c6-38-af-7b" NAS-Identifier = "APtest3" State = 0xb9a67433435733a42f7cbd528aa6ae7a Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message =
0x020504510d800000044716030104170b000307000304000301308202fd30820266a0 03
020102020102300d06092a864886f70d01010405003054310b30090603550406130255 53
310b3009060355040813024d413120301e060355040a13174e6f727468656173746572 6e
20556e6976657273697479311630140603550403130d45434541757468536572766572 30
1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b 30
09060355040613025553310b3009060355040813024d413120301e060355040a13174e 6f
7274686561737465726e20556e69766572736974793112301006035504031309726164 69
7573 EAP-Message =
0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b998 3d
b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399 c3
9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d 76
9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175 a0
47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d13 04
023000302c06096086480186f842010d041f161d4f70656e53534c2047656e65726174 65
64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f8281 57
2f5e EAP-Message =
0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf37 43
0ee64b68e9a158a4563054310b3009060355040613025553310b300906035504081302 4d
413120301e060355040a13174e6f7274686561737465726e20556e6976657273697479 31
1630140603550403130d45434541757468536572766572820900cab77a537cadfaf330 0d
06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e 2d
8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf 00
d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57da e0
c423 EAP-Message =
0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f274 65
1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000 f0
70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df 74
830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e 2f
30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e 69
99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1 a3
25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5f dd
8f7c EAP-Message =
0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d 80
af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf8698 86
11a6916269516c4e5b6bf006d943609a71740a4d3a60 Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae Processing the authorize section of radiusd.conf modcall: entering group authorize for request 8 modcall[authorize]: module "preprocess" returns ok for request 8 radius_xlat:
'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115'
rlm_detail:
/opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% Y%
m%d expands to /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 15 modcall[authorize]: module "auth_log" returns ok for request 8 rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 8 rlm_eap: EAP packet type response id 5 length 253 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 8 users: Matched entry radiustst at line 54 modcall[authorize]: module "files" returns ok for request 8 modcall: group authorize returns updated for request 8 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 8 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: Length Included eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate chain-depth=1, error=0 --> User-Name = radiustst --> BUF-Name = ECEAuthServer --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer
--> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer
--> verify return:1 chain-depth=0, error=0 --> User-Name = radiustst --> BUF-Name = radiustst --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer
--> 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 0086], 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 modcall[authenticate]: module "eap" returns handled for request 8 modcall: group authenticate returns handled for request 8 Sending Access-Challenge of id 71 to 129.10.56.156:6001 EAP-Message =
0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9 c2
4322bdbd6ca0af149ba46d197f153a7f4f32 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x70ed13d02f1854999ba5b4513143d53d Finished request 8 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, length=167 User-Name = "radiustst" NAS-IP-Address = 129.10.56.156 Called-Station-Id = "00-20-a6-4a-12-21" Calling-Station-Id = "00-10-c6-38-af-7b" NAS-Identifier = "APtest3" State = 0x70ed13d02f1854999ba5b4513143d53d Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 9 modcall[authorize]: module "preprocess" returns ok for request 9 radius_xlat:
'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115'
rlm_detail:
/opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% Y%
m%d expands to /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 15 modcall[authorize]: module "auth_log" returns ok for request 9 rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 9 rlm_eap: EAP packet type response id 6 length 33 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 9 users: Matched entry radiustst at line 54 modcall[authorize]: module "files" returns ok for request 9 modcall: group authorize returns updated for request 9 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 9 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: Length Included eaptls_verify returned 11 eaptls_process returned 7 rlm_eap_tls: Received unexpected tunneled data after successful handshake. rlm_eap: Handler failed in EAP/tls rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 9 modcall: group authenticate returns invalid for request 9 auth: Failed to validate the user. Login incorrect: [radiustst/<no User-Password attribute>] (from client testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for
1 seconds Finished request 9 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, length=167 Sending Access-Reject of id 72 to 129.10.56.156:6001 EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 5 ID 68 with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping until we see a request. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
l8* -lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
l8* -lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 - 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.