Multiple incoming requests from unknown clients

[Diego Matute]

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.

Shared secrets are for client-server pairs hence you can have multiple
shared secrets.

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.

On Tue, Aug 14, 2012 at 10:16 AM, Alan DeKok <aland at deployingradius.com>wrote:

> Diego Matute wrote:
> > The only attributes passed to the server config are related to the
> > source IP address, which is not enough information to determine which
> > policy to apply.
>
>   I think you don't understand how RADIUS works.
>
>   Keying policies off of client IP is not always good.  Keying policies
> off of *unknown* client IPs is bad.
>
> > The use case is configuring FreeRADIUS to accept requests from unknown
> > clients with different policies. By different policies I mean different
> > authentication methods. I thought the secret key could be used to
> > differentiate the calls and apply the correct policy. Have I missed
> > something here?
>
>   Yes.  RADIUS doesn't work like that.  You're confused in your
> terminology.  There's no "secret key".  It's the "shared secret".
>
>   Precision matters.  If you ask for a cup of coffee when you really
> wanted a glass of water, you won't get what you want.
>
> > The domain names and potentially IP addresses clients use to configure
> > the target RADIUS server could differ.
>
>   RADIUS doesn't use domain names.  Domain names *cannot* be trusted.
> RADIUS uses source IP addresses.  And it doesn't even trust those.  The
> client still needs the shared secret.
>
> > However, in the backend there
> > would be a single server servicing requests. Not a big fan of this
> > approach. Another way would be requiring the client to configure
> > additional attributes to be passed down in the request. Also not a fan
> > of this approach.
>
>   All of your approaches are based on fundamental misunderstandings of
> how RADIUS works.
>
>   The client IPs have to be known.  The client IPs are used to select a
> shared secret.  The shared secret is used to verify that the packets
> aren't forged.
>
>   Once the server has decided that the packet is OK, the packet is
> proceses through the various policies.  These policies determine which
> databases are used, whether or not to proxy the request, what goes in
> the reply, etc.
>
>   That's how RADIUS works.  I have no idea what you are trying to do.
> From what little I understand, it's much more complicated than necessary.
>
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120814/8c599778/attachment.html>