Hi I'd like to make a public hotspot management system with chillispot and freeradius. I saw in the freeradius source that the NAS are identified from the ip address, and the secret is determined from it. My problem is that there can be hotspots on dynamic ip addresses. The solution I found actually is to have an unique secret shared with all hotspots. So the secret is known by everybody. My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type) - Is there a way of maintaining a per hotspot secret with dynamic ip addresses? Regards Sophana
My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type) one is spell it out and try rumble it so he forms a new word from it - Is there a way of maintaining a per hotspot secret with dynamic ip addresses? yes. check client and clients.conf relationship HTH milver -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/354 - Release Date: 6/1/2006
vertito wrote:
My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
one is spell it out and try rumble it so he forms a new word from it
Is it a real security problem? I will be using accounting for facturation purposes...
- Is there a way of maintaining a per hotspot secret with dynamic ip addresses?
yes. check client and clients.conf relationship
I did not find. clients.conf entry seems to be ip based. How do I setup a NAS without knowing its ip? (and differentiate between several of them)
vertito wrote:
My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
one is spell it out and try rumble it so he forms a new word from it
Is it a real security problem? I will be using accounting for facturation purposes...
- Is there a way of maintaining a per hotspot secret with dynamic ip addresses?
yes. check client and clients.conf relationship
I did not find. clients.conf entry seems to be ip based. How do I setup a NAS without knowing its ip? (and differentiate between several of them) - why not implement static IP for APs? -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/354 - Release Date: 6/1/2006
vertito wrote:
vertito wrote:
My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
one is spell it out and try rumble it so he forms a new word from it
Is it a real security problem? I will be using accounting for facturation purposes...
I am not sure what you mean by facturation. If a hacker knows the shared secret, he can assume the identity of the nas and can utilize the radius server in any way the NAS could, including injecting fake accounting packets, fake auth packets, whatever. This could potentially open up the potential for a DOS attack. For these reasons you should always keep this secret, hence shared SECRET ;-) But this is the way radius works according to the rfcs. It isn't just a freeradius thing. Chris Carver Network Engineer
If you don't want Dynamic address use VPN between your RADIUS server an your hotspots.
My question is : - What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
one is spell it out and try rumble it so he forms a new word from it
Is it a real security problem? I will be using accounting for facturation purposes...
- Is there a way of maintaining a per hotspot secret with dynamic ip addresses?
yes. check client and clients.conf relationship
I did not find. clients.conf entry seems to be ip based. How do I setup a NAS without knowing its ip? (and differentiate between several of them) -
why not implement static IP for APs?
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.1/354 - Release Date: 6/1/2006
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
_________________________________________________________________ Un amor, una aventura, compañía para un viaje. Regístrate gratis en MSN Amor & Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349
sophana <sophana@zizi.ath.cx> wrote:
I saw in the freeradius source that the NAS are identified from the ip address, and the secret is determined from it.
That's how RADIUS works.
My problem is that there can be hotspots on dynamic ip addresses. The solution I found actually is to have an unique secret shared with all hotspots. So the secret is known by everybody.
Or, make the hotspots NOT have dynamic IP's. There's no reason why they should have dynamic IP's.
- What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
If someone knows the secret, he can do *anything* to the packets without the RADIUS server being able to tell.
- Is there a way of maintaining a per hotspot secret with dynamic ip addresses?
Not really, no. Alan DeKok.
Alan DeKok wrote:
My problem is that there can be hotspots on dynamic ip addresses. The solution I found actually is to have an unique secret shared with all hotspots. So the secret is known by everybody.
Or, make the hotspots NOT have dynamic IP's. There's no reason why they should have dynamic IP's.
In my project, I don't own the hotspots, and don't know about the hotspots ISPs. The hotspots communicate to the radius server though the internet.
- What can a malicious user can do with the secret? Can it alter accounting and other things? (chillispot uses chap auth-type)
If someone knows the secret, he can do *anything* to the packets without the RADIUS server being able to tell.
Ok. I don't know much about the radius protocol details, maybe you could help me understanding how secure would be a solution where the secret is know by everybody. Chillispot uses CHAP authentication with a different secret per hotspot. I consider is part as secure. Now, once a user is authenticated, how does the nas send accounting info? Does it have to authenticate again, or is its ip address (and its (public known)secret) sufficient to authenticate? Do you need at least a session id? Imagine that the malicious use cannot listen to the radius communications. What can it do without authentication? I need security, because I will use accounting info to perform facturation... Thanks for your great help.
- Is there a way of maintaining a per hotspot secret with dynamic ip addresses?
Not really, no.
this means I must use a vpn client to connect to the radius server? I would have liked a simple chillispot installation... Regards Sophana KOK
sophana <sophana@zizi.ath.cx> wrote:
In my project, I don't own the hotspots, and don't know about the hotspots ISPs. The hotspots communicate to the radius server though the internet.
I would suggest using another method to get a secure connection to the hotspot. Maybe IPSec. Barring that, each hotspot has a dynamic IP within a small network range. So you can list the network in "clients.conf", and at least have one shared secret per hotspot location. This *is* documented in clients.conf, please read it.
Ok. I don't know much about the radius protocol details, maybe you could help me understanding how secure would be a solution where the secret is know by everybody.
I thought I said it WOULDN'T be secure. What part of my response was unclear?
Now, once a user is authenticated, how does the nas send accounting info?
Read the documentation. That's what it's there for.
Does it have to authenticate again, or is its ip address (and its (public known)secret) sufficient to authenticate? Do you need at least a session id?
You're confused. Users authenticate. NASes don't.
Imagine that the malicious use cannot listen to the radius communications. What can it do without authentication?
Not get on the network? I don't understand why you're asking these questions.
I need security, because I will use accounting info to perform facturation...
Facturation isn't an english word. Alan DeKok.
Alan DeKok wrote:
sophana <sophana@zizi.ath.cx> wrote:
In my project, I don't own the hotspots, and don't know about the hotspots ISPs. The hotspots communicate to the radius server though the internet.
I would suggest using another method to get a secure connection to the hotspot. Maybe IPSec.
Barring that, each hotspot has a dynamic IP within a small network range. So you can list the network in "clients.conf", and at least have one shared secret per hotspot location. This *is* documented in clients.conf, please read it.
I don't want to do that, because it is too complex to setup. My users setup their hotspot by themself (at least at the beginning) Setting up a vpn is too complicated. I just want the setup as simple as possible.
Ok. I don't know much about the radius protocol details, maybe you could help me understanding how secure would be a solution where the secret is know by everybody.
I thought I said it WOULDN'T be secure. What part of my response was unclear?
Now, once a user is authenticated, how does the nas send accounting info?
Read the documentation. That's what it's there for.
Ok sorry for asking. I finally read the RFC2866. I saw that the accounting request authenticator only depends on the famous secret, not on the authentication. I am now convinced that the secret must remain secret. But I think there is a solution for having dynamic ip that could be implemented. Please tell me if I'm wrong. Both the Access Request and Accounting Request MUST have the NAS-IP-Address <http://www.freeradius.org/rfc/rfc2865.html#NAS-IP-Address> attribute or a NAS-Identifier <http://www.freeradius.org/rfc/rfc2865.html#NAS-Identifier> attribute (or both). Does this mean that ALL packets sent from client contains at least one of these 2 attributes? So does this mean that the radius server could lookup in its database a secret according to one of these attributes instead of the ip address? That would definitly solve the dynamic ip address problem wouldn'it?
I need security, because I will use accounting info to perform facturation...
Facturation isn't an english word.
Sorry, facturation is the french word for billing. Regards Sophana KOK
sophana <sophana@zizi.ath.cx> wrote:
Both the Access Request and Accounting Request MUST have the NAS-IP-Address <http://www.freeradius.org/rfc/rfc2865.html#NAS-IP-Address> attribute or a NAS-Identifier <http://www.freeradius.org/rfc/rfc2865.html#NAS-Identifier> attribute (or both). Does this mean that ALL packets sent from client contains at least one of these 2 attributes?
Yes.
So does this mean that the radius server could lookup in its database a secret according to one of these attributes instead of the ip address?
In theory, yes. In practice, this permits additional attacks that can compromise your server. Please read clients.conf, and implement my suggestion for using shared secrets for an entire network. It's by far and away the best choice. Alan DeKok.
Hi,
I don't want to do that, because it is too complex to setup. My users setup their hotspot by themself (at least at the beginning) Setting up a vpn is too complicated. I just want the setup as simple as possible.
you are planning to roll out captive portals, with RADIUS authentication, most likely SQL based accounting and volume/time account restrictions etc. you MAY have to install a form of proxy to protect juveniles from certain sites etc - depending on local legal requirements. compared to this, setting up a VPN tunnel to the central AAA box with OpenVPN is trivial. Its about 15 lines of openvpn.conf file. oh, and a 'yum install openvpn' beforehand. which do you want? security and a workable system, or a hatchet job? alan
Hi,
In my project, I don't own the hotspots, and don't know about the hotspots ISPs. The hotspots communicate to the radius server though the internet.
I would suggest using another method to get a secure connection to the hotspot. Maybe IPSec.
this is again an example where a RadSec extension would come in extremely handy. Short wrapup: RadSec establishes connections via TCP and TLS and transports the RADIUS payload over it, so clients can be identified by their TLS certificate; IPs and shred secrets become obsolete. Create a dedicated CA for your servers, then whoever tries to connect can be checked against your CA root. Make the hotspots talk RadSec and let them communicate with your FR server via this link. The only open problem is: right now there is only one implementation of RadSec in OSCs Radiator, and it could be better coded and more advanced. I am working on a formal specification of RadSec right now, of which I hope it will somehow find a way into the Informational RFC track. There is a lot more potential in it than the OSC Whitepaper suggests. It would be really great to get an implementation of this in FR. Greetings, Stefan Winter -- 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:
Hi,
In my project, I don't own the hotspots, and don't know about the hotspots ISPs. The hotspots communicate to the radius server though the internet.
I would suggest using another method to get a secure connection to the hotspot. Maybe IPSec.
this is again an example where a RadSec extension would come in extremely handy. Short wrapup: RadSec establishes connections via TCP and TLS and transports the RADIUS payload over it, so clients can be identified by their TLS certificate; IPs and shred secrets become obsolete. Create a dedicated CA for your servers, then whoever tries to connect can be checked against your CA root. Make the hotspots talk RadSec and let them communicate with your FR server via this link.
The only open problem is: right now there is only one implementation of RadSec in OSCs Radiator, and it could be better coded and more advanced.
I am working on a formal specification of RadSec right now, of which I hope it will somehow find a way into the Informational RFC track. There is a lot more potential in it than the OSC Whitepaper suggests.
It would be really great to get an implementation of this in FR.
Greetings,
Stefan Winter
I finally found a solution to this problem. I will implement myself the dynamic ipaddress compatible radius server, using the NAS-identifier attributes in requests to determine the secret instead of the ipaddress. I will implement this in python from pyrad, a very simple radius implementation in python For authentication, chillispot uses CHAP which is secure enough for me. (I add some additionnal secret to the password) The accounting request protected by a secret is also safe enough for me. (at the beginning) I am sure that this could be implemented quite easily in freeradius. Maybe I'll do it if I have performance problems. Regards Sophana KOK
Stefan Winter <stefan.winter@restena.lu> wrote:
this is again an example where a RadSec extension would come in extremely handy. Short wrapup: RadSec establishes connections via TCP and TLS and transports the RADIUS payload over it, so clients can be identified by their TLS certificate; IPs and shred secrets become obsolete.
This is *extremely* useful, and solves a lot of deployment problems.
I am working on a formal specification of RadSec right now, of which I hope it will somehow find a way into the Informational RFC track. There is a lot more potential in it than the OSC Whitepaper suggests.
I'm available to work on it too, if you need help.
It would be really great to get an implementation of this in FR.
I don't think it's that hard, it just needs to be done. Alan DeKok.
Hi,
this is again an example where a RadSec extension would come in extremely handy. Short wrapup: RadSec establishes connections via TCP and TLS and transports the RADIUS payload over it, so clients can be identified by their TLS certificate; IPs and shred secrets become obsolete.
This is *extremely* useful, and solves a lot of deployment problems.
I am working on a formal specification of RadSec right now, of which I hope it will somehow find a way into the Informational RFC track. There is a lot more potential in it than the OSC Whitepaper suggests.
I'm available to work on it too, if you need help.
Well, I wanted to get started in the next days. I thought of providing a rough draft, based on OSCs whitepaper, and share that with you and OSC. It will also go through a review on a (public) Task Force, the TERENA Task Force "Mobility", creator of a worldwide roaming service for the education and research community: http://www.terena.nl/activities/index.php?action=set_filters&filters[topic_id]=2 Later on, it is hopefully good enough to be considered as worthy of getting an (informational?) RFC number at the IETF. Greetings, Stefan Winter -- 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
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Christopher Carver -
Santiago Balaguer García -
sophana -
Stefan Winter -
vertito