[RADIATOR] Authenticator check et calculation

[Tuure Vartiainen]

Hi,

> On 8 Mar 2019, at 18.00, Laurent Duru <laurent.duru at lugos.fr> wrote:
>  
> We faced an issue with wrong authenticator on answers sent by Radiator.
> In our design, client source IP is NATed, here is an example of radius.cfg client configuration for discussion :
>  
> <Client REAL_CLIENT_IP >
>         Secret azerty
>         Identifier CLIENT
> </Client>
>  
> <Client DEFAULT>
>         Secret qwerty
>         Identifier Default
> </Client>
>  
> REAL_CLIENT_IP is NATed to NAT_CLIENT_IP
>  
> When receiving Access Request with authenticator from NAT_CLIENT_IP, our radiator accepts the request and send an access-accept. That means the authenticator check is OK and that the usage of the secret “azerty is OK. I think radiator is checking client on NAS-IP-ADDRESS and not IP header address.

Radiator does not use NAS-IP-Address attribute for looking up a <Client> block.

Lookup is done using following:

1. Source IP address of RADIUS request
2. Called-Station-Id attribute (<Client MAC:...>)
3. DEFAULT Client (if configured)

RADIUS Access-Requests don’t have RADIUS authenticator for integrity protection, but 
for hiding attribute values such User-Password. Therefor mismatching shared secret 
causes User-Password value to be decoded incorrectly. Message-Authenticator attribute will 
be needed to protect the integrity of Access-Requests and to drop requests with a mismatching 
shared secret.

Refs:

https://www.open.com.au/radiator/ref/Clientxxxxxx.html#Clientxxxxxx

https://tools.ietf.org/html/rfc2865#page-15 

https://tools.ietf.org/html/rfc2869#section-5.14

>  
> When creating authenticator for the answer which IP is used ? and then is it “azerty” or “qwerty” that is used as secret ?
> To have a working config we had to add :
> <Client NAT_CLIENT_IP>
>         Secret azerty
>         Identifier CLIENT
> </Client>
>  
> Seems to mean radiator is using IP header address to calculate the answer and not NAS-IP-ADDRESS.
> 

When calculating a response authenticator, the same <Client> block and secret 
through which the request was received will be used. 


BR
-- 
Tuure Vartiainen <vartiait at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.