Multiple secrets for 0.0.0.0/0
Hi. I'd like to declare two different secrets for my radius server listening on 0.0.0.0/0. But if I declare two networks in the clients.conf file, like this: client 0.0.0.0/0 { secret = secret1 shortname = wildcard1 nastype = other } client 0.0.0.0/0 { secret = secret2 shortname = wildcard2 nastype = other } The only secret that works is "secret2". Can I have two secrets for the same "network"? even when it's the 0.0.0.0/0 one? Regards, -- Teófilo Ruiz FON - http://es.fon.com
=?ISO-8859-1?Q?Te=F3filo_Ruiz_Su=E1rez?= <teo@fon.es> wrote:
I'd like to declare two different secrets for my radius server listening on 0.0.0.0/0.
No. It's impossible. And it makes no sense. How does the server decide which secret to use? Magic? Trial and error? Alan DeKok.
On 1/31/06, Alan DeKok <aland@ox.org> wrote:
=?ISO-8859-1?Q?Te=F3filo_Ruiz_Su=E1rez?= <teo@fon.es> wrote:
I'd like to declare two different secrets for my radius server listening on 0.0.0.0/0.
And it makes no sense. How does the server decide which secret to use? Magic? Trial and error?
Er.. can't you assign a unique secret for each client? Or am I misunderstanding his initial question?
Alan DeKok.
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
On Tue, 2006-01-31 at 14:54 -0500, Jason Frisvold wrote:
On 1/31/06, Alan DeKok <aland@ox.org> wrote:
=?ISO-8859-1?Q?Te=F3filo_Ruiz_Su=E1rez?= <teo@fon.es> wrote:
I'd like to declare two different secrets for my radius server listening on 0.0.0.0/0.
And it makes no sense. How does the server decide which secret to use? Magic? Trial and error?
Er.. can't you assign a unique secret for each client?
yes, but that requires defining each client more precisely than /0. For example x.x.x.x/32 and y.y.y.y/32.
Or am I misunderstanding his initial question?
His initial question seemed to imply belief that clients.conf determines what addresses radiusd binds to, I think that's where the misunderstanding is coming from. --ben
On 1/31/06, Benjamin Bennett <ben@psc.edu> wrote:
yes, but that requires defining each client more precisely than /0. For example x.x.x.x/32 and y.y.y.y/32.
*oh* Ok, gotcha.. That didn't dawn on me as I specify each client individually.. Just feels more secure that way..
His initial question seemed to imply belief that clients.conf determines what addresses radiusd binds to, I think that's where the misunderstanding is coming from.
Yep.. That sounds about right..
--ben
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
Jason Frisvold <xenophage0@gmail.com> wrote:
Or am I misunderstanding his initial question?
It looked to me like he was asking how to configure clients of 0.0.0.0/0, with two different shared secrets. He even gave examples of the config, which reference the "client" entry. Alan DeKok.
Alan DeKok wrote:
=?ISO-8859-1?Q?Te=F3filo_Ruiz_Su=E1rez?= <teo@fon.es> wrote:
I'd like to declare two different secrets for my radius server listening on 0.0.0.0/0.
No.
It's impossible.
And it makes no sense. How does the server decide which secret to use? Magic? Trial and error?
Whats wrong with trial and error?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
Joe Maimon <jmaimon@ttec.com> wrote:
Whats wrong with trial and error?
Yuck.
Probably.
It also opens the door to "any one of umpteen secrets".
I would like to know what the underlying requirements are, as there's probably a better way of doing this.
Dont know what his requirements are, but the ability to allow any client in the world to authenticate to my server with any one of X secrets, thereby allowing me to associate them to client Y as opposed to client Z is very usefull wherever the IP address range describing the source of client Y and client Z might overlap. The ip address range in question need not actually be 0/0..... This allows me to have specific configurations for this client, cancel service to only one of the "entities" and to upgrade/change the secret without requiring a flag-day event.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Joe Maimon <jmaimon@ttec.com> wrote:
Dont know what his requirements are, but the ability to allow any client in the world to authenticate to my server with any one of X secrets, thereby allowing me to associate them to client Y as opposed to client Z is very usefull wherever the IP address range describing the source of client Y and client Z might overlap.
Sure. But it's a fairly serious performance hit, and a bad idea from the security perspective.
This allows me to have specific configurations for this client, cancel service to only one of the "entities" and to upgrade/change the secret without requiring a flag-day event.
Hmm... that sounds like it's worth doing. The only problem is that this will really work only for packets that contain Message-Authenticator. Alan DeKok.
Hi, Joe Maimon escribió:
Alan DeKok wrote:
Joe Maimon <jmaimon@ttec.com> wrote:
Whats wrong with trial and error?
Yuck.
Probably.
It also opens the door to "any one of umpteen secrets".
I would like to know what the underlying requirements are, as there's probably a better way of doing this.
Dont know what his requirements are, but the ability to allow any client in the world to authenticate to my server with any one of X secrets, thereby allowing me to associate them to client Y as opposed to client Z is very usefull wherever the IP address range describing the source of client Y and client Z might overlap.
That's actually what I need, more than one secret for different phases of a deployment. That way I know how many clients of the first phase (ie secret) are authenticating, deactivate those clients, etc. Another solution, for the moment, is running an aditional freeradius server on one of the other IPs assigned to my box. Using the same MySQL database, if it's not a problem. Thank you in advance, -- Teófilo Ruiz FON - http://es.fon.com
participants (5)
-
Alan DeKok -
Benjamin Bennett -
Jason Frisvold -
Joe Maimon -
Teófilo Ruiz Suárez