allow WLAN-access in certain offices only

[Alan DeKok]

On Apr 21, 2021, at 7:38 AM, radius.pkoch at dfgh.net wrote:
> 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.

  Mostly.  It depends on a host of factors.

> 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.

  As I said, that's likely a poor WiFi experience.

> 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.

  Which protocols send passwords over the network in the clear?  Are you even sure you know what "in the clear" means?  I suspect it doesn't mean what you think it means.

  We've had people worried about using TTLS + PAP, because it sends passwords "in the clear".  This is despite the fact that TTLS uses TLS.  So the passwords are secured "on the wire".  Instead, all they see is PAP, and go "OMFG it's insecure!"

  Well, then logging into Google is insecure, because it *does* send passwords "in the clear" over an HTTPS connection.

> In our case the radius server will get - among other informations - the username and password of the supplicant

  Maybe.  It depends on how the supplicant is configured.

  Again, you *cannot* just say "I want to do X".  You *must* understand every bit of the process, down to supplicant configuration.  Otherwise you will be unpleasantly surprised.

  For background, see: http://deployingradius.com/documents/protocols/compatibility.html

  That page has been explaining WiFi security issues to people for ~16 years.  In many cases, the RADIUS server does NOT get a password.  So what you want to do may very well be impossible, unless you change the supplicant configuration.

> But the radius server cannot do this decision on its own. It cannot verify the password but has to delegate that decision.

  How?  That's what I was trying to get at when I asked "what does the script do".

  I don't mean that the answer should be "it delegates the decision to a script".  I mean "what does the script do?  What does it get as input?  What steps does it take?  What external systems does it check?  How does it check external systems?"

> 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.

  Why?  You later say that the script can query the Oracle database.  So why can't FreeRADIUS query the Oracle database directly?  The SQL module is capable of this.

> 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:

  Those are solutions.  You need a good problem statement first.

> 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).

  Why not write those rules in FreeRADIUS?  It will be simpler and faster.

> 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.

  You didn't understand my point.

  My point is that you need a *problem statement* before coming up with the solution.  As in "I want to take X from the RADIUS packet, use it to do an SQL query for Y, and then compare X and Y.  If they match, the user is allowed online".

  A large part of the contentious discussion on this list is people going "I want to know if I should use solution A or solution B", followed by me trying (in vain) to get them to explain what the underlying problem is.  They get upset that I'm not helping them, and I get annoyed that they're ignoring my explicit requests for more information.

  I don't ask for more information because I'm trying to waste your time.  I'm asking for more information because I need that information in order to help you.

  Replying with "I'm not asking how a script should be written. This is our business" is just unfriendly.  I'm not asking you how the script should be written.  I'm asking you "do you know what the script should do?". 

  If you can't answer that question, then a statement of "FreeRADIUS calls the script via exec or Perl" is just not helpful.

  If you have a good problem description, then I can suggest a good solution.  If you have just want to know "should I use exec or Perl", then I really can't help you.

  FreeRADIUS can do database queries.  FreeRADIUS can do comparisons.  FreeRADIUS can do if / then / else checks.

  The question for you is this:  Do you want our help to create a solution?  Or do you want to be told which of exec / Perl is better?

  Alan DeKok.