faucetsdn
RADIUS integration
Chewie currently has hardcoded credentials.
Let's add the ability to do a RADIUS lookup at auth time
Criteria
- Unit tests where possible
- An integration test harness (currently there's deploy_test.sh to fire up chewie, deploy_wpasupplicant.sh to deploy a client, we should add a deploy_radius.sh to deploy a radius container that we can test against)
- A test case (not necessarily automated) that shows wpasupplicant authing against chewie and succeeding/failing based on a radius lookup
PR #8 adds some parsing/packing/validation for RADIUS packets.
The next step would be to go from EAP -> RADIUS and vice versa. So what I'm thinking is:
- Add two threads for sending/receiving RADIUS packets (similar to the EAP ones).
- Modify StateMachine to include EAP <-> RADIUS transitions.
Is this a correct understanding of the current implementation?
- Only one StateMachine is created.
- At the moment only one supplicant can authenticate, if we want more we'd need to add code to allow that. Perhaps a State Machine per supplicant. Or could we modify the state machine to know the 'state' just from the packet (not sure if that'd work)?
Would it be worthwhile implementing a RFC4137 state machine?
Do we want to be able to run in both 'standalone' and 'pass-through' modes or just pass-through?
based on the test harness it looks like we have a working radius integration, well done!
what steps do we need to take to get this deployed on a real network on real hardware? are there features that we're missing? is there a minimal and highly specific radius config we can get this interoperating with?
also please add your name to the AUTHORS file when you get a chance, you've contributed some good code and should be proud of it.
AFAIK, What we currently have could be usable in the real world (there are things missing).
Over on docs.faucet I have a small list. A couple have been implemented.
- RADIUS Accounting.
- Port status changes do not affect the authentication status. PR 2632
- Multiple RADIUS Servers.
- Other EAP types. E.g. TLS, … (TLS in master - version bump chewie)
- Dynamic assignment of VLAN/ACL.
The FreeRADIUS docker container Dockerfile.freeradius and the non default configuration files in chewie/etc/freeradius/ should be a good starting point for most people. (It's basically the default FreeRADIUS config + what the user needs to set, e.g. users and RADIUS client).
I'll look into trying to swap the RADIUS server to Cisco's ISE to see how it behaves - but no guarantees I'll be allowed.
Over on faucet pr 2613, has a change required for running on Cisco hardware (not required on AT x510). With both hardware the 1X tests themselves pass, but there is a lot of failures in other tests. Master branch (without my changes) also fails so suspect it is something wrong with the setup/configuration.
How many of these can we live without for the first real deployment? Put differently, what is the simplest lab we can set up?
It could look something like the following:
- one client port
- one client MAC
- one radius server
- one supported switch
- hardcodes VLAN (chewie merely enables the porr, nothing more)
This lets us focus on the first problem - having at least one 802.1x controlled port.
Once we get that working on real hardware, we have multiple steps forward:
- multiple ports
- VLAN set by RADIUS server
- additional switch vendor support (provides someone is going to testbed this)
After this it's a case of getting it into production - what features are a must-have for this? Is everyone using TTLS, or able to use that? Let's stick with the one option for now until we find it's preventing us from deploying further. Is radius accounting a must-have for day one? Perhaps it's something the users want, so we should consider this as a feature for day two.
Chewie won't be successful because of a long list of features on paper, but rather because of a long list of organisations who are using it in production. Let's get your code passing real packets on a real network, and then figure out the next steps after that.
On Wed, 14 Nov 2018, 09:51 Michael Baird <[email protected] wrote:
Over on faucet pr 2613 https://github.com/faucetsdn/faucet/pull/2613, has a change required for running on Cisco hardware (not required on AT x510). With both hardware the 1X tests themselves pass, but there is a lot of failures in other tests. Master branch (without my changes) also fails so suspect it is something wrong with the setup/configuration.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/faucetsdn/chewie/issues/3#issuecomment-438431912, or mute the thread https://github.com/notifications/unsubscribe-auth/ABaaP0sSoJkEtMWUHADPe9mXYD4B2FA7ks5uuzC-gaJpZM4UaEOp .