EAP-TTLS/PAP -> LDAP for WPA2
Hi All, Quite new to radius and struggling to get my head around things so forgive me if my assumptions are wrong. I appear to have the setup working but i'm concerned it's not doing what it think it is. I don't think the authentication requests are actually going over an encrypted channel. I'm using freeradius-1.1.2 on a freebsd server and i've compiled it against openldap-2.3.24 which all went well. I'm attempting to set up secure wireless with WPA2 using our ldap directory for authentication. We have a replica of our directory running on the freeradius server. Originally i had hoped to use some sort of web-redirect-to-an-authentication-page system like you sometimes see in hotels but i can't find anything about that (any information welcome). After reading around, the best form of authentication i can see would be eap-ttls with pap as the inner protocol. I believe (from comments in the radiusd.conf file) that i wouldn't be able to use md5 with ldap. Now, i've set it up in a way that appears to be mostly right and i *can* authenticate with my username/password in ldap but doing a tcpdump on the radius server worries me. I can see my username passed in the clear in the packets so i'm concerned it's not using tls at all. I told the wireless client to use ttls so i can't understand what's going on. The following is a summary of the main changes i made from the radiusd.conf and eap.conf files. If i dont mention an attribute it's because i didn't change it from the default setting: radiusd.conf: modules { ldap { server = "localhost" filter = "(uid=%u)" base_filter = "(objectclass=radiusprofile)" start_tls = no dictionary_mapping = ${raddbdir}/ldap.attrmap } } authorize { eap ldap } authenticate { Auth-Type PAP { pap } eap Auth-Type LDAP { ldap } } eap.conf: eap { default_eap_type = ttls tls { private_key_file = ${raddbdir}/certs/radius_key.pem certificate_file = ${raddbdir}/certs/radius_cert.pem CA_file = ${raddbdir}/certs/cacert.pem random_file = ${raddbdir}/certs/random } ttls { default_eap_type = md5 } } Now i know that default_eap_type setting looks wrong but i don't know what i *should* have there. On the server in /var/log/radiusd.log i see the following: Wed Jul 5 16:10:32 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) I based my certificate generation on the instructions at: http://homepage.mac.com/andreaswolf/public/wpaeap.html including using the xpextensions mentioned there. I generated my random file using dd and /dev/urandom. I am a little lost and don't know what is best practice. Any advice would be appreciated. I've tried googling but haven't found a good guide that matches our setup.I can, of course, give more information if needed. Thanks, John Allman
Quite new to radius and struggling to get my head around things so forgive me if my assumptions are wrong. I appear to have the setup working but i'm concerned it's not doing what it think it is. I don't think the authentication requests are actually going over an encrypted channel.
You need to differentiate two parts of the link: a) the data that is passed between the client device and the RADIUS server and b) the backend communication between RADIUS server and LDAP. a) is encrypted when using EAP-TTLS b) may or may not be encrypted, depending on your settings in the RADIUS server.
I'm using freeradius-1.1.2 on a freebsd server and i've compiled it against openldap-2.3.24 which all went well. I'm attempting to set up secure wireless with WPA2 using our ldap directory for authentication. We have a replica of our directory running on the freeradius server. Originally i had hoped to use some sort of web-redirect-to-an-authentication-page system like you sometimes see in hotels but i can't find anything about that (any information welcome).
Try googling for "captive portal".
After reading around, the best form of authentication i can see would be eap-ttls with pap as the inner protocol. I believe (from comments in the radiusd.conf file) that i wouldn't be able to use md5 with ldap. Now,
There is a chance that you could, but using MD5 kindof sucks. And it might be non-trivial to set up.
i've set it up in a way that appears to be mostly right and i *can* authenticate with my username/password in ldap but doing a tcpdump on the radius server worries me.
You should see lots of RADIUS packets going between your server and the client (switch/access point) with encrypted payload in the attribute "EAP-Message".
I can see my username passed in the clear in the packets so i'm concerned it's not using tls at all. I told the wireless client to use ttls so i can't understand what's going on.
You might see the clear text password on packets going from your RADIUS server to LDAP (depending on how you set up the LDAP communication). That's what's going on.
The following is a summary of the main changes i made from the radiusd.conf and eap.conf files. If i dont mention an attribute it's because i didn't change it from the default setting:
radiusd.conf:
modules { ldap { server = "localhost" filter = "(uid=%u)" base_filter = "(objectclass=radiusprofile)" start_tls = no
And this is where the non-encrypted backend communication comes from: no TLS configured for the LDAP backend.
dictionary_mapping = ${raddbdir}/ldap.attrmap } }
authorize { eap ldap }
authenticate { Auth-Type PAP { pap } eap Auth-Type LDAP { ldap } }
eap.conf: eap { default_eap_type = ttls tls { private_key_file = ${raddbdir}/certs/radius_key.pem certificate_file = ${raddbdir}/certs/radius_cert.pem CA_file = ${raddbdir}/certs/cacert.pem random_file = ${raddbdir}/certs/random }
ttls { default_eap_type = md5 } }
Now i know that default_eap_type setting looks wrong but i don't know what i *should* have there.
The one in ttls {} looks a bit awkward. But if things work, it's okay I guess.
On the server in /var/log/radiusd.log i see the following:
Wed Jul 5 16:10:32 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
Which is completely normal. It means that the *client* is not sending a certificate. TTLS makes him send username and password instead of a certificate, so nothing to see here. Please move along.
I based my certificate generation on the instructions at:
http://homepage.mac.com/andreaswolf/public/wpaeap.html
including using the xpextensions mentioned there. I generated my random file using dd and /dev/urandom.
Good boy. And it seems like everything worked out beautifully. Now secure your backend communication with TLS as well if you are really concerned about that, and you're done.
I am a little lost and don't know what is best practice. Any advice would be appreciated. I've tried googling but haven't found a good guide that matches our setup.I can, of course, give more information if needed.
Really? WPA2 is quite a wide-spread scenario. And using LDAP as backend is quite common as well. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche - Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
Stefan Winter wrote:
You need to differentiate two parts of the link: a) the data that is passed between the client device and the RADIUS server and b) the backend communication between RADIUS server and LDAP.
a) is encrypted when using EAP-TTLS b) may or may not be encrypted, depending on your settings in the RADIUS server.
Hi Stefan, Thanks for the quick reply. a) is my concern, b) is not an issue. As i said in the original mail (or at least i meant to!) there is a replica of our ldap server running on the same machine as our freeradius server. It binds to the loopback device only and as such there's no real point in encrypting traffic.
Originally i had hoped to use some sort of web-redirect-to-an-authentication-page system like you sometimes see in hotels but i can't find anything about that (any information welcome).
Try googling for "captive portal".
Thanks - just didn't know the name of it!
After reading around, the best form of authentication i can see would be eap-ttls with pap as the inner protocol. I believe (from comments in the radiusd.conf file) that i wouldn't be able to use md5 with ldap. Now,
There is a chance that you could, but using MD5 kindof sucks. And it might be non-trivial to set up.
As i understand it, if ttls is working correctly, it should adequately protect my username/password no matter what inner protocol i use. So, PAP should be fine, right?
i've set it up in a way that appears to be mostly right and i *can* authenticate with my username/password in ldap but doing a tcpdump on the radius server worries me.
You should see lots of RADIUS packets going between your server and the client (switch/access point) with encrypted payload in the attribute "EAP-Message".
Ah.It would seem my original tcpdump trunkated the packets so i was missing some of the attributes. By setting -s 0, i now get the full RADIUS packets. The EAP-Message doesn't appear to be encrypted on the initial packet from the ap to the server. Inside i see Type and Identity (containing my username. The username is also in the User-Name attribute) After that, all the EAP-Message packets have Type EAP-TTLS [Funk], which i suppose is pretty funky from ethereal's point of view. But it's good news to me. I can look at the SSL fields and it appears that everything is good. So i'm feeling much happier. But i'm *not* happy with the fact that my username is going in the clear. Is there anything i can do about this? This potentially gives an attacker information he can use to try and brute force or even just passively get a list of users...
On the server in /var/log/radiusd.log i see the following:
Wed Jul 5 16:10:32 2006 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) Wed Jul 5 16:10:32 2006 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
Which is completely normal. It means that the *client* is not sending a certificate. TTLS makes him send username and password instead of a certificate, so nothing to see here. Please move along.
Excellent - good news.
Good boy. And it seems like everything worked out beautifully. Now secure your backend communication with TLS as well if you are really concerned about that, and you're done.
As i say, not an issue. No encrypted packets on the network between the radius server and the ldap server as they're on the same host, communicating over the loopback interface
I am a little lost and don't know what is best practice. Any advice would be appreciated. I've tried googling but haven't found a good guide that matches our setup.I can, of course, give more information if needed.
Really? WPA2 is quite a wide-spread scenario. And using LDAP as backend is quite common as well.
But (imho) all the write-ups dont really explain what's going on. Myself, i don't understand what the authorize section and authenticate sections are supposed to do. Could somebody talk to the radius server directly without encryption using my settings? Can i specify what kinds of authentication i'll accept from users compared to the types of backend authentication i can do? I just find it hard to get my head around it... Thanks! John
Hi,
The EAP-Message doesn't appear to be encrypted on the initial packet from the ap to the server. Inside i see Type and Identity (containing my username. The username is also in the User-Name attribute)
that'll be your outer identity... which, as it is plain to see (pun definately intended folks), is why many people use some anonymous identity for protection..why give away some of your credentials? - eg anonymous@your.home.realm.com
But (imho) all the write-ups dont really explain what's going on. Myself, i don't understand what the authorize section and authenticate sections are supposed to do. Could somebody talk to the radius server directly without encryption using my settings? Can i specify what kinds of authentication i'll accept from users compared to the types of backend authentication i can do? I just find it hard to get my head around it...
authenticate = yes, you are who you are authorize = should you be using this? do we perhaps change the service you get (eg VLAN) if you've allowed people to talk to the RADIUS server, then they can...this is why you have eg the clients.conf (or clients SQL) to define *WHAT* NAS can talk to RADIUS server and what secret key they must have to talk to it. you can define whatever type of authentication that FR supports...depending on the eg username... alan
A.L.M.Buxey@lboro.ac.uk wrote:
The EAP-Message doesn't appear to be encrypted on the initial packet from the ap to the server. Inside i see Type and Identity (containing my username. The username is also in the User-Name attribute)
that'll be your outer identity... which, as it is plain to see (pun definately intended folks), is why many people use some anonymous identity for protection..why give away some of your credentials? - eg anonymous@your.home.realm.com
Hmmm. Well, in the first packet i see the Identity in the EAP-Message, but the User-name attribute is in every packet sent by the AP. How would i go about using an anonymous identity? Would that be up to the wireless client configuration? It would be quite important for me to hide this. If i'm understanding you correctly, the User-name attribute and the Identity field in the EAP-Message attribute have nothing to do with authentication which is all enclosed (including the username) in PAP which is encrypted inside EAP-TTLS? If i could just get this fixed, i think i'd be happy with my setup...
authenticate = yes, you are who you are authorize = should you be using this? do we perhaps change the service you get (eg VLAN)
if you've allowed people to talk to the RADIUS server, then they can...this is why you have eg the clients.conf (or clients SQL) to define *WHAT* NAS can talk to RADIUS server and what secret key they must have to talk to it. you can define whatever type of authentication that FR supports...depending on the eg username...
This certainly helps me understand, but it would be nice to get a more complete understanding. I don't want to hassle you by continually asking you questions until i get it - can you point me to somewhere i can read up on this and understand. For example, it confuses me that there is an ldap, eap and pap section in the authorize section, but pap is to be used exclusively inside eap with the client and ldap is to be used exclusively with the backend server. Thanks for your help, John
Hi!
Hmmm. Well, in the first packet i see the Identity in the EAP-Message, but the User-name attribute is in every packet sent by the AP. How would i go about using an anonymous identity? Would that be up to the wireless client configuration? It would be quite important for me to hide this. If i'm understanding you correctly, the User-name attribute and the Identity field in the EAP-Message attribute have nothing to do with authentication which is all enclosed (including the username) in PAP which is encrypted inside EAP-TTLS? If i could just get this fixed, i think i'd be happy with my setup...
The thing about anonymous outer identity is that it doesn't matter what you put in there. If your real name is "iamcool" and your password is "evencooler" you can happily send "foobar" as Identity. Authentication will only depend on what's inside the tunneled PAP request. Most supplicants allow to specify the outer identity to your liking. That said, there is one exception: if you are using roaming, the realm part of the username must be the correct one, otherwise the request can't be routed to the correct server.
This certainly helps me understand, but it would be nice to get a more complete understanding. I don't want to hassle you by continually asking you questions until i get it - can you point me to somewhere i can read up on this and understand. For example, it confuses me that there is an ldap, eap and pap section in the authorize section, but pap is to be used exclusively inside eap with the client and ldap is to be used exclusively with the backend server.
The RADIUS protocol requires that all clients (NASes, for Network Access Server) have to be registered with their IP address and a shared secret before they can send any requests to the server. Once they are registered, they may ask whatever they want. The authorize section lets you configure what exactly a user (or a NAS) is allowed to ask for. authenticate lets you check credentials. For the configuration parts in FreeRADIUS that you don't understand: how about ignoring them? It is not necessary to understand deeply every line of the config. If you are *really* concerned that they do something you don't like, feel free to comment them out and try if your stuff still works. That's called trial and error and is probably a good way to learn about things. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
The thing about anonymous outer identity is that it doesn't matter what you put in there. If your real name is "iamcool" and your password is "evencooler" you can happily send "foobar" as Identity. Authentication will only depend on what's inside the tunneled PAP request. Most supplicants allow to specify the outer identity to your liking. That said, there is one exception: if you are using roaming, the realm part of the username must be the correct one, otherwise the request can't be routed to the correct server.
"Most supplicants". So there's a chance that a supplicant might not do so? Is the Identity in the EAP-Message in the first packet always the same as the User-name i see in all packets? I'm searching through my dell wireless wlan card utility and i'm pretty sure i can't hide it. Are dell breaking any rfcs or other standards that i can take them up on? This is quite worrying for me as it seems to make the setup quite insecure instead of making it more secure as i had originally hoped. Perhaps a shared key and a captive portal would provide better security. I understand the weakness, but i dont see that it would be weaker than a shared key alone and has the advantage of not allowing the username to be read by any arbitrary person. Thanks for the further explanation of the RADIUS protocol - i think i will take your advice about the configuration files and leave well enough alone:) John
"Most supplicants". So there's a chance that a supplicant might not do so?
Yes. It's implementation-specific. The Win XP built-in supplicant for example does not do it.
Is the Identity in the EAP-Message in the first packet always the same as the User-name i see in all packets?
Yes, that's what the RFC demands.
I'm searching through my dell wireless wlan card utility and i'm pretty sure i can't hide it. Are dell breaking any rfcs or other standards that i can take them up on?
No. It's optional. If Dell doesn't do it, bad luck. But you can always install a supplicant that does it, for example at www.securew2.com (very nice supplicant, IMO).
This is quite worrying for me as it seems to make the setup quite insecure instead of making it more secure as i had originally hoped. Perhaps a shared key and a captive portal would provide better security. I understand the weakness, but i dont see that it would be weaker than a shared key alone and has the advantage of not allowing the username to be read by any arbitrary person.
Uh. You should consider that you will have _no_ link-layer encryption when using captive portals. And connections can be hijacked. And with a shared key, you have no accountability. And the shared key will flow over the net unencrypted, so anyone can pick it up and abuse your network. OTOH, what's so secret about a user name? User names are the _public_ parts of credentials, it's the passwords that are critical. If you really don't want usernames to be important at all, use EAP-TLS. The client certificate will identify you, no matter what garbage you put into the user name. Captive portals are a step back with regards to security. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
I'm searching through my dell wireless wlan card utility and i'm pretty sure i can't hide it. Are dell breaking any rfcs or other standards that i can take them up on?
No. It's optional. If Dell doesn't do it, bad luck. But you can always install a supplicant that does it, for example at www.securew2.com (very nice supplicant, IMO).
I'm very impressed. I installed this and all of my complaints and concerns are answered! Now, i'm assuming and hoping the linux wpa supplicant also supports this...
Uh. You should consider that you will have _no_ link-layer encryption when using captive portals. And connections can be hijacked. And with a shared key, you have no accountability. And the shared key will flow over the net unencrypted, so anyone can pick it up and abuse your network. OTOH, what's so secret about a user name? User names are the _public_ parts of credentials, it's the passwords that are critical. If you really don't want usernames to be important at all, use EAP-TLS. The client certificate will identify you, no matter what garbage you put into the user name. Captive portals are a step back with regards to security.
Well, i was going to use wpa2 with a preshared key which would provide the link-layer encryption (as i understand it) but then require a username and password as another step in case the key got leaked. You're right about the accountability, but are you sure about the shared key going over the net unencrypted? This doesn't sound right... Since we're talking about our ldap directory, which we use for pretty much *everything*, having a list of usernames gives an attacker a starting point for trying brute force attacking. This could also be used as a starting point for identity theft or spamming. EAP-TLS probably is the most secure way to do things though it does require installing certs. I'll definitely be giving it consideration Thanks again for all your help - i'm feeling pretty happy with my setup now, John
Hi,
I'm very impressed. I installed this and all of my complaints and concerns are answered! Now, i'm assuming and hoping the linux wpa supplicant also supports this...
Sure thing :-) It's Free Open Source Software after all :-)
Uh. You should consider that you will have _no_ link-layer encryption when using captive portals. And connections can be hijacked. And with a shared key, you have no accountability. And the shared key will flow over the net unencrypted, so anyone can pick it up and abuse your network. OTOH, what's so secret about a user name? User names are the _public_ parts of credentials, it's the passwords that are critical. If you really don't want usernames to be important at all, use EAP-TLS. The client certificate will identify you, no matter what garbage you put into the user name. Captive portals are a step back with regards to security.
Well, i was going to use wpa2 with a preshared key which would provide the link-layer encryption (as i understand it) but then require a username and password as another step in case the key got leaked. You're right about the accountability, but are you sure about the shared key going over the net unencrypted? This doesn't sound right...
You would need to have the user enter his username and password on the captive portal server. From there on up to the RADIUS server, it would be clear text (unless you do some black magic with a PAP to EAP-TTLS gateway, which is possible, but no fun). The wireless link would be encrypted though, so it wouldn't be as bad as *just* the captive portal.
Since we're talking about our ldap directory, which we use for pretty much *everything*, having a list of usernames gives an attacker a starting point for trying brute force attacking. This could also be used as a starting point for identity theft or spamming.
That's pretty much arguable. If you indeed use that username for "everything" the probability that it is spied as the user enters it somewhere, leaves it on a scrap paper, tells it his "best friend" while having a beer etc. is *far* higher than someone sniffing IP traffic between your supplicant and your RADIUS server. Unless the RADIUS server is at the other end of the world.
EAP-TLS probably is the most secure way to do things though it does require installing certs. I'll definitely be giving it consideration
That's for the hardcore paranoid people, right. But if you are happy with SecureW2 and EAP-TTLS: that's perfectly fine.
Thanks again for all your help - i'm feeling pretty happy with my setup now,
Great! Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche - Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
--- John Allman <allmanj@cp.dias.ie> wrote:
Stefan Winter wrote:
I'm searching through my dell wireless wlan card utility and i'm pretty sure i can't hide it. Are dell breaking any rfcs or other standards that i can take them up on?
No. It's optional. If Dell doesn't do it, bad luck. But you can always install a supplicant that does it, for example at www.securew2.com (very nice supplicant, IMO).
I'm very impressed. I installed this and all of my complaints and concerns are answered! Now, i'm assuming and hoping the linux wpa supplicant also supports this...
Uh. You should consider that you will have _no_ link-layer encryption when using captive portals. And connections can be hijacked. And with a shared key, you have no accountability. And the shared key will flow over the net unencrypted, so anyone can pick it up and abuse your network. OTOH, what's so secret about a user name? User names are the _public_ parts of credentials, it's the passwords that are critical. If you really don't want usernames to be important at all, use EAP-TLS. The client certificate will identify you, no matter what garbage you put into the user name. Captive portals are a step back with regards to security.
Well, i was going to use wpa2 with a preshared key which would provide the link-layer encryption (as i understand it) but then require a username and password as another step in case the key got leaked. You're right about the accountability, but are you sure about the shared key going over the net unencrypted? This doesn't sound right...
Since we're talking about our ldap directory, which we use for pretty much *everything*, having a list of usernames gives an attacker a starting point for trying brute force attacking. This could also be used as a starting point for identity theft or spamming.
EAP-TLS probably is the most secure way to do things though it does require installing certs. I'll definitely be giving it consideration
Thanks again for all your help - i'm feeling pretty happy with my setup now,
John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
If your time allows the RADIUS book from O'Reilly is an invaluable reference. It includes FreeRADIUS specifics as well. Laker __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi,
I'm using freeradius-1.1.2 on a freebsd server and i've compiled it against openldap-2.3.24 which all went well. I'm attempting to set up secure wireless with WPA2 using our ldap directory for authentication. We have a replica of our directory running on the freeradius server. Originally i had hoped to use some sort of web-redirect-to-an-authentication-page system like you sometimes see in hotels but i can't find anything about that (any information welcome).
"captive portal" - there are several software tools that will do this... eg http://en.wikipedia.org/wiki/Captive_portal most people seem to be moving away from this method as it is riddled with possible security compromises.
After reading around, the best form of authentication i can see would be eap-ttls with pap as the inner protocol. I believe (from comments in the radiusd.conf file) that i wouldn't be able to use md5 with ldap. Now, i've set it up in a way that appears to be mostly right and i *can* authenticate with my username/password in ldap but doing a tcpdump on the radius server worries me. I can see my username passed in the clear in the packets so i'm concerned it's not using tls at all. I told the wireless client to use ttls so i can't understand what's going on.
PAP uses clear text (unencrypted) password authentication. whilst the EAP-TTLS traffic is encrypted (and the PAP lurks inside that encrypted session) when you CAN see the PAP in the clear is when its being sent over to LDAP - so you need to make sure that that communication is encrpyted...either by making sure its configured to use SSL for its communication channel...or simply 'stunnel'ing the traffic.
modules { ldap { server = "localhost" filter = "(uid=%u)" base_filter = "(objectclass=radiusprofile)" start_tls = no ^^^^^^^^^^^^^^
this!
dictionary_mapping = ${raddbdir}/ldap.attrmap } }
authorize { eap ldap }
alan
A.L.M.Buxey@lboro.ac.uk wrote:
"captive portal" - there are several software tools that will do this... eg http://en.wikipedia.org/wiki/Captive_portal
most people seem to be moving away from this method as it is riddled with possible security compromises.
Thanks for the heads-up. I'll take a look at it, but keep in mind the possible security implications (i'll google).
PAP uses clear text (unencrypted) password authentication. whilst the EAP-TTLS traffic is encrypted (and the PAP lurks inside that encrypted session) when you CAN see the PAP in the clear is when its being sent over to LDAP - so you need to make sure that that communication is encrpyted...either by making sure its configured to use SSL for its communication channel...or simply 'stunnel'ing the traffic.
start_tls = no
^^^^^^^^^^^^^^
this!
As mentioned in my reponse to Stefan, this is not a concern for me as they're on the same host communicating exclusively over the loopback interface. On a side-note, I've now noticed that radius doesn't appear to be respecting my ldap filter. base_filter = "(objectclass=radiusprofile)" but i can authenticate as a user without a radiusprofile attribute. Ideas? Thanks, John
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
John Allman -
Laker Netman -
Stefan Winter