EAP-TTLS inner auth methods for 802.1x
I have configured a working EAP-TLS system and am now migrating to use EAP-TTLS (with both client side certificates and a password authentication mechanism). I'm stuck trying to work out how to avoid sending the password unhashed to the server and think that some form of CHAP/MSCHAPv2 might be the right way to go. My current thoughts are that I should use PAP with SHA1 or SSHA1 but I seem to get the right config (if it is even possible). So, with this problem, can anybody suggest a way to use SHA1/SSHA1 or some other form of cryptographically secure, non-cleartext password within the inner authentication mechanism of EAP-TTLS for use in WPA2 Enterprise/802.1x. If this is feasible/possible, are there any gotcha's with the various supplicants to getting this to work from the client side and avoiding sending the passwords in cleartext (inside the EAP-TLS tunnel). Also, while I'm here, any suggestions for an appropriate backend password store so that there is never a cleartext password except for the initial entry (password change) on the server side would be appreciated. cheers, James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS inner auth methods for 802.1x
On 29/01/2007, at 10:07 PM, Alan DeKok wrote: James Lever wrote: I'm stuck trying to work out how to avoid sending the password unhashed to the server Why? Two reasons - first I am trying to limit risk of client misconfiguration - if a client has misconfigured their supplicant, to avoid passwords inadvertently going through in the clear and secondly to limit the risk of account compromise through abuse of privileges on the radius server. Yes, I realise that this is a small risk, but I'm just trying to see how far I can go in terms of securing the user credentials. See my web page for compatibility issues: http:// deployingradius.com/documents/protocols/compatibility.html Thanks for the pointer. This helps clarify the requirements of the different authentication mechanisms. Your desires are contradictory. If the password is hashed in EAP- TTLS, then the server needs the cleartext password in order to authenticate the user. I don't understand why giving the server access to the cleartext passwords is such a terrible thing to do. What are the risks of client misconfiguration such that it will actually get to the point of attempting to transmit the password in the clear? cheers, James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS inner auth methods for 802.1x
On 29/01/2007, at 11:03 PM, [EMAIL PROTECTED] wrote: MSCHAPv2 is the main way to go. offering challenge/response means the password is never sent clear. alternatively you could use MD5 instead of plain. but client support is an issue... After reading through Alan DeKok's compatibility page and a bit further research from that, it would appear that the risk of compromise is greater from poor storage on the server than the transient cleartext credentials inside the EAP-TLS session. cheers, James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_eap: SSL error
On 17/01/2007, at 4:47 PM, Alan DeKok wrote: James Lever wrote: Wed Jan 17 08:00:11 2007 : Error: TLS_accept:error in SSLv3 read client certificate A That just means there's no client certificate. Interesting given I'm only allowing EAP-TLS access to my wireless LAN (or attempting to) Below is the log output when run in full debugging (excerpt) -- rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 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 eaptls_verify returned 7 rlm_eap_tls: Done initial handshake rlm_eap_tls: TLS 1.0 Handshake [length 0be8], Certificate chain-depth=1, error=0 -- User-Name = clientCN -- BUF-Name = :30 2007 : Info: Ready to process requests. -- subject = /C=AU/issuerDN -- issuer = /C=AU/issuerDN -- verify return:1 radius_xlat: 'clientCN' rlm_eap_tls: checking certificate CN (clientCN) with xlat'ed value (clientCN) chain-depth=0, error=0 -- User-Name = clientCN -- BUF-Name = clientCN -- subject = /C=AU/clientDN -- issuer = /C=AU/issuerDN -- verify return:1 TLS_accept: SSLv3 read client certificate A rlm_eap_tls: TLS 1.0 Handshake [length 0106], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: TLS 1.0 Handshake [length 0106], 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 rlm_eap: SSL error error::lib(0):func(0):reason(0) SSL Connection Established eaptls_process returned 13 modcall[authenticate]: module eap returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 -- When I try to do the same with a Certificate from another CA it fails as expected. So why does the EAP-TLS login work even though it complains that no certificate was received? Is the certificate actually validated and hence there really was no error, or is FreeRADIUS or OpenSSL authorising where it should not? cheers, James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_eap: SSL error
Hi List, FreeRADIUS 1.1.4 on FreeBSD (5-STABLE), Apple Airport Extreme NAS, MacBook Pro client, WPA2 Enterprise with 2k keys. I'm having the much mentioned but very hard to get real information about error below: Wed Jan 17 08:00:11 2007 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Jan 17 08:00:11 2007 : Error: rlm_eap: SSL error error: :lib(0):func(0):reason(0) Wed Jan 17 08:00:11 2007 : Error: rlm_eap: SSL error error: :lib(0):func(0):reason(0) Wed Jan 17 08:00:11 2007 : Auth: Login OK: [wireless- client.jamver.id.au] (from client apple-basestation port 255 cli xx- xx-xx-xx-xx-xx) Now, the best explanation I can find on list is that it's safe to ignore the 3 lines of errors, which, although appears to be very accurate in that they have no effect on the running service, should not be there if they are really not errors. Can anybody explain what is actually causing these errors (and why) and what would be required to silence them? cheers, James smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS/seg fault with 4096 bit keys
Hi again list, Another issue I have had in setting up a WPA2 Enterprise environment is that I can get it to work as expected with 2k keys, however, if I go to 4k keys, freeradius 1.1.4 loads properly but seg faults when handling a 4k key request. The environment is Apple Airport Extreme base station, and MacBook Pro client wth FreeRADIUS 1.1.4 under FreeBSD 5-STABLE. As soon as I migrate back to 2k keys it again works as expected. Can anybody make any suggestions on how to debug this? cheers, James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
