Reliably identify guest users/clients

[Nico Thomas]

On 03.07.2018 21:42, Alan DeKok wrote:
> On Jul 3, 2018, at 3:38 PM, Nico Thomas <nico.thomas at uni-konstanz.de> wrote:
>> I'm working on a module which allows a WiFi network host to dynamically accept
>> or deny guests when they login.
>> Therefore, known Cleartext-Passwords (or guest account data in general) are not
>> available when mod_authorize is called.
> 
>    It's possible to add passwords later in the authentication process.
> 
>> As my first idea of setting Auth-Type accept isn't possible in combination with
>> EAP, I'm currently using a predefined password independent from the user instead.
> 
>    If all of the users have the same password, then that's possible.
> 
>> Then, I try to identify known users later. This is necessary as the
>> Access-Requests are typically retransmitted faster than the network host can
>> decide whether to let a guest in or not.
> 
>    I'm not sure what that means.  What is being "retransmitted"?
> 
>    If your back-end database is taking ~5s to decide if a user is valid, then that needs to be fixed.  It should take ~10ms at most.

Maybe I was too unspecific. The guest network operator/host is notified 
when a guest signs in. The first Access-Request is denied and the module 
waits for feedback from the host in the background. On subsequent access 
requests, the guest is either accepted or denied depending on the feedback.

The idea behind that is to allow dynamic user management and easy 
joining for guests without the need of predefined accounts.
The fact that multiple requests are necessary is sort of a side-effect 
caused by the long host answer time, which is way longer than the ~10ms 
that you mentioned.

> 
>> At the moment, only Calling-Station-Id
>> and user name are used for identification, which I am not really happy with.
> 
>    Both can be spoofed, unfortunately.
> 
>> So my question is: Are there other attributes available to a module in addition
>> to the Calling-Station-Id, which could be used to identify a user/device
>> (besides credentials)?
> 
>    The only attributes you have are ones which appear in the debug log.  i.e. attributes sent by the WiFi access point.
> 
>    And any attributes which can identify the user can be spoofed by the user.  Which is why users have per-user passwords in the first place.
> 
>    Alan DeKok.

As I wanted to make joining for guests as simple as possible, I was 
looking for ways to avoid passwords (unfortunately, key-based 
authentication is not an option, as additional client set-up would be 
necessary).
I hoped to find some attributes which are hard to spoof, but already 
suspected that passwords would be the only reliable way to identify users...

So I'll think about a solution involving per-user passwords.

Thanks a lot for your quick reply!

Regards,
Nico