allow WLAN-access in certain offices only

[radius.pkoch at dfgh.net]

Dear Alan DeKok,

Thanks for the quick reply

Am 20.04.2021 um 21:46 schrieb Alan DeKok - aland at deployingradius.com:
> On Apr 20, 2021, at 1:04 PM, radius.pkoch at dfgh.net wrote:
>> I have just compiled Freeradius from source and red some of the 
>> documentation.
>> WPA2-EAP works with username bob and password hello.
>> radiusd -X shows no errors.
>    That's good.
>
>> Now here's what I would like to achive and maybe some of you can point me
>> into the right direction:
>>
>> We have equipped all of our offices (approx 100) with seperate WLAN 
>> access points.
>> Every employee should be able to access the access point in its own 
>> office and
>> in some of our conference rooms. Every employee owns an OAuth token that
>> generates a 6digit one time password.
>    That's nice, but you really don't want to use OAuth with Wifi. I 
> don't even know how that would work.
>
>    i.e. WiFi is bad enough that devices end up re-authenticating 
> multiple times a day.  And you definitely don't want users to be asked 
> 5-10 times a day for a new one-time password.
>
>    Just use a password.  Or, use EAP-TLS and client certificates.

We are planning to use our time-based one time password OATH tokens just 
in the same way we are already doing this for IMAP authentication. When 
a user authenticates for the first time, he must generate a 6digit value 
with his token, append his own password to that value and use that 
combination. The IMAP server (and I was hoping the radius server could 
do as well) will send the password to our authentication server for 
validation.

We do not use OAuth.

Once a password was used successfully, the same value can be used again 
for a certain period of time that depends on the username. With our 
IMAP-server this period is 30 days, for a WiFi-guest account this would 
be 12 hours.

The passwords we generate with our OATH-token are not used as ONE time 
passwords. Hence they must be kept secret and must not be sent over the 
network in clear.

>> Whenever a user tries to access a WLAN access point with his username
>> and his one time password the following should happen:
>    Scratch all that.
>
>    First, you should figure out how WiFi works.  Then, figure out if 
> your suggested process fits into that.
>
>    If it doesn't, throw away your requirements about what "should 
> happen", and go with something which is realistic.

So here's what I figured out so far about how WiFi works:

- accesspoint is configured for WPA-Enterprise
- hence the supplicant is asked for a user / password combination or has 
to provide a client certificate
- the accesspoint receives additional informations from the supplicant 
(i.e. its mac-address)
- the accesspoint sends all the information it has received from the 
supplicant together with informations about itself to the radius server
- the radius server decides wether to allow or deny access and answers 
the request

In our case the radius server will get - among other informations - the 
username and password of the supplicant plus the IP-address of the 
accesspoint. This is all that is needed to decide wether the password is 
correct and wether the accesspoint is located within the office of the 
person with the given username.

But the radius server cannot do this decision on its own. It cannot 
verify the password but has to delegate that decision. And it cannot 
query our central oracle database on its own about what accesspoint has 
the given IP-address and wether this accesspoint is physically located 
in the office of the person with the given username.

I was hoping that the radius server could delegate this decisions to a 
script. And it seems to me, that there are (at least) the following two 
possibilities:

- use a php-script via rlm_exec

- use a perl-script via rlm_perl

I don't like the rlm_exec option since it seems to have security issues 
(password is visible within the environment of the process) and might be 
slow since for every authentication the php-interpreter has to be 
started and a new oracle-database connection has to be created. But this 
is the easiest way to go.

I don't like the rlm_perl option as well. I have never written a perl 
script, nor have I connected an oracle database from within a perl 
script. Performace would be a lot better since the perl-interpreter must 
not be started on every authentication. But it seems to me that maybe a 
database connection must be created on every authentication request. 
With oracle databases that is a lengthy process and takes more time than 
starting an interpreter.

>
>> 1) if the password is wrong access should be denied
>    So... password checking like normal.  But if this is for passwords 
> which change multiple times a day, then it just won't work.

see above - password is token generated but will not change until it expires

>
>> 2) if the access point is not located in the office of the employee 
>> or in one
>> of the conference rooms of the employees department access should be 
>> denied
>>
>>    So... check the source AP to see if it's allowed.  How do you 
>> check that?  Read the debug output to see what each AP sends, and 
>> then write rules to match those.
wether an accesspoint is allowed or not depends on the data within our 
central oracle database. If an employee moves to a new office (which 
happens a lot lately due to corona) our hotline changes the information 
within the oracle database. This should give the employee immediate 
access to the accesspoint in his new office without changing 
configuration data at additional places (neither manually nor 
automatically).
>> Our central oracle database has information about the ip-address and 
>> location
>> of every access point and the office rooms of every employee.
>    Location is irrelevant.  The only thing that matters is what's in 
> the RADIUS packets, and what's shown in the debug logs.
>
>    Does the term "Conference room 5" appear in the RADIUS packet? 
> No?   Then you'll have to figure out some other way which access point 
> is which.  Maybe by looking at host names (if they show up in the 
> RADIUS packet), or IP addresses (if they should up in the RADIUS 
> packet), or by MAC (well, you get the idea by now).


"Conference room 5" does not appear in the RADIUS packet but so does the 
IP-Adress of the accesspoint. And our central database has all the 
information that is needed to deduce the room number from that 
ip-address and wether the conference room belongs to the same department 
as the user.

>> My first idea was to write a php-script (because that's the scripting 
>> language
>> I'm familiar with) and use that via rlm_exec. I will do this as a 
>> proof of concept.
>    To do... what?  You haven't said.

see above. The idea was to let the script verify the password and 
compare the physical location of the accesspoint with the office of the 
user, based on the information that the script got from the radius 
packet (username, password, ip-address).

>> Since neither I nor any of my colleagues have perl-experience I'd 
>> rather write
>> a new module in C than use perl.
>>
>> Is there a module that will send all parameters to a unix or inet 
>> socket and
>> receives the results from that socket? How abount rlm_socket?
>    To do... what?
>
>    How is any token going to be checked?  REST API?  What?
>
>    Your last comments here are really "how do I write a script to do 
> stuff".  The only answer is "I dunno, it depends on what stuff you 
> want to do".

I'm not asking how a script should be written. This is our business and 
from Freeradiuses point of view it should make no difference wether the 
script uses a REST API to talk with our authentication server or connect 
an oracle database or do whatever is needed to allow or reject a request.

My current understanding is that freeradius will feed a list of 
key-value pairs into such a script and will receive at least a status 
and maybe additional key-value pairs.

Right now my plans are:

1: Create a php-script that will receive key-value data from Freeradius 
via evironment-variables and will return data via exit-code. This script 
has to create a database connection for every authentication request. 
This will be slow (approx 2 seconds) but my hope is, that Freeradius 
will start processes in parallel.

2: Create a perl-script with identical functionality. Maybe the first 
invocation of such a perl script can create a database connection that 
can be reused by future requests. That would improve performance. I have 
no idea wether Freeradiuses builtin perl-interpreter allows to store a 
database connection in a global variable and what happens if multiple 
invocations of such a perl sript are running in parallel.

Any feedback on these ideas is welcome.

Kind regard

Peter