Stefan Winter wrote:
I finally found a solution to this problem.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 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 |
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html