search

faucetsdn / chewie

A python 802.1x daemon
Apache License 2.0
17 stars 17 forks source link

RADIUS integration #3

Open samrussell opened 6 years ago

samrussell commented 6 years ago

Chewie currently has hardcoded credentials.

Let's add the ability to do a RADIUS lookup at auth time

Criteria

Bairdo commented 6 years ago

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:

Is this a correct understanding of the current implementation?

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?

samrussell commented 5 years ago

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?

samrussell commented 5 years ago

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.

Bairdo commented 5 years ago

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.

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.

Bairdo commented 5 years ago

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.

samrussell commented 5 years ago

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:

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:

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 <notifications@github.com 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 .