Conditional EAP Type Acceptance

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

Conditional EAP Type Acceptance

Mike DiBella
I have FR set up to authenticate based EAP-TLS certificate and authorize based on finding an object in LDAP where Calling-Station-Id from the supplicant is equal to an attribute containing the WLAN MAC address, and an additional compliance attribute is equal to zero.    This allows me to only accept requests from managed devices that are policy compliant.

Now I need to add a way to accept requests from guest devices.

So I would need to break the LDAP check into two parts.   First, if an object exists where the MAC attribute matches the request Calling-Station-Id , authenticate by EAP-TLS.   If authenticated, accept the request if the compliance attribute is zero.

If the MAC address is not found, authenticate using PEAP.   Accept on credential match.    I only need a few guest accounts, so I'd load them in a simple store.   Which backend would be most suited for the PEAP accounts?      I'd want to be able to rotate the guest account passwords periodically without much fuss.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Conditional EAP Type Acceptance

Alan DeKok-2
On Nov 24, 2019, at 8:00 PM, Mike DiBella <[hidden email]> wrote:
>
> I have FR set up to authenticate based EAP-TLS certificate and authorize based on finding an object in LDAP where Calling-Station-Id from the supplicant is equal to an attribute containing the WLAN MAC address, and an additional compliance attribute is equal to zero.    This allows me to only accept requests from managed devices that are policy compliant.

  That's good.

> Now I need to add a way to accept requests from guest devices.
>
> So I would need to break the LDAP check into two parts.   First, if an object exists where the MAC attribute matches the request Calling-Station-Id , authenticate by EAP-TLS.   If authenticated, accept the request if the compliance attribute is zero.
>
> If the MAC address is not found, authenticate using PEAP.

  Except you don't control which authentication method is used.  The supplicant (client side) chooses that.

  Further, if you don't issue client certificates for guests, then they can't choose EAP-TLS.

  And, if you don't issue passwords for normal users, they can't choose PEAP.  Well, they can, but they can't authenticate because they don't have a password.

  So what you really need to do is for EAP-TLS, check that the MAC attribute matches the Calling-Station-Id.  And that's about it.  Which is what you already have.

>   Accept on credential match.    I only need a few guest accounts, so I'd load them in a simple store.   Which backend would be most suited for the PEAP accounts?      I'd want to be able to rotate the guest account passwords periodically without much fuss.

  Anything that makes you happy.  Even a simple text file is fine.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Conditional EAP Type Acceptance

Mike DiBella
In reply to this post by Mike DiBella
The vulnerability I'm trying to control is the gap where unmanaged devices are converted to managed devices between guest account password rotations.

The supplicants on these devices have already made the guest account credentials part of the saved preferred network information.  MDM cannot erase that, only the user can "forget" the network on the device itself.   When these devices enroll in MDM, they will receive the certificate for EAP-TLS, but the device can continue to use the saved guest credentials until the password is rotated, subverting the compliance check.

Rejecting PEAP authentication when the device is found in the managed device directory will encourage users of these devices to "forget" the network and use the certificate instead.

----------------------

> So I would need to break the LDAP check into two parts.   First, if an object exists where the MAC attribute matches the request Calling-Station-Id , authenticate by EAP-TLS.   If authenticated, accept the request if the compliance attribute is zero.
>
> If the MAC address is not found, authenticate using PEAP.

  Except you don't control which authentication method is used.  The supplicant (client side) chooses that.

  Further, if you don't issue client certificates for guests, then they can't choose EAP-TLS.

  And, if you don't issue passwords for normal users, they can't choose PEAP.  Well, they can, but they can't authenticate because they don't have a password.

  So what you really need to do is for EAP-TLS, check that the MAC attribute matches the Calling-Station-Id.  And that's about it.  Which is what you already have.




-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Conditional EAP Type Acceptance

Alan DeKok-2
On Nov 26, 2019, at 1:58 PM, Mike DiBella <[hidden email]> wrote:
>
> The vulnerability I'm trying to control is the gap where unmanaged devices are converted to managed devices between guest account password rotations.
>
> The supplicants on these devices have already made the guest account credentials part of the saved preferred network information.  MDM cannot erase that, only the user can "forget" the network on the device itself.   When these devices enroll in MDM, they will receive the certificate for EAP-TLS, but the device can continue to use the saved guest credentials until the password is rotated, subverting the compliance check.
>
> Rejecting PEAP authentication when the device is found in the managed device directory will encourage users of these devices to "forget" the network and use the certificate instead.

  Then you can add something in the "post-auth" section:

        if (users mac address was found && EAP-Type == PEAP) {
                reject
        }

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html