0

I don't know if this idea is non-sense but I was wondering if it was possible. I have a FreeRadius server backed by a LDAP server with uses EAP-TTLS (that is, username+password) to authenticate. So when users connect to a 802.1x switch, they are granted to access by querying username+password's supplicant connection with the ones are in LDAP server. This part is ok.

But what I want is, once this user has been granted, to distinguish between "regular" users and "admin" users by a client certificate which will have been referenced as a attribute by the LDAP server to be downloaded from any suitable place (a NFS server, for instance) but only if that user is of type "admin". Then, that client certificate would be used (I don't know how, that's the question) to ask access to another FreeRadius server, which would use the EAP-TLS method in this case so the "admin" users would be granted to another part of the network (where there would be another kind of sensible servers) while the "regular" users wouldn't.

In summary: I want to have a FreeRadius server to grant access users to a first "view" of the lan and also another FreeRadius server (proxied by the former?) that would give access to another "more secret" zone on the lan depending on the user. Is this possible?

Thanks a lot!!

2
  • This makes no sense. The strength os chained authentication is determined by the weakiest authentication method in the chain. That is, second authentication process (CBA) does not provide any additional security and is equals to username/password security level. – Crypt32 Oct 27 '19 at 9:40
  • 1
    I disagree. The op is essentially describing an out-of-band credential provisioning mechanism, which would reduce the potential for exposure of the initial credentials (username/password) used for bootstrapping. – Arran Cudbard-Bell Oct 28 '19 at 2:02
1

In a perfect world you'd do what you're describing using an EAP method like TEAP which supports in-band provisioning of credentials (like X509 certificates). Unfortunately, EAP-TEAP and its predecessor EAP-FAST haven't seen widespread implementation.

I know you were just using this as an example, but I definitely wouldn't use NFS. Even if NFS was supported on the supplicant host, manual configuration would be required. I'd say HTTP(S) is the more obvious choice for getting access to the certificates, given its widespread support, and user familiarity.

Trying to create some kind of post-authentication provisioning mechanism is going to be quite difficult. It's fairly trivial to identify an administrator logging in with credentials and assign them a VLAN which provides access only to a walled garden (where they can download their admin cert). The issue is walled gardens themselves are becoming increasingly problematic.

More websites are switching to 'secure by default' which means the initial connection attempt a user makes is likely to be over https. It's not possible to redirect/rewrite https traffic in the same way as http traffic, so it's difficult to direct users to the walled garden's landing page in a seamless way. If you did want to try a walled garden you'd need to verify it worked correctly for wired connections on your target OS(s).

Regarding using different RADIUS servers for the different EAP methods, that's not necessary. EAP provides a mechanism for method negotiation. The same EAP module in FreeRADIUS can run EAP-TTLS or EAP-TLS. If the EAP module requests EAP-TLS by default, and the supplicant has a certificate available and has EAP-TLS configured, then EAP-TLS will run, otherwise the supplicant will negotiate EAP-TTLS and and EAP-TTLS Will run instead.

Honestly though, provisioning credentials after initial authentication just seems like a nightmare for the helpdesk. Even if an administrator manages to access, download, and import their certificate, they'd need to manually reconfigure their supplicant to make use of it.

If I were implementing this I'd ditch username/password based authentication entirely, and instead use one of the dissolvable installers offered by cloudpath (now Ruckus) and others. These temporary applications can provision user certs and configure security profiles for network interfaces as part of the same operation. You'd offer the dissolvable installer via a public website, and point users to it during onboarding.

All users would have a similar onboarding experience, but administrators could be provisioned with a certificate that identified them as such, either via a special OID, or using a different intermediary CA.

2
  • Thanks a lot for your so clear explanation!!! Thanks! – Osqui Oct 28 '19 at 13:20
  • 1
    No problem! Just to mention with Hotspot 2.0 there is a mechanism for onboarding users via a special SSID. I believe the SSID and the landing page are either broadcast in beacon frames, or are available via ANQP. Didn't mention it in the answer because you stated wired 802.1X, but mentioning it now in case the network media is flexible. – Arran Cudbard-Bell Oct 28 '19 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.