RADIUS non-supplicant re-auth

jmo

RADIUS non-supplicant re-auth

Post by jmo »

Hi all,

we're migrating an automatically configured secure environment (where only per-port authorized MAC addresses may communicate) from using on-switch-configured MAC lists (managed via SNMP) to using 802.1x / RADIUS (with LDAP as config store) where possible. Currently I'm testing different scenarios to verify possible operational processes. I'm using a 6450 with AOS 6.6.4 for tests, but will have various other Alcatel switch models to handle as well.

Currently, when central processes decide that a MAC address is no longer permitted on a specific port, that MAC address is removed from the port configuration. If for some reason the system is still active, the port is immediately shut down by the switch.

With 802.1x/RADIUS, I have noticed that changes in the LDAP directory will not reflect to the switch, since the switch doesn't send re-authentication requests to the RADIUS server at all, despite having set "802.1x s/p ... re-authperiod 240 reauthentication". I guess this setting only affects supplicants? (We'll have to act much quicker than any re-auth timer, but need a fail-safe against failing SNMP requests.)

A potential work-around would be to issue "802.1x s/p port-control force-unauthorized" followed by "802.1x s/p port-control auto", but this will interrupt traffic for all stations using that switch port, not only that single MAC address. Is there a way to "reset" the authorization status of a single non-supplicant/MAC?

Originally we started walking this path because of switch limits when creating MAC-to-port security relationships, and overloading the switch by SNMP requests for configuration updates and state monitoring. But it seems that port mobility, although recommended by Alcatel staff, does have sufficient own limits and still depends on plenty of SNMP communications in our use case :(

Regards,
Jens
silvio
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 2087
Joined: 01 Jul 2008 10:51
Location: Germany

Re: RADIUS non-supplicant re-auth

Post by silvio »

Hi Jens,
Currently, when central processes decide that a MAC address is no longer permitted on a specific port, that MAC address is removed from the port configuration. If for some reason the system is still active, the port is immediately shut down by the switch.
If I understand correctly you use non-supplicant-authentification against a radisu-server (no port-security for this goal). How did you remove the Mac than from the port? Delete in mac-table? did you have tested >802.1x re-authenticate x/x?

regards
Silvio
jmo

Re: RADIUS non-supplicant re-auth

Post by jmo »

Hi Silvio,
silvio wrote:Hi Jens,
Currently, when central processes decide that a MAC address is no longer permitted on a specific port, that MAC address is removed from the port configuration. If for some reason the system is still active, the port is immediately shut down by the switch.
If I understand correctly you use non-supplicant-authentification against a radisu-server (no port-security for this goal). How did you remove the Mac than from the port? Delete in mac-table?
sorry for the confusion - the quoted description describes the currently active system, which works with port security dynamically managed via SNMP.

We're trying to replace that system (at least in part) by RADIUS-based authentication.
silvio wrote: did you have tested >802.1x re-authenticate x/x?
Yes, I did test "802.1x re-authenticate x/x", but nothing was received by the RADIUS server. This makes me believe that reauthentication might only be implemented for supplicants.

Regards,
Jens
silvio
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 2087
Joined: 01 Jul 2008 10:51
Location: Germany

Re: RADIUS non-supplicant re-auth

Post by silvio »

in my opinion reauthentication means that I send a reauth-request to the client. But at mac-auth there is no authentication process between client and switch. So I think the onliest way will be deleting this mac in the mac-table (no mac-address-table xx:xx:xx...).
regards
Silvio
jmo

Re: RADIUS non-supplicant re-auth

Post by jmo »

Hi Silvio,
silvio wrote:in my opinion reauthentication means that I send a reauth-request to the client. But at mac-auth there is no authentication process between client and switch. So I think the onliest way will be deleting this mac in the mac-table (no mac-address-table xx:xx:xx...).
regards
Silvio
that's what I feared - I'm trying to get away from all these SNMP commands towards the switch, as we found out that the switches don't take them too well, at least not when we're sending many of 'em.

No option for re-auth for non-supplicant is IMO a design flaw that I'll report to Alcatel - while the client will of course not "expire" (i.e. it's certificate aging out), the authorization for the device may well be revoked since last "login". Which is just what we're trying to handle: Disabling a non-supplicant device no longer permitted where it currently is connected. Having to mess with the mac-address-table of the port seems a bit... strange.

Regards,
Jens
silvio
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 2087
Joined: 01 Jul 2008 10:51
Location: Germany

Re: RADIUS non-supplicant re-auth

Post by silvio »

Hi Jens,
if you have a answer from Alcatel please let us know.... Maybe there is a chance/workaround. Or they will create a new command :)
thanks and regards
Silvio
jmo

Re: RADIUS non-supplicant re-auth

Post by jmo »

Hi Silvio,

sometimes things hide in the open... shame on me I didn't remember: The most straight-forward approach is to use "change of authority" (RFC 5176).

Regards,
Jens
silvio
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 2087
Joined: 01 Jul 2008 10:51
Location: Germany

Re: RADIUS non-supplicant re-auth

Post by silvio »

So me... CoA I do also associate with 802.1x - but it is also for Mac-auth. Has you tested it? What server did you use for it? Official only ClearPass is supported.
regards
Silvio
jmo

Re: RADIUS non-supplicant re-auth

Post by jmo »

Hi Silvio,
silvio wrote:So me... CoA I do also associate with 802.1x - but it is also for Mac-auth. Has you tested it? What server did you use for it? Official only ClearPass is supported.
we'll be running our own client against the AOS implementation (actually we're running a distributed management engine, AKA "server", in every location), which will receive the session information from a FreeRADIUS back-end upon login.

But first we'll have a meeting with the Alcatel folks who recommended using this, discussing the details - I will have to know if all the switch types / AOS versions in this environment will actually support RFC 3576 and how we need to set up the listener in the switch (i.e. security).

Regards,
Jens
jmo

Re: RADIUS non-supplicant re-auth

Post by jmo »

Hi Silvio,

some interim update: I've run first tests of CoA (or rather the according "disconnect" message) sending them to my test switch (6450) via Freeradius' radclient. So we're not using some server (not even "radiusd"), but rather throw properly formatted packets at the switch directly.

It does basically work - but there are a number of open issues where we're looking for details on how to configure and what to expect, rather than reverse-engineering that info by issuing request after request and analyzing resulting switch behavior.

All it takes is the MAC address you'd like to disconnect, plus the proper password to authenticate against the switch. We've had difficulties originating the requests from different machines, though. Once I have it figured out sufficiently, I'll report back.

What I can say for sure is that the current implementation violates RFC 5176:

--- cut here ---
The combination of NAS and session identification attributes included in a CoA-Request or Disconnect-Request packet MUST match at least one session in order for a Request to be successful; otherwise a Disconnect-NAK or CoA-NAK MUST be sent.
--- cut here ---

During my tests I noticed that the session id attribute can be given with invalid values (not matching the session id reported during the RADIUS accounting messages - I set it to "dummy") but we'll still see the station disconnected and receive an according Disconnect-ACK packet. But what's new? :D

Regards,
Jens
Post Reply

Return to “OmniSwitch 6450”