Migration -> FR3 + CiscoAPs + Multiple SSID+ EAP-TLS + Multiple Certs

[Alan DeKok]

On Nov 24, 2018, at 9:59 AM, Ted Hyde (RSI) <thyde at rndstudio.com> wrote:
> Currently I have a number of Cisco AP's in autonomous mode with mixed authentication - some local to the AP, but one SSID that is EAP-TLS. Other SSIDs are on other VLANs, but only the one VLAN/SSID has .1X involved. The clients have the certificate installed, and the system works. Of course that cert is not unique to any device, thus any device that has that cert can authenticate against that SSID. That is by design for this SSID and is intended to remain as such.

  It's not perfect, but OK.  It's easy to manage at least.

> I want to turn a separate "House" SSID that *was* strictly WPA2-PSK into one that is MAC auth based, so I don't have to worry about changing and re-issuing WPA passwords when one user has to be de-auth'd. However there are limitations on mixed config on the Cisco APs where PSK + MAC just doesn't work. (It makes sense that encryption + no encryption isn't a viable transaction concept, so I'm not too sad about it.)

  Ideally the AP would support MAC auth for anything, but some products just can't do it.

> I have been able to get MAC + EAP-TLS to work really well, so my concession is to use a cert in EAP-TLS along with the MAC restriction. I am fine with distributing a cert to the "house" users; in this instance, the cert provides the framework for encryption, the MAC list provides the authorization. This whole exercise isn't about making it easier to turn a specific user on or off, it's about how the other users are handled when that event occurs. In test right now, I can distribute the same certificate to any client, and tell them to associate against the house ssid (the non-restricted SSID is for a special purpose, not roaming users) and it works, because eap just runs regardless.

  That's a bit confusing, but OK.

> This sounds amazing at first go, however I need to retain that one SSID that has NO MAC restrictions alongside an SSID (same AP group of course) that DOES have MAC restrictions. With the ordering of auth's, if a client had the one certificate, but was de-auth'd from the house SSID, all they would have to figure out is to try and associate with the non-restricted SSID and they're back in (albeit on a different VLAN). This I know from testing. It is not the situation I am looking for.

  The solution is to block them from using the non-restricted SSID.  You can do this at the RADIUS server.

  This really is the hardest part about complex RADIUS configurations.  You can get the FreeRADIUS syntax correct with reading the docs, asking questions, etc.  But that's *how* to do things.  You need to know *what* to do.

  The solution then is to write down what you want to happen, and then implement it in the FreeRADIUS configuration.

> So my next trick would be to try and set up multiple EAP instances, with separate certificates and FR listening for some discerning data during the EAP request packet to limit which SSID can authenticate with which certificate.

  I don't think that's necessary.  You should just be able to list what you have and what you want:

* have: 2 SSIDs, one open, one MAC limited
* have: known machines which can go on to the MAC limited SSID
* have: known machines which are blocked from using the MAC limited SSID
* have: various other machines which are not tracked, but which are allowed on the open SSID

* want: known machines on the MAC limited SSID to be allowed to go there
* want: unknown machines on the open SSID to be allowed to go there
* want: known machines which are blocked from the MAC limited SSID to *also* be blocked from the open SSID
* want: unknown machines to be blocked from the MAC limited SSID

  I'll get to that below.

> Then it wouldn't matter if a deauth'd house client had the house-only certificate; it would/must fail if they try to associate with the non-restricted SSID. This is where I am lost. I followed a couple google'd options, and they all came down to the CSID containing the SSID or Vlan tag; that only happens if you are using a WLC apparently, where I am using autonomous APs. However, with an extra vsa option in my Cisco configs, I can get an AV-pair in the request such as from a "freeradius -X" debug output:
> 
> Called-Station-Id = "0021.d849.a671"
> Calling-Station-Id = "e458.b8d0.6455"    <----- note there is no suffixed SSID here (sad)
> Cisco-AVPair = "ssid=MIWIFI-HSE"         <----- a source of potential magic!
> Service-Type = Login-User
> Cisco-AVPair = "service-type=Login"      <----- but caution, an additional AV-pair tag here, so how to handle?
> 
> I have [hackingly] messed around with replicating eap instances inside mods-enabled/eap, as well as including the statements for Auth-Types in the default virtual server, but I then get lost on how to use the ssid=xxxx to make decisions for which module to use.
> 
> I am testing on baseline debian stretch with FR3 (3.0.12+dfsg-5+deb9u1) and text files (clients.conf and users) as data sources. Aside from mods-enabled/eap being modified to have multiple instances and sites-enabled/default to include multiple Auth-Types, all files are default.

  This is all very much a specific solution to something that *might* be a problem.  If the problem statement is wrong, then this solution is wrong.

  Why not just:

	if (MAC SSID) {
		look up MAC
		if !known MAC reject
		if blocked MAC reject

	} elsif (open SSID) {
		if blocked MAC reject
	}

  Does that sound reasonable?  If not, you need to describe your requirements a bit more clearly.

  Alan DeKok.