Multiple incoming requests from unknown clients

[Alan DeKok]

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.