<font><font face="verdana,sans-serif">I guess I misunderstand why knowing the client IP matters, if the shared secret is passed isn't that enough. The IP address isn't secure either.</font></font><div><font><font face="verdana,sans-serif"><br>
</font></font></div><div><font><font face="verdana,sans-serif">Shared secrets are for client-server pairs hence you can have multiple shared secrets.</font></font></div><div><font><font face="verdana,sans-serif"><br></font></font></div>
<div><font><font face="verdana,sans-serif">What I am trying to do is enable multiple unknown clients to connect to a single server and be served off of different user stores.<br></font></font><br><div class="gmail_quote">
On Tue, Aug 14, 2012 at 10:16 AM, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com" target="_blank">aland@deployingradius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Diego Matute wrote:<br>
> The only attributes passed to the server config are related to the<br>
> source IP address, which is not enough information to determine which<br>
> policy to apply.<br>
<br>
</div>  I think you don't understand how RADIUS works.<br>
<br>
  Keying policies off of client IP is not always good.  Keying policies<br>
off of *unknown* client IPs is bad.<br>
<div class="im"><br>
> The use case is configuring FreeRADIUS to accept requests from unknown<br>
> clients with different policies. By different policies I mean different<br>
> authentication methods. I thought the secret key could be used to<br>
> differentiate the calls and apply the correct policy. Have I missed<br>
> something here?<br>
<br>
</div>  Yes.  RADIUS doesn't work like that.  You're confused in your<br>
terminology.  There's no "secret key".  It's the "shared secret".<br>
<br>
  Precision matters.  If you ask for a cup of coffee when you really<br>
wanted a glass of water, you won't get what you want.<br>
<div class="im"><br>
> The domain names and potentially IP addresses clients use to configure<br>
> the target RADIUS server could differ.<br>
<br>
</div>  RADIUS doesn't use domain names.  Domain names *cannot* be trusted.<br>
RADIUS uses source IP addresses.  And it doesn't even trust those.  The<br>
client still needs the shared secret.<br>
<div class="im"><br>
> However, in the backend there<br>
> would be a single server servicing requests. Not a big fan of this<br>
> approach. Another way would be requiring the client to configure<br>
> additional attributes to be passed down in the request. Also not a fan<br>
> of this approach.<br>
<br>
</div>  All of your approaches are based on fundamental misunderstandings of<br>
how RADIUS works.<br>
<br>
  The client IPs have to be known.  The client IPs are used to select a<br>
shared secret.  The shared secret is used to verify that the packets<br>
aren't forged.<br>
<br>
  Once the server has decided that the packet is OK, the packet is<br>
proceses through the various policies.  These policies determine which<br>
databases are used, whether or not to proxy the request, what goes in<br>
the reply, etc.<br>
<br>
  That's how RADIUS works.  I have no idea what you are trying to do.<br>
>From what little I understand, it's much more complicated than necessary.<br>
<div class="HOEnZb"><div class="h5"><br>
  Alan DeKok.<br>
-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_blank">http://www.freeradius.org/list/users.html</a><br>
</div></div></blockquote></div><br></div>